The Relationship Between MDM and Data Governance
Posted by 
Share this Post
MDM and data governance are intertwined yet distinct, much like Escher's reptiles
Just today, I saw some very interesting tweets on the relationship between Data Governance and Master Data Management. @GarnieBolling started it by asking, “Is there going to be a blur between MDM & data governance? Seems that way, but is that a good thing or should we keep them separate?” and “If mdm is not data governance but part of DG has MDM, then what is your definition of DG? I'm curious to see what you say.”
Of course, Jim Harris (@ocdqblog) felt he had to give it his unique humorous touch by adding, “Maybe MDM is MDG (Master Data Governance) - not to be confused with MGD (Miller Genuine Draft).”
Let’s start by defining what I mean by data governance. Data governance is the ongoing process of defining data management principles and making declarations of policy, process/procedure and business rules that, when implemented, will make measurable improvements in data quality.
DG also involved defining those metrics that are used to measure data quality improvements. The discussion of "how" you do this and "who" does the work is too much to tackle in this post, so we’ll tackle it in a future one.
Data governance is >80% "administrative" (writing policies, dealing with organizational & political dynamics, achieving shared vision) and <20% technical (implementing technologies that implement/enforce policies).
For a full review, check out our Intro to Data Governance page, which includes links to webinars, podcasts, white papers and more.
Now, let me define what I mean by Master Data Management. MDM is the orchestration of people (roles & responsibilities), processes (automated and manual), policies and technologies to gain control of the quality of master data within an ecosystem.
The definition of "master data" is also beyond what I can address in this post, but again, another good future topic. MDM is the opposite: >80% technology implementation, project management, testing, tuning etc. and <20% "administrative." This alone suggests that these are different beasts, but is not enough to clarify the question about their relationship one to another.
(Again, our Intro to MDM page has a wide variety of resources.)
So how are DG and MDM related? Let me examine it from two angles: from the perspective of DG and from the perspective of MDM.
Data governance could potentially define policies for every piece of data within an ecosystem, but since this scope is so large and unattainable, it is prudent to help DG initiatives focus on writing policies for those data that "matter most" to achieving enterprise objectives.
Again, this scoping and focus is outside the scope of this blog (yes, I know... another future blog topic). But DG can and should focus on writing policies for the most opportunistic, most impactful, "biggest bang for the buck" projects.
Those may be data integration projects, new "data acquisition" projects (new applications that capture data from users, customers, outside sources etc.), BI projects, data quality implementation projects, and others. So, not all the projects being influenced by a DG initiative will be MDM projects.
But, because MDM projects solve for DQ problems for the most critical kinds of data within an ecosystem, they absolutely depend upon the declarations written by a DG Council (or Board or whatever an organization wants to call the function).
Now, from an MDM perspective, when an MDM project team implements rules and algorithms for resolving duplication in sets of master data, it is implementing policies that should have been authored by a DG initiative. Since one of the characteristics of master data is that they are highly shared, then these policies require the purview of a DG Council to establish policies that work across organizational and political boundaries.
When an MDM project implements authentication and authorization rules, it is implementing policies that should come from a DG initiative. These should not come from the project team; these should be implementations of the declarations made by a DG Council, representing the needs of data owners and directing the efforts of Data Stewards.
MDM cannot be successful if there are no guiding principles from a DG Council. But that does not mean MDM is an instance of, or an implementation of, DG.
Let me try an analogy that I've used in discussing enterprise architecture. A city council is responsible for governing a city - writing policies, passing resolutions and generally making declarations of "how things must be done" in that city. The permits that are filed and buildings that are built are subject to those resolutions, regulations and policies.
But the buildings are not instances of the City Council, nor are they "owned" by the City Council. They are "regulated" by the council's ordinances, and in some cases the council may direct funds to help pay for parts of the building project or a related project that may impinge upon the building, but they are not the building project. This is the same for Data Governance Councils and MDM projects.
Ok, so I've created more work for myself here - suggesting the need for three other blog posts, and perhaps stirring up some conversation that'll need some clarification on my part... so have at it, commenters!
8 Responses »
Trackbacks
Leave a Response
Entries(RSS)
Great post Marty,
The relationship between MDM and Data Governance is one of the most common questions that I receive from clients.
My Twitter joke about how maybe MDM is Master Data Governance had some seriousness to it (like all good jokes in my opinion
).
Data governance, among its many other aspects, focuses on policies and strategic alignment for people throughout the organization in relation to data access, data sharing, and effective usage in support of critical business decisions, and optimal business performance.
The concept of “master policy management” within MDM has very similar characteristics, which I agree with you should be under the purview of data governance--as long as such a function has been established within the organization. However, sometimes this aspect of MDM spawns the first real incarnation of data governance. However, MDM is not equivalent to data governance, for many reasons, but most importantly, because data governance includes more than just “master data governance” -- data governance provides oversight for ALL data management activities, not only those related to master data.
Some clients (especially very large organizations) describe both MDM and Data Governance as separate initiatives being run by different project teams, which leads to the common “chicken and the egg” question of which one came first or which one is the subset of the other.
I agree that MDM (with the possible exception of some implementations of Analytical MDM, which not to start another debate, could be argued to not be “real” MDM) cannot be successful without Data Governance, but that does not mean MDM is either an instance or an implementation of Data Governance.
I believe it is because of the critical role that Data Governance plays in the success of MDM, that they will forever be discussed in relation to each other.
However, because of the critical role that Data Governance plays in ALL enterprise information initiatives, perhaps we should instead be asking why MDM is the only one whose relationship with Data Governance is frequently discussed -- yes, that's right Data Warehousing and Business Intelligence -- Data Governance and I are looking right at you!
Best Regards,
Jim
Marty, well spoken. Around Easter I was thinking about the chicken and the egg too.
OK OK, I guess I should post "something" since I posted the Question
Marty, great insight, and I agree with you. Also Jim has a great point, MGD is Miller Genuine Draft, since it is Friday, time to get a few bottles
The City Council analogy is perfect. I really want to spend more time on this, so let me make it home, decompress, and think a little more before I "enrich" your great post. I appreciate you answered my question, seems this is going to be a major discussion for the next year or two, because there are "some" out there that are interchanging MDM with DG, and vise versa.
now where is my MGD ? or is that MDG ?
Dialog over the distinction between Data Governance and MDM willcertainly increase as new data governance solutions come to market. You make some great points, Marty. I largely agree with the high-level distinction. MDM is ultimately about putting in place people, process and tools to improve a certain class of shared data (i.e., master data) while data governance is about institutionalizing the process of more effectively managing data as a critical asset.
It’s less about the act of “fixing” and more about the act of “establishing processes and behavior” to improve the management of data. Using policies as an instrument to enable definition and enforcement (primarily through measurement) is the approach we see being adopted.
In addition, data governance is not only about improving data quality, but establishing policies for data usage. This leads us to two additional areas of policy governance; security & compliance and data lifecycle management (from authorship to destruction). Focusing on data quality can have the most immediate, beneficial impact on an organization’s top or bottom line and is rightly getting the majority of the focus…and budget.
An equally important aspect of effective data governance is to drive it more directly from the business impact of good (or bad) data. To do this effectively, data governance organizations need to relate the data to business processes that ultimately use the data. It is equally important to govern transactional data as master data (which reinforces what you say Jim)In-turn, this leads you full-circle back to the relationship to business performance metrics (the purview of data warehousing and business intelligence).
Data governance relates to many data management disciplines and deserves a focus all on its own. Companies have spent billions on “data fixing” and “data movement” and are clearly demanding a shift in focus to an overarching discipline which ties these initiatives together – driven directly from business value (and the processes that deliver it).
Darren - thanks for weighing in, and thanks for your excellent input! I agree with you completely!
One Q that plagues me, and let see if I can ask it succinctly: how to you work on the business processes that use the data being governed and not get into what I've seen as "boiling the BPM ocean?" In other words, how do we do "just enough" business process redesign to help us implement DG policies?
I have a gut feel "metric" that I use that relates the affinity of a business process to the data I'm working on, but processes affect other processes and you have to have the ability to draw a line and say "enough is enough - we're only going to rework these n processes?"
Thoughts anyone?
Based om previous experience I'm convinced that you need to regard the information in three different tiers. 1. information that's outside your control ie vat no, some adresses ..., 2 information needed across your business and 3 processpecific information. Masterdata for me is category 1 and 2 and should in an IT solution be stored and managed in a masterdata repository(MDR). The MDR should make the information availible to information subscribers in the business by use of integration engines. To regard all information as master will probabely not work out well. One example could be that a third party organization could be customer and provider to your business. The MDR also provide the unique identifer that should be used in all processes. Preferably just a sequence number without any embedded functionality
Hey Mats -
Thanks again for your great input - I agree that not all information is master data, which is why we need a good definition of what "master" data are vs "reference" data vs "transaction" data vs "audit" data.
Malcolm Chisholm had a good set of definitions for those, but I think we can take them a little farther still.
Your tiers is helpful regarding what might be "master" data vs data required on a transaction. One of the Qs I'll post is this: How many systems need to share data for it to be considered "master" data? I've gotten this over the years (since 2003 when I built my first MDM hub), but I'd be interested in other people's opinions as well.
watch for it - I'd love your input!
Cheers!