--- published: true layout: post title: Good API Governance Is Just Guidance tags: - Governance - Guidance - Provenance - Policies - Platform image: >- https://kinlane-productions2.s3.amazonaws.com/algorotoscope-master/copper-circuit-central-park-winter-walkway.jpeg --- This is one of my oldest API governance phrases, and my wife just reminded me after listening to API blah blah blah during a couple back to back calls, that I need to write a blog post titled—-Good API governance is just guidance. It sounds nice rolling off the tongue, but it also makes a ton of sense on the ground in enterprises. Whether you are governing APIs or a country, governing with rules will only get you so far, and seeing API governance as about guiding teams who are producing APIs will set a much healthier tone for your work. The current tone of API governance is very focused on API governance rules using Spectral and other formats, then automating those rules as part of CI/CD pipelines, whe everyone really should be focusing on guiding teams forward by enriching rules with the following. - **Guidance** - Show teams producing APIs what they need to do to deliver a high quality API experience by providing links to documentation, videos, blog posts, code snippets, and artifacts. - **Policies** - Providing the business and more importantly the human reason why a particular rule will impact the business bottom line, the experience for consumers, and other relevant areas. - **Provenance** - Sharing the story behind why a rule or an aspect of governance the way it is, helping illuminate how we got to where we are at with governance for teams producing APIs. - **Platform** - Provide common infrastructure, services, and tooling to do the work when it comes to specific aspects of governance so that teams producing APIs don’t have to carry the load. - **Evangelism** - Create videos, write blog posts, share helpful tips and guidance with teams via the communication channels, services, and tooling they are already using as part of their day. It is unlikely you got into the role of API governance to be a governor and enforcer of enterprise policies and rules. I am guessing you are there because you have seen first-hand the impact of poorly designed and delivered APIs. Avoid the common pitfalls of defining a single set of API governance Spectral rules and then enforcing them via CI/CD pipelines-—this is the quickest way to fail at API governance. Do the hard work to properly define your API governance rules and align them with your business using relevant policies, share the history behind your governance rules using provenance, connect governance to what is already happening as part of your API platform work, and make sure you do the evangelism necessary to get people involved in API governance. If you do the work to properly define the way your enterprise works, how teams operate, and invest in the areas above, your API governance will just be seen as good API guidance.