Blog post

Data Quality does not Equal Data Governance

By Andrew White | January 27, 2010 | 7 Comments

MDMGovernanceData Quality

I was on a briefing the other day with a small software vendor talking about governance.  We were exploring and contrasting experiences with how users look at “governance”.  A couple of my favorite angles included:

  • Business users tend, if you are luck, to accept that they “own” process, but few accept that they do, or should, own data.  Conclusion – get over it, and start talking of “stewardship” instead
  • When someone talks of “governance”, without any context, its tantamount to talking about fools gold.  Conclusion – governance, out of context, is dangerous; add context in order to make it meaningful
  • “Governance of data/information” needs to start, or be applied first, with a focus on data/information that is meaningful to the business: Conclusion – start a governance focus on “enterprise information” (that is, stuff that’s important like master data or reference data).

One question that came up from the vendor was this: does a focus on data quality (DQ) confuse, or complicate, a message related to data governance (DG)?  It turns out that the vendor perceives a risk that users will think that a message/offering oriented around “data quality” might get confused (i.e. might compete) with something oriented around “data governance”. 

Clearly there is a potential for this.  Even in our research, “data quality” at an holistic level, implies a broad view of the quality, integrity, and consistency of data and/or process etc.  So at one level, there is overlap.  However, the reality is that most users do NOT take that holistic view; they equate “DQ” with a technology that is applied to a problem at a point in time.  Few use the term DQ to equate to a living, breading process that manages, or ‘governs’, the process or data. 

Bottom line – DQ and DG are different, but related.  The vendor does run a minor risk (in my view) but I think it’s a slight one.  For sure, there are lots of “DQ” messages and offerings on the market today; and there will be a lot more related to DG soon.  I’d go with a focus on DG and message how DQ technology supports DG.

Comments are closed


  • David Loshin says:

    Clearly, “data governance” has become a hot term, yet in most contexts we have seen, when they (vendors, consultants, and customers!) say “data governance” they really mean “data quality management.” In fact, the message gets even more confused in two different ways:

    1) The use of the term “governance” is intended to convey a business context with business stakeholders involved in overseeing the management of the enterprise data asset. However, the organizational structures associated with data governance only start out with business participation, and frequently devolve into monthly arguments about the real meaning of “customer.”

    2) Alternatively, the need to drive data governance through business impact assessments and cost benefit analyses detracts from the intent of governance as applied in other contexts (such as financial governance or asset management). Let’s talk about an elephant in the room: if there are data elements and data sets that exist and are managed within the organization, the asusmption should be that those data assets are meaningful to the business – otherwise, why would money be invested in managing it?

    Our experience with customers is that the desire for data governance is really a request for assistance in generally instituing good data management practices, and baking those practices into the business application development life cycle, in a way that is similar to software software safeguards.

    To some degree, the drive for MDM and data governance both expose an real desire for more trustworthy data. I expect that over the next few years, the general messaging will cycle back to focusing on data quality management best practices and how the vendors tools support those practices.

  • This raises an interesting question and provides some useful pointers. In my opinion, DQ and DG should work together, but they can tend to be looking at different parts of the problem, unless the scope is well defined.

    There is a risk that DQ activities on their own are just addressing the symptoms of the problem, i.e. “We have x% invalid data”, “Data profiling has found y suspicious values”, “We have matched z% of the entries in these two data sets”. Approaches like these risk confusing activity with effectiveness for they can be addressing the symptoms of the problem with resolving the root cause.

    DG should be more focused on the big picture of organisational context, process management, strategic direction etc. This should ensure that the root causes of problems are identified and resolved, as well as correcting the effects of these problems, which is where DQ can come in.

    The skills required for each activity can tend to result in different people being required for each area. For example, DQ teams can tend to be more technically focused (geeks?), whereas DG teams can tend to be more management focused. This is clearly a generalisation as some people can happily operate in both arenas, but may also help illustrate the differences and similarities.

    Other organisations use the term Process Governance, however, this may not be an issue if the scope and activity of the Governance group is clearly defined and understood. So whether it is DG, PG or something else, the approach can still be correct if the scope is clearly defined. Which also addresses another of the points in your post.

  • A subject close to my heart. As stated / implied above, DQ and DG can be viewed from an IT or Business perspective. ‘Detect and Correct’ Data Quality might be a good approach to resolving misalignment of data between a source system and a repository. Data Security and Authorized Access are critical parts of DG. The problem is, if a DQ or DG program tries to tackle the full breath of either subject it leads to a complex long running program that takes a long time to deliver return on investment; most critically, the delay in achieving real business value from the program can stop it in its tracks.

    We have a responsibility to outline the different aspects of DQ or DG from the outset. Set the scope for specific achievable steps or stages in the program in mind within the context of the whole program and deliver some demonstrable value and benefit early. Learn from the experience, communicate success and move on to the next, small step. If you are not clear about the scope and responsibilities of the project within the greater scheme of things, you risk having to fend off shots from other parts of the organization (e.g. security, compliance or audit) for the duration of your project, if they don’t scupper you at the outset.

    Paul Woodlock

  • Ken O'Connor says:

    Thanks for starting this discussion.

    I agree – Data Quality does not equal Data Governance.

    In my experience, Data Governance covers a multitude, including Data Protection, Data Security, and of course Data Quality.

    I have worked on many data intensive regulatory compliance programmes. Time and again, the same data governance issues occur – including issues related to Data Quality.

    I provide a process on my blog for assessing the status of common Enterprise-Wide Data Governance issues within your enterprise, or that of a client.


  • Andrew White says:


    Good points – thanks for responding. I wonder if it might be a reasonable statement to suggest that “MDM is as much a (master) data governance discipline” as much as anything else. I certainly get confused when I read and see DQ and DG mentioned in the same way; I do believe it makes more sense to explain the different, and then how they intersect. MDM seems just a more recent excuse to re-engage in this ongoing dialog.

  • Andrew White says:

    Hi Ken,

    I looked at your page that provides a framework for gauging the evolving status of (data) governance in an enterprise. The model looks pretty good in fact. I looks not unlike our own Maturity Model for (data) governance that is part of our overall Building Blocks model for MDM (a program managers bible). Some of these things seem pretty consistent, wherever you look.

    Shame it continues to be a challenge for organizations. We have all spent millions on “data quality efforts” yet how many organizations have real, effective, living governance organizations? Not as many as we would want…

  • Data governance is different than data quality in that it involves a major evolution for a company. Depending upon where the company is in the evolutionary process, they may use data quality or master data management technology or any of the other technologies to achieve improvements in the way the company manages and leverages data.
    Data governance often takes the shape of a series of coordinated data quality and master data management projects with a governing strategy driving it. In order to do coordinate those projects, however, you need a different way of thinking about data, a different management structure, different people in your meetings, etc. If the strategy is confined to a single business unit or project, it’s probably not data governance.