To make a success of opening up an information system, both the benefits and the limitations of API Management need to be fully understood

Business transformation is increasingly based on developing value chains with the wider ecosystem. More and more attention is being paid in this regard to APIs (Application Programming Interfaces) and their role in enabling applications to interact together under predetermined, properly documented conditions.

API governance: an obvious response to the growing number of interchanges with partners

API Governance through an API Management solution is entirely warranted when the number of partners and APIs is expanding and the accompanying implementations have to be managed, including interface agreements, explanations and documentation, etc. In other words, once the scale of interchanges with its ecosystem makes standardisation necessary to prevent this process slowing down. The risk is that the roll out of services and support to partners is similarly hampered.

API Management is intended to be a response to these challenges of scalability and reusability. API Management software consequently gives control over APIs through management of the publication, promotion and supervision of data interchanges between the relevant supplier and buyer departments, all within a secure and upgradeable environment.

The specific challenges met by an API Management platform are:

• Standardise API publication
• Administrate exposure and consumption, i.e. keep control over what is distributed
• Manage the full lifecycle of your APIs (initialisation, versioning, withdrawal, etc.)
• Centralise internal and external API distribution
• Manage API consumption
• Automatically document APIs
• Provide a developers’ workspace with a sandbox

Monetise API consumption

API Management (or governance) must therefore deliver on a number of promises:

Focus: What is an API gateway?

An API gateway is a component in an API Management system.

As part of an API Management solution, exposing an API gateway architecture to the outside provides control over what enters from the outside and what happens internally. It channels all incoming requests and outgoing responses through a single point to provide security and control over the associated accesses. A gateway component will offer a full set of transcoding, exposure and communication optimisation functions. It should also be entirely scalable.

Talking more broadly about the concept of a gateway, taking the example of Blueway, several types are found in API Management solutions:

• A dedicated subscriber gateway: organisations consuming APIs can see to which APIs they are subscribed, and access their consumption statistics, via their own portal. Access tokens are used to make authentication secure.
• A centralised gateway dedicated to monitoring your stock of APIs: a comprehensive overview of all of your APIs means you can easily manage and enhance them and configure their exposure. Track consumption and the technical health of your APIs through a gateway to all the consumption logs and statistics for your APIs. Manage your customers’, suppliers’ and partners’ subscriptions to your APIs over periods and using criteria of your choosing.
• A developer platform: all the documentation for your APIs, their structure and the tools made available will enable developers to run tests independently.

Creating and managing APIs: two separate yet dovetailing issues

While API Management solutions are essential to govern interchanges with your partners, the boundaries need to be clear. An API Management system is not designed for building APIs, but for coordinating their exposure. The APIs have to be built first.

API Management consequently exposes services that already exist in the information system. APIM is also not intended to structure or re-engineer your in-house information system.

Implementing API Management software will therefore not meet the challenge of APIzation of your information system. Before pressing on with your choice of API Management software, you should step back and examine a number of key questions. What services do you need to expose? What business requirements will be met? What is the expected level of granularity? How mature is your ecosystem? What KPIs do you plan to monitor?

The other side of the coin to bear in mind is that exposing a service just because you can is of no benefit to anyone! Actual requirements must inform your integration and APIzation strategy.

It is therefore only after the first APIs have been defined and are available in your information system that an API Management solution will show any real value. However, it is not necessary to have set up all your APIs before you begin. The process can be iterative. A ‘Big Bang’ approach is best avoided.

How then should you build the APIs to be exposed

Your APIs can be developed using your own code and development frameworks. However, API Management really does benefit from a foundation of IS re-engineering and a service-oriented architecture (SOA).

In any event, separating the APIs already in the internal IS, and clearly defining what enters from the outside and what happens internally, is an important stage before exposing a gateway architecture.

This view of API governance is consistent with Blueway’s beliefs: the response to any issue cannot be purely technical. Technology is a means, not an end in itself.

To avoid shoehorning a response to fit the technical scope of any given software, an overall picture of data interchanges is needed, including processes, master data repositories, data transport and openness to the outside world.

In this case, re-engineering the information system is the foundation for building exposable services that will become your APIs. An ESB (Enterprise Service Bus) approach makes it possible to implement a service-oriented architecture (SOA) with standardised and reusable data interchange components.

With an ESB, data interchanges are standardised and are conveyed in the IS using an application bus. Various applications in the information system then subscribe to the relevant services.

API Management software will then help to extend the SOA strategy being applied to internal IS to data interchanges with your ecosystem. It can also help take full advantage of external APIs.

Clear distinction must therefore be made between the orchestration of internal services managed by the ESB and the governance of interchanges with the outside managed by API Management software. Your transformation requirements determine the value to be gained from each tool, not vice versa.

!