In my last post on APIOps, I looked at API first as a strategy for designing APIs. But how can APIs created in this way be found and standardized? And how can they be made usable and secure? In this article, I would like to take a deeper look at the increasingly common term API governance and show how this concept can help speed up the design process.
What is API governance?
API governance is a method of applying common rules related to standards of APIs. It also often includes the development of APIs based on a common data model with reusable resources or model objects. Finally, governance can be used to ensure that APIs are sufficiently enriched with metadata so that they can be easily used by a broader audience, both within an organization and externally.
Who needs it?
In simple terms, API governance is important for any organization implementing an API-first strategy, where APIs are at the core of their transformation to a digital enterprise. It is also important for anyone planning or already implementing a distributed microservices environment. There is one specific use case where API governance is absolutely business-critical: large enterprises. That’s because they need thousands of consistent, secure and reusable APIs – representing both business and IT functions – rather than a handful of well-documented public APIs in an API portal.
How does governance help establish speed in API design?
To build speed, a wide variety of issues need to be reconciled. The first one is to give a central core to the issues around APIs. In the literature, you will often find the term “Center for Enablement” (C4E in short). This is crucial for the introduction of governance, as it provides the appropriate framework for all further action. This also includes introducing API first in a purposeful and continuous manner, which must be supported by centrally controlled API governance. Only this ensures consistent and reusable APIs, which in turn also lead to organization-wide standardization. This requires creating and enforcing design guidelines for all APIs, regardless of the underlying architectural style (SOAP, REST, event-based). However, the design guidelines also simplify the already mentioned reusability. This is done on the basis of so-called Information Models (also known as Canonical Models in the age of SOA), i.e. proven model objects and resources that standardize organization-wide information in predefined structures.
The process, the API lifecycle, in which APIs are found, basically consists of several phases. With the introduction of API governance, it is important to be able to apply it in all phases of the lifecycle. The easiest way to do this is through automation. I described one possible way of automation, APIOps, in detail in the blog article mentioned at the beginning. In the context of this post, I would like to briefly summarize the most important points.
APIOps can be integrated into already existing CI-/CD-processes by simple means, as these processes have to be extended or adapted. The specification of an API becomes Configuration as Code within the deployment to be available via a gateway accordingly. The image shows an example of this with the Kong Enterprise Gateway with additional portal using Insomnia and Inso CLI.
A version control system is always used for automation. Therefore, the desire to version an API arises over and over. However, as I noted in the codecentric blog post on “API as a Product” in 2018, an API stands for immutability. This means that changes must always be backward-compatible. To ensure this, it’s worth keeping three short rules in mind:
1st rule: Don’t leave anything out!
2nd rule: Do not change the meaning of anything!
3rd rule: Everything added is optional.
When APIs are available for a long period of time, they may become obsolete. Again, define a policy within API governance that supports this process. This allows consumers to know when they should expect an API to become unavailable. Last but not least, the visibility of available APIs must be considered. The key here is to find a means to make APIs easily searchable and discoverable. Thus, it becomes clear that an API portal becomes a part of governance.
API governance helps save time and money by enabling consistency across APIs, allowing reuse of components, and ensuring that APIs are created proactively to achieve specific goals and add value to the organization. API governance also helps organizations make smart decisions about API programs and establish best practices for creating, deploying and using APIs.