The lack of business and technical alignment across API operations was the number one concern I heard across my 125+ guests doing my Breaking Changes podcast. In my experience, the lack of alignment between what the business side of the enterprise wants, and what the engineering side of the enterprise wants, is the number one cause of friction, chaos, and sprawl across API operations. What product managers, and sales are asking engineering for when it comes to what consumers need increasingly does not always look like the API engineering is producing. The difference between business requirements and the actual resources, capabilities, and experience provided by HTTP APIs can be quite large within the enterprise, depending on the group you are working with, introducing an unmanageable amount of API sprawl and chaos.
I met a number of people who were heavily focused on bridging the gap between how product and engineer works together to produce APIs, as well as how producers and consumers worked together to iterate upon APIs. I learned a lot about this gap interviewing people on Breaking Changes, but also through the many other off the record conversations I had with enterprise organizations during my four years at Postman. I left Postman to learn more about this, leading an API governance program at Bloomberg, and now I am looking to continue this work across multiple industries and enterprise organizations through API Evangelist contract services offerings, and the storytelling on my blog. I have thought a lot about why there is a gap between product and engineering, as well as producer and consumer, and I have some strong opinions about what work needs to happen to align all of these API actors, and begin bridging the divide between them, while achieving more alignment.
There is so much deficiency when it comes to business stakeholders involved in the API lifecycle, I do not dare offer anything too radical or complex, or even begin to prescribe specific services and tooling, opting to focus on the following fundamentals:
- Expose Business Stakeholders to API Operations
- Expose All Leadership to API Operations
- Educate Product Managers About APIs
- Get Product Managers Involved in Lifecycle
- Introduce a Business API Contract Into Mix
- Wrap Spectral Rules with Business Policies
- Product Managers Define Use Cases
- Product Managers Craft Getting Started
- Product Managers Define Plans and Limits
- Product Managers Write Summaries and Descriptions
- Business and Technical Ownership of Road Map
- Business and Technical Ownership of Leadership
- Business and Technical Involved in Support
- Product Managers Take Lead on Feedback Loops
- Provide Business Dashboards and Reporting
To do this I am not introducing anything radical into the discussion, just holding business stakeholders more accountable, while also forcing engineering stakeholders to make more space for business folk to get involved. While there are many historical reasons behind the divide between business and IT, I hold both sides accountable for bridging this, with an expectation that business stakeholders will get more API education and be less afraid of the tech, and engineering realize it is in their best interest to stop putting up walls and moats for business stakeholders. The minimum entry fee into the API club for business stakeholders is that you have to be able to read and edit YAML, and work with these machine (and human) readable artifacts in a GitHub, GitLab, or BitBucket repository. And for engineering stakeholders, you have to accept YAML during design-time, and stop being so resistant to talking about things in business terms.
This list seems like a lot, but it represents the key areas I’ve been seeing internal and external APIs go off the rails. I have a number of other policies, as well as ideas for integrating in Jira, Google Sheets, and other services and tooling that business stakeholders rely upon. However, I am determined to beat the drum exclusively in these areas while developing a backlog of other policies and platform capabilities that will give product managers more super power throughout the API lifecycle. Like every other aspect of my API contract work in the coming months and years, I will be heavily focused on the fundamentals and low-tech ways to find more alignment between the business and engineering side of the API equation, and I am looking to not “other tools” myself and get distracted along the way. If you have opinions on this intersection, feel free to fire up an API Evangelist Contract for your organization, or you are just welcome to join me for an API Evangelist Conversation to discuss more.
