[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.

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.