When I engage with folks around API governance it inevitably centers around design governance applied at design time—focusing as far left as possible on the API lifecycle. Occasionally you find someone who is keen on applying API governance as part of the CI/CD pipeline, but most folks will end up getting burnt by this far-right approach to API governance, and will end up realizing that being heavy handed isn’t sensible until the API supply chain is a little more tamed in sense of governance. Injecting governance into the pipeline is a great way to catch inconsistencies across APIs, but it is also a great way to slow the velocity of an organization when not done thoughtfully. What really intrigues me, is why are folk so interested in API governance at the extremes of the far left and right of the API lifecycle, but you don’t see much meaningful strengthening of the core of how we deliver APIs.
Design governance using a rules-based listing approach at design time makes a lot of sense. Design time is the best place to apply governance and introduce API design governance literacy, but what happens if teams are not design first? The gut reaction is always to inject governance in the pipeline, which almost always bursts into flames, leaving everyone doing nothing about governance. I am eager to push forward the conversation around how we can do a better job of strengthening the core of how we deliver APIs, providing API developers with what they need to learn about and apply governance at any stop along the API lifecycle. As a developer I shouldn’t have to wait for a version of an API to be designed, or experience the heavy handiness of pipeline governance to begin learning about and thinking API governance. This is the core of how we deliver APIs that I am looking to invest more in, helping define API governance strategies that can also be applied at design or build time, but can be utilized at any other point in time, while also rolling up into an overall API strategy.
Governance is increasing something I am seeing enterprise organizations realize they can’t ignore anymore, while simultaneously being overwhelmed with where to get started with an effective approach to the strategical and tactical aspects of API governance. It is one of those things that often gets slowed due to the overwhelming scope, but also by a lack of design-first discipline across teams. I am determined to come up with a more hands-on and modular approach to providing API governance guidance driven by simple API governance collections, and by organizing and telling the story around useful rules that can be applied as part of listing at design, develop, or build time. Like almost any other area of the API lifecycle, I feel API governance just needs a lot more workshopping and storytelling before we can get the masses of folks understanding and applying. Something that I feel should always start at design time, but due to the realities on the ground within enterprise operations, is something we will have to find other ways to strengthen the core of our API operations by applying governance wherever and whenever possible—think DevOps for API governance.
