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
[wd_hustle id=’Social’ type=’social_sharing’/]
MDM projects often begin with a purist vision of creating an enterprise view of master data and sharing that view with all operational systems. The MDM project team may become frustrated trying to build 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 hand over control of their business data for a number of reasons. The reasons for this pushback may be “hard” such as limited field sizes or “soft” such as a resistance to change, but at some point, for some systems, you will run into a scenario that requires an operational system to have a different view of enterprise information than the MDM Hub. MDM architects need to accept that this will occur and should design processes that cater for this out-of-sync condition.
Designing for Out-of-Sync Systems requires a few key capabilities:
1. Avoiding “flip-flop situations
If we have two systems contributing to an MDM Hub with different values for the same attribute (let’s say System A has “123” and System B has “456”), the MDM hub must determine which of these competing values it believes to be correct, It must also store this value on the master, and 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 (in which case it would not be the same decision).
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 System, Record or Attribute. Individually each of these rules may be fairly simple, but when these rules are applied en-masse, the results can be difficult to understand.
When the question is asked “why is this not the same as the hub?” you do not want to be faced with a review of twenty or thirty interconnected rules to find the answer. The hub should make it clear what rules have been applied to any given record so the user understands what has happened and not what should happen.
3. Make the differences visible
The Hub needs to be able to provide a report that shows where the data from any contributing system differs from the hub data. This report should ideally differentiate between data that is truly different and data that is the same but formatted differently (see When is Different not Different). This visibility instils confidence that the hub is “on top of what is going on” which in turn helps break down resistance to change and ultimately results in broader adoption of the centralized hub data.
As a side note: We consider it “good manners” to make this difference report 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 more sharing world of MDM.
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.
[wd_hustle id=”SimpleSubscribe” type=”embedded”/]