What’s Your (MDM) Type?

By Bill O'Kane, Senior Consultant

 

photo by Dan4th

As part of an interview recently given by Evan Levy, he was asked to explain the various flavors of MDM implementation. The three generally accepted categories are persistent (all master attributes stored and maintained exclusively in the data hub for access by client systems), registry (sets of master attributes stored and maintained in client systems are registered, or “pointed to” by the data hub), and hybrid (also sometimes referred to as co-existent, where a copy of some or all of the client systems’ master attributes are stored and maintained both in the data hub and the client systems). While each MDM implementation is inherently different due to the uniqueness of each business and operating environment, these categories sufficiently encompass the vast majority.

I’ve come to realize that all of the projects I’ve been involved in have been of a single type: they began life as persistent-style hubs (and in fact, were justified this way in terms of a business case), and later became hybrid, as the costs associated with ancillary tasks (such as remediating all of the legacy batch processes to access the data hub) came to light during detailed source system integration planning and analysis.

I often discovered a heavy reliance on vendor-driven operational systems, which many times limited the ability to remediate certain technical processes. However, in spite of the fact that it became necessary to retreat from the completely persistent view from a tactical perspective, I believe that all of these projects remained successful because the persistent-style vision was kept on as a strategic guiding principle. In other words, the project teams were held accountable for creating data architectures that would support a persistent-style implementation, even if the source systems were allowed to keep their copies of the master data for a while longer. In fact, on some occasions, the project team was even asked to submit project plans for these future remediation tasks for use as time and budget might permit.

Although I’m less familiar with pure registry-style implementations, the idea of implementing something like this without a more persistent-style strategic vision to guide the proceedings makes me a bit uneasy. For example, questions I’ve heard come up more than once in regard to registry style: How is this different from the Virtual Data Warehouse concept we tried and failed to implement fifteen years ago?, or Won’t we just be creating another data silo? I have to confess, I don’t have a great response to these. Moreover, one of the things that originally drew me to MDM is that its nature (when persistent or hybrid) forces organizations to at last come to grips with the sins of their pasts in regard to data architecture, data governance, and metadata. 

---

Bill O'Kane has twenty years of experience in the design, development, and implementation of large-scale Master Data Management (MDM) systems and Data Warehouses, with an emphasis on Customer Data Integration (CDI). His experience includes both the development of internal systems and the integration of vendor-based solutions in complex environments. Bill has achieved success in diverse corporate environments including Fortune 100 financial services and health management companies, mutually held insurance companies, and privately held software vendors.

Comments

[Dan Power]

Nice post, Bill. You capture the three major MDM implementation styles very well.

I think you put your finger on one of the major reasons companies do MDM: hoping to "come to grips with the sins of the past" with regard to how they strategically create, manage, and get value from their data.