In my previous posts Secrets of Operational MDM – Part 1 : Choosing System Behaviors and Secrets of Operational MDM – Part 2 : Contributing Systems we categorized systems connected to our MDM environment as Consumers, Managers and/or Creators of master data. We also looked at what how these system should contribute to an MDM environment. Now let’s look at these systems should consume data from MDM.

For consumption there is another very important system characteristic to consider. That is if the consuming system can handle merging of records.  While ability to group and “merge” and “unmerge” records is one of the key benefits of MDM it is not necessarily a strength or need of operational systems.  The real power an MDM tool is supporting integration on either the merged (consolidated) or the unmerged (unconsolidated) record.

So two additional categories to introduce are merge aware and non-merge aware systems.

A merge aware system can be informed that multiple entities it contains are actually duplicates and will correspondingly merge those entities in its own operational store.  Be cautious here, errors in merge are possible;  so it is important to understand and design for the unmerge case as well.

For many systems it is not practical nor appropriate to be merge aware.  Operational systems manage their own independent transactional data.  If a duplicate mastered entity ends up being created and some transactions are recorded against both entities. It may be cumbersome and even violate some business rules to force these to entities merge. So it can it is vital to support the ability to find their own independent records in many cases.

To best support both merge aware and non-merge aware integration it is best to have the following IDs

• • Consolidated ID that uniquely identifies any existing merged entity
    • Note a given Consolidated ID will disappear if it is merged and re-appear if unmegred
  • “Global ID” that uniquely identifies every record that is loaded in the MDM
    • Note a Global ID is managed and independent of the contributing source and should never change
  • Source Key is a source specific key uniquely identifies records contributed to the MDM

Consumers

Merge Aware: Systems that only consume data from and can accommodate merging for mastered entities simply need to contain a Consolidated ID for each master entity.  And also register to receive notification of any merge / unmerge.  To cover the unmerge case this usually requires keeping the Global ID Identifiers as well.

Non-Merge Aware: In this case the consuming system still needs to get an ID but since it will not be updated in the case of a merge so utilizing a Global ID is the best practice.

Managers

Merge Aware: Systems that manage data from and can accommodate merging for mastered entities simply need to contain Consolidated ID and its Source Key for the record it contributed.  Also these system will need to receive any notification of merges / unmerges.  Since managers will have their own IDs for their contributed records these can be used to resolve unmerges from MDM.

Non-Merge Aware: In this case the managing system could just use its own Source Key.  However it is a good idea to use a Global ID which would be consistent across sources.  This is particularly helpful when data from these systems is brought into a data lake / warehouse.

Creators

In all cases any system tat can create master data should first search the MDM environment prior to actually creating a record.  This “search before create” simply reduces the number of potential duplicates and the amount of manual entry. This is true of merge aware and non-merge aware systems

Other than the addition of search before create creators should consume data form MDM environments the same way that managing system do.

One of the major and costly errors I’ve seen in implementations is assuming that systems should always want to integrate at the consolidated level.  If this ends up being desired make certain to validate update and unmerge behavior.

In terms of making consuming application merge aware or non-merge aware the guiding principle needs to be the operational benefit. Getting a insight based on merging master data entities  is very important.  But a great MDM environment goes beyond this and also allows systems to operationally efficient and work on unconsolidated data as desired.