One of the red-meat topics in IT guaranteed to spark a debate is the topic of "lock in", e.g. the difficulty in moving away from a given technology should the desire present itself.
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
At a high level, enterprise IT groups exist to deliver information services to the businesses that need them.
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.
One consideration among many is switching costs -- which might be important if your choices don't work out down the road.
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
My previous employer, VMware, is an interesting study on how 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 do admit I get a bit annoyed when someone throws out the simplistic red-meat argument that "lock-in is evil". In reality, it's just a fact of life that has to be managed.
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?
Usually I have been on the team asking people to switch to our technology - from paper, Excel, home-grown tools with Access databases, more complex homegrown tools and customized off-the shelf products.
A tongue in cheek estimate of the probability of getting an organization to switch:
Probability of switching = p / ( n^2 * T^4 * A)
p: pain that will be relieved in total number of headaches per month (one migraine equals a 100 headaches)
n: number of people who need to make the switch
T: number of IT people involved in the decision
A: Avogadro's number
Note the wonderful example of Direct Current - the last direct current ConEd customer was transitioned in 2007 and even that by placing a rectifier on-site past the meter.
Posted by: Sukh | October 21, 2015 at 12:32 PM
Hah! That's brilliant. Thanks for sharing!!
Posted by: Chuck Hollis | October 21, 2015 at 10:38 PM