Data, Governance and Data Governance

There have been some great discussion threads on the IAIDQ LinkedIn group recently. One thread that attracted a lot of attention started with a question from a PhD candidate in Data Quality. It simply asked whether there is an accepted definition of data quality. 200 replies later, most people would say, "No." More recently a thread began by bemoaning the fact that there is no accepted definition of Data Governance. A lively discussion followed that continues even now. Yet another refers to an article on five reasons to cleanse downstream instead of preventing upstream.

I am about to shed some light, however feeble, on the subject. Allow me to start by admitting that I am a person who likes to do the analysis necessary to solve a problem. Though my patience is improving with practice, those who know me will back me up when I say that I want to solve a problem ONCE.

Previous posts here have explained the abstract nature of data and all that implies in terms of getting people on board when it comes to doing something about quality. People will listen to or read a horror story about some preventable data issue that cost Company ABC $umpteen million. They will nod sagely and say something like, "They should have seen that coming." They are simply unable to see that their own company is engaged in the exact same practices and completely at risk for the $umpteen million.

Friends, it isn't just our favorite whipping boys, Management. There is no more recognition within IT than there is in the boardroom. Our boxes and wires friends think of data in terms of DASD and Raid configurations or bandwidth and throughput. Our developer pals don't really think of data at all except as the fuel that activates their code. Architects appear to be concerned with the storage and throughput views overlaid with an access management filter. They seem more concerned with making developers and DBAs happy than with the quality of the asset.

Enter Data Governance, which in most instances wants to be about definitions, rules and "enforcement." Often Data Governance tries to heap another thick layer, called meta data, on top of all the data that is already being mismanaged in the organization. It's often the case that Data Governance fails to practice what they preach.

Here's the revelation: Data Governance isn't about data. Data Governance is about process. It is the means to the Data Quality end. I have already said that Data Governance is that part of corporate governance that is dedicated to stewarding the corporation's data asset. It is exactly analogous to the role of Finance/Accounting with respect to the capital asset. Unfortunately, Finance has two things going for it that Data Governance doesn't have: GAAP and audits.

Generally Accepted Accounting Practice is a set of guidelines for money management processes that are accepted as the name implies and USED nationally and internationally. The use of these practices insures that processes will be auditable. The audit process verifies that GAAP was used and if there were exceptions, that they were clearly noted with enough information to allow the results to be brought back into alignment with GAAP. The underlying theme is that if the processes were sound then the result is believable.

Imagine if every company of any size whatsoever were able to devise and use its own bookkeeping structure and process. There could never be a stock market. Equity trading would be too risky for anyone and all business would essentially be sole proprietorships. Moreover, there would be no chance of oversight by outside bodies (Government).

This is a picture of the situation with respect to data today. When will it get better? Data Governance has no power to make the situation better. Without an externally defined data management framework and periodic audits by independent auditors, there will be no improvement. In the meantime, if data quality metrics improve, it's only because some particularly strong and charismatic personality is present.

No one questions the need for accounting nor the rigor of accounting procedures. Actually the same can be said for data governance and data management procedures. The difference being that in the case of money, the lack of question results in compliance while in the case of data it results in apathy or confusion.

Does the data world have something like GAAP that could become the necessary process infrastructure to support data management audits? I don't see it. Data is still too personal, too subjective, too misunderstood to attract the attention of researchers. Data management is a black box to virtually everyone and they like it that way.

People prefer to cleanse downstream data because their customers fell their pain being relieved. Happy customers is the goal after all. The bonus is that cleansing provides an unending source of employment for those doing the cleansing. It's win-win! People aren't going to be highly motivated to change a win-win scenario any time soon.

Whose Job Is It, Anyway?

There are several reasons why you are reading this blog post. Leaving out all the self-aggrandizing ones, let's focus on those who actually have the title question in their minds. You may have been drawn here by an interest in BI (business intelligence), the latest name for "reporting." It is likely that you have had some bad experiences involving reports or dashboards, or mash-ups or some other information display/access effort.

You spent what seemed like way too much time getting to an understanding of

• how this this was to be used
• the kind(s) of content that would be useful/acceptable
• how the information should be arranged/displayed

If you are part of a really accomplished organization, you may also have had seemingly endless discussions concerning

• How "bad" data would be recognized
• How "bad" data would be handled
• Remediation or cleansing processes to reduce the incidence of "bad" data

And, finally, if your organization is in the six-sigma population

• What is "bad" or poor quality data?
• Where does it come from?
• What does it cost?
• Where should we devote our efforts?
• What kinds of efforts offer the greatest ROI?

If you follow the various discussion forums concerning data quality, you will find one question popping up with regularity: "Who is responsible for Data Quality?" I asked myself why the question is asked. What prompts the question? It seems not to matter whether the organization has a reputation for quality, nor whether it has a history with data quality, nor whether the questioner is experienced or inexperienced, executive, manager, or front-line production. Why?

Having talked with some of these folks and researched the situations of several others and then simply meditated on this over an extended period of time, I have come up with a few likely scenarios.

1. The questioner knows the answer but either wants validation or a sufficient number of the "right" answer from people who are likely to be respected.
2. The questioner has encountered roadblocks from unexpected directions and is dealing with surprise and disappointment.
3. The questioner is curious about what others are doing.

What I have NOT seen is any evidence that the questioner is sincerely trying to determine how best to attack the problem of poor data quality. It would be easy to assume from these same discussion forums and conversations, that nearly everyone knows what they're doing and has either solved the problem or is well on their way to a solution. When we learn enough about human nature we understand that these people are all feeding their egos (or rather that their egos are feeding themselves since much of this is unconscious) and that they are taking an incidence of limited or small-scale success and projecting it into an eventual enterprise level solution. I have done this myself.

I know this--that data quality, or any other variety of quality for that matter, will not bend to advanced degrees, nor to mastery of data and information design concepts, nor to any product or set of products, nor to any effort by marketers, nor even to the best-designed procedures, methods, governance structures, architectures...

The ONLY way to data quality lies through the hearts and minds of each and every person in your organization. Each of them has the power to subvert any plan, procedure or method; to render ineffective any tool or product; and to humble the greatest of egos.

The bottom line is that it must be everyone's job but of course that isn't a satisfying answer because the very short list of things that everyone believes are important includes things like breathing, eating, elimination of wastes, procreation, maybe community, relationship, acknowledgement... This list of universally agreed-upon important things will never spontaneously include data quality. In fact, if a poll were conducted in the boardroom, it is unlikely that data quality would appear on the list of things important to the company.

Don't misunderstand--the quality, security and accessibility of your data assets is at least as important to the continued health and well-being of your company as that of your capital assets. The problem lies in the fact that data isn't real and tangible. If bad data smelled bad or rusted or developed crumbling holes, or if it resigned and went elsewhere where it was more appreciated or was subjected to audits by outside entities, or showed up on a P&L or balance sheet where it was reviewed by prospective data contributors--THEN it might get some attention.

It is true that anyone can produce an example of data but virtually no one--even those responsible for collecting and storing its instances--will understand that data is something other than what they are holding or pointing to or storing. But I digress.

If we can't accept the answer that data quality is everyone's job then we need to move on to identify the person or corporate function who will be accountable for the quality of the company's data. It's not possible here to put a name to this accountable party. What we can do, though is itemize some of the skills and abilities required to help point the way to your unique name.

First and most important, let's agree that what we are talking about here is cultural change and cultural change, more than any other kind of change, requires leadership. Already we see that a corporate function can never be accountable although you can tape a job title on the person's door when you identify him/her. This leader will be able to move freely across the company and will be able to give everyone the feeling that they have been heard. This DQL (data quality leader) will be conversant with principles and practices of quality improvement. The DQL must be completely comfortable with the nature of data and will not be confused by the display of samples. Attributes of the data asset as a whole will be the focus of all of the DQL's efforts. S/he may well choose to shine the spotlight on a segment of the population and may delegate someone more familiar with that segment to assume the leadership of this effort. That surrogate DQL will also deal only with population attributes (metrics).

The DQL will never fall into the trap of confusing examples with anything else. An example may be representative or it may be an anomaly. Only the population metrics allow us to tell the difference.

Further attempts at guiding your choice may be counter-productive if you begin to feel manipulated or otherwise used.

A final caution concerns those characteristics that will render a person unsuitable. Just as you might wonder about a carpenter who feels compelled to talk interminably about his hammer or his saw, the person who leads with the name of a tool, tool vendor, methodology, author, book, etc., is unlikely to be the one you're looking for. The last thing that the leader/agent of cultural change needs is to divert any attention away from the primary focus. Products and tools may be useful for producing the population metrics discussed above, but beyond that should be well in the background and completely invisible to the majority of those you are attempting to influence.

Those who confuse files or [mega/tera]bytes with data are likewise unsuitable as are those who confuse a spreadsheet, chart or report with data.

I hope I haven't made it seem like an impossibility. Talk with people about this and over time you'll begin to get a feel for what to look for and what to avoid.

Leadership, Management, Governance

Leadership for change

Management for effectiveness

Governance for stability

It is way too easy to become confused where these three functions are concerned. We like to think of ourselves as leaders when what actually consumes our time and attention is hitting deadlines and deliverables. Leaders emerge when change is in the air.

When the marketplace is shifting; when the economy is deteriorating and taking our profitability down with it; when we're no longer able to keep up--that's when leadership is required and leaders step forward. Anyone can steer a straight course through calm seas with good charts. It takes a master to sense the environmental factors, inspire confidence among the crew and make the continuous changes required to keep the ship from breaking up or running aground until things settle down and we get back into familiar waters. We risk disaster when leadership isn't acknowledged and permitted to assume control. When the crisis is over, we often find that the leader has little or no interest in the day-to-day operations of work rosters, schedules, performance reviews... The leader may make a very poor manager.

The manager is the master of routine. She is the one who keeps the machinery humming and the product going out the door. He makes sure that time boxes are hit, that deliverables are delivered and that budgets are created and followed. When the winds of change begin to blow, the manager who fails to recognize the need for leadership or believes in error that he can handle the leadership role can cause massive and sometimes irrecoverable damage before she agrees to [temporarily] relinquish the helm. Exceptional management defines the team, builds the team and keeps the team vision alive. This management is essential.

Governance is ubiquitous and invisible. Governance is observing, analyzing, formalizing, monitoring, measuring, improving. Governance establishes the standards to which managers hold themselves, each other and their teams accountable. It should be readily apparent that governance is every bit as necessary within a high-performance organization as is management. An exceptional governance function is a combination of historian, engineer and seer. A liberal dose of management is required to insure that governance doesn't degenerate into approval by the de facto expert.

The six sigma governance function will have incorporated leadership into the system of standards. A set of standards and standard processes may be of little use to the leader in the midst of the storm but may have helped to prepare that leader to be able to step forward.

Leadership for change, management for effectiveness, governance for stability is the tag line of WhiteLake Data Management. Data Management will be a microcosm of the enterprise as a whole. Every point of view (perspective) within the enterprise will be represented in Data Management. Virtually every process within the enterprise will be examined by Data Management in an attempt to "get it right." The risk associated with unreliable information (data) can only be assessed in light of the process(es)--and the personalities-- involved. Data Management is not governance but must include governance as an essential component. As its name implies, management is its bread and butter. Because it is frequently considered the homely step child, however, the availability of leadership may well be the key to its success.

Data Governance Is...

Recently someone on a LinkedIn discussion forum asked for a definition of data governance because he had yet to find one that was universally accepted. Now he has about 30 definitions and all of them are "personal" in the sense that they apparently work for the person who responded and/or that person's company.

In fact the lessons of the past 10 years or so produce the conviction that data governance is anything, everything and nothing.

It is anything we need it to be that serves our immediate purpose.

It is everything in that it spans all corporate functions in order to produce the needed results.

It is nothing because we always have to define the term whenever it is used and no two definitions are the same.

My own input to the discussion was that

Data governance is that part of corporate governance that is concerned with insuring the integrity of the corporate information resource.

The only useful application for this definition is in establishing a context for any initiatives and establishing responsibility or accountability. This definition cannot be used as a strategy or a vision to drive results. It doesn't suggest any metrics. It doesn't help us to isolate key processes nor does it suggest any standards.

Other definitions you may have seen involve "decision rights". The problem with "decision rights" is that there are always individuals who will pop up once one of these rightful decisions is made and insist that the decision in this particular case was rightfully theirs. Quite often this individual will make a good case and the "rightful" decsion will be overturned--often at considerable cost. When this happens, it calls into question the makeup of the existing decision-making bodies and can cast a long shadow over the entire concept.

My definition contains a problem in that it invokes another poorly defined concept--that of corporate governance. As I have discussed in previous posts, corporate governance in any form that would support the needs of those desperate for data governance is as rare as a polar bear in west Texas. It is the most challenging, most demanding and most thankless job imaginable to create a system of governance in the midst of a feudal culture.

This is not to say that results--even valuable and far-reaching results--can't be obtained. Such results are possible for those who are dedicated, courageous, knowledgeable and visionary. If one can keep the vision of data governance as part of a corporate culture and pursue integrity for all information but do it one relationship, one entity--even one attribute--at a time, then real progress can be made.

I have often wondered why we think we need a definition for data governance when it is so obviously subjective. Of course data integrity and data quality and even data itself are equally subjective. None can be discussed without first offering a definition ("What do you mean by that?") and we don't have definitions that we can quote that are meaningful to "this" audience. In fact, we are given to definitions that are nearly meaningless even to our colleagues and serve only to get us all in the same ballpark.

It is possible to take any result and call it data governance (who could argue?). It is possible to take any corporate initiative and use it to promote data governance. Why don't we simply get busy and spend our time discussing results instead of definitions? Show me the data that demonstrates you have brought processes into control for some subset of your company. Let's talk about which processes are most critical and which represent the greatest opportunity. Let's get moving.

Principle Before Practice

Before I begin, a caution. Do NOT think that I am taking a negative position re: data governance. On the contrary, I firmly believe that the concept is essential. But what is the concept?

As I watch data governance related position descriptions parade by on DICE.com, MONSTER.com, etc., I am struck by the focus on the practice of data governance. They are all about tools and skills and methods and all either assume that everyone knows what the goals are or (worse yet) that goals for this company are the same as those for every other company.

I have learned at least one thing in my 27 year adventure in all things data-related and that is that doing something, no matter how efficiently or effectively, is very often a wasted effort without some forethought about the principles that we are attempting to implement.

Principles provide the glue that links all of our efforts together and the medium that allows us to be productive even when our last effort was a failure.

As with so many initiatives around data, this wave (governance) has crested and achieved the status of "best practice" without ever achieving measurable ROI. We have seen smaller-scale successes--enough to keep hopes high--but not, to date, the enterprise wide success that was used to sell the initiative in the first place.

But maybe I'm getting ahead of myself. What is the principle that data governance represents? Some candidates are:

• Make life easier for DBA's by reducing the rate of database schema changes
• Make life easier for developers (programmers) by making requirements less ambiguous
• Reduce cost due to rework by making the rules for data quality and completeness more accessible at the point of capture
• Make the data warehouse more useful by applying the same rules to data everywhere it is captured.
• Reduce the number of sales lost because we can't keep track of our customers
• Establish process consistency so that we can begin improvement efforts
• Stop those sobs from delivering junk and expecting me to fix it
• Define and establish (standard) processes to reduce variability in output quality
• your favorite here

Which one(s) do you like? I believe the answer is all of the above and then some. What is the principle that unifies all of these goals? I discussed this in a broader context in a prior post. My point though is that if we don't have a firm and commonly held idea of the principle(s) we are attempting to implement, then no matter what we do, which tools we use, or how skilled the workers are, we aren't going to accomplish anything meaningful. To put it another way, "If you don't know where you're going, any route will do."

What Do You Do When Things Aren't Working The Way You'd Hoped?

Let's pick a context first because a) this problem is pervasive in the world I live in (how about you?) and b) the context will determine our course of action. I'll use my own life as an example.

I have spent my life seeking to understand my environment so that I could have a chance of staying out of hot water by being able to predict outcomes. I actually got pretty good at the predicting part but was never able to translate that into the staying out of hot water part. It turns out that when you see a result coming that is unwelcome to everyone, hot water is the least of your worries.

Of course I could have kept quiet and just let things happen but the problem with that is that almost invariably a minor course change would have prevented the outcome. It always seemed reasonable to attempt that minor change. Just as invariably there were political implications involved in any changes to the published plan. Bottom line: my career is littered with "you were right's" that came three years after I moved on.

So. if you would learn anything from my example, maybe it would be that "being right" carries no value. Maybe it's that you should just keep your head down and wait for the seniority promotion of for retirement. Maybe the lesson is that you do what you can and the rest belongs to someone else.

I will say that over time I have achieved objectives that others considered "impossible" because I was willing to take risks. The problem there of course if that if the objective was considered unachievable then no one is prepared when the find themselves standing inside the walls.

I think that this is also the story of data management (to include what has come to be known as data governance). Organizations have been talking about data management for nearly thirty years now and there are hundreds if not thousand of experts who will tell you exactly what you should to enjoy the benefits of good data management practice. What none of them will tell you because a) you don't want to hear it and b) you wouldn't hire them is that there is no proven methodology--no set of practices and tools, skills and technology--that will guarantee results.

Why should this be? You would think that in 30 years someone would have stumbled across something that will deliver predictable results. The answer lies in the subject matter. "Data" is a concept understood by everyone. Everyone in the boardroom has their favorite data. The issue at the root of all problems is that "everyone" is seeing data "as through a glass, darkly."

The inability to communicate about data and reach a consensus is what is keeping us from our objective. To this add the cult of personality that defines the management--let's call it governance--of the corporation. The decision makers understand nothing of the underwater portion of the data iceberg, seeing only the table, graph or dashboard that's in front of them. What must be managed is the abstraction that is data and not the values that are only the visible portion. When we try to do anything with the abstract, we find that there are side effects on the visible portion that cause VIP personalities to convulsively respond in exactly the least useful way.

You can get useful results if your objective is modest. For example, it is possible to get two business functions who are exchanging data or three or more that have a symbiotic relationship based on data to take consensus action to stop what is often a great deal of daily pain. The intractability is encountered when we attempt to broaden the scope to cross departmental or divisional boundaries. The goals and methods of data management are counterintuitive to those raised in the power politics of corporate "success."

We usually find ourselves managing data as a commodity, "how much", "how many", "what is the cost", "who produces", "who consumes", "spoilage rate", "how fast"... While these all have an attraction in that the answers can be easily captured in one of those tables, graphs, dashboards, none deal with the underlying problem of managing the abstraction. Data is the most complex thing that a corporation attempts to manage. It is more complext even than money.

The pity is that we treat data as if putting it into a "piggy bank" solves all our problems. You heard it here first:

• Technology is no answer--technology can help us sort different kinds of values into different piggy banks, no more.
• Technical skills (modeling, DBA, quality...) are no answer. The cashier makes use of such skills to keep his/her drawer in order and reconciled.
• People skills by themselves can't achieve any result except perhaps building meaningless consensus.

This is enough clues. If you call, don't bother to tell me what DBMS or CRP system or BI tools you're using. None of those things are of interest until the final stages of a solution. I don't expect any calls because too much credibility is wrapped up in the current initiative--whatever it is. When it fails to produce results, a new personality will step in and you'll start the cycle anew. Someone, someday may actually be willing to take a risk to stop the pain. I'll be retired or deceased by that time but maybe you'll have learned from this what you should be searching for.

Data Quality: Getting Started

If you happen to be a "mover and shaker" or if you aspire to that role, then you'll be looking for access to one or more key decision makers of influencers closest to the top of your organization. You'll be determined to convince those people that

1. investing in data quality is a sound business decision
2. you are the right person to produce the ROI that they'll be looking for

If, however, you simply want to make things better as soon as possible and create new friends and allies while doing so, then you may want to take a different approach.

My recommendation is to use the tactics of the Special Forces. The "Green Berets" were formed into small teams comprising skills critical to the people they were trying to help. They then went out to those people and lived with them. Doing this allowed them to gain credibility and to learn what kinds of changes might (or might not) be acceptable.

The Green Berets helped the people with their work and, while doing so, offered improvements--small changes that produced higher productivity or more consistent results. The goal was to create allies.

"Data Quality" represents exactly the same kind of productivity and/or consistency improvement for our "indigenous" people in whatever part of the company they may serve. A DQ Team may be as small as one member and can produce results that are shocking in their scope and value as well as in their lack of cost. It isn't necessary to spend long periods of time "living" with the people. In fact, one lunch or a couple of coffee breaks will do IF you

1. ask the right questions
2. listen carefully to the responses
3. offer support
4. follow through

You'll ask about what happens when they get incomplete or incorrect forms (data is usually thought of collectively as a form) from their internal "customer". You'll ask about the extra work they have to do in such situations. Be prepared for an emotional response, this is what causes them to miss deadlines, work overtime, add staff... Also be prepared to hear that they simply pass the problems on because they aren't staffed to deal with them and don't feel accountable for fixing problems they didn't create.

Listening will uncover the sources of the most frequent or egregious DQ errors. Now you can mention that you are about to begin a project with those dirty so-and-so's, that it's likely they don't even know the hardships they're creating, and that you'll be happy to mediate a discussion amongst the parties to try to find a resolution. You may already have some ideas.

Create the meeting, making sure that ALL parties are represented (you were listening carefully, right?) and facillitate the discussion, if necessary gently guiding the discussion but never offering solutions. When the solution is "discovered", the people will own it and will implement it with minimal assistance from you. If your assistance is required, make certain that you deliver and do not hold them up.

Follow up by monitoring, coaching, facillitating and then ask if they'd like some help in publicizing their success. Because you know important people, they'll almostly certainly jump at this opportunity. You give them all the credit and they'll make sure to let everyone know that your help was both timely and critical.

This approach works and can even result in regular meetings to follow the improvement and to look for new opprtunities.

Two approaches--you choose which one has the highest probability of success for the greatest number of people in the shortest time at the lowest cost.