From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

On APIs: Cars, not assembly lines.

592 Words. Plan about 4 minute(s) to read this.

In recent years, infrastructure vendors have been proudly pointing out their APIs. The idea is that because a chunk of infrastructure can be monitored and configured with APIs, the product can be described as automation-ready or open.

Vendors, you’re getting it wrong here. Even making the assumption that the APIs are both well-documented and a thorough exposure of system capabilities (both bad assumptions in many cases), yes, an API does open a system up. But consider — how many of your customers have the time or ability to write a custom application to leverage those APIs? And even if they did, can they handle the technical debt incurred by the system they create? Most of your customers have neither the time nor debt tolerance.

Why is there a partial disconnect between vendors and customers when it comes to APIs? I believe it’s because vendors often focus on the high-volume, high-dollar accounts that make up the most interesting part of their sales pipeline. In the networking space, buyers with 8 or 9 figure spends probably do have access to the expertise required to create customized systems leveraging APIs. Therefore, open APIs seem like a big deal that should be in all the marketing slide decks.

Perhaps. But let’s consider an alternate way of looking at this issue. APIs are tools used to build something valuable. From a certain point of view, it makes as much sense for a vendor to brag about their API as it does for an auto manufacturer to brag about their assembly line. I care about the car. I care little about how the car was made. APIs are not the car. Please sell me a car.

Some folks in the vendor community get it, don’t get me wrong. Here’s a key response I received to a tweet the other day from Colin Dixon of Brocade and the OpenDaylight Project.

Remember, most customers are not spending 8 or 9 figures. Most customers are mid-market. They spend 5 or 6 figures annually. Their operations teams are comprised of a small number of folks with an increasing workload often spread across multiple silos. These folks don’t care terribly much about the API itself. Rather, they care about a fully integrated system that out of the box make their lives easier.

The overlooked mid-market — that as an aggregate spends billions — is looking for their IT infrastructure vendors to make their operations easier. They need simple configuration. They need excellent reporting. They need fabulous monitoring. They need full-stack integration. And they don’t have the time or ability to write these systems themselves. Consider the success of hyperconvergence: a critical part of the value proposition is the operational interface.

A historical case-in-point is SNMP. The mid-market isn’t creating their own network management stations from scratch simply because there’s a documented MIB. Rather, they buy an NMS from SolarWinds or one of the dozens of other players in the space. That said, might they write a script to access some particular OID containing a value of special interest to them? Absolutely. I’ve done that myself. But that’s a far cry from writing an NMS.

Vendors, I believe it’s time to start thinking about APIs and the growingly converged data center in the same way as we think about SNMP’s usefulness. The vast majority of your customers want open APIs, sure. But what they want (and need) even more is a turnkey system that leverages APIs without having to know or care about them.

Cars. Not assembly lines.