You don’t want vendor lock-in… but aren’t you always locked in?

I’m privileged to meet with companies and CIOs on a regular basis. And I don’t know how often I’ve had a discussion around the subject of vendor lock-in. I clearly understand the fears companies have to hook themselves with a vendor and not be able to take advantage of innovations coming from other sources.

But frankly, as soon as we make a choice of technology, we are locked in with that technology. Hear me out.  Whether it’s provided by a commercial company or a not-for-profit organization, the situation is the same. We become dependent of that technology. What makes matters more complex is that most innovations are proprietary by nature in the sense that they have been defined outside the control of standards bodies. So, either companies only choose standards and may feel they do not take full advantage of innovations, or they choose innovations and may be left with difficult to maintain technology if the innovation does not latch on. It’s only when innovations reach mainstream that they are getting standardized. Let me take a very old and simple example. If you have a car with a manual gearbox, the clutch is on the left, the brakes are in the middle and the accelerator on the right, isn’t it? Well, it hasn’t always been like that. I remember my father in law talking about a World War II truck he drove where the gas pedal was in the middle. Things took time to standardize. The same is true for every technology.

So, rather than discussing whether to accepts vendor lock-in or not, the discussion should focus on how a company can protect itself through the use of an open environment where technologies from a variety of sources can be assembled. Let’s look at how this applies to cloud computing.

An integrated cloud platform or DiY

This leads me to a simple question. Are you choosing for an integrated cloud stack or do you want to build your cloud using a best-of-breed approach, a do it yourself (DiY) approach? It’s not the first time companies were confronted with such dilemmas. I very well remember the early days of ERP. Many companies started with best of breed, but most have integrated packages today. Why? Because ERP used to be a differentiator while now it’s a must have. I still remember a pharmaceutical company that had developed its own network solution and was frantically looking at someone to support it when they realized the cost of keeping the solution alive.

I believe we are going down a similar path with cloud. Large companies in industries where IT is at the core of what they do (such as telco and banking) have a tendency to go for best of breed approaches, often based on opensource software. About one year ago I asked the CTO of a larger telco who had implemented its own OpenStack-based cloud environment whether this had been cheaper than using an integrated platform. His answer was very interesting. Yes, the license costs of the software was reduced drastically, but he had hired 160 people to implement, integrate, maintain and evolve his cloud offering. So, he concluded, it had not been cheaper, but “we are not locked in with a vendor.”

An integrated cloud platform facilitates the implementation and puts the burden of maintenance and support in the hands of the supplier. So, if you go down that route, make sure you choose a company that can provide you the level of support you expect. What do I mean by that? Let me give you an example. A while ago I talked with the head of network operations for a large manufacturing client. They had decided not to rely on the software assets from the large established vendors, but work with small start-ups that carefully listened to the company prior to developing their software. He expressed his frustrations when he realized that the support was actually delivered by the same three engineers that developed the software. So, in case of urgency, he relied on three people, hoping no other customer had a problem at the same time.

Three key things to know before you make a choice

Before choosing what route to follow, there are three key things you should define very clearly:

  • Define what capabilities you want your cloud to have not only at the start, but also three years down the road. This will allow you to highlight the features and functionalities the chosen/designed cloud platform needs to be capable of delivering.
  • Identify the assets (if any) you already have and want to keep. For example, one of the banks I talked to wanted to keep their user identification/authentication platform, so the users would use the same identifier for all their operations.
  • Think through the whole lifecycle of your cloud platform. What are you willing to do yourself and what do you expect from your partners? Do not just look at the building/installation of the platform, but think about support, upgrade, evolution, etc.

Eight key features you may need

Once you know your base strategy, what level of flexibility do you expect from your cloud platform? Here are some points to look at:

  • What level of customization do you need? Can you work with the existing portal or do you need something different for example?
  • What existing identity & access management do you need your cloud to re-use, what authentication mechanism, what approval rules are you familiar with?
  • How do you want your service catalog to be structured? Do you have multiple organizations that each need their own catalog? Are you having different roles each requiring access to different services?
  • Will you deliver all your services from your own cloud platform or are you planning to intermediate and aggregate services provided by external providers.
  • Do you want to use one or more hypervisors? Which features of each hypervisor do you want to be accessible?
  • Do you have a homogeneous resource pool or do you plan to re-use resources already available in a more heterogeneous cloud? Are you planning to allow bursting in case of lack of resource availability?
  • What type of storage and networking are you looking for? How much multi-tenancy do you need? Are you planning to develop a multi-site environment?
  • Are you planning to implement charge-back or billing? If yes, what billing schemas are you requiring? Is it pay-per-use, is it monthly fee? Is it a combination of both? Make sure you understand what you need.

Once you have answers to all these questions, you can start identifying whether you go with an integrated cloud platform or develop your own cloud based on best of breed building blocks. You also have a good understanding of the features you need to ensure are available in the platform or the components you choose. Do a thorough analysis of what is available, and do not just take “it can be done” for an answer.

What you may want to do is prioritize your requirements as you may have to do some compromises. Maybe an integrated cloud platform addresses 90% of your needs. In that case the question is whether you can live without the last 10%.


In this blog post I’ve tried to give you some hints on how you could define what approach to take and what components to use. Regardless of the technology you use, you will have some level of lock-in. So the real question now is how you can immunize the implications. I have five suggestions for you and will highlight those in my next blog entry.