What are integration design patterns?

If you are an integration specialist, you likely have used or implemented integration design patterns. There are dozens of patterns available––from canonical data model patterns and façade design patterns to messaging, routing and composition patterns. 

All of these integration design patterns serve as a “formula” for integration specialists, who can then leverage them to successfully connect data, applications, systems and devices. To better understand these patterns, let’s take a look at one integration design pattern discussed in Service-driven approaches to architecture and enterprise integration.

Integration design pattern Canonical data model pattern 

The canonical data model pattern is considered as the “oldest” integration design pattern. It refers to creating a messaging or data model that can be leveraged by consumers directly or indirectly. The data and/or message are then routed through an integration platform (e.g. Enterprise Service Bus) where they are then converted into a canonical standard format. 

This integration design pattern is widely used in the enterprise for a variety of reasons. First, it greatly reduces an organization’s maintenance costs. Second, it also reduces the integration “learning curve” because integration specialists won’t need to understand new data structures; rather, they can work with the canonical model and complete integration projects more quickly.
However, one drawback of this canonical integration design pattern is that it is time-consuming, as one must produce the model from the ground up. 

Integration design pattern: Façade design pattern

A second example of an integration design pattern is the façade pattern. This pattern aims to mitigate some of the drawbacks of the canonical data model pattern. This is done by defining simplified interfaces without using canonical models. Under the hood, however, the messages within these interfaces are translated into the canonical model. 

One advantage of this integration design pattern is the interfaces themselves aren’t based on the canonical model; as a result, any changes that are made to the canonical model won’t impact the interfaces and their consumers directly. This means organizations will not have to change every interface that uses this model.  

One drawback of the façade integration design pattern is that it leads to increased maintenance resources and costs because, unlike the canonical data model pattern, both the transformation and integration logic must be managed and maintained. 

Leveraging integration design patterns

Canonical data model patterns are one of many integration design patterns that are used. Every pattern exists to serve a specific purpose––whether it is to transmit events from one application to another or to consume application messages as they become available.

The first step to efficiently leveraging integration design patterns starts with adopting a new approach to integration: API-led connectivity. Learn more about API-led connectivity and see you can use it when implementing integration design patterns.