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:
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 three 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 five 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:
Advantages to this way of working include:
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.”