last week’s post Master Data Management (MDM) – Going Where the EDW has Gone Before, I discussed the idea that Enterprise Data Warehouses (EDW) have long been used as default MDM solutions.

In this post I will discuss two barriers that have inhibited it from working, and what I think does work.

Barrier One: Multiple “Single Versions of the Truth”

First, the EDW supports “downstream” analytical application and business intelligence but not “upstream” data sources such as Enterprise Resource Planning (ERP) systems. This is not an inhibitor to supporting BI and reporting. But it does become a problem when it’s expected to support operational MDM, i.e. creating a master list to support ERP systems.

The underlying assumption for most IT groups is that the ERP systems manage their own data, including master data, since the ERP system was where the data originated in the enterprise.

But a funny thing happened on the way to delivering the single version of the truth via ERP systems – people used more than one of them, and each one had its own version of master data. Maybe an enterprise had products from different ERP vendors or maybe they implemented the same ERP system multiple times in their enterprise specific to different business groups.

Regardless of why, the end result was that the ERP systems needed a MDM repository to accomplish an enterprise role. That has led ERP vendors to start building their own MDM solutions specific to their products, and for other software firms to build stand-alone solutions.

Barrier Two: No Silver Bullets

The second constraint on successfully implementing an MDM solution using an EDW has been the assumption that technology was going to solve the MDM problems without significantly including people and process (and of course politics) in the equation. Data governance, with the business taking ownership of the data and IT becoming its custodian, is needed to successfully design, deploy and sustain a MDM solution.

Business people need to help IT identify master data, define it and assist in determining what the resultant master list should be. Managing master data needs business commitment if it is to be treated as the corporate asset that it is.  It is important to note that this inhibitor is not systemic to any technological approach, but rather needs to be included in whatever solution is developed.

What’s the Solution?

So, you may figure that since the approach using an EDW as the default has not worked flawlessly, it must be time to buy a MDM product, right?

Although buying versus building may be the most cost-effective approach, let’s step back before you sign that purchase order on a shiny new MDM product. You should determine what is needed before you buy. Failing to understand why past efforts have come up short is a sure recipe to failure. You might deploy a new MDM product, but still not achieve the business results you want. Even worse, you might be creating yet another data silo – moving you either further from a single version of the truth.

The two ingredients to success are an Enterprise Data Integration (EDI) platform and Enterprise Data Management (EDM).

An EDI platform addresses the first inhibitor discussed above by enabling two-way integration between your operational and analytical solutions using the appropriate technique, such as SOA, EAI, EII or ETL, that is needed to integrate the various enterprise applications and EDW. By implementing tactical stand-alone data-integration tools in the past we constrained each solution built. Typically, an EDW used ETL and the enterprise applications used EAI technology,  which limited the ability of the analytical and operation systems to exchange and integrate their data

EDM, particularly data governance, is essential for any MDM solution to get started and stay in operation. No technology is going to eliminate the human element of these solutions.

Should you buy a MDM product? Maybe, but before you do make sure that an EDI platform and an EDM program are in place to ensure success.