Are You Building an MDM Hub or a Roach Motel?

10 Critical Myths and Realities of Master Data Management

Prevalent myths surrounding MDM alongside an explanation of the realities.

A common trap for customer data MDM projects is to build what The Data Warehousing Institute calls a "roach motel MDM architecture." Data checks into the hub from operational applications such as ERP, CRM and financial systems, but when it comes out, it's routed downstream to (often siloed) databases.

That's a nice trick for analytics, but it's not really addressing the "big picture" goal of MDM of creating a "golden record" of customer data across your system.

Bottom line: This one-way approach to master data (data checks in but doesn't check out) won't work when you need to fix your reference data in one place and then publish it to the various operational applications, warns a recent TDWI report on MDM best practices.

You'll see a lot of discussion about MDM hubs in the tech publications, and that's why I'm bringing this up: TDWI is making an important distinction here. Lots of MDM approaches will be called "hubs," but that's confusing and it may account for why some MDM initiatives pay off and others don't. As TDWI explains:

Although roach motel MDM architectures are sometimes called a customer data hub, it's not really a hub. A roach motel is merely an operational data store (ODS) or, worse, a data staging area. If you want to reach the full potential of MDM-and especially if you want to operationalize MDM-then you need a real hub that can do more than just aggregate data and pass it to a short list of targets.

In other words, in a true hub, the data flow should be a two-way street. If it flows into MDM from an application, it should also be able to flow out of MDM to the application - after, of course, it's been cleansed.

And that brings us to another important distinction TDWI is making about MDM hubs: It shouldn't just move the data, it should improve the data:

All MDM applications should improve reference data on the hub and then synchronize it back to source systems so they benefit, too. Typical improvements include data standardization, matching, deduplication, and identity resolution. As with the roach motel, reference data from a hub can still flow downstream to BI data stores. Yet these may also add value to reference data and then sync with the hub.

So how do you go about building an MDM hub? TechTarget published a practical step-by-step guide on this topic. One warning: The language is different, but I'm 95 percent sure the TDWI's advice would diverge at point Eight, "Out of the staging environment," item a: The registry approach. That's because TDWI's first piece of advice for a hub (bidirectional MDM architecture) is first of all, avoid roach motel MDM architecture by making "reference data fully sharable by managing it through a true hub that supports data movement in many directions."

In which case, a registry isn't going to cut it.

Beyond that, what other steps can you take to ensure you're building a true MDM hub? The TDWI says the hub should:

• Make MDM's reference data fully accessible by a variety of interfaces, including Web Services.
• Improve reference data, rather than just managing it in the hub.
• Synchronize reference data across multiple applications. (Again, see point one: Avoid roach motel MDM.)

I suspect this advice may be too late for a lot of organizations. In another TechTarget article, Gartner analyst John Radcliff says he's starting to run into companies with several MDM solutions. He describes companies as having a "hierarchy of MDM hubs" that are "hard merged" locally but "soft linked" centrally.