Capital G API Governance vs Lowercase g API Governance
08 Oct 2019
API governance is a hot topic amongst leadership and stakeholders who care about the long term health of API operations. I regularly get questions from folks about what I’m seeing when it comes to API governance, from developing an API design guide, all the way up to the deeper dive into governance I did last year for the Department of Veterans Affairs. I would say that this work goes way beyond what most organizations are ready for, but API leadership is still interested in learning more about how they should develop what I would consider to be a capital G API Governance strategy. Something I recommend everyone think about, but make sure you also think about the more organic and incremental governance efforts as well, finding a balance between the two.
I have come across numerous enterprise groups who have begun putting in place capital G governance as part of an organized effort, only to encounter resistance on the ground across teams. Resistance from folks on the ground range from not understanding what is being mandated, having better ideas on what can be done, or simply just being against anything that leadership proposes. Governance is hard work, and something that can be fraught from the beginning, depending on the nature of your organization and the industry you operate in. When I first began studying the world of API governance I was pretty against the term and the concept, but over the years I’ve learned more about what t takes to do APIs at scale across large organizations and I changed my tune. I would say after about seven years, I’m slowly drifting back towards thinking governance might do more harm than good.
I am a fan of organizations having API design, deployment, management, testing, and other guidance in place, helping govern how APIs are delivered. However, within large organizations I have begun to see more examples of how capital G API Governance can become at odds with lowercase g API governance. For example, I spoke with a group in charge of governance recently, and learned about how they had governance in place for how you publish documentation, requiring everyone publish OpenAPI, Redoc, and some other elements to a central internal developer portal and catalog—makes sense right? Then I spoke with another group within the same enterprise organization, and they were explaining how they were doing some innovative work around API documentation, going beyond the existing guidelines, but they weren’t able to publish and share because of the governance guidelines that were in place, and they weren’t getting a response about evolving governance from the central group.
This story is probably more about making sure you have proper feedback loops in place for your API governance efforts, than it is about governance itself, but I think it provides something we should consider when it comes to how we impose API governance on high, and how our well meaning work could stifle innovation and incremental improvements on the ground. Putting capital G Governance at odds with lowercase g API governance. I think this example shows the importance of going beyond just the technical aspects of API governance and ensuring we have the proper ongoing feedback loops in place, giving everyone a voice in how the API governance guidelines get established, communicated, and evolved. I think that API governance should be sure to have change baked in from the beginning so that practices don’t get stuck in any single rut when it comes each of the stops along the API lifecycle. Allowing anyone on the ground within an organization to showcase incremental improvements or seismic shifts to an organizational API governance strategy—as long as they are willing to step up and own it.
I am going through all of my research right now and reworking it all to better serve the work I am doing with Postman. A part of this includes going through all of API governance work and thinking deeply about how it all works, and fits together with the other moving parts of designing, development, and operating of APIs in production. As part of this work I am going to rethink my views on API governance, and consider how they might be bad for innovation and agility at the lower levels. I’m going to think more about how difficult it is to evangelize and gain adoption with API governance across large organizations, and what this means when you need to make incremental changes on the ground. I’m betting that API governance continues to be a hot topic due to the increased number of APIs being developed and operated on the ground within large organizations. Doing APIs well at scale across large organizations isn’t easy, and I’m looking to understand the honest realities of what it takes to realize API governance, or maybe continue eroding my beliefs that it is even necessary at all, and maybe there is a more distributed, organic, bottom up approach we should be setting into motion—moving beyond the word governance all together.