Vendor lock-in is either a key technology problem or an overhyped marketing missile depending on the point of view. I think there's a definition problem at the heart of the agita over in the issue. John Dewey remarked, "A problem well put is half-solved," so I aim to reframe the question while trying to avoid bikeshedding.
The heart of vendor lock-in is the obscene nature of the problem, by which I mean "I know it when I see it" a la Potter Stewart's famous opinion on obscenity laws. You can almost hear the start of a Jeff Foxworthy routine...
You might have vendor lock-in if:
- com.ibm.websphere is in your Java classpath
- You've ever used Windows
- You've ever had to buy a special dongle to run the software you just bought
- You've used license management software
So what are the keys to vendor lock-in and how does it differ from mere friction?
Lock-in only comes into play when you attempt to exit the tool you are currently using. If I lock you into your house, you will only realize it when you attempt to leave. If I've used a Locks-R-Us doorknob lock, turning the knob opens the door. Not a whole lot of lock-in. But if I use a SuperLock9000 RFID deadbolt lock with no keyhole and you don't have a keycard, that's a whole new level. Getting your data (which is what we all really care about) out of the tool is when you notice vendor lock-in.
This seems fairly straightforward, so where does the controversy come in? The basic premise is that even when designed for it, data portability isn't easy. Just like a body at rest, data has inertia and moving it requires differing amounts of effort. Some systems just require more effort to exit. Data is only a component of our overall application landscape. We have to look past the keystone and see the rest of the arch when we talk about re-platforming or redeveloping an application.
Both of these are reasonable positions, so how do we reconcile the two? I say we are actually talking about characteristics of a second concept: technical debt.
Technical Debt
Introduced by Ward Cunningham and expanded by Steve McConnell, technical debt is a metaphor for programming shortcuts that mirror financial debt. We all know about financial debt: you spend someone else's money with the promise that you will pay them back with a bit more on top. Servicing the debt is the fancy terminology for paying back the principal and interest. For our metaphor, taking a short cut that delivers now, but increases maintenance, incurs technical debt in a project. You have to re-factor the short cut (pay principal) and deal with daily maintenance issues until you've done so (pay interest).
Cunningham and McConnell both stop at the choices made by developers when coding. I want to extend the metaphor to all technology choices made, not just those made by application developers writing apps. The choice of operating system, development frameworks, database system, hosting environment and network infrastructure all have the potential for incurring technical debt. If you search for 'vendor lock-in', you will see stories from all tech sectors talking about people who would love to move to shiny new “Solution X” if only they hadn't heavily invested in “Solution B” so many years ago. The very idea of a legacy system is one that is weighed down by its technical debt to the point that no new functionality can be added. But it must be maintained as a critical component and data source.
With the potential for technical debt at every level of a solution, we have to expand McConnell's list of types of debt to include unintentional debt incurred by tool choices. This is where technical debt leaves the realm of "friction" and enters vendor lock-in. I say that the "friction" argument really indicates the overall technical debt of a system that increases over time as a function of entropy of any system. All software is in flux at all times as bugs are introduced and patched. The act of patching introduces entropy to the application. Any end user application is really a stack of other applications (operating systems, firmware, application frameworks, language interpreters, turtles all the way down) so there is entropy added from all directions.
Enter the Vendor
So the choice of a proprietary UNIX versus an open source GNU/Linux system introduces technical debt of a specific kind. Each dictates hardware requirements, infrastructure software availability, application tooling availability, and more. The proprietary UNIX choice increases the technical debt of the overall system by limiting the sources of those direly needed resources. A GNU/Linux based environment provides more options at the operating system and hardware levels, and the open source nature also makes for easier transitions. There is still a level of debt incurred by the GNU/Linux choice, but it is far lower than the proprietary UNIX choice. And since the proprietary UNIX solution is only available from a single outlet, that is vendor lock-in.
Framed around technical debt, vendor lock-in and platform friction are two sides of the same coin. Vendor lock-in is debt introduced by the simple act of selecting their tools or using their extensions. Vendor lock-in is technical debt that is likely not accounted for in the overall planning for exit costs. Even if your dev team fully understands and accounts for technical debt, they probably aren't looking at the frameworks and tooling they use; only their own practices and shortcuts. But the use of a specific Java class from a middleware vendor is just as much unintended technical debt if all the pros and cons of that call are not accounted for. There is, of course, the argument that these vendor hooks are specifically designed to create lock-in (remember the Halloween documents and 'Embrace, extend, extinguish'?).
What do you think about technical debt and lock-in? We are building the legacy apps of tomorrow, today. Thinking about sunset planning and replacements now can make technical debt a manageable expense in your future. Ensuring you look at all sources of potential debt early will allow you to avoid a big balloon payment at the end of service.
Image courtesy of SXC.HU
Related Blog Posts
