API Interoperability is a Myth
There are a number of concepts we cling to in the world of APIs. I’ve been guilting of inventing, popularizing, and spreading many myths in my almost decade as the API Evangelist. One of them that I’d like to debunk and be more realistic about is when it comes to API interoperability. When you are focused on just the technology of APIs, as well as maybe the low-level business of APIs, you are an API interoperability believer. Of course everyone wants API interoperability, and that all APIs should work seamlessly together. However, if you at all begin operating at the higher levels of the business of APIs, and spend any amount of time studying the politics of why and how we do APIs at scale, you will understand that API interoperability is a myth.
This reality is one of the reasons us technologists who possess just a low-level understanding of how the business behind our tech operation, are such perfect tools for the higher level business thinkers, and people who successfully operate and manipulate at the higher levels of industries, or even at the policy level. We are willing to believe in API interoperability, and work to convince our peers that it is a thing, and we all work to expose, and open up the spigots across our companies, organizations, institutions, and government agencies. Standardized APIs and schema that play nicely with each other are valuable, but only within certain phases of a companies growth, or as part of a myth-information campaign to convince the markets that a company is a good corporate citizen. However, once a company achieves dominance, or the winds change around particular industry trends, most companies just want to ensure that all roads lead towards their profitability.
Believing in API interoperability without a long term strategy means you are opening up your company to value extraction by your competitors. I don’t care how good your API management is, if your API makes it frictionless to integrate with because you use a standard format, it just means that the automated value harvesters of companies will find it frictionless to get at what you are serving, and more easily weaponize and monetize your digital resources. It pains me to say this, but it is the reality. If you are in the business of making your API easier to connect with, you are in the business of making it easier for your competitors to extract value from you. Does this mean we shouldn’t do APIs, and make them interoperable? No, but it does mean that we shouldn’t be ignorant of the cutthroat, exploitative, and aggressive nature of businesses that operate within our industries. Does it mean we shouldn’t invest in standards? No, but we should be aware that not every company sitting at the table shares the same interests as us, and could be playing a longer game that involves lock-in, proprietary nuances, or even slowing the standards movement in their favor.
I think that storage APIs are a great example of this. In the early days of cloud storage APIs, I remember everyone saying they were AWS S3 compatible—even Google and Microsoft highlighted this. However, as things have progressed, everyone adds their own tweaks, changes, and nuances that make it much harder to get your terabytes of data off their platform. It was easy to get it in, and keep it synced across your providers, but eventually the polarities change, and all roads lead to lock-in, and are not in the service of interoperability. This is just businesses. I’m not condoning it, I am only repeating what my entrepreneurial friends tell me. If you make it easy for your customers to use other services, you are eroding their loyalty to your brand, and eventually they will leave. So you have to make it harder for them over time. Just incrementally. Forget to grease the door hinges. Change the way the doorknob turns. Make the door narrower. Stop following the international or local standards for how you design a door, call it innovation, and reduce the ways in which your customers can easily get out the door.
I call this the Hotel California business model. You can check-in, but you can never leave. Wrap it all in a catchy tune, even call yourself a hotel, but in reality you’ve gotten hooked a technological myth, and you will never actually be able to ever find the door. Anyways, c’mon, I fucking hate the Eagles, don’t we just have some Credence we could play? Anyways, I got off track. Nobody, but us low-level delusional developers believe in API interoperability. The executives don’t give a shit about it. Unless it supports the latest myth-information campaign. In the long run, nobody wants their APIs to work together, we all just want EVERYONE to use OUR APIs! Sure, we also want to be seen as working together on standards groups, and that our APIs are the the standard EVERYONE should follow, ensuring interoperability with us at the center. But, nobody truly believes in API interoperability. If you do, I recommend you do some soul searching regarding where you exist in the food chain. I’m guessing you are a lower level pawn, doing the work of the puppet master in your industry. This is why you won’t find me on many standards bodies, or me blindly pushing interoperability at scale. It doesn’t exist. It isn’t real. Let’s get to work on more meaningful policy level things that will help shape the industry.