Like many aspects of our API operations when you say API governance it will mean different things to different people. So, it is always helpful to ensure that people are on the same page when it comes to your definition of API governance, and what your intention is. I’ve explored the definition of API governance before, and how it overlaps with the governance of countries and even engines, but the misconceptions and overlaps in which people tend to see API governance addressing tend to focus on four key areas.
- APIs - The governance of the technical details, or often governing the design of an API.
- People - Governing the behavior of people involved with producing or consuming APIs.
- Process - Defining and governing the process involved with producing or consuming APIs.
- Vendors - Governing the decisions that have been made over years to purchase infrastructure.
In reality, API governance is about governing all of these dimensions, but where the friction comes in is when leadership believes they are only governing one of these areas, when teams are governing other aspects that are intended by leadership. For example, most job descriptions for API governance are written to speak to the governance of APIs, when they are mostly about managing people and legacy vendor decisions. You won’t see processes being governed except for with some of the enterprises who are further along in their journey. Understanding the intent behind API governance in the beginning, but also over time determines the tone and effectiveness of enterprise API operations.
