Enterprise integration patterns (EIP) are a set of concepts and practices on how to best configure integrations between systems, applications, or data, often collectively referred to as enterprise application integration (EAI).

Gregor Hohpe and Bobby Woolf began documenting these patterns over 20 years ago in order to lay a foundation on how integrations can be configured, without needing to reinvent the wheel each time you come across a similar integration scenario.

Their work has focused on describing patterns related to messaging within integrations; how integrations send and receive information between systems.

Why are Enterprise Integration Patterns important?

Enterprise integration patterns form an important basis for defining an enterprise integration architecture and building enterprise application integrations, which often are business-critical and work with a complex ecosystem of data and systems.

For enterprise architects, these patterns help to best architect integrations in scenarios where there are numerous systems and processes that are interconnected.

Are Enterprise Integration Patterns still relevant today?

Like in many other situations, learning the theoretical concepts, background, and best practices do help in building expertise into how to reach the best outcomes. However, enterprise integration patterns have become a mainstay in the tools that are being used for enterprise integrations.

Most of the examples described below are well documented within the integration platforms. Many platforms have abstracted away from using these concepts and instead focus on the business outcomes of integrations instead of the technical know-how necessary to build such integrations with code or with a legacy integration tool. 

When integrating the growing number of SaaS applications organizations are working with, there often is no say in how source or destination applications have decided to relay messages or receive messages. Thus studying all of the integration patterns is a worthwhile endeavor only if you are building applications and you need to decide how your application communicates outside of its boundaries.

Common Enterprise Integration Patterns examples

In their Enterprise Integration Patterns book from 2003, Hohpe and Woolf discuss 65 different enterprise integration patterns. Most of the patterns presented are related to a messaging scenario, where systems relay packages of information to each other frequently.

In more general terms, enterprise integrations can be split into four example scenarios each with its ideal enterprise integration patterns for how to configure an integration. The example scenarios include:

• Data migration
• Data synchronization
• Aggregation
• Broadcasting

Data migration

In a data migration scenario, data is moved from one location to another (A to B). Migration can happen as a one-off migration or done periodically to ensure that data from one location is also available in another location. Migration can also run for a certain period of time, for example when one system is to be replaced by another, but the old system cannot be decommissioned immediately.

Currently, many organizations are moving to the cloud. As this is not a small undertaking to complete, in a cloud migration organizations may choose to keep the on-premise systems running and migrate data to the cloud over a longer period of time.

Data synchronization

Data synchronization is the process of keeping two sets of data synchronized with each other bidirectionally. The bidirectional nature ensures that data flows in both directions to keep both sets as identical as possible. Data synchronization bidirectionally is simple when the two systems are identical, but in cases where the synchronization occurs to a system with a different data model, it gets more complicated. You may need to add additional fields to be able to store the information in the other system and often you have to find ways of transforming the data to suit the data model of the other application. 

Integration platforms can simplify the transformation of data, but not all of the platforms help you determine what information should actually be synchronized.

When synchronizing internal data, a complete data synchronization of all data kept within systems may be an acceptable decision. However, integrating your tools with a customer or a vendor can bring more harm than help.

In the ITSM context, this bidirectional synchronization is typically called eBonding, when two ITSM tools are bonded to each other and kept identical. When integrating a customer’s ITSM tool to yours to bidirectionally move tickets and their updates, there’s often a lot of information that should not be made available outside of your organization. Thus, full data synchronization and its patterns may not be the correct approach to integration.
‍

Read more about eBonding:
‍Is eBonding a scalable solution? No, definitely not. Here's why.

To combat the downsides of full bidirectional synchronization, a correlation pattern may be used. Integrations that are capable of handling correlations will only synchronize data, which has a correlation to the other data set, i.e. there is a real need for that information in the other system and is only transferred when that need arises.

These conditions for transferring data only when necessary and maintaining information about what records correlate with each other are difficult to configure and maintain.

However, advanced integration tools such as the ONEiO Integration Automation Platform do have support for correlating records with each other to simplify the setup.

Aggregation

In a data aggregation scenario, data is transferred from multiple sources to a single destination. When aggregating data via an integration, it is accepted that not all systems contain the same data, but there is a need to collect the information in one place.

The benefit of data aggregation is that it allows keeping the source systems fairly untouched, while the destination system needs to be able to cope with the various data retrieved from the source systems. Aggregation commonly occurs in the context of business intelligence (BI), where information from multiple sources is brought together to be displayed in dashboards and reports.

Read more about aggregation patterns:
‍Everything you need to know about Data Integration

Broadcasting

In the broadcasting integration pattern, data flows from one source to multiple destinations in a real-time or near-real-time manner. This is achieved by the source system sending the information to multiple destinations without the destination systems having to retrieve the data from the source system.

Compared to a data migration scenario, in broadcasting the focus is on moving smaller increments of data instead of migrating a lot of information in one go. Each time a change or transaction is made in the source system, it will attempt to propagate this change to all of the destinations. If this transaction between a source and destination system fails, the original change can be rolled back to its previous state.

Broadcasting is ideal for situations where you would like to have the information available to you as soon as possible, whereas data migrations often take a longer time to execute.

How to implement Enterprise Integration Patterns with ONEiO?

ONEiO is an Integration Automation Platform built to remove the need to worry about the different integration patterns and instead allow you to focus on the outcomes.

With ONEiO, you don’t have to be an expert in integration patterns nor do you have to find out your best enterprise integration pattern solution. You can focus on the business logic, i.e. what should happen and when instead of considering how the messages will flow between systems.

ONEiO’s endpoint types remove the need for you to consider whether the source system is broadcasting data or whether it needs to be polled periodically to obtain the data, it’s all built-in to the endpoint type.

‍

Reach out to us if you would like to understand more about how ONEiO can integrate your tools with a 100% success rate.