IT architecture integration based on API-led Connectivity

API-led connectivity is a concept based on connecting data between systems through reusable and purposeful APIs (Application Programming Interfaces). This connection is a method of delivering services within the meaning of Service-orientated Architecture (SOA).

Read this article to find out:

• the nature of this integration model
• how this model is different from other solutions
• the pros and cons of this model
• its application areas

---

In most cases, data is transferred between systems based on the following pattern: data sourcing > transformation > delivering data to the user. However, there is an approach based on the introduction of finer granularity and multi-level integration mechanisms. This approach opens up many more opportunities for both data recipients and data owners.

We are talking here about API-led connectivity, a concept based on connecting data between systems through reusable and purposeful APIs (Application Programming Interfaces). This connection is a method of delivering service within the meaning of SOA.

In this approach, APIs – structured interfaces that enable communication with data sources – are purpose-built: to obtain “raw” data from source systems, integrate them with business processes or deliver a specific business value to users. APIs fall into three categories:

• System APIs – they provide access to data obtained directly from source systems. They insulate the user from complicated logic and system structure, while ensuring the full compatibility of the interface with the source system. Once created and kept updated, API can be used as the basic source of data for many potential users, without the need to know the source system.
• Process APIs – created for the purpose of business processes, they interact with System APIs by obtaining data from them, then putting them into specific structures independent of source systems. Process API can obtain data from many System APIs, which breaks down data silos in the organization (no data sharing and data is isolated only for the purpose of a particular infrastructure segment).
• Experience APIs – simple APIs responsible for providing end users with data obtained from source systems by means of System APIs, and processed through a series of Process APIs. The data can be used by all applications, regardless of their structure, technology, platform and application. Experience APIs can use one or more Process APIs, composing or recomposing data structures.

The above concept of system integration breaks with the approach based on full access and centralization of information in the organization, as individual users within the company obtain access to data in a phased manner. Not everyone can or wants to have access to data directly transferred from the core system. In this case, they are “pinned” to the last API layer, which provides processed data that is fit for use in a business context.

Lying at the foundation of this API-led connectivity, APIs are fully manageable by their owners and are generally available to potential users who have access to the API directory. It is in this directory that you can check the API documentation describing API operations, as well as supported data structures, and request API owners for access to specific interfaces.

The main goal of the API-led connectivity concept is to achieve reusability not only at the level of interfaces provided to users, but also with regard to the full integration processes happening inside the integration layer (the path from the source system to the end user). In this way, in addition to providing an easy access to integration flows, the solution does not duplicate the logic contained in individual interfaces, which significantly reduces the time to market; namely the time it takes to deliver a valuable solution that meets the intended business goal.

Strengths and capabilities of API-Led Connectivity

• Transparency and availability of service – potential data users from the organization can familiarize themselves with the documented Experience APIs, and the data structures transferred within them, which is a step towards an initial self-service in the process of providing data to partners’ systems. This brings mutual benefits, as the layered nature of integration architecture ensures it is easily manageable by its owner.
• An increase in efficiency and reduction of the time needed to develop new integration solutions as, thanks to the reusability of interfaces and processes implementing integration mechanisms, the logic is not duplicated and can be used by many recipients.
• Easier change-handling in the integration layer – thanks to the modular structure and full isolation of individual API layers, if any part of the solution (on the side of interfaces or source systems) is modified, no comprehensive regression tests need to be run to eliminate the risk of any unforeseen impact of the introduced changes on the entire solution. More often than not, it is sufficient check the interaction of “neighboring” categories in the hierarchy with the API .
• The high granularity of the tailor-made architecture components makes it easier to apply modern technological solutions that are fully scalable and can be cloud-based (e.g. microservices). Mechanisms developed in accordance with the concept described may be deployed using cloud-based infrastructure right from the start. In addition, the complete solution can be easily migrated from on-premise machines to the cloud.
• Greater transparency of the integration platform – its layered structure facilitates its exploration, for example, when looking for the causes behind the incorrect operation of integration processes. This significantly reduces the time needed to study and maintain the solution.

Weaknesses and limitations

• To implement the API-led connectivity concept, you need to have an in-depth understanding of its assumptions.
• You also need to be familiar with designing, creating, documenting, developing and maintaining APIs that have been produced in various technologies and the various communication protocols they use.
• Querying a series of APIs, divided into role-based layers (categories) results in an additional time overhead related to the mutual communication between individual instances. However, these extra times requirements can be minimized through proper scaling.

Application, selection criteria

Building integration architecture in accordance with the guidelines of the API-led connectivity concept is a challenge, but in the long run it provides many business and operational benefits for the enterprise. If your organization:

• has large and heterogeneous systems in its infrastructure
• uses complicated data sharing mechanisms and structures
• plans to build new processes aimed at the safe extraction of data from source systems, and the effective distribution of the data to users, in a business-understandable form and according to the “just what’s necessary” principle

then this IT architecture integration solution will definitely do the job. However, if your organization has:

• a small scale IT architecture, consisting of several systems that need to exchange data in a basic way
• a small number of current and potential users of data from the organization’s source systems
• insufficient competences to design, build and maintain advanced integration architecture – on the side of in-house HR, or the HR of the partner who will undertake the project;

then it should look for other ways of improving the structure of its applications and data to respond to smaller-scale needs.