API Management experts | API Management technologies

What is it?

API Management is, from a technology perspective, a suite of tools which enables organisations to deploy and manage APIs. More broadly, it is the capability that enables an organisation to control and govern its API estate and the associated lifecycle of those APIs. There are 5 typical key features we expect to see in an API Management technology:

Developer Portal – attract and engage developers
API Gateway – secure and mediate traffic between API consumers and backend services
API Lifecycle Management – manage the process of designing, developing, publishing, deploying and versioning APIs
Analytics – provide insight on usage for product owners, administrators and developers
API Monetization – enable providers to package, price and publish their APIs

API Management technology can be procured/engaged in a number of ways:

Subscription based technology to run on-premise or in the cloud (WSO2, Kong HQ, Mulesoft, Axway)
Consumption based technology (Microsoft Azure, Amazon, Google Apigee)
Open source technology (Kong, Google Apigee, Gravitee.io)

Whichever path you take to acquiring the technology, understanding its value to the organisation should quickly become apparent for everyone involved.

Value proposition of the capability

When an organisation engages in producing APIs for consumption by developers it should become clear that achieving and maintaining consumption should ultimately be the business goal. This is especially true where an organisation has some focus on API monetization. The developer portal is key to consumption. The documentation it provides, and the quality of that documentation, underpins the success of the developers in consuming APIs.

API Lifecycle management features are key to ensuring that what hits the developer portal is fit for consumption. APIs generally don’t get consumed unless the design of the API lends itself to consumption. The exception to this is if the value of the data behind it outweighs the needs for good design. That lasts as long as there isn’t a competing data set or comparable value elsewhere. Where comparable value exists elsewhere, experience of the API becomes defining.

API Monetization features allow organisations to package their APIs as products. Increasingly APIs have product managers. Defining product subscriptions, API Keys etc are all key to the monetization of the API. Analytics enable us to understand the success of our APIs as well as troubleshoot and operationally manage them. The API gateway is the bridge between the API and the backend services that they connect to. Enabling us to secure and mediate the traffic between the consumer and the data services.

The value proposition of an API Management technology is in bringing this all together into one coherent whole. Not just bringing together the technical components and features, but crucially the stakeholders that make an API Management initiative/implementation a success.

Common uses or use cases

API Management is normally implemented as the focal point for API initiatives. It’s the presentation layer or facade for development elsewhere on APIs. That may take the form of microservices development, integration development or as a facade on top of an existing application or system’s APIs. It allows organisations to consolidate all these activities into an almost ‘one stop shop’ of APIs in the organisation.

The initiatives that occur behind an API Management technology are generally about meeting a functional need. The API Management layer is about meeting consumption needs like:

Accurate documentation or API contracts
Consistent authentication and security
Lifecycle management and versioning
Ability to mediate and monitor API consumption
Understanding APIs as products for consumption

The final point is probably the most important in terms of consumption. If we want APIs to be utilised or consumed then we need to look beyond the functional need and see the API as a product. There will be many organisations out there looking at their API Management implementations as little more than a gateway or proxy i.e. in functional terms. The most successful organisations with API Management technology see it as a product even if that product is only ever about internal consumption in the organisation.

Implementation Best Practices

The API Management end of an implementation is often distinctly separate from the other development activities that sit behind it. It would also be reasonable to expect it to come after those activities in the project planning. However, if an organisation is thinking and designing in consumption terms it should really be prioritising the API Management activities up front. Designing for consumption. When we think of API Management, we generally consider the roles of API Designer, Developer and Administrator. We should be considering assigning a product owner or product manager to the API. Responsible for it’s roadmap and agreeing its feature set with the key stakeholders.

Integration developers often find themselves post delivery of an integration process building an API contract (Swagger definition) for the service they have developed. This really should happen as an integration design activity. Documenting the API contract up front, designing the data schemas and thinking about how the process will or can be consumed. We should avoid creating a product in a API publisher portal to affect getting a subscription key for authentication at the end of delivery. We should be thinking about the product upfront and the likely subscriptions and use cases required for that product.

How do technologies differ?

Beyond the 5 key features we expect to see in an API Management product, we may see differentiation of products in terms of additional functionality or particular strengths in certain areas. Integration with subscriptions billing systems like Stripe for example for monetization. Combination of API Management capabilities with integration capabilities to enable service chaining. We may also see particular strength in the API design tools or quality overall of the developer portal experience.

The other key area of differentiation in API Management is in how an organisation pays for it. This can affect the overall uptake of a technology. An open source implementation may quickly address the functional need in an organisation. However, a lack of investment and prerequisite business case for that investment may never see APIs addressed as products of value within the organisation. An up front investment in a subscription based technology may force an organisation to think more seriously about value beyond features. Likewise with respect to consumption based pricing models, is our cost in consumption stacking up at the value end in API utilisation?

Considerations

The when and why of API Management can be different from organisation to organisation. There are lots of ways to generate and provide APIs. Typically, an organisation is going to have, or plans to have, a meaningful number of APIs before investing in this type of technology. The important point to reiterate is that we should think beyond the functional need to more of an API Management initiative or strategy.

Organisations should be thinking of the roles in the organisation that the technology supports as much as the functional needs it meets. If we’re not thinking in terms of API designers, developers, administrators and product owners then is this the technology we are looking for? If you just need strong documentation and design capability then maybe it’s an Apiary or SwaggerHub type service that the organisation should be considering.

Why Chakray?

Chakray has extensive experience working with a number of API Management technologies in the market including WSO2, Amazon AWS, Microsoft Azure, Kong HQ, Gravitee.io and Traefik Labs. More important is our knowledge of the discipline of API design, development, deployment and management within these generic technologies. This enables us to work with customers globally, across industries and technologies on their API Management initiatives.