Modeling the MDM Blueprint – Part 1

Several practitioners have contributed to this complex subject (see Dan Power’s Five Essential Elements of MDM and CDI, for example) and have done a good job at describing the critical elements.  There is one more element that’s often overlooked however, and it remains a key differentiator and all too often, it’s the difference between success and failure among the major initiatives I’ve had the opportunity to witness – modeling the blueprint for MDM.

pen1This is an important first step to take, assuming the business case is completed and approved. It forces us to address the very real challenges up front, before embarking on a journey that our stakeholders must understand and support. Obtaining buy-in and executive support means we all share a common vision.

MDM is more than maintaining a central repository of master data. The shared reference model should provide a resilient, adaptive blueprint to sustain high performance and value over time.

An MDM solution should include the tools for modeling and managing business knowledge of data in a sustainable way.  This may seem like a tall order, but consider the implications if we focus on the tactical and exclude the reality of how the business will actually adopt and embrace all of your hard work.

Or worse, asking the business to start from a blank sheet of paper and expect them to tell you how to rationalize and manage the integrity rules connecting data across several systems, eliminate duplication and waste, and ensure an authoritative source of clean, reliable information can be audited for completeness and accuracy. Still waiting?

So What’s in This Blueprint?

The critical thing to remember is the MDM project is a business project that requires establishing a common information model that applies whatever the technical infrastructure or patterns you plan on using may be. The blueprint should remain computation and platform independent until the Operating Model is defined (and accepted by the business), and a suitable Common Information Model (CIM) and Canonical Model are completed to support and ensure the business intent.

Then, and only then, are you ready to tackle the Reference Architecture.

The essential elements should include:

  • Common Information Model
  • Canonical Model
  • Operating Model, and
  • Reference Architecture (e.g. 4+1 views).

I’ll be discussing each of these important and necessary components within the MDM blueprint in future articles in this series, and I encourage you to participate and share your professional experience. Adopting and succeeding at Master Data Management is not easy, and jumping into the “deep end” without truly understanding what you are solving for is never a good idea.

Whether you are a hands-on practitioner, program manager, or an executive planner, I can’t emphasize enough how critical modeling the MDM blueprint and sharing this with the stakeholders is to success. You simply have to get this right before proceeding further.

Tags: , , , , ,

4 Comments on “Modeling the MDM Blueprint – Part 1”

  1. Tom Engers 07/28/2010 at 2:26 pm #

    I would most appreciate someone discussing the values and hardships of:
    1. MDM feeding the DWH … and
    2. The DWH feeding the MDM

    … thanks


  1. Thank You To Our Readers « Hub Designs Blog - 12/23/2010

    […] and Roadmap, and the First Look at Oracle Fusion MDM Hub. Jim Parnitzke’s series on Modeling the Blueprint for MDM proved so popular, we re-ran it this summer, as did Rob DuMoulin’s series on Data Profiling […]

  2. Hub Designs Blog’s Top 10 for 2010 « Hub Designs Blog - 12/29/2010

    […] Modeling the MDM Blueprint, by James Parnitzke – A six part series on applying important enterprise architecture concepts to MDM projects. […]

  3. Writing for the Hub Designs Blog « Hub Designs Blog - 01/14/2011

    […] of our most popular articles on the Hub Designs Blog have been written by guest authors such as James Parnitzke, Rob DuMoulin, Maureen Butler and Joan […]

%d bloggers like this: