Contact us for additional information

Where Data Governance Stops and MDM Starts

I have to admit, the title is a slight misnomer. Data Governance (DG) never actually stops, but the lines of responsibility vary greatly based on the flavor and depth of Governance in an organization. From the other direction, MDM itself is an exercise in data governance, so can we extrapolate that MDM is really just DG? If it were so, I could redefine an entire industry with this article. The gray area between DG and MDM is real and artificially exists due to a lack of definition, maturity, or understanding within an organization. Considering that methodologies for MDM and DG have many variances, it would be a challenge to hit on every possible permutation of DG and MDM to define the dividing lines. Doing so would make for a long and painful read and probably be published under a self-help genre for curing insomnia. Instead, let us generalize on the goals of each and try to find that utopic business model where there is complete harmony. To do so, I have broken the discussion into three topics: DG, MDM, and that gray matter in between. 

Governance

Data Governance organizations are business entities that define and manage the most vital corporate asset, business information. Governance organizations may vary in participation and influence, but they share common goals of corporate data policy definition, policy enforcement, and communication. DG initiatives arise from self-awareness amongst the business leadership that they create and own information and that IT serves as its librarian. Throughout the business are pockets of information, some self-contained within a single business process and some shared across many. The self-contained departmental information can be manipulated, manufactured, and retired with little concern over consequences to external business processes and are of lesser concern to Governance organizations. When information created by one business process is integral to other business processes, it become apparent that a lack of control introduces organizational risk. DG strives to define the structure within the organization to manage the complete information lifecycle of information deemed to be of business importance in order to mitigate risk.

The best or most effective methods to accomplish successful DG can be the subject of numerous heated debates. I submit that such debates detract from the true mission of identifying what information is important, how to manage it, how to communicate about it, and most importantly, how to measure the effectiveness of your Governance efforts. If the business already realizes a need for Governance, half the effort is done. As long as there is a desire to institute and improve a process, most any dialog is a step in the right direction.

One aspect of Governance that is rarely in dispute is the identification of data owners and data stewards. Data Owners are responsible for the accuracy and completeness of the information and Data Stewards are entrusted to maintain this accuracy. Also common is the Governance Council which defines the standards and processes to be followed by the Owners, Stewards, and Librarians. These standards and processes are company assets that become the rules of law for all things data. Like rules that govern acceptable behavior in our society, these rules are in place for the good of the business.

MDM

MDM is an information-centric business process to consolidate and manage specific enterprise data that just happens to use technology to assemble, merge, and distribute the data in question. MDM arose from a need to ensure consistency of strategic shared information to improve data quality, accessibility, and security. MDM is unique in that it is limited to specific shared information that is not transactional in nature such as: common reference codes, persons, products, or locations. Value realized from an MDM solution occurs when information is made consistent across the organization, duplicate records are identified and handled, and the quality of the information is markedly improved. Achieving data consistency and quality requires a thorough understanding of the information at hand, how and where it is created or modified, and what roles and rules are needed to manage its data lifecycle.

Methods for MDM, like DG, vary by business and business need. Long before any MDM solution can be implemented, extensive process and information re-engineering must be planned for. Organizations that do not integrate information across departments effectively have a much harder time getting consensus during this planning process.  Despite the MDM data subject, methods, or tools used, a common practice of the planning process is to identify those responsible for the data in question and those responsible for its daily management (similar to the data owners and stewards above). For the select information within its domain, MDM should consider management from data inception through retirement and all uses between.  Roles of an MDM project include Business Analysts, Data Architects, Data Owners, Data Stewards, data providers, and data consumers.

Gray Matter

Unless my hints were not blunt enough or I've put you to sleep already, it should be apparent that there is significant overlap in the purpose, roles, and assets between Governance and MDM. Both processes define data elements and rules around their creation, management, and retirement. They also both identify owners and stewards of information and place a structure around the process for ensuring data quality, security, and interaction.  So it seems simple that these overlapping roles would be one and the same, right?  Right?

In a utopic business world, the DG organization would be in place before an MDM initiative begins. Such a DG organization would be structured with the foresight to handle an MDM initiative. In fact, in Utopia, the DG organization would be the driving force for identifying the business need and performing the cost-benefit analysis to justify such an MDM project.

Without tight coupling between MDM and DG, each initiative will see void in their processes and fill them in order to be successful in their own right. If DG has not instituted data standards prior to the MDM envisioning stage (or they are not followed), MDM may limit itself to what is needed to satisfy the current phase or one system. For example, MDM in a vacuum may have no reason to validate the business definition, domain, or business name of an attribute or list of values does not conflict with an already-established business data element. A source system may use NULLs to indicate yes or no conditions or have other non-documented defaults that flow into the Best Version of Truth. Without a global view of how Yes/No indicators should be handled, an MDM project could proliferate ambiguous data to all its consumers.

Another area of consideration is the logging and reporting of data errors and exceptions. In Utopia, Im told, it is a law that each data element is assigned a data owner, a data steward, a domain of allowed values, restrictions, and a distinct definition. When data is introduced that break these laws, the violation is recorded and the owner or stewards are notified to rectify the situation. A clearly defined policy to automatically identify and report such violations along with a policy to address these issues in a timely manner ideally springs from a strong DG presence rather than an MDM afterthought.

It is expected that DG evolves to handle new technologies regardless if the technology is only new to the organization.  In the case of MDM, a DG organization needs to be able to address MDM concepts like trust and survivorship as well as create expand policies around data dictionaries and canonical modeling. With tight coupling, an MDM project will look heavily to a DG organization for guidance and resources and MDM will become another data standardization model to demonstrate the value of DG. 

Summary

MDM should be considered an extension of DG. Without proper controls and standardization of data, the worst case for an MDM project is that is becomes a waste of budget. The best case under the same lack of vision is that the project becomes a waste of potential. Strong DG methods are undeniably needed when defining and standardizing information within an MDM solution. Without an Enterprise-wide focus on DG, an MDM solution will eventually arrive at a solution that meets the myopic needs of its immediate source/target systems, but little else. When an MDM expansion opportunity arises, the original lack of global vision will result in either a reevaluation of the entire MDM solution or a limiting of the new audience to the initial design goals.

When considering a new or expanded MDM initiative, the first step should focus on your DG program. DG Stewards and Sponsors are the driving force for MDM justification and definition and are the true customer for MDM. Defined global controls should be finalized and introduced early into the process. Only then will you be in considered a citizen of Information Utopia.