A Tale of Two Pities: A cautionary look at vendor lock-in

Several years ago when I was at Juniper, I joined Juniper Founder and CTO Pradeep Sindhu, another product manager, and a couple of account guys as we visited a massive enterprise here in The Valley. For those of you who have not met him, Pradeep is ridiculously smart – he can talk competently at so many levels. And that intelligence carries with it this gravitas. As you watch him work a room, it's like watching National Geographic – you know that the lion is eventually going to get his prey.

But not this time. I watched Pradeep fire off a few questions, respond to some comments, and explain how network architecture needed to evolve. But the head of IT at this company looked unmoved. No matter what Pradeep said, the guy was simply unfazed. It's not that Pradeep wins every sales engagement he is in, but he usually lands his points. In this particular meeting, his counterpart just stood there, almost defiant.

And then in the last couple of minutes, it came out. He had already made his mind up. He knew a couple of years ago how he was going to build out his next-generation data centers. But it wasn't for the reasons you might think.

Many years earlier, they had made a decision to transform their network to handle VOIP. They had switched out all the phones in the company, and built the network to support their VOIP requirements. A couple of years before our visit, they had looked at upgrading some part of the network but determined they could not do anything lest they would upset the VOIP architecture. They required certain features to keep it all up and running. Switching from their incumbent vendor was simply not an option without incurring a metric ton of expense. So no matter what Pradeep had in his arsenal, this gentleman already knew he wasn't in a position to do anything. He was locked in. And for the foreseeable future.

It wasn't the physical form factor that locked him in. It was the litany of VOIP features that they had added, one by one, over the years. The hardware was the least of his problems.

In a similar engagement on the service provider side, we had worked for almost a year on one particular project. In the end, the customer actually liked the solution. It was a more elegant way of solving the scaling issues they were facing. But again we lost. Why? The OSS/BSS integration was going to be a nightmare, and it couldn't be solved in the timeframe required to get the new service turned up.

In both cases, the customer was locked in to their solutions. In neither case, the culprit was hardware.

There is a lot of talk these days about vendor lock-in. With architectural upheaval all about thanks to any number of trends (SDN, network virtualization, big data, you pick), customers are heading into architectural decisions with eyes wide open. The problem is that there seems to be a misperception that the networking bogeyman is hardware.

The reality is that for the past couple of decades, lock-in has been dominated by software. It's not the wires that are hard to swap out; it's all the softer tools and systems that surround the infrastructure. Even when you get past specific on-box capabilities, it's the provisioning, scripting, monitoring, troubleshooting, and other supporting tools that are difficult to maneuver around or without.

If you want to be aware of lock-in, you need to be somewhat cognizant of the number of things that connect to something. For example, in a former life, we built an internal database to track feature planning. Over time, we connected it to the customer request system, the bug tracking system, the source code management system, and so on. When the thing fell over dead under all of that load, we couldn't replace it because we couldn't redo all those connections easily. Effectively, we were locked in to our poor software choice.

As customers make their plans, they need to be aware of vendor lock-in, but the two things that matter most are:

Is this a point of control? If it is, chances are that more tools and process will flow through it, so you need to be aware of what you are doing. For example, switching from a Cat6k to a Nexus5k to a Plexxi Switch1 will be far easier than migrating from vCenter to anything else.

Is it designed for integration? Where there is a single point of integration, if it is designed explicitly to be easily integrated, it will be easier to add onto or remove entirely if the time arises.

At the end of the day, every solution has some manner of stickiness. The real question is how many things does it touch, and how easy is it to replace. On both counts, software is likely where you want to do most of your analysis. If hardware is networking's bogeyman, then I suppose software is more like Voldemort – that unspeakable thing whose name we dare not mention.

[For those of you still reading, I had every intention of using the Dickens villain Madame Defarge from A Tale of Two Cities, but I figured no one would get the reference. So I am including it here just for you.]