What MDM Is and Isn't

Loraine Lawson

Some things are more confusing than they should be - like those road loops in the UK or the logic behind leap years-some things seem very simple when they're explained, yet people are constantly confused about them.


IT seems to have more than its fair share of these issues. And for some reason, master data management is becoming one of them.


Personally, I've always thought vendors were to blame for the confusion. I know they're an easy target, but in this case, I think it's fair. After all, MDM is a discipline, yet vendors say they offer "MDM solutions." What they really mean is they sell products that support MDM efforts. But that's not what they say, so people get confused. I should know. I was one of the confused masses.


But after reading a recent Information Management article, "Top 5 Master Data Management Misconceptions," I realized I may have been unfair. While I can and do blame MDM vendors for misconception number 2 - "MDM is a technology/infrastructure initiative" - they really can't shoulder the blame for all four of the other MDM misconceptions:

  • MDM is like data warehousing (okay, maybe they have a bit of responsibility there, too).
  • MDM should be treated as a data quality program.
  • Assume data governance is an "optional" architectural component of MDM.
  • MDM should be treated like an application.


Of course, regular readers will recall we've talked about that "MDM is data warehousing" issue previously-including how it differs, why data warehousing staff may not be the best choice for spearheading MDM technology initiatives, why you shouldn't couple data warehousing and MDM, and how the architectures differ.


Reading through this list and the author's attempts to clear up the misconception, I realized that the underlying problem seems to be selling MDM short. It includes applications, it can require new infrastructure and technology investments, and a data quality program is a key part of it-but these are only parts, the sum of which creates an MDM program.


And for that matter, your MDM program will only be as good as the parts you've used. Short your data quality project, and MDM will suffer. Fail to do governance, and you'll be backtracking.


Alas, that goes for the technology underpinning MDM as well. A recent TDWI article suggests that those with homegrown or ad hoc MDM solutions may want to consider an upgraded solution. The article notes that MDM solutions have matured substantially since 2005, when companies began to embrace MDM. Four-generation tools will offer more support for multiple master entities and search or text analytics for unstructured data, the article notes. You'll also see MDM tech integrated with other technologies and initiatives, including BI, RFID and entity analytics, according to the article.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


More from Our Network
Add Comment      Leave a comment on this blog post
Nov 24, 2009 2:15 PM Martin Doyle Martin Doyle  says:


Interesting piece, you're right to blame the vendors to a degree. Vendors are labelling MDM in the same way as CRM vendors did so MDM is seen as a technology, when principally they are both a philosophy supported by a technology.

I believe labelling is disabling. Some might argue MDM stands for "Make do and Mend".  This is in its own way a philosophy, a philosophy though of fix rather than cure.

That's the thing about labels, the labelled thing can look very different depending on your point of view.  If you look at MDM from the Make do and Mend side you end up fixing bad data, if you look at it from the Master Data Management side you will successfully cure bad data, maintain accurate sources and avoid the unnecessary cycle of correction and corruption .

I see Master Data Management as the final verb in a proactive chain of data management.  It is the last action in the sequence of dynamic data management.  MDM happens after, cleansing, validation, de-duplication and record linking which all serve to define a 'Single Record View' (SRV).  Only when you have a SRV can you go onto deliver MDM, where MDM-enabled through technology-updates the multiple locations where the same record is stored in an application or database, where in its context, is completely fit for its intended use.

Labelling is disabling here because the label MDM clearly means different things to different people.  Until we all have a common understanding we'll never all be on the same journey to data and information nirvana; friction will prevail and MDM will go the way of CRM and probably fail for all the same reasons.

P.S.  Always look for the value. Assess whether the MDM technology cure more costly than the complaint?

Jan 29, 2010 12:55 PM Alan Semple Alan Semple  says: in response to Martin Doyle

As a total MDM 'newbie', I'm a little confused by a part of the above comment.

Surely, in order to know how to clean, validate, de-dupe, etc, you first need to understand what it is you're trying to create - i.e. you first need to define what your Master Record is before you can create it.....?


Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.