Integrations have been a challenge since the creation of the second computer.
Today, they are the critical factor for companies’ successful transformation because the context is more complex, changes are happening quickly, and the traditional approach to APIs can’t keep up. Throughout the years, we have been seeing the integration landscape evolve from batch files and simple text schemas to more evolved schemas of file exchanges, such as XML.
How We Got to APIs
In the past, integration was much more of an ad-hoc issue rather than a company-wide matter. Reuse was rare, and maintenance was a complete nightmare. We had integration broker approaches and enterprise service buses — modern monolithic middleware — that replaced ad-hoc activities and added governance. But these were a single point of failure by nature, which limited their ability to scale.
After the broker era, the concept of API management simplified integrations and freed applications from monolithic architecture by adopting a common communication language between systems, strong governance and security model and easily consumable documentation.
These days, most organizations rely on an API management strategy to modernize their system architectures. One usual way to start the implementation of such a strategy is by using an API gateway. The API gateway is the main security gatekeeper that connects to internal assets and provides a common standard for customers and partners to access data using APIs.
Unfortunately, however, that’s only half the solution because it won’t solve the entire integration challenge from end to end.
What’s Wrong With Current API Management Strategy?
As the name suggests, the API gateway was created to be the portal between the outer world and the inner world and not to make an end-to-end connection between them. It is true that some API gateways emerged to play the role of the integrator, but that is definitely beyond their scope.
What ends up happening is that these architecture components often fail because they are bloated with too much responsibility. Organizations must be able to constantly reconnect their resources in order to adapt to business changes. That’s why a full integration narrative is needed, not just the thin outer layer provided by the API gateway.
As enterprises are expanding their scope to new internal services, external cloud systems and ecosystems of partners, a new approach is needed — which will deal with the dramatic increase in the number of integration points and the rigidness to reconnect services.
Where Do We Go From Here?
New digital demands require a new type of architecture. This type of architecture must deal with the dynamism of digital connections in a flexible way. It must recognize that integrations happen in multiple interconnected places: in the cloud, on-premises and close to the end users.
Enter the hybrid integration platform (HIP). An HIP enables users to develop, secure and govern integration flows connecting diverse applications, systems, services and data stores. It also enables rapid API creation, composition and lifecycle management to meet the requirements of a range of integration use cases.
A modern HIP should offer a visual and intuitive interface based on low-code concepts, where the integration complexity is abstracted away by ready-to-use components that implement business cases, thus reducing the effort to accomplish such tasks.
An HIP also needs modern architecture to scale, covering and replacing the main features of traditional integration landscapes like message queues, service brokers, file management and more. It serves as an accelerator so development teams can focus on what is most important to them: their business demands.
To get the most out of an HIP, you must take into account all the security aspects involved in supporting these dynamic use cases. It must handle different user profiles, encryption mechanisms and a myriad of critical credential types across hybrid environments. In addition, the adoption of technologies such as Kubernetes will allow these platforms to scale on demand while achieving high levels of resilience. An HIP must deal with the non-deterministic scale that these digital demands will require.
Based on the issues I’ve laid out above, it’s clear that traditional API strategies alone are not enough to handle today’s systems complexity and the variety of targets to be connected. In this day and age, an HIP is simply better suited to solve the digital transformation challenges that organizations are facing.
The adoption of an HIP will reduce the friction you frequently find when connecting any kind of IT assets — whether they’re legacy or not. A pure low-code, cloud-native and secure HIP will release development teams to focus on more important matters that help the business win.
