API Maturity

API governance is utilized to drive consistency and trust through the development of APIs, but most of the work that teams do on API governance prior to APIs being published is completely hidden from the end customer. Like all great designs, the customers only experience a polished product and don’t notice the thoughtful details in the background that make it all possible.

Although the internal stages of the API life cycle are hidden from the customer, what is visible to the customer is API maturity. API maturity is a label that companies give to their APIs to set expectations with the customer regarding supportability, versioning, and backward compatibility, among others.

The following diagram illustrates the different levels of maturity that an API goes through as it gets developed and is released to customers.

Companies building commercial APIs, such as eBay, Twilio, Okta, Stripe, and others, drive customer trust by communicating clear SLAs, release cycles, and versioning in their API documentation. Making APIs robust, reliable, and scalable requires emphasis on the infrastructure side of API development. This aspect, however, is completely invisible to the end customer, who simply has to assume that the infrastructure is kept to a high standard. Because the customer may not have a way of evaluating the robustness, reliability, and scalability of a given API, the API maturity status becomes the proxy for the customer to interpret these API characteristics so that they can make decisions on using the API for their development.

API maturity communicates the following elements to customers:

• The performance and scalability of the API.

• SLA expectations for each level of maturity.

• Degree of backward compatibility for upcoming features and expectations of changes in API functionality.

• Documentation standards.

• Ownership and liability in the case of incidents and when SLAs are not met.

API maturity is closely aligned with the release process of an API. When we roll out new features in such a way that they are first tested internally to make sure they are working as expected, we can feel confident that features are working as expected. New features are then carefully rolled out to wider audiences in a beta version to set expectations and provide the opportunity to make improvements based on the feedback that is received at this stage. Only once the products are performing at close to general availability capabilities are they transitioned to general availability. This method ensures that products are released in a step-by-step way and that only high-quality products are labeled as being available to the public.

The controlled release of new products and features is a methodology that allows quality control and measured improvements to be made. When we keep the quality of products that are available to everyone high, we can set SLAs that build customer trust. In the next section, we’ll learn how the most well-known API-producing companies determine ...