Vendor lock-in is an important subject. Everybody knows that. But few of us realize just how complicated the subject is, nor how riddled it is with paradoxes. Truth be told, I wasn’t fully aware either. But when I set out to write this post, I found that it just kept growing longer.
1. The most basic form of lock-in is:
- You do application development for a target set of platform technologies.
- Your applications can’t run without those platforms underneath.
- Hence, you’re locked into those platforms.
2. Enterprise vendor standardization is closely associated with lock-in. The core idea is that you have a mandate or strong bias toward having different apps run over the same platforms, because:
- That simplifies your environment, requiring less integration and interoperability.
- That simplifies your staffing; the same skill sets apply to multiple needs and projects.
- That simplifies your vendor support relationships; there’s “one throat to choke”.
- That simplifies your price negotiation.
3. That last point is double-edged; you have more power over suppliers to whom you give more business, but they also have more power over you. The upshot is often an ELA (Enterprise License Agreement), which commonly works:
- For a fixed period of time, the enterprise may use as much of a given product set as they want, with costs fixed in advance.
- A few years later, the price is renegotiated, based on then-current levels of usage.
Thus, doing an additional project using ELAed products may appear low-cost.
- Incremental license and maintenance fees may be zero in the short-term.
- Incremental personnel costs may be controlled because the needed skills are already in-house.
Often those appearances are substantially correct. That’s a big reason why incumbent software is difficult to supplant unless the upstart substitute is superior in fundamental and important ways.
4. Subscriptions are closely associated with lock-in.
- Most obviously, the traditional software industry gets its profits from high-margin support/maintenance services.
- Cloud lock-in has rapidly become a big deal.
- The open source vendors meeting lock-in resistance, noted below, have subscription business models.
Much of why customers care about lock-in is the subscription costs it’s likely to commit them to.
5. Also related to lock-in are thick single-vendor technology stacks. If you run Oracle applications, you’re going to run the Oracle DBMS too. And if you run that, you’re likely to run other Oracle software, and perhaps use Exadata hardware as well. The cloud ==> lock-in truism is an example of this point as well.
6. There’s a lot of truth to the generality that central IT cares about overall technology architecture, while line-of-business departments just want to get the job done. This causes departments to both:
- Oppose standardization.
- Like thick technology stacks.
Thus, departmental influence on IT both encourages and discourages lock-in.
7. IBM is all about lock-in. IBM’s support for Linux, Eclipse and so on don’t really contradict that. IBM’s business model is to squeeze serve its still-large number of strongly loyal customers as well as it can.
8. Microsoft’s business model over the decades has also greatly depended on lock-in.
- Indeed, it exploited Windows/Office lock-in so vigorously as to incur substantial anti-trust difficulties.
- Server-side Windows tends to be involved in thick stacks — DBMS, middleware, business intelligence, SharePoint and more. Many customers (smaller enterprises or in some cases departments) are firmly locked into these stacks.
- Microsoft is making a strong cloud push with Azure, which inherently involves lock-in.
Yet sometimes, Microsoft is more free and open.
- Office for Macintosh allowed the Mac to be a viable Windows competitor. (And Microsoft was well-paid for that, generating comparable revenue for per Mac to what it got for each Windows PC.)
- Visual Studio is useful for writing apps to run against multiple DBMS.
- Just recently, Microsoft SQL Server was ported to Linux.
9. SAP applications run over several different DBMS, including its own cheap MaxDB. That counteracts potential DBMS lock-in. But some of its newer apps are HANA-specific. That, of course, has the opposite effect.
10. And with that as background, we can finally get to what led me to finally write this post. Multiple clients have complaints that may be paraphrased as:
- Customers are locked into expensive traditional DBMS such as Oracle.
- Yet they’re so afraid of lock-in now that they don’t want to pay for our vendor-supplied versions of open source database technologies; they prefer to roll their own.
- Further confusing matters, they also are happy to use cloud technologies, including the associated database technologies (e.g. . Redshift or other Amazon offerings), creating whole new stacks of lock-in.
So open source vendors of NoSQL data managers and similar technologies felt like they were the only kind of vendor suffering from fear of lock-in.
I agree with them that enterprises who feel this way are getting it wrong. Indeed:
- The management of even NoSQL DBMS is a big issue, and help in that area has high cash value for customers.
- Serious users need support.
- Support and management tools happen to be synergistic with each other.
This is the value proposition that propelled Cloudera. It’s also a strong reason to give money to whichever of MongoDB, DataStax, Neo Technology et al. sponsors open source technology that you use.
General disclosure: My fingerprints have been on this industry strategy since before the term “NoSQL” was coined. It’s been an aspect of many different consulting relationships.
Some enterprises push back, logically or emotionally as the case may be, by observing that the best internet companies — e.g., Facebook — are allergic to paying for software, even open source. My refutations of that argument include:
- Facebook has more and better engineers than you do.
- Facebook has a lot more servers than you do, and would presumably face much higher prices than you would if you each chose to forgo the in-house alternative.
- Facebook pays for open source software in a different way than through subscription fees — it invents and enhances it. Multiple important projects have originated at Facebook, and it contributes to many others. Are you in a position to do the same thing?
And finally — most of Facebook’s users get its service for free. (Advertisers are the ones who pay cash; all others just pay in attention to the ads.) So if getting its software for free actually does screw up its SLAs (Service Level Agreements) — well, free generally comes with poorer SLAs than paid. But if you’re in the business of serving paying customers, then you might want to have paying-customer kinds of SLAs, even on the parts of your technology — e.g. websites urging people to do business with you — that you provide for free yourself.
Related links
- The technology underlying packaged applications (November, 2015, but it has a historical focus)
- Topics in migration (January, 2015)
- Much of the vendor advice on Strategic Messaging.