Five Confusing Questions About MDM
Posted by Loraine Lawson Aug 5, 2009 2:28:38 PM
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.
--- original artice at : -------
http://www.itbusinessedge.com/cm/blogs/lawson/five-confusing-questions-about-mdm/?cs=34728
No comments:
Post a Comment