This week was, of course, spent at our annual Gartner IT Expo/Symposium. As usual it was a very busy week, presenting and meeting with customers 1-1. It is always fun to meet so many customers over a short period of time – and looking at the vast array and breadth of issues they have, even if they might all fall under one topic (such as master data management).
I presented on master data and management and receive a very large number of questions from users. It was quite amazing how broad the topics were, from governance, organization, metrics, technology maturity, technology overlap, IT skills, relationship of MDM to other IT and business efforts, and so on. The good news is that I have lots of work to do to answer the client questions; the bad news is that this continues to show how complex and immature this market is. Here are some other questions and answers regarding MDM and Business Intelligence that we published last year.
Lastly I had the good fortune to sit in Ted Friedman’s presentation on Data Quality. This was an early morning presentation on the last day and the room was over half full (and it was a very large room) which is testament to the importance of DQ. I learned a lot – as I always from Ted – about how DQ tools and skills apply and are being applied to MDM. One observation Ted made was that, “some users think that MDM is DQ – and vise versa”. Clearly this was a very clever point he made. They are not quite the same, but MDM is as much about “how to assure the quality of master data” and likewise, when you apply DQ tools to cleaning up and sustaining the quality of master data, you are in affect “doing” MDM.
2 responses so far ↓
1 Dan Sholler // Oct 21, 2008 at 3:30 pm
Well, MDM certainly can make the extent of your data quality problem visible, but it does not change the character of the problem in any way. If you have 3 customer master databases, each of which has duplicates, the problem can seem worse after you apply MDM to federate the data. (before you applied it, you could only see 2 of me.. after you apply it, there may be 6 of me in one view… ) This is an example of how it can appear worse, but the fact is that there always were 6, it was just they were only accessible 2 at a time.
I have always cautioned not to tie the two things together. The value of MDM as a means of federating the complete set of master data is separate from the value of improving the quality of that data. Given that they have separate value propositions, they can be approached separately. Obviously, one would not design the MDM methods to propagate obvious quality flaws, but neither should one insist on fixing every quality flaw as a precondition for doing MDM.
2 awhite // Oct 21, 2008 at 3:50 pm
Dan, it looks like you are confusing the issue. MDM is a discipline that seeks explicitly to improve the data quality of the master data in question to the point that a “single view” of the data is achieved. As such, it can’t get worse (else by definition MDM was not initiated). MDM may or may not include data federation; that is in fact a specific on implementation style (the ‘how’ single-view is achieved). But I agree your last point, data quality and MDM are related, but different.
Leave a Comment