Blog: Dan E. Linstedt

« Demystifying the MDM definition | Main | A tribute to my mentors »

Understanding MDM: Rough Seas and Muddy Water

I recently blogged on this subject, and then I asked my friends in the industry what they thought MDM meant to them. Not surprisingly, I received a number of different answers. I'll post their answers in this entry, and then discuss what I believe MDM to be. David Loshin recently wrote a new article on MDM and the basics of MDM, some of which I agree with, other parts I disagree with - I'll post here what my thoughts are on this subject as well. In the next blog entry we'll dive a little deeper and work at defining specifics for Master Data.

Bill Inmon on MDM:

I have always thought of MDM as reference tables. You can extend the definition a little and include other kinds of metadata I suppose. But I think people are stretching MDM way out of proportion.

Stephen Brobst:

I would extend MDM beyond just dimensional data.

I like to think of data in three categories:

* Data that keeps track of events (e.g., sales detail, deposit/withdrawal txns, CDRs, etc.)
* Data that keeps track of the “state” of an entity (e.g., customer, account, product, etc.)
* Data that keeps track of “relationships” (e.g., the relationship between products and categories, persons and households, etc.)

MDM generally encompasses the second category and the third category as it applies to the second category. In other words, MDM keeps track of “state” entities and relationships between “state” entities. But not events or relationships to events.

Claudia Imhoff:
Claudia and I had a discussion about MDM, I will have a quote for the next entry I make, and she and my good friend Colin White are currently writing a research study on MDM, due out soon. I expect this to be extremely helpful. However, in paraphrasing what Claudia and I discussed, here is the general gist:

Master Data Management should be thought of as a process, a business process, not as a tool set or something that a vendor sells. Master Data exists as reference tables throughout the enterprise, be-it on source systems, data marts, data warehouses, staging areas, or operational data stores. It doesn't matter where the tables reside, just that they do reside within the organization as a centralized master list of information containing both the KEY and the DESCRIPTIVE components of what that key represent today.

David Loshin:

Master data objects are those core business objects that are used in the different applications across the organization, along with their associated metadata, attributes, definitions, roles, connections and taxonomies. Master data objects are those "things" that we care about - the things that are logged in our transaction systems, measured and reported on in our reporting systems, and analyzed in our analytical systems. Common examples of master data include:

* Customers
* Suppliers
* Parts
* Products
* Locations
* Contact mechanisms

Ok, I can see where all the confusion comes from. The father of data warehousing and my good friend Bill Inmon has said quite plainly that MDM is nothing more than REFERENCE TABLES, which can include references to anything you want. Centralized information, centralized metadata, and centralized definitions - all quality checked, integrated and providing singularity for data attributes by their corresponding key.

MDM is NOT:
* A data warehouse
* A data Mart
* An Operational Data Store
* A single source system
* A Tool, or technology per-say

MDM IS:
* A governance process, a business driven process, a consolidation of localized information used for reference by the business to better understand their business processes.

Yes, MDM includes Governance, Data Administration, and parts of Data Management. It also includes the data itself as the "master list" of reference material. We've had these concepts for years, especially back on the mainframes. I remember 12 to 15 years ago working with "master parts lists, master contracts lists, master work-orders lists, master employees lists", and of course "master systems" that are supposed to dictate the creation and management of the data set, dispersing it to "child systems" - of course this is all part of what lead to integration mass confusion (nightmarish over-night synchronization processes that were supposed to keep the master lists in synch across the different systems).

I just read a Knightsbridge paper that stated that "localized copies of master data are OK." I beg to differ. Today's networks are fast enough and global definitions (metadata synchronization) is better done these days, good enough to create and locate a SINGLE MDM data source for reference information. The point is to avoid the future "fights" over who's right and who's wrong with their "copies" of the data sets. Integration NOT DIS-INTEGRATION is what we are trying to achieve with MDM.

If you need to warehouse your Master Lists, then do so, but fight the good fight to consolidate the metadata definitions, and consolidate the data sets across the same semantically defined layers (see Data Vault Data Modeling). At the end of your MDM initiative you should be able to identify true MASTER data stores that are not localized, that can be utilized horizontally and vertically across your organization without fear. Quality data and single copies of information are what we want. Utilizing the Data Vault Data Modeling architectures, you can easily encompass the MDM definition of all four individuals above.

In my next blog entry I'll go through a few things like creating a single definition for MDM,

How are you implementing MDM? Which of these definitions matches your business?

Come to TDWI in August, San Diego, share your MDM experience in my MDM night course.

Thanks,
Dan L

Share: