Not all operational systems will choose to, or be able to, consume the changes made to master data in an MDM hub. The reasons for being out-of-synchronization may be technical, regulatory, political or economic but at some point, it will be necessary to manage different views of the same master data.

MDM projects often begin with a purist vision of harmonizing Master Data across the enterprise. At some point, the project team is likely to have trouble building consensus among stakeholders about the “correct” view of enterprise data, and often this can cause an MDM initiative to stall.

Application owners may be reluctant to change their business data for a variety of reasons including technical, political, financial or regulatory restrictions. Without commenting on the validity of these arguments, at some point the MDM project team will run into a scenario that requires an operational system to have data that is out-of-sync with the enterprise Master Data Hub.

Designing for Out-of-Sync Systems requires a few key capabilities:

1. Avoiding “flip-flop” situations

If we have two systems contributing to a master record with different values for the same attribute (let’s say System A has “123” and System B has “456”), survivorship rules in the MDM Hub will determine which of these competing values to survive to the master record and it will inform all connected applications of this choice.

Let’s assume that the “123” value from System A is preferred which also implies that the Hub has evaluated and rejected “456” from System B. At any point in the future if System B resends the “456” value to the hub, the hub must ensure that the same decision is reached and under no circumstances select “456” just because it is newly submitted and publish this change to System A – that creates a flip-flop.

However, if System B was updated to “789” then it would be perfectly valid for the hub to reassess the decision and potentially decide that “789” is preferable to “123” thus creating a suggested update for System A.

The golden rule is not to re-make the same decision twice unless something has changed.

2. Track the reason for differences

The decision to keep a system out-of-sync may be made for a variety of reasons. Business rules to define harmonization may be applied at the level of the contributing system, record or attribute. Individually each of these rules may be simple, but when these rules are applied at scale, the results can be difficult to understand.

You should ensure that you can track the data policies and survivorship rules that create differences between connected systems and the master record. At some point, users will certainly challenge why their data is not the same as the master record and you can only preserve their confidence if you have a clear and well-documented answer.

3. Make the differences visible

​

User confidence is highly correlated with visibility into the master data processes. Reports that show where differences exist and the underlying reason for this difference is critical to keeping users engaged and leads to broader adoption of the centralized hub data. These difference reports should discern between data that is truly different and data that is the same but formatted differently (see When is Different not Different).

We have found that it is preferable to make these reports something that systems owners can “pull” rather than something that is “pushed” to them. Allowing application owners to take value from the hub at their discretion is the easiest way to ease them into the collaborative master data processes.

Keep Reading

When is Different, Not Different

​An MDM solution must be able to tell the difference between how data is represented versus what it represents. This is just another of the complications that MDM architects must deal with when designing a solution.

Summary

Providing a capability to deal with out-of-sync situations lowers the risk of connecting to a central hub for many applications owners. Each application should be able to contribute information to the hub without the requirement to accept changes back from the hub. By allowing application owners to subscribe to data from the Hub on their own terms, and on their own schedule, will greatly reduce the resistance to the MDM program.