I am all about API governance these days. In my day job, and evening thoughts. I am no longer a cheerleader for all things APIs, unless they serve API governance. As I take all my observations of the universe of APIs over the last thirteen years and scrutinize them through my current lens I am left with a deep awareness that API governance is all about the limitation of speed. I love this title for a blog post because 98% of the people who read it will immediately assume that API governance being about the limitation of speed is naturally a bad thing. And this is precisely why moving forward I will be all about limiting the speed of API to something that makes sense for the space I am in.
The pace of API has reached incomprehensible levels. Call it API sprawl, API chaos, API legacy, or what you will, but it is the thousands of APIs that exist across your average enterprise organization. The signs are everywhere, beginning with the title of this post. I simply say slow down. Not how much, where or when, and people will dismiss at face value as a bad thing. Most technical people who are at all aware of API governance will tell you it is about the consistent design of your API, which is really just about slowing down and being thoughtful about the design of your API. Most business people who are aware of APIs will tell you treating your APIs as a product is what matters, which is really just about slowing down to listen to your consumers. We are moving so fast that when you ask the average API developer or product manager to provide a proper description of their API, and answer simple questions like who will use it and what they will do with it, they feel you are slowing them down, and they respond extremely defensively.
Yes. Yes, I am slowing you down. Fast does not equal good in all situations. Look at the world around you. Governance is critical to everything around us. To help me think through this for 2024 I wanted to spend a moment and break down governance at large, and then use it to help me locate what truly matters when it comes to API governance—let’s begin with the definition of governance.
- the system by which entities are directed and controlled.
I like that definition. It is simple. It applies to society, as well as API. Governance is how complexity is able to function at scale. It is how our world is orchestrated across many competing interests. When it comes to API governance, directing the design of APIs is just the beginning, we also have to address the other moving parts, as well as the people. Expanding in this direction I wanted to explore the human side of things with a definition of governor.
- one that exercises authority especially over an area or group
API governance is about exercising authority over those producing an API, as well as those consuming APIs. I am a governor, and I am looking to train up the next waves of governors. Again, like governance limiting speed invoking negative emotion, I think that a governor does the same, despite us (in the United States) acknowledging the need for 50 governors of each of the states. As I was grabbing the definition of governance, I also noticed the machine version of the definition.
- an attachment to a machine for automatic control or limitation of speed
This is a very analog definition of governance, but one that I feel is that I need to overhaul for a digital age where speed and forward motion is seen to be an inevitable constant. It isn’t, and we are reaching unsustainable levels. I know that people are looking to AI to clean all of this up. It won’t. It is going to make things worse. Sure, it will bring incremental evolutions, but it will not fix the API sprawl and chaos that is the accepted state of the enterprise. Because this is a people problem, not a technical one. The technical is just what’s most visible. What we need to do is slow down a bit and be more thoughtful about not just the design of our API, but the entire end to end lifecycle of our APIs.
It is painful for me to have spent 13 years demonstrating why good APIs and API operations matter, only to have folks dismiss me, move forward and make the mistakes and feel the pain I talk about, then come around to an understanding of what I was saying after five years of suffering. Most people I evangelize APIs to are too busy to listen. Most people I evangelize APIs to are too caught up in the forward motion of their company’s blind belief in the technology sector’s promise of salvation just around the corner, if you just move fast enough (a break things). It is hard to be a database person with over 35 years of experience, with the last 15 of it witnessing the evolution powers of APIs, seeing database people 20 years into their career dismissing the importance of API experience and governance, and doubling down on speed over everything else.
Alongside my day job of API governance, I have spent the last six months thinking deeply about API discovery. Which is the single API area I consider myself an expert. I wanted to understand why we haven’t “solved” API discovery, or even provided a single meaningful API discovery solution (that has stuck) in the last 20 years. I have covered every inch of the subject only to conclude that API discovery is truly a problem we face in the API space which is extremely difficult to solve, simply because nobody will slow down and solve it. I see waves of folks come along and begin solving only to get distracted and shift gears because things move too “fast”, abandoning their solution before it ever reaches scale. Sadly the monetization approach for web discovery does not work for API discovery, and nobody has the time, imagination, or money to come up with an adequate solution — me included.
Moving forward I will be spending time on API governance in my day job at Bloomberg, with API Evangelist dedicated to API governance of public APIs in the service of API discovery. I am 100% focused on using APIs.json to tell stories about “the system by which entities (APIs) are directed and controlled”, being the “one that exercises authority especially over an area (APIs) or group (API producers and consumers)”, and leveraging APIs.json to turn APIs.io into “an attachment to a machine for automatic control or limitation of speed”. This is how I will govern API discovery in 2024 to help “solve” the API discovery problem. Nobody else will slow down long enough to do it. I will. AI will not solve this problem for us, and we will need it solved to ensure AI isn’t a total fuster cluck. API discovery is essential to AI working. I won’t go into how I will do this, you’ll just have to tune into the API Evangelist, APIs.json, and APIs.io blog to find out.
I will still be publishing blog posts across these three domains to tell my stories. However, I will focus primarily on telling my API stories through the APIs.json reviews of public APIs. I will be taking the time to get to know and properly profile each API, and lean on APIs.json to provide the narrative. Stories are how I will contribute solutions to the massive challenge we face with API discovery. Stories are how I will govern public APIs. My blog stories will still matter, but I feel pretty strongly that word and visual stories of APIs and the operations that surround them is how we are going to make sense of this sprawl. I see it as the next generation of my API storytelling at scale, and APIs.json will provide me with a machine-readable way to help make my stories more consistent, while also helping provide the stories we need to help govern this API sprawl. I am looking to help us slow down in the right ways and make sense of things. I am not delusional in thinking that everyone will get on board with my approach to API governance and discovery, but for those who do, we’ll collectively find a better path forward through the API chaos and sprawl.
