Beyond API Design Governance and Moving Towards Operational API Governance
When you talk about API governance, 90% of the people you encounter will assume you mean the governance of a single definition of an API, and not multiple versions of an API, or the operations and lifecycle surrounding an API. Leading edge API governance solutions like Spectral>a help you effectively codify the patterns you are using to define and design consistent APIs across your operations, but until recently there hasn’t been much in the way of helping you governance change across APIs, and how you deploy, document, test, and operate your APIs. API design governance is critical as part of API operations, and we have a lot of work to do when it comes to getting API teams applying consistent standards and patterns when designing and iterating upon APIs. However, I am also seeing more investment in API governance that is more about operational level API governance, than just focused on the design of APIs.
API design governance focuses on the surface area of your APIs using OpenAPI and other API specifications. Governance at this level is critical, but it is also important to be governing across multiple versions of an API, looking not just at each API in isolation, but also in context of previous versions, otherwise you will always possess a limited view of what is happening. It is natural for us always to be looking to the future, but it is also important that we are building a future that doesn’t ignore the past, because not all of our consumers will be moving forward at the same pace, or with the same context. Being able to see breaking changes across multiple versions of our API is an important place to begin with this type of operational level API governance, but then we should be able to go even further, understanding the impact of change across our consumers. Like design governance, we are going to have to automate the governance of change across our APIs, otherwise we just won’t be able to keep up with the change occurring across operations.
Beyond design governance and design change governance, I am seeing more investment in governing the operations around APIs. Ensuring that each APIs have a workspace or repository, that API document exists and is up to date, as well governing that there are always contract, performance, and security tests present for each API. Governing the design, development, deployment, and even management of APIs across teams. Realizing that there are APIs behind our APIs. And using existing API testing, CI/CD, and automation infrastructure to govern the operations and lifecycle that surrounds each API. Helping us standardize how we deliver and operate our APIs, enabling teams to move across a well-known API lifecycle, using the right platform enabled tooling to iterate upon APIs as part of an existing software development lifecycle (SLDC). Governing API operations using the APIs that exist behind our existing infrastructure, using the artifacts they generate to govern the state of API operations, while also making them more observable using existing outputs. Moving API governance well beyond just the design of our APIs, and helping stabilize the operations around them.
This type of operational level API governance is only beginning to take root, and many enterprise organizations are still getting a handle on API design governance, but once organizations begin realizing they can enable their teams to be more productive and efficient through enablement at the design, but also deployment and management layers of their operations, you’ll see this space rapidly expand. Both design and operational level governance will be further restricted by the absence of higher level API governance, with teams struggling to realize consistency across domains if there isn’t any leadership steering the ship. The majority of my API governance storytelling in 2022 will be focused on design governance, but you’ll increasingly see me include more operational API governance guidance, helping onboard enterprise organizations who are just getting started, while also investing in what will need to come next. Experimenting with ways of address change management through governance and enablement, and shape how we document, test, secure, and observe our APIs at scale across teams. Pushing the boundaries of what is possible when it comes to what API governance means, and innovating out ahead of where the conversation is at today.
This article originally appeared here.