Data Governance Remains Immature: Increase Focus On Business Process To Build Momentum

I just read a great blog post by Marty Moseley discussing the results of a data governance survey he and his team recently fielded. The feedback he collected matches recent data-governance-related surveys and interviews I've done with my clients at Forrester - the general consensus being that most data governance programs - if they exist at all - remain extremely immature and fraught with risks. The most common roadblocks range from minimal to no executive sponsorship (as Marty also noted), IT-driven efforts with limited to no business participation, lack of business justification and the ever-present likelihood of "de-prioritization" when a more compelling initiative or fire drill comes along.

But there is a silver lining here. As I shared with the survey results in my Oct 2009 research, "Trends 2009: Master Data Management", while only 4% of my 113 survey respondents felt they had a very high level of data governance maturity (represented by a cross-enterprise, cross-functional data governance organization spanning both business and IT roles with top-down executive sponsorship and measurable value-add), the vast majority of these organizations also recognized "trusted data technologies" like data quality and MDM as critical paths to their organization's success. Most organizations admit there remain a number of inhibitors (mostly political, prioritization and ROI calculation-related) that make it difficult to support large investments in these technologies. But most also believe that data governance is the right approach to bridging this driver/inhibitor gap and are investing more time and resources to figure out how to operate data governance processes within their own organizational context and culture.

In my interactions with Forrester clients, I get the sense that data governance is receiving the most senior-management-level attention today than I've seen throughout my 18+ year data management career. One of the biggest turning points has been the growing recognition that data governance is not – and should never have been – about the data. High-quality and trustworthy data sitting in some repository somewhere does not in fact increase revenue, reduce risk, improve operational efficiencies or strategically differentiate any organization from its competitors. It’s only when this trusted data can be delivered and consumed within the most critical business processes and decisions that run your business that these business outcomes can become reality.  So what is data governance all about? It’s all about business process, of course.

 My Forrester colleague Clay Richardson (who covers Business Process Management technologies and best practices) and I have been collaborating on a concept we call Process Data Management, which recognizes that effective data management requires a focus on business processes – and vice versa. We kicked off our discussion on this topic in our research “Warning: Don’t Assume Your Business Processes Use Master Data” and will be publishing another piece later this quarter called “Align Process And Data Governance To Deliver Effective Process Data Management” which will focus on the need for data and process governance efforts to be more aligned to deliver real business value from either. Later this year I’ll also be publishing an update to my annual MDM trends piece, “Trends 2010: Master Data Management,” which will include new survey results reviewing data governance and MDM maturity.

 I'm optimistic that we might finally see some real momentum building for data governance to be embraced as a legitimate competency within many large organizations – especially with a focus on business processes to help evangelize and secure business sponsorship. It will likely be a number of years before best practices outnumber worst practices, but any momentum in data governance adoption is good momentum!


Data Governance and Business Process

Great post, Rob. I couldn't agree more.

- Data governance is the missing link between data and business process. It's finally a concrete, value-driven way to bring the two disciplines together under one roof.
- The business case of data governance starts with a business process that can be improved with better data.
- Data governance should be formalized as a business process in its own right.
- There're 3 ways to narrow the scope of a data governance initiative: data, process, and system. Process is the better way to go.

Look forward to your research in this area, including process data governance.


My blogs are:

Great Blog Post!

Hey Rob -

Thanks for the mention and for such a great blog post. I appreciate what you bring to the public discourse.

I'd like to respond to Winston's comment that data governance is the missing link between data and business process. I think that's a good generalization, but the thing that I fear in making such a broad connection is that it's like solving world peace. within a given enterprise there are tens of thousands of business processes - most of which exist within a self-contained application or business system. And there are tens of thousands of data elements, many of which are not shared and are private to a given system.
So perhaps I can attempt to put a finer point on it? I'd say that instead of DG being the link between data and biz process, instead the real link is some kind of specification that declares what that relationship is. It might be a schema, it might be a set of rules, constraints etc. but DG is not required to produce all those. I'd say that instead DG is responsible for publishing declarations of levels of quality that must be achieved by the processes that CRUD the data. But *how* that's implemented may be private to any given business process, and I don't think DG cares how their policies and procedures are implemented in every single case, but in only those where the data are highly shared.

so, the link between data and process is managed by UML or other analysis/design construct. Policies influence these specifications, and DG produces only those critical few policies etc. (I call 'em "declarations") that matter most to achieving business goals.

Does this make sense?


Thanks Winston and Marty for

Thanks Winston and Marty for your great additions to the conversation!

I agree with your points Marty (and guessing that Winston would agree too) that data governance efforts should only focus and prioritize the "critical few" business processes and data elements that represent the largest impact to the organization - and will never attempt to take responsibility/acccountability for the vast majority of processes and elements that are not cross-enterprise dependent, shared, and most impactful to the business.

The biggest challenge for many is figuring out the most effective way to scope and prioritize those critical few processes. In my research I've provided a short list of questions data and process professionals must ask to most effective scope. It's not nirvana, but it's a start:
1. What business processes are most important to the organization?
2. What information is used to support those processes?
3. What people, systems, and processes create, capture, and update that information?
4. What is your level of confidence when using that information?

Thanks again!


Good starting list. Here's what I usually advocate starting with:

as a corporate executive/biz leader, what are the top 5-10 things that keep you up at night?

Or a variant:

what's most broken in your enterprise? Where are the risks, issues, friction and inefficiencies that keep you from achieving your corporate goals?
...along with the corollary...
what are the top 3-5 things you can't do today that would make a big difference in you exceeding your corporate goals?

that usually give me an answer to your first question that's not as "nerdish" and immediately gets them emotionally involved.

Is this being manipulative? Do you respect me any less???

M :o)

Well hey Marty, there's a

Well hey Marty, there's a fine line between "manipulative" and "influential" isn't there? And if data governance isn't the poster child for a program sorely in need of serious influencing skills, I don't know what is!

Completely agree from a feet on the street perspective, business leaders need to be approached by data evangelists using "plain English" to solicit their short list of critical priorities. Anything that you can do to first simplify, then to simplify, and then finally to simplify will only help your cause in the end.

Rob, Marty, I agree. For DG,

Rob, Marty, I agree. For DG, you have to start with the core business processes where a lot of revenue comes in or a lot of cost incurred. Rob's short list of questions are dead-on. I'd follow up with:

5). What are the policies and rules for data that feed into the business process that would result in process improvement?
6). How would we monitoring compliance to the policies?
7). What happens when they're violated?
8). How do we systemically remediate recurring compliance problems?

My first job out of school 17 years ago was to develop an IDEF based modeling tool for process and data. The relationship between data models (IDEF1x) and process models (IDEF0) was very clear: business processes consume, or produce data. Marty, I think this is what you mean by declaring/modeling these relationships, which are critical for DG.

BPMN 2.0 supports this, but the use case is more about generating low level services, rather than declaring accountability for data.

I'm sure someday, these things will all come together. But until then, we make peace one country at a time.

Great additions

Those are great additional questions to help folks operationalize their data governance policies and procedures - thanks for contributing those thoughts!

Governance vs Agile

Rob, I'd be curious to hear your thoughts on how proper data governance supports or interferes with agile practices. While I can't argue with any of the points you make about executive sponsorship, business ownership, documented policies and procedures - wouldn't all that create extra layers of red tape and potentially impede any agile and lean methodologies?

Governance can and must be agile...eventually

Boris - excellent point, and I agree that ineffective data governance that focuses on layers of bureaucracy and endless meetings will spit in the face of any efforts at building an agile IT organization.
But at the same time, you can't have it both ways - data governance means accountability which means structure. And that structure will not be "lean". It should be as lean "as possible", but you're not going to solve data governance with only 2.5 FTEs all outsourced to India - won't happen.
But Agile best practices can and should be applied to contain role confusion, scope creep, boiling the ocean, analysis paralysis, and other banes of successful data governance.
There are not yet a whole lot of examples of Agile principles being applied to data governance efforts, but I'm confident many vendors and management consultancies are already well on their way in development methodologies and tools to promote this as we speak. I'll look forward to seeing these early results.