You are here:  Home  >  Data Blogs | Information From Enterprise Leaders  >  Current Article

Diving into the Details of MDM

By   /  July 1, 2013  /  No Comments

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


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


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


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.

About the author

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.

You might also like...

Three Ways to Mitigate Your Company’s Data Risk in 2019

Read More →