Result

Disruptive modification of business models

API stands for application programming interface. That might sound very technical, but the impact an API has on a company’s business model is much more disruptive than any changes that might be made to the technical architecture.

APIs enable the exchange of commands and data between different software system components. This technical capability can have a tremendous economic and organizational effect on companies in today’s networked and increasingly digital world. For example, APIs are an essential technical foundation for the creation of networked production systems, including systems that operate across multiple companies.

The large number of APIs that exist – and this number continues to increase – doesn’t make the management of IT systems and software any easier. In addition, more and more business processes and operations now rely on these APIs, which means the way APIs are used, and the way the business models they are based on are used, will become increasingly important.

In light of the fact that APIs and their management can be key elements of a forward-looking enterprise architecture solution, the Cross-Business Architecture Lab decided to create an API Management workstream. This workstream provides member companies with a neutral overview of the technical and strategic aspects of API management in a manner that takes into account the actual experiences of the companies participating in the workstream. It also examines the specific effect API management has on enterprise architecture and a company’s business model

Procedure model

The companies that participated in the workstream first defined what API management actually is and then proposed a model for a basic procedure. 

This procedure is divided into five (fully customizable) steps. First, there is the initial catalyst that causes the API issue to be addressed. After that, a strategy is defined. Implementation then begins with technical prototyping. After that comes the rollout, or the “API-fication” of the company. There is also a parallel step here for internal marketing activities. Logically, the next step is the operating phase. This step involves more than just technical aspects , which is why it is also referred to as the management phase.

Catalyst and reasons

Usually some type of catalyst causes a company to “seriously” address the issue of API management. This catalyst can originate from inside or outside the company.

Some examples:

• The company believes that “everyone else” is making APIs available and using them.
• Market considerations: Customers and partners expect / are demanding that APIs be offered.
• The IT organization recognizes the opportunities offered by APIs and wishes to create a suitable “showcase” to persuade technical units/departments to utilize them.
• New business models / API management approaches are being viewed as positive disruptive opportunities.
• A need has been identified to automate/improve existing processes (B2B or internal).

Strategy definition

In general, the great disruptive potential harbored by the topic becomes more important as developments proceed. The strategy defined for API management is part of a company’s IT strategy or digitalization strategy.

Among other things, this strategy must provide answers to the following questions:

• Why does the company need API management?
• Is the perceived catalyst the only reason, or are there other strong catalysts or considerations either inside or outside the company that need to be taken into account as requirements?
• What types of changes will APIs initiate?
• What types of measures are needed in this regard?
• What type of scope has been planned for API management?

Technical prototyping

Technical prototyping should initially be conducted as a low-risk proof of concept that includes the basic infrastructure for API management as well as a reference architecture. The various architectural starting points need to be taken into account here – for example whether a service-focused architecture has already been implemented at the company.

API-fication

After the proof of concept has been successfully tested, the IT landscape and EAM system need to switch over to an API-based operations approach for the provision of services. The API Management workstream Coordinator, Yannis Baillet, who is also an enterprise architect at SBB AG, stresses the importance of changing the company’s business model here: “Companies need to view API as a marketable product or service, and not just an interface. Let’s say, for example, that SBB were to offer an API that makes data from ticket-vending machines available to third parties. This would generate added value for many tourism companies, which would then pay SBB for this benefit.” Baillet is convinced that the business impact of APIs significantly outweighs their technical impact. “Architecturally speaking, I view APIs as an evolutionary further development,” he adds. “The things they enable in terms of business are disruptive, however, and companies need to be prepared for that.”

Marketing

Internal marketing activities must be conducted as a parallel step to API-fication. More specifically, the development community and all IT staff must be made to understand that APIs are necessary, and the business organization in particular needs to be extensively informed of the advantages offered by API-fication.

Management

After the API infrastructure has been set up and all essential connections are in place, the infrastructure has to be operated and continuously improved.

Reference architecture

In addition to defining the strategy and the procedure model, the workstream team developed a reference architecture that is structured as follows:

Providers use the API Management Platform to manage APIs and make them visible to potential consumers. The APIs are kept in the API Repository. Consumers can use the Developer Portal to view published APIs and register to use them, after which they are issued a personal API key. They can also try out APIs in the Sandbox environment. When an API from the provider publishes an endpoint (access point), the API is transported to the API Gateway and is then ready to be used productively by authorized consumers via this endpoint.

Following implementation in the Consumer System, the latter can route API calls via the Gateway, which then forwards the request to the Provider System. Before this happens, however, the Gateway checks the API key to determine whether the consumer is authorized to use the API that is the subject of the request. Depending on how an API is configured, there may be restrictions regarding the frequency or number of API calls that can be made (throttling). All API calls are logged, which enables the provider to obtain an overview of how each API is being used (via the Provider Portal Dashboard).

Additional mechanisms (e.g. OAuth) must be used if more restrictive authentication and authorization policies are to be implemented.