Augmenting a specs-only approach to API governance, I am continuing to invest in a GitOps-Driven API source of truth. I don’t care if it is GitHub, GitLab, or BitBucket, but Git is the core of your API governance, and the factory floor of your API operations. These three pieces of infrastructure I give a pass to when it comes to my specs-only policy. I also require that business and technical stakeholders both equally be able to engage around APIs.json, OpenAPI, JSON Schema, Spectral rules and other custom schema. A specs-only approach combined with a GitOps-driven engine is how I will operate my strategic and tactical API contract services, but also encourage my customers to operate their own API governance programs in a similar way.
Having a single source of truth for an API is critical. I know most people will say that the code behind an API or the gateway for an API is the single source of truth for an API. They are correct when it comes to an instance, but I am talking about the single source of truth overall for an API across the lifecycle and instances. It is Git, and the handful of artifacts that define each API and the operations around them, and provides the overall source of truth for the conversation and lifecycle surrounding the delivering, iteration, and deprecation of API resources and capabilities. This is where I am going to be investing when it comes to my API governance services. This is where I am going to be operating when it comes to engaging with the API governance programs of my customers. This will give me a way to stay focused on the artifacts that are defining, configuring, and governing API operations, and stop short of the pipeline and other integrations with enterprise infrastructure, tooling, and services.
I draw the line in API governance at source control, however I don’t want to get in the way of any other infrastructure, tooling, and services being used across the API lifecycle. I am happy to share guidance regarding what infrastructure, tooling, and services could be used across the API lifecycle, but I prefer to leave it up to API platform, business, and governance leadership within an enterprise. What happens in a CI/CD pipeline and via web hooks is where I draw the line with my work, and I stay back in source control with the artifacts. I am happy to define a platform artifact with the Tyk, Kong, SwaggerHub, Redocly, Jira, Confluence, Bump.sh, AWS, Azure, Google, or any other API infrastructure, tooling, and services, and help you automate around that definition. But, I strongly encourage keeping all of these infrastructure, tooling, and services plugged in via native Git, CI/CD pipelines, and Webhooks—separating the overall API source of truth from any on-premise or cloud infrastructure, tooling, and services, while seamlessly integrating API operations wither wider enterprise operations. It is the job of Git to aggregate and accumulate the source of truth from across every infrastructure, tooling, and services used by teams across the API lifecycle.
I see GitHub, GitLab, and BitBucket, but more importantly Git as the factory floor of enterprise API operations. I see API contracts as what defines, configures, automates, and governs this factory floor. I am simply interested in the artifacts and the quality, maturity, provenance of artifacts, and leave the automation and integration of these artifacts to teams who are delivering APIs. I think teams should have the agency, autonomy, and accountability to operate their own pipelines and web hooks, and leave the governance of these to platform and governance leadership. API Evangelist is in the business of managing API contracts within Git repositories, providing a source of turret that can be applied during design, development, build, runtime or distribution. The focus of API governance for me is specifically on a GitOps-Driven API source of turn to help govern the performance and velocity of API operations.
