The Four Most Important Dimensions That Block API Progress

I am working my way through 100+ Breaking Changes podcast conversations I have had , as well as 75+ customer conversations I have had this year, and reflecting on a book I just finished called The API-First Transformation (Coming Soon). Across these conversations I see four dimensions that are holding back enterprise organizations from achieving their desirable levels of conversations. While there are many points of friction across API operations, these four areas cause the most amount of instability and friction for teams in my experience.


Not having a common definition of what the API Lifecycle is contributes to endless circular debate, miscommunications, and teams talking past each other. If you do not share an opinionated and consistent view of what the API lifecycle is across your teams—-there will always be miscommunication. The second major dimension here is that people are heavily positioned as an “API producer” or simply acting as an “API consumer”-—without much clarity and empathy regarding what the lifecycle is for both the API producer and consumer, there will always be friction.


This one catches me daily. I find myself talking to someone about the lifecycle or about governance, and all they care about is publishing documentation. Who you are, what you do in your job, and at what level you operate within the enterprise will dramatically change the conversation you and I have about APIs. Knowing you are talking to, understanding and empathizing with what they care about as part of their day, and what their incentives are, paints entirely different pictures of what APIs are, how we talk about the API Lifecycle, and whether or not you will care about API governance.


Whether an API is new or legacy, who the target audience is, the internal and external accessibility, the support structure and feedback loops, as well as how many times an API has been iterated upon all feed into the overall maturity of an API. This maturity will shape, color, and dramatically alter the conversation I am having with you about the API lifecycle. If we aren’t forthright and honest about maturity, and able to have a conversation about what maturity means and the real state of each API, we’ll never be able to get on the same page when it comes to the entire API lifecycle, and how we govern APIs at scale.


People love their brands, platforms, and tools. Vendors, their capabilities, and whether they are API-first or not will completely dictate the API Lifecycle, governance, and overall strategy conversation I have with you. If you articulate that you are interested in treating APIs as a product, and you are an Apigee customer, I will likely have a different conversation with you then if you aren’t an Apigee customer. The tractor beam of API service providers, and specifically that outsized death star tractor beam of our grandfather’s generation of API management service providers provides many of the under currents and undertows that will dictate API operations and the conversation I have with across all areas.

Grounding Our Conversations

I spend about 25% of time lately trying to ground conversations with folks across these four areas. Otherwise I don’t find much forward motion with these engagements. Without grounding in the life cycle, roles, maturity, and vendors, everything is up for grabs and just flapping in the wind. I can talk about something I feel is very common, and you’ll look at me like I am an alien speaking an unintelligible language without clarity in these areas. We just won’t be on the same page, and when we do get on the same page about a single area or element of the API lifecycle, the next step will likely show us off balance again because our worlds aren’t aligned. Without grounding in these areas we will continue to talk past each other, and encounter friction.

I have spent most of 2022 getting opinionated on the API lifecycle. I am not beginning to invest more energy in getting opinionated about roles involved and the maturity of our APIs. Vendors is something I’ve long been opinionated about as the API Evangelist, but I am working to confirm my arguments when it comes to design, gateways, testing, security, governance, and other critical areas. What will be different about my opinions is I won’t just be opinionated about the technical implementation. My opinions will be shaped by the business realities that exist across API operations, as well as the politics of a very human-defined enterprise. With all of this, I am hoping that my storytelling in 2023 and beyond will be much more consistent, grounded, and speaking to the right audience, helping folks cut through some of the Groundhog Day nature of operating in the API universe, where we tend to repeat things over and over until we learn the lessons we need.