A brief history of API management and where it’s going

The term “API Management” is used frequently, but it can mean different things to different people. There is no single “right” or “wrong” way to define it, but it is important to understand what somebody refers to when they talk about API Management.

One interesting way of looking at the various possible perspectives on API Management is to look at the evolution of API Management and of the API space, in general. Such a view on how the space and how practices have evolved allows us to better understand why terms such as API Management have changed meaning, over time.

Keep in mind that this is by no means is intended to be a full history of the API space in general. We will look at how the space evolved when the view on APIs became more dynamic (they change over time and that change needs to be managed effectively) when API landscapes became bigger and bigger, and when increasingly the focus in the API space is not so much on technical details but on the value that they bring to organizations.

Technical API Management

Initially, API Management was seen in a rather narrow way of managing one API and doing this in a way that was not part of the API implementation itself, but done by a separate management component. This component would perform tasks such as authenticating and authorizing access to the API, preventing unauthorized access. Another typical function would be throttling access so that API consumers would not be able to overwhelm an API provider by sending too many requests.

This kind of management typically is performed by an API gateway, a component that sits in front of the actual API, managing the access to the actual API and only forwarding requests according to configured policies.

This view of API Management is technical and rather static, but it still is at the core of any kind of API Management model: Making sure that access to an API is controlled in a way that the API is used as intended and that it cannot be easily misused or attacked.

API Lifecycle Management

APIs started appearing in greater numbers and had to be updated more frequently because of more consumers and therefore evolving consumer demands. API Management evolved alongside it, now covering the entire lifecycle of an API, and the development cycle of releasing, testing, deploying, and updating the API.

For this wider scope of API Management, additional components such as testing and monitoring tools entered the picture. Vendors had to adapt by covering these aspects as well, either in their product or through partnerships with vendors of specialized tools.

The underlying force of this evolution was to make API development more effective: Teams should be able to focus on the business logic of their APIs while repeating tasks should be addressed by using available tooling.

However, while this evolution was a useful step in terms of adapting to growing and evolving API landscapes, the resulting API Management model often was still tied to a particular API management platform.

This might be a specific software product used by an organization or part of a cloud platform, and this makes it inherently hard to adapt to more complex deployment models such as hybrid and multi-cloud. The reason for this is that API lifecycle management is still relatively tightly coupled with the infrastructure that is doing the technical Management.

API Product Management

With APIs becoming increasingly critical and visible at the business level, the next logical evolution step is to decouple Management from the technical aspects and to focus on API products. An API product is an API that is designed, documented, and discoverable in a way that can be readily and easily used by the intended audience.

With this more consumer-oriented view of APIs, it makes sense to approach API product management in a way that is independent of the technical specifics of where and how an API is provided. As long as consumers can find and use it, that’s all that matters.

This is where the concept of an API Catalog enters the picture. One way to think of such a catalog is to see it as the enterprise resource planning (ERP) tool for an organization’s digital products. Ideally, such a tool provides universal and unified visibility of all digital products and it easily adapts to whatever technical platforms are in place to provide these products.

API Product Marketing

API Product Management is where modern Management stands today. It provides a way to manage API products in a unified way, and it does not unduly constrain the way in which APIs are being developed and deployed. However, it is still very much a model where API products are made available, but they are not actively marketed to potential consumers.

It may be not too far-fetched to speculate that the next evolution step in Management is API product marketing. Like for all products, the value of products is not that they exist, but that they get consumed. This means that like for any other product category, taking a more active role in marketing APIs makes a lot of sense.

This more active role follows the usual path of product marketing: Understanding consumers, understanding their pain points, understanding and clearly documenting how these pain points are addressed by products, and then marketing these products to the target groups.

For API Management, this means building consumer-focused tools on top of the catalog, such as portals and marketplaces, and using these to actively market APIs, to understand consumption, and to feed this back into API product marketing and into API development.

This final evolution step is still in its infancy, but given the growing importance of APIs in digital transformation and the way how the economy works, it is likely that it will become the next major evolutionary phase of API management.

Conclusions

If you want to hear more about this evolution of Management, feel free to check out the following video. Also, if you have any comments about where you think Management is going, please comment here or leave a comment on the video.