Bi-Directional Pattern

The Bi-Directional sync data integration pattern is the process of integrating two datasets in two completely different application systems so that they behave as one. Additionally, during this process they are designed to respect the need to continue to exist as different datasets. This integration type comes from having different tools/systems for performing different operations on the same dataset.

As an example, we may have one system for taking and managing orders and another system performing our customer support activities. In this scenario, perhaps these two systems are considered best of breed and it is critical to our enterprise needs to use them in combination rather than a suite which supports both functions and uses shared data structures. So, instead we are using the bi-directional pattern to share a dataset to facilitate the utilization of both of these systems, and maintaining a consistent real-time view of the data in both applications.

Value of Bi-Directional

The Bi-Directional synchronization pattern can be both an enabler and a savior depending on the scenarios in which it is being deployed. If your systems have two or more independent (and isolated) representations of the same data, then we can utilize bi-directional pattern to optimize your processes.

On the other hand, we can deploy the bi-directional pattern to transition our system from a suite of products that work well together (but may not be the best of breed at their own individual function), to a suite implementation has been crafted to integrate together using an enterprise integration platform (like MuleSoft, Boomi, Informatica, Oracle, TIBCO).

Usefulness of Bi-Directional

The requirement for a bi-directional integration application is synonymous with the need for an object’s representation of reality to be both comprehensive and consistent. For example, if we need a single source of truth of our, it can be provided manually by giving everyone access to all systems that have a representation of the notion of a customer. But, a more efficient solution is to list which fields need visibility for a customer object in each systems and identify which systems are the owners.

Most enterprise applications have a method to extend objects such that you can modify the customer object data structure to include those fields. Then, you can create integration applications either as point-to-point applications (with a common integration platform) for a simple solution, or utilize the pub/sub or queue routing model for a more advanced routing system when there are multiple systems at play.

For example, a salesperson needs to know the status of an order delivery, but they don’t need to know which warehouse the delivery was made. Similarly, a delivery person needs to know the customer name for delivery without the need to know how much the customer paid. Through the use of Bi-directional synchronization. both of them to have a real-time view of the same customer and access the unique content they need.