What is a Digital Integration Hub?

Are your old legacy systems preventing you from starting a full-speed digitalisation? Struggling with data access delays? Would you like to start running real-time business processes and acquiring real-time anaytics? In this case, Digital Integration Hub (DIH) as a solution is a way to achieve those goals much faster and more cost-effective than microsrvices and traditional API startegies.

What is a Digital Integration Hub?

In 2018 Garther for the first time introduced the concept of "Digital Integration Hub", or "DIH". What was meant by it is the approach that can help you connect "dispersed data across multiple sources" without complex intgrations and cost-efficient. Already by 2021, the approach has significantly evolved, and today DIH can offer much more. According to Garther, today DIH can:

• enable digitalization of the old legacy systems by using an integration platform;
• speed up the process of deploying responsive and reliable APIs;
• ensure compitability of infrastructure with hybrid and multicloud architectures;
• reduce over-provisioning and overloading of back-end systems,
• enable real-time data analytics when API integration platform is combined with DIH.

The need for DIH is obvious - the demand for digital services and channels are on a steady rise from business' persperctives. The need has risen even more since COVID-19.

In a nutshell, a digital integration hub is an approach in which APIs act as front-end facades to hide legacy systems. The APIs follow the best practices of microservice architecture (MSA) and represent simple atomic business functions. The API itself might get the data from, or write it to, one or more core line-of-business systems. APIs in Digital Integration Hub are functions like "getCustomerData" or "orderProduct". APIs that use several data sources to create a single data object are composite APIs.

If we weld these APIs directly to the backend systems, we will end up with something called coupled system. Let's take an example: Your APIs are facing public internet and are used in, e.g. customer mobile apps. In that case, you'll end up with problems as the load eventually overloads the backend system.

The idea in DIH is to remove this tight bound between API and existing legacy and move to uncoupled architecture. Digital Integration Hub enables good old three-layer architecture with the old legacy systems. Even file-based vintage systems may be digitalized if a little latency in data is allowed. Three-layer architecture also enables a graceful system retirement. As the communication to the old system is moved to happen via API, we can update the core system to a new one without the users even noticing the change. In addition, a DIH approach can also facilitate migration to the cloud and support hybrid deployments, in case on-premise systems are still in need by an organisation.

DIH + iPaaS (A tech overview)

With the right DIH approach, you can take off the pressure from your legacy systems and shift the whole workload to APIs. Moreover, when extending your Integration Platform with DIH, you are unlocking even more capabilities of your platform.

Legacy data source interfaces will not be able to scale unless we do something about it. And what we can do is to introduce DIH to your Integration Platfrom as a Service.

In the case of Frends iPaaS - DIH combination, we pump the crucial business data to an intermediate database (e.g. in-memory database) and APIs get connected to the database. Data pumps - frends agents with specific orchestrations inside - read data from multiple data sources and create data structures to the intermediate data storage for fast reading.

Supposedly, the API is updating data in the legacy systems, e.g. "orderProduct". In that case, the data pump orchestrations handle the complexity of multiple source updates. For example, purchase orders are coming through API, and simultaneously sales representatives still use the legacy systems' old UI. This lead to data consistency problems inside the old legacy system. Data pump - or more precisely, the logical and business rules inside it - solve these conflicting updates. If there are no other sources of writers to the same data that API updates, a message queue behind the facade API might be enough.

And this is only one of the case scenarios in which iPaaS-DIH approach can help you in avoiding operational problems, and most importantly, with this approach, it is also possible to extend the lifetime of an ERP for an extra decade.