Lock-in is frequently presented as an evil thing, to be avoided at all costs.
The reality is a bit more nuanced: if you're working in enterprise IT, some degree of lock-in is inevitable -- there will always be switching costs involved. For experienced practitioners, it's just one more aspect of a complex equation to be managed and optimized.
Like most aspects of enterprise IT, I've given the topic considerable thought, as I'm sure others have done.
When I was at EMC, lock-in was a huge customer concern. At VMware, paradoxically it didn't come up all that much. And now that I'm in Oracle, I'm back in the middle of lock-in debates.
So lets' get started, shall we?
My Theory Of Enterprise IT
To the people who pay the bills, enterprise IT is essentially a black box: money goes in, services come out. Success can be measured by reducing the money that goes in, improving the quality of services produced, or a combination of both.
Alternatively: IT is more about the "I", and less about the "T".
To deliver these services, enterprise IT groups build and operate one or more 'architectures' (combinations of technology and process) that support the applications that deliver the services. To build an architecture, you make very complex and nuanced decisions about what you select.
This is where the notion of reducing lock-in comes into play; the idea that certain technologies have reduced switching costs, making them inherently more attractive as architectural choices.
An example of a technology with low switching costs might be Linux -- there are multiple distros from multiple providers with a great degree of compatibility. An example of a technology with much higher switching costs might be an enterprise network, even though they are built from ostensibly industry standards.
Pay Now, Or Pay Later?
An over-emphasis on reducing *potential* switching costs down the road can get in the way of the immediate mission at hand: quality services at attractive costs. Put differently, if a given technology is better/faster/cheaper/more secure than other alternatives, but it also entails the potential of somewhat higher switching costs in several years, what to do?
Since you're basically hedging against a potential risk in the future, most reasonable folks would make sure they have an idea of what a Plan B would entail, and go with option with the more immediate payoff.
Operational Switching Costs
Many people tend to focus on the technology switching costs, and perhaps don't fully appreciate the true nature of operational switching costs.
Let's say you bring some technology in. You train your people. You migrate to the new thing. You integrate it with everything else it needs to talk to. You set up a cadence with the vendor: procurement, support, upgrades, etc. You go through inevitable growing pains.
It's a lot, isn't it? And all of this has very little to do with the specific technology being discussed, does it?
Add it all up, and operational switching costs can easily outweigh any technology concerns.
An all-too-frequent story: you meet certain enterprises that have invested in automating the heck out of their infrastructure operations. Good for them. But to do so, they had to write to vendor-specific APIs to get what they needed. Ruh-roh.
As a result, they now realize they're locked in from choosing alternative infrastructure components as the effort associated with re-establishing the automation environment is so daunting that they end up buying more of what they have, even though they realize there are better alternatives out there.
Well, it sounded like a good idea at the time :)
Perceptions Don't Always Align With Reality
It's not uncommon to meet enterprise shops who are "all in" on vSphere and associated components. From an outsiders' perspective, you see the potential for extremely high switching costs should an alternative be required, but -- for some reason -- this doesn't seem to be a concern for most.
Maybe they feel there's safety in numbers? I really can't explain it. The same is largely true for x86 architectures now that AMD is no longer a viable alternative for many.
It also can go the other way.
Now that I'm at Oracle working on infrastructure, I hear the "lock in" thing all the time. The reality is that Oracle software runs on just about anything and everything. Switching costs are comparatively low -- it's relatively easy to move an Oracle database from place A to place B should the need present itself.
Granted, that Oracle database runs better/faster/cheaper/more securely on Oracle infrastructure, but I would describe that as optimization. More bang for your infrastructure buck isn't lock-in, folks.
The Evolved Perspective
I buy a car, or a house, or get married, or have kids, change jobs, etc. -- I'm essentially locked in for a while. Switching costs can be high indeed.
Life would be worse if I avoided those commitments.
Lock-in (or perceptions thereof!) isn't inherently good or bad; it's just another factor in the Big Enterprise IT Equation. At a high level, it's three factors: switching costs in their entirety, combined with the likelihood you'll need to switch, amortized over the time horizon of your decision.
Every moderately-sophisticated enterprise IT environment has lock-in everywhere: it's the natural result of people making pragmatic decisions around architecture and operations.
All things being equal, should lock-in be minimized? Perhaps.
But don't forget you're part of the black box of enterprise IT, and results matter to the folks paying for it.
Like this post? Why not subscribe via email?