Demystifying API Management: Concepts and Demarcations

Digital transformation is on it’s way and the industry is required to adopt the new concepts and techniques, like the Internet of things (IoT), Cloud and Enterprise Mobility. Due to the chances provided by that, new business models arise, which need to be evaluated by company’s to not lose valuable market shares and to stay in touch with the competitors. One topic, which is essential and thus is a key enabler in the context of a successful digital transformation strategy, is API management.

Why that?

To be able to keep up with competitors from a long-time perspective, companies need to focus on their core business. As a result of the progressive digitalization, the value of information will become more and more important for businesses; information will become the new currency! Since companies start focussing on their core business, external services are used in the context of information gather, which are e.g. needed to support business decisions. To guarantee a consistent and secure exchange of data over corporate boundaries, stable and robust APIs are needed. To manage those APIs is one key area of an API management approach.

At this point an experienced developer would say: “Stop! We are using and developing APIs for years now, why should there be any new challenges today?”. Good point! But when digging deeper and asking questions about what managing an API means, the answer is usually closely related to API lifecycle management. It’s an important topic that’s for sure, but API Management in today’s digital business is much more than that and this is what I want to outline within this blog post.

API Management

To make it clear from the beginning: API management is not just introducing a tool respectively a piece of software. It is also not just versioning and documentation of an API. API Management is a complex discipline, which needs a proper, long-term strategic planning. Oracle ACE Director Luis Weir gives a very good definition, on what API management really is about:

API Management is the discipline that governs the development cycle of APIs, defining the tools and processes needed to build, publish, and operate, also including management development communities around them. (https://goo.gl/uKiUoy)

 

According to this definition, API Management has different flavours, from which API Lifecycle management and API Security respectively API Gateway are only two. In today’s digital business, there is also a need for API Analysis, to allow complete usage tracking which is important regarding a later monetization for external as well as internal API consumers. In addition, as APIs are build, managed, discovered and consumed by different personae, a central platform is needed, which allows the management of the needs the different personae might have.

API Gateway

It is important to understand that API Management and API Gateway is not the same. In discussions I often have the feeling that this is not clear.

An API Gateway as such is a concept how APIs are exposed to the outside world. So usually an API Gateway is a software component that allows to implement security features, like basic authentication as well as authorisation, throttling and maybe protocol translation. So the API Gateway acts like a gatekeeper fora company’s information that are exposed by public APIs. Usually the API Gateway is something which is deployed in the DMZ.

API Gateway vs. ESB?

Most API management platforms, offered by platform vendors like Oracle, Computer Associate or Mule, include an API Gateway component. For some vendors the API Gateway can also be used to implement business logic like data transformations. Since this overlaps with functionalities that are usually delivered by an ESB, this may be confusing for users and leads to questions like: “Why do I need an ESB, if I have an API gateway that provides similar functionalities?” (or even vice-versa, in case there is already an ESB in place). Good question!

To answer such kind of questions, it helps to take a step back and think about concepts of an ESB.

Enterprise Service Bus (ESB)

The concept of an ESB means to establish a central hub within a company that is responsible for connecting different services respectively systems, all having different data formats and using different protocols with each other.

In this context, an ESB as a technical software component is responsible to validate, transform and route messages between the different systems. In addition, additional integration logic, like message enrichment or message splitting, might be implemented in the integration routes. Furthermore an ESB is optimised to handle a huge amount of transactions in parallel.

In a modern IT system landscape, an ESB should be used as the central integration backbone. So from a strategic perspective, an ESB is the heart of a company’s integration strategy, which is base for every digital transformation strategy.

Back to the original question…

After this short breakout, we try to answer the question, why an ESB is needed, if an API gateway that provides similar functionalities is already in place:

For sure there is maybe no technical reason to do so, but there are many good reasons from a conceptual perspective, to separate the two areas also from a tooling perspective:

• API Gateway
  • Acts a central entry point to a company
  • Exposes public APIs
  • Should not implement any business logic
  • Responsible for API analytics, like usage tracking
• ESB
  • Acts a central integration backbone
  • Used internally for integrating heterogenous systems and services
  • Should not expose functionality to the outside world
  • Provides new internal services and APIs

According to these explanations, the most valuable and future-oriented solution with respect to digital transformation is to combine API Gateway and ESB.