Five Confusing Questions About MDM

Loraine Lawson

One of the more maddening things about new technology topics is how difficult it can be to pin down the basic facts, like how it is defined and what's the best approach.

 

It's a bit like playing Scrabble without establishing a dictionary of record. Nobody knows for sure, but everybody has an opinion-and usually, they don't agree. It's very frustrating. I suggest Gartner amend its hype cycle to include this as a sixth phase-it could be called something like "The Mud Ditch of Confusion."

 

Right now, I'm mired knee-deep in the mud with master data management. A few of the issues I'm trying to trudge through:


What is master data and how do you define MDM? Gartner analyst Andrew White recently noted that definitions of MDM and even the key term-master data-differ. If people can't agree on that, it only follows that they'd disagree over what constitutes MDM. As David Loshin, author of Master Data Management, recently told me in an interview:

 

There are different definitions, which I suspect are crafted by the definers to suit their own purposes. My understanding centers the common themes around unifying the semantics of replicated models and descriptions of business concepts, and the techniques for resolving the identities of entities within each business subject area.

Does it matter if you do implement MDM in small stages? Loshin recently looked at the hazards of small starts in the third of his BeyeNetwork MDM checklist series - "Maintaining the Enterprise Scope." He warns, "each newly consolidated data source increases the likelihood of losing critical differentiating information associated with other data sources." But when I raised this point during a recent interview with Evan Levy of Baseline Consultant, he just laughed and said that sounded like a "datawarehousing person," adding that it's really not an issue, given the capabilities of MDM solutions. And then there's the bigger, related question...


 

Where do you start with MDM? White penned a humorous, but thorough, look at this problem, concluding, " the place from which every firm starts the journey is different, and infinitely complex." That may be true, but it's not particularly helpful if you're trying to figure out where you should start. Maybe his bigger point is that it doesn't matter?

 

Where should MDM reside? This is actually an infrastructure and a political question, as I've learned recently. Marty Moseley, the CTO of master data management vendor Initiate Systems, says you shouldn't couple MDM with your data warehouse, though this is what many companies do. And during our talk, Levy added that developers who come from the data warehouse are often the last to "get" MDM, because they bring the limitations of data warehousing with them.

 

How low can you go, technology-speaking, with MDM? A recent article published by the Integration Consortium explained how you can build an MDM solution on a shoestring budget.The basic premise is that if your data-profiling tool has the right capabilities, you can use it as an MDM solution. I have to wonder, though, since everybody else seems to view data profiling as a "A Necessary but not Sufficient First Step."

 

And all of that's without even wading into the whole multidomain MDM issue.

 

Of course, these discussions may not matter to you. Many people adopted Web services and called it SOA despite the teeth-gritting of analysts, but it didn't matter because they'd found something that worked for them.

 

But if you're trying to compare solutions or figure out which is the best place to start-then these unresolved issues can be problematic.

 

I'd love to help, but I'm pretty mired down in the mud here myself. I'll keep working on it, but in the meantime, here's what I can do: I'll keep pointing out the issues and try to present all sides of the discussion. I hope you'll be able to find a path out of the mud that works for you.



Add Comment      Leave a comment on this blog post
Aug 6, 2009 5:10 AM Mark Raskino Mark Raskino  says:

I just browsed Andrew's July 2009 MDM hype cycle report and most of the entries on it are positioned early along the path.  It is usual for the sort of confusion you are seeing, to be dissonance arising from hype exceeding progress (including definition progress).

So in fact it appears MDM as a whole is still hovering around the Peak of Inflated Expectations phase of the Hype Cycle.

We do acknowledge a sixth and a seventh stage of the Hype Cycle but rarely discuss them. That's because they come after the Plateau of Productivity, beyond which something is no really longer viewed as a new innovation or emerging technology (the prime focus of the tool).  Those additional stages are 'The Swamp of Diminishing Returns' and 'The Cliffs of Obsolescence'.     

Reply
Aug 6, 2009 6:23 AM Marty Moseley Marty Moseley  says:

Mmmmm!  Confusion, mud, hype and dissonance!  You gotta love it!

Jill - thanks for sharing your muddy experience with us without slinging any mud in the process!

Isn't it weird that something that can be so valuable is so hard to define crisply? Maybe that's why a good MDM implementation can add so much value.  If it were easy to define and do, then the need wouldn't be so great & we'd have to go work in BI or some other area.

Thanks again...

Cheers...

Reply
Aug 10, 2009 11:25 AM Richard Ordowich Richard Ordowich  says:

Loraine, great article. I think we should rename MDM. Lets call it Master Data Mashup. When all is said and done it looks like a mashup! This way we can keep the acronym.

On a less serious note though I believe that MDM is a good technique to apply to data when designing new systems, a technique that is applied in ERP designs. Trying to reverse engineer legacy systems and create master data from years of ill defined , undocumented data is like digging for fossils. No naming standards, no data definition standards, no semantic standards and business rules embedded across the enterprise makes the effort seem like a search for the Holy Grail.

Even reference table data is difficult to harmonize within an MDM environment. An example is 16 different tables to store state codes. Each table had its own business uses and rules which were not compatible with each other. A mashup ensued.

I chuckle when people make the statement that embarking on MDM is a journey not a project. I think what is meant by that statement is that you may never get quite where you're going.

Richard

Reply
Sep 23, 2009 3:57 AM David Loshin David Loshin  says:

I still can't believe that Evan Levy thinks that I sound like a data warehousing person.

Reply
Mar 30, 2011 9:56 AM glennda mirabete glennda mirabete  says: in response to David Loshin

What did Evan tell you anyway to get a reaction from you like that?

--

Hair updos for weddings

Reply

Post a comment

 

 

 

 


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

 

null
null

 

Subscribe to our Newsletters

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