API Management – Why it matters?

Sven Bernhardt, Danilo Schmiedel OPITZ CONSULTING Deutschland GmbH

Schlüsselworte Digitalization, Integration, Middleware, API Management

Motivation Digital transformation is on its way and the industry is required to adopt new concepts and techniques, like the Internet of things (IoT), Cloud and Enterprise Mobility. As a matter of that, new business models arise, which need to be evaluated by companies to not lose market shares and stay in touch with the competitors.

Figure 1: Bi-modal IT [6]

Gartner’s vision of Bi-modal IT seems to become more and more the reality, which besides all chances, also brings a lot of challenges companies have to deal with. One essential topic for implementing the ideas of Bi-modal IT is API Management – at least from our point of view. In addition, it is also a key enabler to define a solid strategy, in order to meet the challenges with respect to digital transformation.

Why that? To be able the keep up with competitors from a long-time perspective, companies need to focus on their core business. As a result of the proceeding digitalization, the value of information become more and more important. Phrases like “Data is the next big thing” [3] or “Data is the new oil” [4] from business show the value and emphasize the meaning of information for companies and their business-relevant decisions. Consequently, due to the increasing value of information, new business models come up, where data is shared between companies by providing public APIs to allow external access to a company’s data and information. For consuming the provided services, the consumers are charged. As it can be seen this means a new way for companies to generate revenue. As an example let’s take Expedia [5]: From $2 billion revenue, about 90% are gained by the public APIs they are providing and not by selling holiday travels, as might be expected.

The way to get there and start with those new business models is challenging. The business has to identify use cases and think of possibilities to adopt the new ideas for the specific segment where a company is working in and also for a company’s IT, since it’s the responsibility of the IT department to enable the new digital business models. For IT departments, this means on the one hand that services and data, which are part of a new business model needs to be exposed using to be defined APIs. This is important since APIs are defining the “door to an enterprise’s information”, which should be open for everyone, who is permitted, but should also keep out all others. To guarantee a comprehensive and secure exchange of information with the outside world, a consistent API Management approach needs to be defined.

API Management API Management means much more than just introducing a tool respectively a piece of software, like an API Gateway for securing APIs. 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.” [1] According to this definition it can be seen that API Management has different flavors, from which API Lifecycle Management and API Security are only two. In addition, there is also a need for API Analysis, like usage tracking which is important regarding a later monetization, and since APIs are build, managed, discovered and consumed by different personae, something like central platform that needs to be managed, needs also to be considered.

Figure 2: API Management [1]

API Gateway An API Gateway as such is usually a software component, used to manage public interfaces. Key features of an API Gateway are security, like basic authentication as well as authorization, throttling and maybe protocol translation (e.g. XML2JSON or JSON2XML). So the API Gateway is something like the gatekeeper for a company’s information that are exposed by public APIs (see Figure 2).

Figure 3: API Gateway [2]

Usually the API Gateway is something which is deployed in a company's DMZ.

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 optimized to handle a huge amount of transactions in parallel. As it can be seen from that explanations, an ESB is used as the central integration backbone in a company’s IT system landscape. So from a strategic perspective, an ESB is the heart of a company's integration strategy, which is base for every digital transformation strategy.

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. This is 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). For sure there is maybe no technical reason to do so, but taking the explanations from the sections above, there are reasons from a conceptual perspective:

• An API Gateway should not implement any business logic • An API Gateway acts a central entry point to a company and should enforce policies, by

securing the exposed APIs • An API Gateway is responsible for API analytics, like usage tracking • An ESB is used internally for integrating heterogenous systems and services, but should

not expose functionality to the outside world • An ESB may provide new internal services and APIs

According to the explanations above and this is also my view, the most valuable and consistent solution with respect to digital transformation is to combine API Gateway and ESB, because there are dedicated use cases for both of them. In one of the next section regarding architectural considerations, we will see how this may look like.

Architectural considerations When talking about architectures we should first of all take one step back, to look at how integration infrastructures are designed today and what kind of problems that architectures are addressing. In addition, it is important to understand, what kind of considerations needs to be done when defining a new architecture to handle the upcoming challenges.

Integration style When talking about integration architectures today, we usually mean integrating different Enterprise Information Systems (EIS). With respect to Gartner’s Bi-modal IT idea, this means that we are mainly focusing on the so called “Systems of Record”, like ERP and CRM Systems, which are stable and depict core business functionalities.

Figure 4: Bimodal IT

In this area of integration software platforms like Oracle SOA Suite and Service Bus are used for implementing integrations between the Systems, e.g. for harmonizing data between those Systems. Basically those are typical SOA-style integrations, as we already do for many years now. It is important to build a solid fundament for a company’s business, because it helps to make the IT system landscape more comprehensive and decouples systems from each other. But it is not capable to further innovation and to allow the elaboration of new business models, because changes in the “Systems of Record” cannot be done in an appropriate duration of time. On this level changes are done slowly, because nothing should break the existing functionality; the reliability and stability of the existing solution is the most important thing. Innovative ideas and solutions are designed and created in the area ”Systems of Innovation” (see Gartner’s Bimodal IT). To make this happen as fast as possible and also to allow first productive tests in a very early stage of a new Product or Service, a Lean Startup mentality is needed: Start with an idea, implement a Minimum Viable Product (MVP) and then further elaborate and evolve or throw it away. To support this in a proper way, a consistent API Management approach is key to reuse existing functionalities. Combined with a Microservice, where the Microservices depict the new functionalities, this approach is the key for approach the challenges of the digital transformation.

API First As already mentioned APIs are essential for exchanging information across company boundaries or even between different departments within the same enterprise. Before starting with the implementation of new Services to depict the additional needed functionalities, an API’s contract should be defined that contains information about functional (e.g. operations, data structures) as well as non-functional (e.g. availability, response times) characteristics. The advantage of this API First approach is that an almost robust definition exists from the beginning, which enables API implementers as well as API client developers to start working in parallel. Modern API design tools, like Apiary [7], are supporting an API First approach. The design of an API should be done by following six simple Rules of Thumb [8]:

• Be minimal • Be complete • Have clear and simple semantics • Be intuitive • Be easy to memorize • Lead to readable code

Following those simple guidelines will lead to good APIs, which can reach a high user acceptance and so will find a good spread.

Managed vs. Non-Managed APIs When talking about API Management it is important to understand what kind of APIs needs to be managed. It is a matter of fact that not every API, which is available on an enterprise level needs to be managed; APIs have to be distinguished based on their characteristics. For instance, if an API is defined for just one single purpose, e.g. for supporting a specific marketing campaign that is valid for just a few days, it doesn’t make much sense to manage such APIs. On the contrary, managing every API is misleading and undermines every API Management strategy, because consequently one would end up with an unmanageable amount of APIs.

Blueprint for API Management Architectures Modern API Platforms, like Oracle API Platform Cloud Service, consists of a Management Portal, for defining and managing APIs. Using this Portal, different Personae, like the API Developer or the API Manager, are supported to execute their tasks seamless and consistently. Typical tasks in the context of API Management are for instance the creation of APIs, the definition of specific Policies for the newly created APIs and the corresponding lifecycle management. Today those API Portal solutions are often Cloud-based solutions; the On-Prem Portals are about to die. In addition, the API Platforms usually provide an API Gateway component, where the defined APIs, including the corresponding policies, can be deployed to. An API Gateway is the entry point to an enterprise’s Services and information and as a matter of that it has to be deployed in a company’s DMZ.

Figure 5: Exmaple API Management Architecture

After passing the Gateway the underlying Systems and Services within the enterprise are involved to deliver the corresponding functionalities, as depicted by Figure 5.

Summary As it can be seen from the explanations before, defining a consistent and comprehensible API Management is a very important building block for creating a future-proven IT architecture and allow companies to create new products and services that can be used to differentiate themselves from the competition. Classic integration or SOA approaches are no longer applicable to approach all the challenges, which enterprises have to deal with frequently changing business requirements and rapidly evolving concepts and technologies. This where amongst others API Management jumps in and is one key pillow for success. From our point of view, companies should directly start thinking of how to redefine their Enterprise IT architectures on the one hand and also the IT organization, because all those changes cannot be done by solely addressing the arising challenges with technologies and new IT concepts.

Sources:

• [1] http://www.soa4u.co.uk/2015/08/oracle-api-management-implementation.html • [2] http://microservices.io/patterns/apigateway.html • [3] http://www.forbes.com/sites/perryrotella/2012/04/02/is-data-the-new-oil/#4441e25c77a9 • [4] http://ana.blogs.com/maestros/2006/11/data_is_the_new.html • [5] http://www.forbes.com/sites/mckinsey/2014/01/07/ready-for-apis-three-steps-to-unlock-

the-data-economys-most-promising-channel/#161145a789e5 • [6] http://www.gartner.com/it-glossary/bimodal/ • [7] https://apiary.io/ • [8] http://www.designprinciplesftw.com/collections/six-characteristics-of-good-apis

Kontaktadresse: Sven Bernhardt OPITZ CONSULTING Deutschland GmbH Kirchstraße 6 D-51647 Gummersbach Telefon: +49 (0) 2261 6001-0 Mobil: +49 (0) 172 2193529 E-Mail sven.bernhardt@opitz-consulting.com Internet: www.opitz-consulting.com Danilo Schmiedel OPITZ CONSULTING Deutschland GmbH Tempelhofer Weg 64 D-12347 Berlin Telefon: +49 (0) 30 6298889-0 Mobil: +49 (0) 173 7279001 E-Mail danilo.schmiedel@opitz-consulting.com Internet: www.opitz-consulting.com