Over the last few months, a few companies have asked me a disturbing question: “Which project do you recommend we do first, Master Data Management (MDM) or Data Governance?” “We have pressure to do both.” My answer in all cases has been “why do you believe you need to choose? You should do both as one project.” The reality is that while you can implement a Data Governance program without doing an MDM project, you cannot implement MDM without doing a significant bit of Data Governance. The two efforts are not mutually exclusive.
I hope my answer has not surprised you. Yet for those of you that are new to Data Governance and MDM, the answer may actually surprise you. But consider this: one of the most significant business use cases for Data Governance is the implementation of MDM. We see MDM used in two different types of business use case approaches to justify Data Governance – either as an offensive approach, to generate greater sales; or as an efficiency approach, to reduce the cost of operations. Let’s explore both approaches and how metadata, the business glossary, and data governance can be leveraged for MDM success.
MDM can be implemented to improve revenue opportunities and improve the customer experience. My first Business Glossary implementation was in support of an MDM offensive business case. These use cases may include clarifying and consolidating the customer base, and identifying customer touch points and customer interactions. Often this includes defining what each business unit considers to be a customer or prospect; yet the objective is to identify, define, and implement the data, people, and processes that can generate additional revenue. This approach is generally driven by a business executive or even the CEO.
MDM can also be implemented to reduce the systems and cost of creating and maintaining product, reference, or customer data. This is often the use case where an organization has gone through many mergers and acquisitions (M&A) over the years. The same customer may have the same data in many siloed applications that have point-to-point interfaces to share that data and metadata. About four years ago I worked with an organization that had 72 separate applications that created and maintained customer data. Yeah – firms had been bought by firms that in turn were bought others, with no consolidation over the years. Thus, multiple applications performed the same business functions with what seemed like the same customer data but not necessarily with the same rules. This is a Data Governance business use case for consolidation, optimization, and efficiency improvement. We often see this use case driven by the technology organization as this use case is seen as a technology problem. Hidden in this use case is often a large problem with reporting and analytics quality and consistency. There are many views of a customer, thus no one correct count of customers can be agreed to until we address the MDM problem.
So why should we consider the above MDM implementation cases as Data Governance use cases? Why MUST one do a bit of Data Governance in every MDM project? Glad you asked Bob. Let’s look at what resources, processes, data, and metadata is needed to make the MDM project successful. And, of that, what your Data Governance processes and resources should provide. Of course, we must recognize that not all technical or business functionalities needed by an MDM application will ever be provided by a Data Governance team. Yet, the following should.
Simply an MDM implementation requires the following Data Governance activities:
- Agreement on the 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 accountability does not have to be for the full golden record, but can be by data element in the golden record. This is a Data Governance activity and the results should be maintained in the Business Glossary. The identification of Accountability is a critical deliverable from Data Governance.
- 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.
- Agreement on the business terminology of the data being mastered (customer or vendor or employee). This terminology is your Business Terms and should be maintained in the Business Glossary. Additionally, you will need to create a hierarchy for the terms, which is generally called a taxonomy.
- 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, archiving, 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. The decisions about those rules should be maintained in the Business Glossary. There is a triple play here that must be achieved, since the rules and policies will be at the business level, data quality level, and technology data consolidation level. I’ve split this up for simplicity.
- Agreement 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 and the associated thresholds are a Data Governance activity. Agreement on the profiling rules and sources for determining 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 consolidation rules. There will likely be many applications that will provide individual data elements for the golden record. Conversely, 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 this and the merge/purge functionality must be maintained and provided to all data consumers. This is known as traceability and data lineage so consumers can know where the data came from to determine their data usage correctly. Again, the metadata for data lineage and traceability should be maintained in the Data Governance 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 to make use of the Governance resources.
- Agreement on the processes and standards that will be used to manage data issues for the MDM data. Management of data issues is a functionality that the Data Governance team should be able to provide to the MDM project.
- Agreement on the measures and metrics that will be used. These may be metrics for 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 the “golden record” that will be used by applications and the data that will be visible to customers. The what, why, how, when, and where for the usage of data is the responsibility of Data Governance. The mastered data in a golden record is one view of the data that needs to be governed in a consistent manner. The data usage policies, communications, education, and data sharing agreements are the responsibility of Data Governance. Leverage these deliverables for your MDM project.
- 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 project 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!
Hopefully, I’ve made my point. There should not be a question of whether to do an MDM project or a Data Governance project. It is not a question of which, but a question of when do we start the MDM project so we can further the adoption of Data Governance. It is not two efforts, but just one that has significant benefits and value to the organization from a business and technical view. Yes, MDM is more than Data Governance and Data Governance is more than MDM. But the MDM project should be considered as an implementation of both practices. And as always, stay calm and allow your data governance program to prosper.
