Monday’s Musings: Master Data Management – Do Styles of MDM Matter Anymore?

Published on February 2, 2009 by R "Ray" Wang

Three Architectural Styles Represent Different Technologies To Build MDM

In 2003, customer data hub (CDI), product information management, and master data management (MDM) vendors strived to differentiate themselves by architectural style.  Each approach had its advantages and disadvantages.  A religion about styles emerged overnight along with a hard core following.  Here’s a quick recap (see Figure 1):

Figure 1.  The Three Architectural Styles of Master Data Management

Three Common Styles Of Master Data Management

The bottom line – choose a style that aligns with your project’s business driver
While these approaches still exist, leading vendors such as D&B Purisma, IBM, Initiate Systems, Oracle, Oracle-Siebel, SAS DataFlux, and Siperian now have offerings in more than one style. This may make the question seem less relevant, however, its still important to understand the trade-offs while beginning your MDM journey.  In fact, it’s best to align the style and approach based on your business driver.  Here’s a high level summary:

  • Cross-referenced registry delivers rapid results for operational efficiency business drivers. This approach is best suited for rapid implementation scenarios such as POC’s that prove the value of master data.  Also valuable when data can not be stored on-site.
    Pro’s: Rapid implementation without having to agree on a common enterprise data model.  Utilize existing source systems.
    Con’s: Deduplication of source systems not addressed.  Data quality must be solved in each independent source system.
  • Hybrid harmonized reference enables compliance and regulatory business drivers. This approach allows the best of both worlds, especially when moving to a transactional operational data store is not politically feasible and data governance and stewardship activities are just starting up.
    Pro’s: Single master copy of reference data.  Uses links to access source system records.  Model allows data quality efforts to be applied to shared master  reference data.
    Con’s: Synchronization with source systems can create some complexity if changes are not made in the hub.
  • Transactional operational data store supports strategic business drivers.  This approach provides a long term path for how legacy applications utilize data.
    Pro’s: Single master copy of data.  No fussing with latency or synchronization issues.  Minimal mapping issues.
    Con’s: Requires an agreed upon common enterprise data model to be used by all applications.  History must be harmonized and requires extensive key mapping.  Assumes homogeneity and requires tons of ETL and dedupe.

Your POV.

Which MDM style are you deploying? What successes have you seen?  Post your thoughts or send me a private email to

[poll id=”2″]

Copyright © 2009 R Wang. All rights reserved.

  • Time and budget have led us to cross-reference registry. All we need is real time matching and to get to accurate analytics. Option 2 and 3 are just way too complex and unnecessary for us b/c we do not have to clean the data up.

  • It seems to me that MDM is a technology focused activity that should be replaced by a Business Architecture approach. The problem is that the MDM is focused towards the data store but not towards the use of the data in the programs, the service interfaces, business rules, the business content and in the user presentation. A single enterprise ontology of business objects that implements a well-defined taxonomy of would then provide the data model for storage and archiving. Phew … yup, there are quite a few technology chasms to cross. Today a change in the MDM requires further changes in many other places that have to synchronized in deployment. Anyone surprised that we don’t have agility? SOA is not going to change that …

    Alternatively you could work with the Papyrus WebRepository and get all that for free

  • Styles matter hugely, but mainly due to the capabilities required to implement them. I suspect that many an MDM effort has failed due to over-engineering. It’s all too easy to lay out a full hub strategy even if you only need a registry at a point in time…it just makes strategic sense apart from anything else.

    However, progressing through the maturity curve from registry->hybrid->hub allows you to build your company’s data management capability (inc. establishing governance) incrementally. Registries require capability a factor of 10 smaller than hubs. Chances are that if you need MDM then your data governance and management practices are not the best so why increase the risk of failure if you don’t need to? Works extremely well if your MDM requirement is even partially BI driven. If the need is more operational then it’s still a great first step…build a registry hybrid, spend some time sorting your governance and quality out, then once you have a nice clean set of master data, flip the model on its head and…hey presto…you have your hub – and you can manage it!

    Remember – single point of entry/distribution home built MDM ‘solutions’ (the ‘original’ hubs) have been around in the ERP space for 10 years. The reason they failed in many orgs is due to poor governance and management. MDM packaged apps can help in this regard, but you have to grow into them. MDM is a journey and there’s no easy shortcut to the end.

    One thing that would help: The MDM vendors that provide mixed mode MDM solutions should consider associated pricing structures. $x for use as registry, $x+y for hub. Would certainly support quicker adoption and success rates.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Posts