Avoid Creating Another Information Silo with MDM

In my last article, I discussed the five most critical success factors when implementing a Master Data Management solution. At the top of the list was a warning: “Don’t Create Another Information Silo”. What does that mean? Why is that important? What is different about this new system we are calling “MDM”?

I define “Information Silo” as an application which has the following characteristics:

1. The application has its own database.

2. The database is highly normalized, because the designer of the data model has made an effort to reduce duplication of data.

3. Identity is invented in the database, because things like Customer, Product, User all need primary keys to identify the record within the system.

4. Domain Logic controls most, if not all, of the data quality requirements, because encapsulating business logic outside a database promotes re-use.

Each of these principles makes perfect sense for a custom application. But if you use them in your Master Data Management solution, you will make another Information Silo, and you’ll be right back where you started.

Certainly, our Master Data Management solution will include a database, the “MDM Hub”, which will be the central place for data in our system to reside. But we need to design a different kind of database model, unlike many other systems we have designed for the enterprise. What should this data model look like? There are 3 modeling approaches to consider. I’ll explain each, and then tell you which is the best and why.

A Registry approach is the lightweight model whereby only the pointers to source data are stored in the Master Data Hub. We are capturing only minimal attributes in the hub with this pattern, and consumers of data will be required to seek out an authoritative data source elsewhere. Essentially, this MDM pattern is designed to store nothing, only to tell consumers where to get the data. This does not work well when it comes time to implement Data Governance, because the MDM system has not defined a Jurisdiction for the Data Governance team to work in.

A Transaction approach represents the opposite end of the spectrum from Registry, and it helps to address the common fear of “Garbage In, Garbage Out” which so many first-timers experience. The idea with Transaction is that Master Data should be created in a tightly controlled environment which imposes rigor on the master data creation process and ensures that ALL data is collected up front. This approach sounds worthwhile, until you consider what it will take to build such a system: you may as well build a new ERP system. This is the classic trap leading directly to another silo of information!

A Federated approach represents a middle ground between Registry and Transaction. Think of this as the “come as you are” alternative, because we are going to pull the master data from the sources with as little translation as needed, and we are going to leverage the source identity in MDM, combining the name of the source system with the source system’s identifier. The Federated approach recognizes that in order for the data governance team to effectively govern, it needs enough master data attributes to discern critical differences in the MDM hub, but not all of it.

Here is an example of how the Federated model works. Let’s say that we have 5 sources of Customer Master data: 3 ERP (JD Edwards Enterprise One, SAP and Dynamics AX), 1 CRM (SalesForce) and 1 Custom SQL solution used by a Web site. A Federated design would dictate:

  • An Entity named “Source System” whose members would define the sources of data (i.e. JDE, SAP, AX, SFDC, SQL)
  • An Entity named “Customer” whose members would have an identity which would be the combination of the Actual Id value from the source system, prefixed by the Source System code itself (i.e. “JDE-100054”, “SAP-000005478”, “SQL-1”). If the Actual Source System Id is used, then these MDM Identifiers will be unique in the Federated model.
  • Some number of additional attributes which help the stewards of the master data understand if these records represent a common customer. This needs to be defined by the business stakeholders, not the database administrators.
  • A solution for creating a Golden Record in the MDM solution. This solution should match members based upon matching rules and group them together as proposed units. The common grouping for these records is a reference to the Golden Record. For example, the solution should present hierarchy with the Golden Records as parents of the sources.
  • MDM-100 : “BlumShapiro”
  • JDE-100054 : “Blum Shapiro & Co”
  • SAP-0000005478 : “BlumShapiro”
  • SQL-1 : “Bloom Shapiro”

Advantages to this way of working include:

A. Because we are bringing source data in “as is”, data can be loaded quickly into the MDM hub

B. A Federated MDM solution can produce reports which tie out to legacy reports, because they use the same Master Data.

C. Your Data Stewardship team works with the data as it is, without translation or normalization, and has enough data to begin defining data quality rules

D. The solution is positioned nicely for source system synchronization, because a one-to-one relationship exists between the Authoritative record in MDM and the target

A Federated MDM Data Model for your Master Data Management program is the best approach for getting started. It is simple to design, easy for business users to grasp, and avoids creating another data silo. In fact, it is only aggregating from silos and grouping for matching, harmonization and coherence. Most importantly, this approach gets you something fast. It gets your governance team something they can touch and feel. An MDM initiative must deliver value to the business quickly, and to do this it must be relevant as soon as possible.

Next time, I’ll talk about how an MDM differs from CRM, and why you should treat your CRM(s) as “just another source of master data”.

Leave a Reply

Your email address will not be published. Required fields are marked *

qZRXI qZXY f93

Please type the text above: