In a recent post on the Predictive Analytics Trends blog, Stephen J Smith wrote about how Master Data Management is broken

Some key points:

Master data management is not a technology problem.

“In master data management, fundamentally, your data problems are not technology problems. They are not even MDM problems. Your data problems aren’t even really well … data problems. They are business problems”

For master data management to succeed, we need to work from the business down.

This means working with multiple business stakeholders to understand their issues, their priorities and how they use data.

It means consolidating these different perspectives into (if possible) a single plan and agreeing on priorities.

It means managing expectations knowing that not everybody will have their immediate needs addressed in an initial deployment,

It’s about getting and keeping business support.

Data governance looks to achieve these goals.

Data governance defines accountability for how data is used within the organisation, and by extension, data governance defines how master data should be defined within the organisation

Data governance (and master data management) must be collaborative

In many cases, master data projects are driven from a central point based on the needs or demands of one key stakeholder, at the expense of others.

Often this is done with good intentions – to reduce complexity and to deliver value quickly – but it can have severe consequences.

• Key knowledge and requirements may be missed or ignored. This can mean that the value assumed is not realised, or that it cannot be easily extended into additional business areas
• Ignored stakeholders can become unhappy stakeholders.

From a management perspective, keeping everybody in the loop is critical to identifying the correct priorities for your MDM program, and to managing expectations as the program unfolds. This keeps people on side as they understand and agree when their priorities will be delivered, and have visibility into the program’s progress and success.

Data Stewardship is not Data Governance

A large number of master data management tools claim to deliver data governance.

In most cases, these capabilities are limited to providing interfaces for master data stewards to manually approve potential matches

They do not provide a collaborative environment to define and agree on business priorities, rules and approaches as mentioned above.

You will have to look elsewhere.

Do we need to choose between MDM and Data Governance?

If data governance is essential for MDM then should we put MDM on hold until we get governance right?

Data governance, like anything else, should be implemented for a purpose. Master data management provides a fantastic, focused use case for data governance.

In Data Governance + Quality = MDM I discussed how any master data project should comprise 4 streams:

1. Data governance: Defining the requirement and business responsibility
2. Data quality: Agreeing on the data standards and match rules for master data
3. Data integration: Defining the requirements for synchronizing master data
4. Data architecture: Agreeing on the technology stack to achieve the above

Starting with data governance for MDM will help you to understand the decision-making processes and structures, help to identify key stakeholders, and start to get some clarity on business definitions, policies and rules, etc.

This start can then be extended to other data governance use cases, such as advanced analytics, data privacy, or a myriad more.

Data governance is the foundation of MDM

In a great post last year, our partner discussed why MDM needs data governance and looked at a number of examples of when, and how, data governance has helped clients achieve their MDM business goals.

The post is worth reading in its entirety – but I have quoted extensively from it with this list of data governance activities that support MDM

• Agreement on the business and technical resources that will be accountable for the mastered data. It is necessary to have one resource (person, business unit, or committee) to be accountable for the data in the MDM “golden record”. This is a data governance activity and the results should be maintained in the business glossary.
• Agreement on the data that will be mastered and the associated metadata (data length, type, etc.). The decision may not be a simple one as all business unit functions and usages of the mastered data must be considered. This is often a technology decision and may impact existing application systems. This too should be maintained in your business glossary.
• Consensus for the business terminology of the data being mastered (customer or vendor or employee). This terminology is business terms and should be maintained in the business glossary.
• Agreement on the business rules and policies that will be enforced for the management of the “golden record data.” The business rules that govern the creation, management, archive and disposition of the customer data may vary by the legacy application and business unit functions, as well as regulations that govern an individual business unit. These rules and policies need to address all of the needs of all business units. These rules should be maintained in the business glossary.
• Consensus on the data quality rules for the golden record data. This one can be a challenge given that all application and business unit usages must be factored into the decision. Defining data quality thresholds are a data governance activity. Agreement on the profiling rules and sources for determine the quality level is also a data governance activity. Data quality metrics should be maintained in the business glossary so all data consumers are aware of the level of quality prior to their usage.
• Agreement on the technical data integration and consolidation rules. There must be rules for the consolidation of like data into the golden record. The data from one application may take precedence over the same data from another application. This is also a data governance activity, determining the best data for the organization to use. The metadata of the merge/purge functionality must be maintained and provided to all data consumers. This is known as traceability and data lineage. Again, the rules and operational metadata should be maintained in the business glossary.
• Agreement on the resources that will function as data stewards to maintain the mastered data and validate merge/purge records to maintain the best data in the golden record. Yes, these are the data governance resources in both the technology and business teams. You may need stewards from many business units to manage customer MDM data. The roles and responsibilities, as well as policies from data governance should be used by the governance resources.
• Consensus on the processes and standards that will be used to manage data issues for the MDM data. Management of data issues is functionality that the data governance team should provide to the MDM program.
• Agreement on the measures and metrics that will be used. These may be metrics in the progress of the MDM implementation, metrics for data quality, metrics for data issues, or metrics for the governance of the MDM data. Again, this is a critical deliverable from data governance and the metrics should be maintained in the business glossary.
• Agreement on all associated reference data that will be used with the mastered data. We see the increased importance of reference data in both product and customer MDM implementations. Many consider reference data as a type of MDM implementation. It is a core set of data that the data governance team must address as early as possible. Reference data is one of the data domains that must be considered as enterprise data and has significant value to the MDM program and all other applications in the enterprise. And yes, your reference data should be maintained in the business glossary (not that you would question that by now).
• Lastly, the MDM implementation should leverage the data governance ability to communicate, educate and promote the critical data projects that impact everyone in the organization that uses data. And, today who does not use data!

Don’t make the mistake of building your MDM without a sound foundation.