I have long stated that I am focused on in the intersection of the technology, business, and politics of APIs with my storytelling. When I started API Evangelist I was fairly well versed in the technology of APIs, but I wanted to learn more about the business of APIs. I knew there was more to what I was seeing than just the technical aspects of doing APIs, so I sat down to learn. After a couple of years I realized that politics of APIs were another critical piece of the pie, leaving me studying the technology, business, and politics of APIs from around 2014 through 2024. Now, I am evolving that view of the landscape, to focus at the intersection of the technology, business, policy, and people of APIs.
The technology of APIs plays a lead role in the API musical, but it always takes a backseat when it comes to the business of APIs. This is something most developers do not see or think about, as this isn’t their realm. When I poked my head up in 2010, I was making a conscious effort to understand more of this realm that existed outside my technical lens of the world, and develop an awareness of how it impacts the technology of APIs. After about four years of this journey, learning about APIs within startups, enterprises, higher educational institutions, and government agencies, but also learning how venture capital was changing the game—-I found myself learning about how corporate, industry, and government politics were actually shaping everything.
I am now in the business of shaping change, not just the punditry of it. Stories are an important part of this, but people and policies are what I think are the most important tools in my toolbox at this stage. APIs still dominate over any individual application or infrastructure, and obviously business still drives everything, but actively defining and shaping policies, while also being honest about the people of all of this is the same path forward in all of this API sprawl, noise, and chaos. There is no stopping it. There is no fixing it. There is only incrementally shifting how things work and continuing to reveal how things work (or do not work) behind the scenes. After almost 15 years of studying the technology, business, and politics of APIs, I am confident that it will be the technology business, policy, and people of APIs is how I actually make a meaningful impact on things.
I will have to update my Venn diagram image that I created In 2014 to accommodate these four dimensions. I don’t feel that the technology and business of APIs have changed much since I started in 2010. I’d say there are fewer good API ideas getting funded, and the money landscape has shifted a bit, and APIs has widened to include REST, GraphQL, gRPC, and event-driven APIs, but aside from that there isn’t much new. Not even AI and bot automation—I’ve already rode several of these waves. I feel like we are at the phase where we can be individually and collectively defining API policies that begin to ground and stabilize things. Sure, it won’t stabilize everything, and there will always be volatile aspects of doing APIs across specific APIs. But, I firmly believe we are leaving the teenage years of APIs and are approaching where we are going to have to start getting our shit together. Granted, this doesn’t mean everyone will pull their shit together, but many will opt for a more stable reality.
A policy can be as fine grain as agreeing upon the why and how of API versioning. Are we doing it in the path or via headers? Then we can have automated rules that lint for it, but let’s get the people together within this enterprise or industry and agree upon the policy. Policies can be broad, such as—we publish REST and GraphQL APIs for each API product. Which are more difficult to establish machine-readable rules, but still are important even if the enforcement is purely human-driven. There is no right way to do APIs, but a group of people can come together and define a policy that helps ground us all and keeps us in alignment. Policies are living and can change and adapt with the times. Policies can be deprecated. I am done focusing on the politics of APIs, and I want to be in the business of defining API policy, and telling stories that convince the people involved why policies matter.
I guess for me the big shift here is instead of being in the business of identifying and highlighting where the politics are, I am in the business of taking a definition of the politics I have identified existing at the technical or business levels, and driving a conversation around how to standardize a policy and set of rules that anyone can put to work if they choose. Ideally policies have a URL to a machine-readable artifact, are small in scope, and can be automated by humans and machines. Policies bridge the business and technical divide. Policies are defined, iterated upon, and applied (or not) by people. I am developing my own set of operational and individual API policies as part of my APIs.json work. We’ll see when and where I publish them. You can find them expressed as APIs.json properties often, something that is validated using rules, but I will likely begin polishing them as an open format using APIs Commons.
I will continue my work to understand and bridge the technology and business of APIs, however my period of simply observing the politics of it all, and maybe bitching about it are over. I am going to begin calling what I do as being about the technology, business, policy, and people of APIs. I will create a new Venn diagram that helps visualize what I mean, and I’ll keep telling stories at this intersection but rather than just convincing folks with my blog, I will publish more as actual policies that can be applied using APIs.json. The core capability of APIs.json powered by API Commons has shown me the importance of translating the human interfaces we depend on at the API layer into machine-readable ones, but ones that are defined and shaped by policies that make sense to humans and the machines—agreed upon by the humans. I am just laying the foundation with the post for the next generation of my storytelling, and drawing the line in the sand when I first made this shift.
