Don’t Create A Data Governance Hairball

Are you in one of those organizations that wants one version of the truth so badly that you have five of them?  If so, you’re not alone.  How does this happen?  The same way the integration hairball happened; point solutions developed without a master plan in a culture of management by exception (that is, address opportunities as exceptions and deal with them as quickly as possible without consideration for broader enterprise needs).  Developing a master plan to avoid a data governance hairball is a better approach – but there is a right way and a wrong way to do it.


Point solutions eventually come back to haunt you.  It might take 5 years, 10 years, or more.  But eventually the weight of carrying overlapping and inconsistent solutions and the drag on innovation grow to the point where it reaches crises levels (quite literally in many cases). At this point, organizations react and start cleaning up the mess.  Many organizations have already hit that point as evidenced by the growing number of enterprise initiatives to rationalize their application portfolio, reduce the number of technology vendors, and generally simplify IT operations.

While the integration hairball and application sprawl have been with us for years, there is a new and growing threat, the data governance hairball.  IT staffers, and data management professionals in particular, have long been pushing for data governance programs, but all of a sudden top-level business  executives are very interested.  Maybe because of regulatory pressures, or maybe because of data security or privacy concerns, or maybe because of clear opportunities to grow revenue by leveraging and consolidating data assets. Regardless of the reason, there is a growing wave of demand for data governance. So much so that I am starting to see multiple data governance initiatives forming in the same enterprise; one might be driven by the risk management interests, another by marketing interests or a 360-degree view of customer, and another by operations to optimize the supply chain or improve efficiency. Each group is creating their own framework, separate business glossary, and laser-focused governance process. Eventually these initiatives will clash and spawn yet another crisis or expensive reconciliation effort.

The alternative is to develop a master plan first, but there are two common mistakes that are made over and over again.  First is what I call “governance by white board”.  The governance framework is at such a high level and so abstract that of course everyone agrees with it – but yet so vague that it doesn’t provide any guidance so the debates and disagreements continue. At the other end of the spectrum is the thought, “we need a current state process analysis as a foundation”.  Two years later the team is still doing current state analysis, and eventually their funding is cut and the team is disbanded.

The problem with a master plan is that there is no business value generated by it. Only once you begin implementing the plan is that value created.  So the secret – the right way to do it – is to develop the master plan at the right level of granularity.  The master plan should be completed in about three to four months and should include a governance framework, clarification of roles and responsibilities, an enterprise reference architecture, and the identification of the first few business initiatives that would benefit from the master plan.

I could go on, but this is already a long post.  For further reading, check out chapter on Lean Data Governance in Run Grow Transform: Integrating Business and Lean IT or some of the recent discussions on