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 need for a bi-directional sync integration application is synonymous with wanting object representations of reality to be comprehensive and consistent. For example, if you want a single view of your customer, you can solve that manually by giving everyone access to all the systems that have a representation of the notion of a customer. But a more efficient solution is to list out which fields need to be visible for that customer object in which systems and which systems are the owners.
Most enterprise systems have a way 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 (using a common integration platform) if it’s a simple solution, or a more advanced routing system like a pub/sub or queue routing model if there are multiple systems at play.
For example, a salesperson should know the status of a delivery, but they don’t need to know at which warehouse the delivery is. Similarly, the delivery person needs to know the name of the customer that the delivery is for without needing to know how much the customer paid for it. Bi-directional synchronization allows both of those people to have a real-time view of the same customer through the lens they need.