Blog: Dan E. Linstedt

« Golden Rules of Performance and Tuning | Main | Understanding MDM: Rough Seas and Muddy Water »

Demystifying the MDM definition

MDM = Master Data Management, why should you care what it means? There are many vendors out there who've defined which part of MDM they implement, unfortunately they've called it MDM; it's just one piece of MDM that they are tackling. MDM or true Master Data Management is a much larger umbrella than just "master conformed dimensions", or "Master lists of quality/cleansed information." MDM includes the term: Data Management and we all agree (at least for the most part) that Data Management is all encompassing right? So why the fuss over defining such narrow implementations and then titling them MDM?

What is Master Data Management anyway?
Let's break it down in to two pieces: Master Data, and Data Management - I think "Master Data" invokes quite a number of elements that need to be considered. Below is a check-list which my firm uses during implementation of Data Governance and best practices:

Master Data Questions
1. Does the data need to be compliant and Auditable?
If yes, then their are two copies of Master Data in the integration arena, the first copy of the data is compliant, and auditable, and merged only according to the business key. Merged is the wrong word here, by merged I mean attached to the same key defined to be the same semantic level across the business, that essentially means the same thing to the business. This is the only level of integration that takes place, without a loss of grain. Each target zone contains a record source that allows maximum traceability and compliance of the data. The data set is housed _exactly_ as it stood on the source system. Read the Data Vault data modeling for more information.

The second copy of the Master Data is in the data mart side of the house, remember: any time the data is truly merged, quality cleansed, altered, or prepared for user-utilization, that I call that: a data mart (it can be a single table, a conformed dimension, or a master data table with "quality" data) - it's all a data mart, where end-users can get their information quickly, and the model is tuned for speed and quality of data. In this case, the second copy of Master Data might be a "Master Dimension".

2. Does the data require existing as a System Of Record?
If yes, then the data set must be a "master" single consolidated instance of the data at the lowest level of grain, again see my response above about compliance and auditability.

If no, then maybe all you have is the notion of "Master Data Sets" embedded in conformed dimensions. Maybe you've defined your warehouse as a Conformed Dimension quality-cleansed warehouse, again this is ok if you don't want, or don't need an SoR in your warehouse, or don't have compliance and accountability to deal with.

3. Is your Master Data housed on your source system?
If so, then you might have a single copy of the data set. If not, then the data set might be spread across multiple source systems.

Data Management Questions
Note: this area is huge, and due to time and space constraints I will not address the entire segment of Data Management, hopefully I will present the feeling that MDM is a much larger umbrella than the "vendor hype" would lead you to believe.

1. What is Data Management?
That is a huge question with a huge answer. Data Management encompasses the act of understanding, monitoring, managing, maintaining, moving, integrating, synchronizing, dis-integrating, and delivering your data. It also includes items like security and access (data Governance), growth (metrics), value (KPA's & KPI's), and mining (asking unknown questions). Master Data Management encompasses the "master data notions", with Data Management notions - it is bigger (much bigger) than just data warehousing, or data integration.

2. How does Data Management affect Master Data?
Data Management is an initiative, a journey - not a destination. It is an ongoing effort to track, manage, and unravel the information across the enterprise. Data Management stretches across all data sets, but in particular, the Master Data shows high-value and high return (when done properly). Managing that data set over time will prove to keep the high-value proposition in tact. Without data management strategies and best practices, the "master data" sets decay over time, their usefulness slowly fades as the enterprise changes business rules and business processes. What's a master data set today, may not constitute the "right" master data set tomorrow. Be careful not to fall in the trap of letting your Master Data Set be set in stone from this day forward.

Master data sets need to be managed. Ahh but don't forget semi and unstructured data sets, those too must be managed, and believe it or not there are Master Data sets lurking in these areas as well.

Do you have an MDM initiative? What's worked for you and your organization? What differs from the vendor definitions?

Thanks,
Dan Linstedt

Share: