Hardware Vendor Lock-In: A Long and Messy Past
If you think about the beginnings of networking, hardware lock-in was the norm. The original IBM Token Ring, for example was a proprietary networking solution; and every new purchase order had to go to the same vendor if customers wanted to ensure connectivity.
Customers demanded interoperability between hardware vendors, and so came Ethernet which promised to be an open, interoperable standard. However, vendors recreated lock-in by implementing proprietary VLAN extensions such as private VLAN.
Internet Protocol (IP) was another open standard. Yet hardware vendors convoluted the standard, and came out with proprietary routing protocols such as IGRP which were designed to lock customers into the hardware vendor’s equipment exclusively.
Today, with the emergence of merchant silicon, whitebox switches, and open source switch operating systems, it is more important than ever for businesses to defend themselves from lock in, and have the flexibility to be vendor-agnostic so they can leverage those options.
Yet by the same token, it has become more critical than ever for the hardware vendors to defend themselves from the competition by locking in their customers!
So with white box switches, open source device operating systems, and commoditization on the rise, what is the new hardware vendor lock-in strategy? Hardware vendors are coming out with proprietary management APIs which lock their hardware to their management systems. These proprietary network management solutions are the ultimate form of lock-in — not the SNMP add-ons of the past, but sophisticated network monitoring, configuration and trouble-shooting solutions that only work with that one vendor’s equipment. Uber lock-in!
Why is Hardware Lock-in dangerous?
The dangers of hardware vendor lock-in are real, consequential, and affect every aspect of IT business operation. Hardware vendor lock-in is a primary inhibitor of organizations’ digital transformation initiatives and their ability to compete. It starts with the fact that IT is completely at that vendor’s mercy, which has profound consequences.
Extremely high costs
When an organization locks itself into their hardware vendor, two things happen:
1. IT loses control over the pricing of hardware:
How can IT have any leverage when there is only one vendor to talk to? IT may have negotiated an initial deal for the first batch of hardware, or for the first year. But when IT is locked-in, nothing prevents the hardware vendor from coming back with higher prices as soon as they are able.
Hardware vendors aggressively promote and position their own management software because they know once deployed they gain account control, become deeply entrenched, and make it difficult to replace them. At that point, IT has all but guaranteed the highest prices and TCO (total cost of ownership).
In this report, Gartner comments that “By introducing competition in this thoughtful manner, Gartner has seen clients typically achieve sustained savings of between 10% and 30% and of as much as 300% on specific components like optical transceivers”. In another report, Gartner analysts Mark Fabbi and Debra Curtis find that “Sole-sourcing with any vendor will cost a minimum 20% premium, with potential savings generally reaching 30% to 50% or more of capital budgets when dealing with premium-priced vendors”.
2. IT loses control over operational expenses
Even more importantly, with vendor lock-in IT loses control over the ability to reduce operational expenses. This happens for many reasons:
- Reducing operational expenses is achieved by using the automation tools that meet IT’s business needs. Those automation tools are generally built by specialized best-of-breed companies which are 100% focused on solving those problems. It is highly unlikely that the management software built by the hardware vendor, and designed to lock the customer into that hardware vendor will meet all the customer’s requirements for automation.
- Hardware vendor positions extremely expensive and highly profitable “professional services” that build spaghetti code to remediate this divergence between IT requirements and the capabilities of their software solution. With every new version of the management software, the spaghetti code has to be upgraded, at excessive cumulative expense. The result is massive costs, coupled with an innate inability to deliver on the needs of the business.
- The IT team becomes mired in hardware vendor minutia – from arcane commands to arcane workflows, or arcane vendor specific tools; this wastes resources and time, and keeps IT away from the tasks that are more aligned with the needs of the business. It is no wonder that according to ZK Research, businesses are now dedicating 82% of their IT budgets solely to keeping the lights on, leaving very little budget for innovation.
In fact Gartner finds that by breaking their lock-in from one single vendor, some organizations were able to reduce their opex costs by as much as 95%!
Outages and security risks
1. Substantially higher rate of outages
When IT is locked into one hardware vendor, the business is completely at the mercy of their bugs and quality problems (both hardware and software). When problems occur, customers have no recourse but to depend on their hardware vendor, and them alone, to solve these problems. Even if they are motivated to fix the issues, they are limited by development cycles, and it may take them a lot longer to solve a problem than what IT has written down in an SLA contract, or by what is acceptable by the business. Even if IT is able to hold them accountable for violating their SLA, it doesn’t help the business, and frankly IT has very little recourse since they’re locked in. Being locked into the management software and analytics that the hardware vendor has provided means not being able to take advantage of other tools on the market that may be more effective at preventing these outages in the first place.
2. Security vulnerabilities Exposure
Security vulnerabilities are common and are routinely discovered on devices in the infrastructure. When a hardware vendor discovers a security vulnerability in a customer’s hardware and device OS that they are locked into, the customer must wait for the hardware vendor to provide a patch, which may take months; and then when this patch shows up, the customer will need to go through their qualification process for that security patch, which may take many more months. Skipping the qualification process is akin to rolling the dice on new potential unknown bugs (a very common occurrence with new device OS versions) that could potentially cause bigger problems, performance problems, or outages. Gartner analyst Andrew Lerner wrote a great blog about the pain involved in network upgrades, where he compares the process to going to the dentist!
In summary, when a customer is locked into a hardware vendor and faces a security vulnerability there is a risk of being exposed for months before it can be remediated.
Failing to deliver for the business and losing relevance as a result
1. Unable to meet the requirements of the business
When IT locks itself into hardware, a massive missed opportunity cost is incurred. As engineers are deployed to become experts on vendor-specific hardware and device OS versions, they are unable to focus on the initiatives that are most critical to the business: the cloudification of their infrastructure; improving their infrastructure to avoid outages and improve application availability; automation efforts in support of the business’s digital transformation initiative, to name a few.
Indeed, it is common that Fortune 500 enterprises delay their critical automation initiatives because of their investment in becoming world experts at the vendor’s latest hardware or latest device operating systems. This is often viewed as a “sunk cost” and results in dramatic consequences to the business, and also to the relevance of infrastructure teams. As businesses digitally transform and application teams grow impatient with their hardware-first infrastructure teams’ inability to deliver on their requirements, application teams turn elsewhere to make progress.
2. Shadow IT
What often happens is that application teams and DevOps teams start spinning up workloads in the cloud, hence bypassing the IT infrastructure teams completely! The phenomena, often referred to as “Shadow IT,” is quite pervasive. For example, according to a 2014 PwC report, it was estimated that “80% of enterprises have used cloud platforms and SaaS applications that have not been approved by IT; and for those enterprises, the percentage of applications that were running on shadow IT was a whopping 35%.”
Needless to say, shadow IT significantly increases the security risks for an organization; it also results in costs ballooning out of control.