The Great API Unbundling

I have been talking about the expansion of needs when it comes to API operations, the lifecycle, and governance for a number of years now. I have been hearing it called the great unbundling of API management for a little while now, and while the word “unbundling” is appropriate, it represents an outsider, or market-driven view of what is needed. Unbundling refers to the separation of components from a suite of products the last generation of API service providers were selling you, so that we can invent new words to describe the new suite of modular products that matter when selling you something. Which is fine, except it isn’t about what is needed on the ground, and has no self-reflection about how we deliver modular API-driven solutions. Outsiders never want you to sell you API-driven solutions, because they are harder to see, quantify, and trap you into a single way of buying / selling.

The API Management bundle wasn’t about what API producers needed, it was about API vendors selling and locking API producers into a 1, 3, or 5 year contract. So unbundling by its root has nothing to do with what API producers need to solve their problems, and is once again how we sell to API producers. Bundling or unbundling don’t meet the needs of API producers, except maybe from a procurement perspective. What happens in this line of thinking is you spend all your time thinking about how you will sell enterprise organizations the API tools they need, along with a bunch of tools they did not need, for a period of time which will be longer than the time they find value from said tooling. Now don’t get me wrong, enterprise organizations traffic in the same approaches as API service providers, so I am not defining them from this abuse—I am just pointing out this isn’t about solving problems.

The API universe chronically suffers from a “perspective illness”. It all starts with API producers and consumers, but then you throw in API service providers, analysts, and venture capital—it all has become a house of mirrors. I liken it to one of the top discussions driving AsyncAPI from version 2.0 to 3.0, around their default API example — the street light API. I regularly enjoyed the usual arguments about whether you were the publisher or subscriber of the street light, but also whether you were the municipality that owned the street, or maybe you were the street light, or maybe you were the average person just walking home trying to feel safe and see where they are going. What I am trying to say is, so many of us get all caught up in what is going and and what is needed, but we really aren’t on the ground walking down the street anymore, and we spend a lot of time in meetings, ivory tower design discussions, and pontificating and analyzing at the highest levels, that we never walk down the street and experience what it is like for the street to be dark.

If you are selling API services and tools to API producers you are going to get caught up in your own bullshit at some point—although it is likely you were from the get go.. If you are an analyst who spends all day thinking about what API producers are needing, and even if you are talking to API producers regularly, it is likely that they are missing out on a lot of key interactions, behaviors, and needs. This comes down to incentives. Your incentives will shape how you see things, and you have to really understand the incentives of your customers before you provide what they need. You need to have been in their shoes. Or, maybe you stop focusing on selling them what you think they need, and providing them with what they need. This is truly the most difficult place to operate from. So many believe in the art of the sale, but few believe in truly providing what is needed anymore and just let the sale happen. In today’s funhouse of mirrors we are all about the product, the sale, and can’t find the value, purpose, or meaning in what we are saying and doing.

As a consumer I don’t approach my day considering what I want to unbundle. I go out in the world and obtain what I need. The fact that many of us fall for the bundling of all the products I need into a single grocery store, or fast-food chain, does not make bundling or unbundling a thing. It is something that will stop working just as fast as it started working. If you are truly interested in providing what enterprise organizations are needing when it comes to APIs, you have to adopt an API mindset. I do not want the resources I need for my API platform, operations, and governance from a single bundled provider any more than I want the resources I need for my web, mobile, and device applications from a single provider. Just stop it. API service providers and analysts saying one thing and believing another thing is destructive and annoying. There is no great unbundling. That is more about you than it is about the realities of doing APIs. There is just a wide and ever-growing need of digital resources, capabilities, and experiences I need to operate my platform—please help me find the best solutions possible.