MDM's Value? It's the Customer, Stupid - Page 2

Loraine Lawson
He suggests bringing in the data steward or stewardship team to oversee data governance. Honestly, I think that if you've gotten as far as MDM it's definitely time to move beyond data stewardship and consider an Integration Competency Center (ICC). I base this not on my own opinion-which is useless-but on the many conversations I've had with experts about the value of ICCs and the complications of MDM.

That may seem odd if you don't understand how much integration work MDM entails. As analyst Robin Bloor-who's a sort of "Carville" for the integration set-recently said:

What I don't subscribe to is the idea that a large MDM project will deliver anything more maintainable than a pragmatic series of data integration projects that are aimed at specific targets. Indeed, from what I've seen, it is likely to deliver far less.

An ICC will bring together all your data stewards, as well as lessons learned from your other integration projects, for a nice conversation about best practices that you can then apply to MDM.

It's also tempting to confuse MDM programs with an MDM technology solution. Don't. As D'Cruz warns:

While packaged products are a viable means of quickly implementing a solution, it is worth noting that some products are more customizable than others. This can sometimes limit the optimal implementation of an MDM solution. Most products offer a set of entities related to the customer function, but there needs to be a certain amount of extensibility to the schema. Some products allow for this. Others require numerous configuration changes and limit the ease of use, which is important. These are reasons why some organizations build homegrown solutions to suit their needs.

As for the metadata, if you'd like to read more about how that works with MDM, I think Evan Levy of Baseline Consulting did a great job of explaining that during an interview earlier this year:

The reason metadata is important is, if I have two files, how do I link them? Metadata is going to tell you which columns mean which things. Without metadata, it's like looking in a medicine cabinet with a bunch of unlabeled bottles. Unfortunately, with databases we feel that somehow people are supposed to be able to figure that out. That's what's so ridiculous.

You can read my interviews with Levy regarding , as well as its role in integration and MDM, for more information.

Add Comment      Leave a comment on this blog post
Sep 27, 2011 11:15 AM Clive Clive  says:

Note the statement:

One thing D'Cruz doesn't cover is just how hard it can be to even define "customer"...

That is because "customers'" do not exist in the core business processes, since the core business processes deal with specific relationships or roles - "customer" is a derived term that can mean many different things and it is up to marketing to decide what relevance the information has. Example - A 'person/customer' can but an airline ticket and the name of the purchaser must match the name on the credit card and the name on the boarding pass must match the passport - two entirely different processes and measurements. Also the two processes may relate to two different addresses - one for the flight details to be sent and the other for the receipt. You don't actually know for certain whether the two people with very similar names are one and the same person and you cannot make assumptions.

The entire concept of a 'customer' for core processes is completely bogus and the habit of imposing this term on business (data) analysis from the outset is one of the main reasons that people foul up business analysis and system design. This happens because people are happier to deal with what they like to call "the real world" rather than paying attention to what is really happening IE the actual business rules.

Own a bank account as a 'customer'? No you don't - the bank owns the account and you sign a contract that makes you liable for monies taken from the account - still the term "customer" is much friendlier than being called the liable party isn't it?

Systems are analysed and developed from the top down and I believe this approach is what causes most of the issues with poorly designed systems. They should be analysed from the bottom up (after a scoping exercise) and you can derive whatever you like from the REAL meaning of the data in question. This problem has dogged IT for years and one failure after another of large systems doesn't seem to have any affect on those that can't see the trees for the forest (yes, I really did say that!).

A lot of this misunderstanding is caused by the comfort factor of being able to talk with business users through a commonly held view of the world. Try looking instead at the contracts that people sign rather than a wooly chat about abstractions and then you will see what the business relationship with the "customer" really is.

All of this has been known for years but it doesn't seem to stop people writing books of complete rubbish on the subject. Rather than IT staff analysing businesses, it's about time someone started to analyse the psychology of the IT staff that blunder from one failed project to another without ever grasping the basics of what they are dealing with.


Post a comment





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



Subscribe to our Newsletters

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