Over a million developers have joined DZone.

Vendor Lock-in: Everyone is Complicit, no One is a Victim

DZone's Guide to

Vendor Lock-in: Everyone is Complicit, no One is a Victim

· Java Zone ·
Free Resource

Atomist automates your software deliver experience. It's how modern teams deliver modern software.

Twilight-Sparkle-my-little-pony-friendship-is-magic-20571945-570-402In my last post on vendor lock-in, I suggested that the dominant contributor is software. But that's not to say that it is the only contributor. In this lock-in game, vendors and customers are both complicit.

If you have ever worked for a large company or even a growing company, chances are that these three letters send chills down your spine: ERP. Enterprise Resource Planning is the generic name for the major products offered by Oracle, SAP, and others. As your company grows, at some point your company will need to go through an ERP upgrade. 

The way these upgrades work is somewhat fascinating. The first thing you do as a company is appoint some executive as the sponsor. Be warned – these projects fail something like 4 out of 5 times (ultimately requiring a second run at it). The exec sponsor brings in DeLoitte or Accenture or PRTM or Infosys. Analysts run amok for several months, interviewing, assessing, and ultimately reporting. Then there is some evaluation of Oracle and SAP before the exec sponsor recommends to the CEO and CFO that they spend $60M over 3 years to get this thing done.

It's a piece of software. Sure, it's a BIG piece of software, but how does this cost $60M and 3 years?

The answer is that this is one of the most customized pieces of software on the planet. It has to plug into just about every tool and process in the company. Strategic planning, business planning, resource planning, budgeting, manufacturing, you name it – they are all involved. And rather than make the functions change how they work, almost every company decides they want the software customized to match their existing workflows. Never mind that it never works quite right, even if it did, it is a hugely costly task.

As the company grows more (or even as the ERP software just needs updating), you can guess what the process looks like. This level of customization is like crack – once you get hooked, you cannot get off the stuff. And by the way, once you are hooked, you are never changing vendors. That $60M looks cheap compared to what you are in for next.

An interesting aside – though I will never find the link, when we were going through this hell at Juniper, one of the change management specialists talked about how Apple was going with an out-of-box experience with SAP. They were doing away with customization precisely because of all the pain it caused and because it prevented them from putting price pressure on their ERP vendors (lock-in can be a powerful way to make sure your discounts go away).

The point of this story is that the software vendors (Oracle and SAP in this case) will happily give you the customization you want. They will make every field special to just you. Because they know that once you have tailored your surrounding systems and processes to their products, you aren't ever leaving them. 

Networking is not that different. Every networking vendor's roadmap is littered with one-off requests. At Juniper, we called these Feature Velocity requests. No account team can get enough of them, every customer deal hinges on one or two of these. They are generally knobs, tweaks, subtle changes in behavior. They aren't typically huge new technologies. But every time you deploy one of these little tweaks and build your operational processes around it, you get a little more sucked into vendor lock-in.

Think about it this way: lock-in basically means that there is no other device that is a functional equivalent. That is to say that you cannot swap one vendor's gear for another because it won't operate the same way in your environment. The tricky part is that it is not a single feature that is the culprit; it is the combinatorial effect of whatever features you have collectively deployed. You can likely find multiple vendors that support (or are capable of supporting) a particular feature, but you need to find a vendor that supports the exact combination of features you are relying on. The superset problem limits your choices to a small number (maybe just one) of vendors.

There are two things, though, that help mitigate this.

First, when companies like Cumulus come out, they are an immensely powerful force on the industry. It's not that their products are any better or worse, but what Cumulus is doing is building software that represents the minimum set of technologies required. They don't have a fully featured software product; they have identified the most important features. As they are successful, they help solidify an industry definition of what is actually required to call something a switch. This is great for everyone who does not already support the superset of features, because it focuses buying and deployment behavior on a smaller set of must-haves.

Second, I don't want to suggest that everything becomes a Lowest Common Denominator problem. That would be insane. If you had to wait until all vendors supported a new technology before you could deploy any technology, you would never move forward. But you have to be aware and make eyes-wide-open decisions. If a capability drives enough value, then absolutely deploy it. If it just a convenience, maybe think twice lest you get locked in.

Ultimately, the decision for customers is what role they want to play in locking themselves in. Every technology decision has to be weighed against the short and long-term impacts. As a rule of thumb, though, there are a couple of things to look for:

  • When a new technology is patent protected, you are likely locking yourself in for good. When it is the law and not development that keeps other companies from offering functional equivalents, run away. 
  • When a new technology is ubiquitously talked about, don't fret. For technologies that the entire industry is adopting en masse, there will be long-term substitutes. While it might not pop up on a particular roadmap for a couple of months or even a year or two, it will eventually get there, and that should be enough to allow you to move forward. You aren't going to swap all that gear out in the first 18 months anyway, so don't worry about short term feature disparities.
  • When a new technology is not in a company's best interest, be very wary. If a feature or capability seems to fly counter to how a company competes, it is a good bet that they will drag their heels on supporting it. A company that has higher-margin products with one solution will be hard-pressed to openly adopt a lower-margin alternative (unless it leads to significant market share increases).
  • If a new capability requires specialization (or you are the only one asking for it), stop drop and roll.

Remember that vendor lock-in is not necessarily a bad thing. It is a tradeoff – do you need the capability or the flexibility more? Just make sure that you go into all decisions with your eyes open, aware of what decisions you are impacting down the road. None of us are victims here. But if you are making a dumb decision, don't expect your vendor to do much more than help you get there faster.

- See more at: http://www.plexxi.com/2013/08/vendor-lock-in-everyone-is-complicit-no-one-is-a-victim/?utm_source=feedly#sthash.YCDKVexT.dpuf

Get the open source Atomist Software Delivery Machine and start automating your delivery right there on your own laptop, today!


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}