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.
By Martin Dunn
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.
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.
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.
Martin Dunn was the co-founder of Delos Technology which developed the MDM technology marketed under the Siperian brand. The Delos MDM technology introduced many MDM concepts that are now widespread within the MDM discipline including a data steward console to adjudicate match results, opt-in synchronization, cell level delta detection and the concept of measuring trust.
Martin is now a partner with Gaine Solutions and continues to advance the techniques by which enterprise Master Data is managed.
Key Questions to Ask During Master Data ConsolidationsTypical master data consolidation starts with combining the operational master records from all the data silos where they exist. The key aspect being, creation of master data indexes to support single view; knowing...
Changing a Match RuleWhen we are talking to companies about our MDM platform we cover a broad range of topics, from measuring ROI, to more technical questions about the way the software operates. A common technical question is "How do we change a match rule?" Our...
Business Process ImprovementsThe analysis of master data and MDM processing logs can reveal interesting opportunities for business process improvements. We show how, as long as you collect the right data and know how to analyze it, you can drive significant business...
Ready to master data mastering?
Subscribe to our mailing list and we’ll send you courses, insights, product updates, and more. Get to know the ins-and-outs of your Gaine MDX platform, features, and solutions.