APIs are very often put forward in the field of integration and middleware. However they cannot represent all the diversity of integration patterns on their own. In fact, several integration technologies must be combined to cover all use cases. For example, we can bring together the two major integration market patterns (modular logic carried by API Management and mass logic carried by Data Integration) to form a common integration approach: a second-generation hybrid integration platform. What does this look like in practice? Read our article to learn more!
In the field of integration and middleware, APIs are at the forefront. However, the API market alone cannot cover all the diversity of integration patterns.
As we discussed at API Days, a combination of an API Manager and an ESB (Enterprise Service Bus) is not uncommon and can cover obvious cases like the one shown below:
Combining integration technologies to cover all use cases is an obvious issue. The construction of integration platforms is proof of this since it allows the company’s integration assets to be coherently and completely implemented, by managing APIs, events, files, services and data in a common way.
However, the integration market itself is evolving, which may impact the very construction of these platforms. To understand the dynamics at work, we need to look at the breakdown of revenues by segment, projected over five years:
The growing segments are quite clearly:
● API lifecycle management suites aka API Management,
● iPaaS (integration Platform as a service),
● Data integration solutions, among which we include Data Virtualization solutions,
● Robotic Process Automation (RPA).
On the contrary, the decreasing segments are:
● ESB, quite clearly,
● To a certain extent, Managed File Transfer, pure B2B solutions and Business Process Management Suites (BPMS)
This decline is underway and we can indeed estimate that it is initiated by the domination of API Management solutions, but also iPaaS, with two different logical approaches:
● API Management remains a technical subject carried by dedicated competence centers in which we will find architects and developers,
● iPaaS aims to bring integration within reach of a wider audience, based on a large number of application connectors, an assisted and graphical development process with a light knowledge of programming, and accessibility in the Cloud.
This five-year projection shows a potential decommissioning of ESBs, which will eventually disappear, but they are still part of the existing business environment and will have to be dealt with for a few more years.
However, if we look at the growing segments that will eventually structure the composition of platforms, we can assume that iPaaS will remain a stand-alone technology, connected to platforms but not very integrated, because it is aimed at a specific category of users, with less need for governance.
We can then see that the integration market is built around:
● A modular logic approach carried by API Management,
● A mass logic approach carried by data integration.
The real challenge for platforms is to bring these two major patterns together to form a common approach to integration, a second generation hybrid integration platform, which can be represented as follows:
The Service/API approach and the Data approach are specific and remain so in this representation. However, they are brought together by other levels: ingestion, security, and most importantly, the integration scenarios. We will describe the different levels of this platform in the rest of this article. Stay tuned!