API Architecture as Organization's Integration Architecture

API stands for Application Programming Interface. Sometimes when talking about APIs, the terminology can get a little confusing, so let’s repeat the basics:

• OpenAPI: A standard that defines how an interface should be described and documented.

• Public API: Any interface that is published on the open Internet and is publicly available. The interface does not need to implement any standards to be public.

• Partner API: an interface published on an open network to a limited number of consumers who have somehow been accepted as users of the API and with whom some form of agreement has been established .

• Internal API: An interface published on an internal network for use by other services or systems in an organization. May or may not be implemented according to the OpenAPI standard.

In other words, interfaces that implement OpenAPI standard can also be published on organization's own intranet for consumption by their own systems. Often, OpenAPI and API catalogs are only talked about as enablers of digitalization and new sales channels, but APIs are sometimes a good solution for implementing organization’s internal integration architecture - i.e., modern SOA (Service Oriented Architecture).

API Architecture and Microservices

Microservices are often nominated as SOA's successor. They are APIs that include an entire business function and are not mere integrations to other systems. The idea of ​​microservices is to scale elastically on a cloud platform with no dependencies on other systems (uncoupled). Microservice development is thus practically pure software development. If an organization already has ERP or CRM in place for which APIs are being built, microservices are not the right choice.

Miniservices are otherwise the same thing as microservices, but they can be loosely coupled. In this case, elastic scalability is not achieved, but functionalities of the ERP or CRM do not have to be built from scratch.

Microservices are suitable development model for an organization that cannot use any off-the-shelf software because there is none. Miniservices, on the other hand, are the right choice for an organization that wants a general-purpose API architecture to support an existing system landscape.

When to Choose the API Architecture?

An internal API architecture should be considered if the parties consuming the services are able to call the interfaces and don't need to be triggered. If the integration platform acts as a process initiator, traditional integrations and batch runs may be a better choice.

APIs are also a great way to hide old systems in the background. Every organization has systems of different ages with different interface solutions. The services provided can be harmonized by hiding older technologies behind APIs: in this case, the API acts as a façade between the consuming parties and the back-end system. And when the backend system reaches the end of its lifecycle, it can be switched to a newer system (or even several different systems) without the need for the parties consuming the APIs to make any changes. The APIs add additional years to the backend systems' lifecycle and shortens the time to start consuming the services because the services are made independent of the programming language and device according to common practices.

APIs are also a good choice if the goal is to create services that collect data from multiple sources. The sources can be back-end systems, database tables, or other sources.

General Services

The idea of ​​API architecture is to provide services that are consumed by multiple parties. One can succeed making point-to-point integrations even with APIs, if each interface is customized for one single consuming party. In the API architecture, the keywords are generality and scalability. Therefore, when designing APIs, it is important to identify what data is being shared and to whom. As always with integrations, the main question with API architecture is: what is your organization’s business need for this service?

There is little joy in publishing services if no one in the organization knows about their existence. Search engine optimization is not possible on the intranet, so when publishing services, it is important to manage the internal information sharing of the organization so that those who need and consume information know about the published interfaces. API management can also be practiced within the organization. If the organization also has public interfaces, the external and internal interfaces can be divided into different sections using the API management tool. This allows all APIs to be managed on the same platform, but users can only see part of the interface descriptions at a time, depending on whether they are on an intranet or a public network.