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.