Diving into the Details of MDM

diveby Christine Denney

A very astute reader commented on a past blog and suggested that it would be nice to dive into some details about MDM implementations because there are so many things uncovered during a detailed analysis.  I wholeheartedly agreed!  The devil is definitely in the details and MDM projects are notorious for being complex.  There are also implications, resulting from the implementation, that aren’t necessarily considered during the planning stages.  With so much variance in MDM projects, how could I provide enough detail to be useful, while allowing for multiple factors affecting projects?  After trying to consider all the possibilities, I was swimming in a sea of details.  There had to be an answer, but what was it?

As I looked at a variety of projects, I noticed that the triggers for many MDM projects seemed to have some common themes.  Implementation patterns sounded like a viable option.  If we looked at common business problems that triggered the need for MDM initiatives, what were the common themes?  At the conclusion of the implementation, were there any similar outcomes?  In this installment, we examine three sample cases.

Case 1:  Technically Challenged

Characteristics:

The seemingly simplest case is where you have existing governance, data standards, and rules, but there are some technical barriers causing inefficiencies (i.e., IT solution is less than optimal).  For this example, we will pretend that the data are managed in spreadsheets and the stewards are having issues with concurrent users trying to make updates, routing/approval of changes, and tracking updates. While trying to manage the master data, stewards are updating the spreadsheet manually and sometimes changes are overwritten.

The Solution:

This seems to be the perfect case for an IT solution (e.g., an MDM package or a database with a user front-end) that allows concurrent users and tracks each record that is entered or updated.

Potential Outcome:

The new tool has been implemented.  Stewards can enter records, route them for review, and manage changes.   It’s exactly what they needed, isn’t it?  After all, the only issue in this scenario was the tool, right?  Perhaps, but moving from a steward-controlled spreadsheet to a central system may uncover some process issues and business rules that were not apparent.  Were all of the exception cases considered?  With the spreadsheet, stewards had full control over what to do when something out of the ordinary arose.  Need a new column? Just add it.  Need a new value entered for a pick list?  Just add it.  The data anomalies can prove to be a huge problem and need to be explored during the requirements gathering.  Another thing to consider is whether the existing governance model will require changes.  Are there new roles or responsibilities that emerge with the presence of the new environment?

Case 2: A Mixed Bag

Characteristics:

A slightly more complex case is where you have a distributed model for the master data – attributes for the master data entity reside in multiple systems and need to be consolidated together. Each source system has an active steward and contains a unique set of attributes that will contribute a master data record.

The Solution:

In this case, we will pretend that duplicate records do not need to be reconciled/merged and each system has an attribute that can be matched to other systems.  A consolidation mechanism, such as a physical or virtual repository, offers an area where the data attributes can be brought together.

Potential Outcome:

The attributes have been brought together, into a complete view of the master data element.  It’s exactly what they needed, isn’t it?  The issue with the varying locations of the attributes has been solved and there is nothing else to consider, right?  Probably not.  Bringing together attributes from a variety of sources introduces new security, data quality, and governance requirements.  Who is responsible for the consolidated data (that can be a tough discussion)?  If errors are found, where are changes made?  Does a record have to have attributes from every system?  Who determines when and how the data can be shared?  Some attributes may have more security limitations than others.  The governance structure, data security, and confidentiality level of data may change when different sources are brought together.  Consider these aspects in requirements and design.

Case 3: Chaos Reigns

Characteristics:

Unfortunately, this is one of the most common cases, but is also the case where a successful implementation brings tremendous value.  In this case, data governance is limited (or non-existent), multiple sources and processes are used to create the master data element records, and the sources do not even have a common identifier.

The Solution:

Complexity in the processing of the disparate data requires additional capabilities that the previous cases did not need to consider.  In addition to solutions mentioned above, this case requires data quality solutions to recognize and reconcile duplicate records and stewards to manage the data.

Potential Outcome:

A new governance organization was established, the legacy source systems have been mapped to a new, common model, and a tool has been implemented to assist with the stewardship process and matching/merging of records.  Everything is settled, right?  Because of the complexity of this case, there are (unfortunately) a number of factors that need to be considered.  Is there support for establishing a “master” data source?  Is there a group who clearly has responsibility for this type of data?  Are the rules to match records too complex or varied to be automated?  In a future installment, I will talk about some templates that can help with the details and considerations of this complex case.

And now for some good news….

MDM projects aren’t simple, nor are they free, but they do bring tremendous value to the business.  If we examine a variety of potential outcomes (both positive and negative) during the early phases of the project, we can deliver a better solution and avoid some of the common pitfalls.

NOTE: All opinions in this blog are those of the author and not her employer.  Any similarities between the cases mentioned above and my (or your) implementations is completely coincidental.

Related Posts Plugin for WordPress, Blogger...

Christine Denney

Christine Denney is responsible for Enterprise MDM strategy and implementation at a fortune 500 company. She has almost 20 years of experience in systems development and data management, with a focus on Data Governance, Reference Data, and Master Data Management for the past 12 years. She is co-founder of the Translational Medicine Ontology task force, a W3C Healthcare and Life Sciences Interest Group, and serves as the VP of Communications for DAMA Indiana. Christine has a Bachelor of Science degree in Computer Science, holds mastery CDMP and CBIP certifications, and is ITIL v3 certified. Christine can be followed at: http://twitter.com/im4infomgt NOTE: Thoughts expressed in blogs and articles are the author's and not her employer's. 

Tags:

  5 comments for “Diving into the Details of MDM

  1. July 1, 2013 at 1:35 am

    This is an excellent post Christine.

    It reminds of a blog post I made around hub styles.
    http://www.semarchy.com/semarchy-blog/backtobasics-mdm-hub-patterns/

    I think that you should also take into account that fact that customers shift from one situation to another over time. As a consequence, the MDM solution that will be delivered has to evolve over time.

    • Christine
      July 11, 2013 at 9:44 am

      Great point – yes, MDM solutions must keep up with the changing needs of the business. Thanks for sharing the link to your post!

  2. Richard Ordowich
    July 22, 2013 at 8:17 am

    I question this statement: ” but they do bring tremendous value to the business”

    I have not seen any substantiated evidence of this. We read about the numerous MDM projects that have stalled or failed however.

    Legacy systems create a complicated environment for MDM and most projects stall after one system uses the MDM environment (typically a data warehouse). Each subsequent system must be reconciled to this view of the data from both a technical perspective (technical metadata, name, definition, value domain) but more challenging from a business perceptive(business metadata, semantics, taxonomy, ontology). Reaching consensus on metadata is time consuming and difficult process and is the Achilles heel of MDM. Few organization realize this until well into the development of an MDM solution.

  3. Christine
    August 19, 2013 at 10:27 am

    Hi Richard,
    It is unfortunate that the MDM failures make the news, rather than the successes. Fortunately, we do have many success stories to remind us of the value (and possible success) of MDM. The Customer domain probably has the most success stories (because it was an early domain), but Product and other domains also have had success.

    One of the issues is scope (an issue for most IT projects). We tend to think that MDM utopia can be achieved in one huge project, with an enormous and complex data model, and a multi-year development timeline, but that doesn’t seem to be the best strategy in most cases.

    Second, we have to use MDM appropriately to solve a Master Data problem. Often there is confusion around the purpose of MDM and it is used (or people claim they are using it) when other techniques are more appropriate. MDM isn’t intended to replace data integration, warehousing, transaction processing, or analytics. We also need to stop calling multi-discipline integration solutions “MDM” and recognize that MDM is just one component of those solutions.

    Again and again, I hear some common themes in the success stories: 1) Governance – having the right, authoritative decision makers and guardians of the data assets, 2) Finding the “core” attributes that must be synchronized to enable identity management of the person/place/thing – you don’t need every attribute from every source system…reach consensus on the critical attributes that must be integrated, and 3) incremental development – find the smallest delivery that will add value and prove it works.

    Best,
    Christine

Leave a Reply

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