I've been reading about data governance a lot recently, with the idea that I might do a post on common mistakes and how to avoid them.
But after a few good solid days of research, I've reached a few conclusions. First, there are too many common mistakes. If you're curious, they're things like making data governance an IT project; not involving the right people; no executive sponsor; too much analysis, too little actual work; too few resources or time; and - not surprisingly, giving the list thus far - data governance initiatives that are too rushed.
Which brings me to my second conclusion: All of the mistakes boil down to one fatal flaw, which is that the business doesn't like data governance. Primarily, that's because those involved see it as (pick at least one): a. too complicated; b. requiring too much change (see reason a); and/or c. something IT should be doing, and, hey, aren't they the ones who brought up this whole governance thing in the first place?
Sure things are getting better. As Rob Karrel wrote last summer, data governance is receiving the most senior-management-level attention he's seen during his 18-year career.
But, while we're waiting for the big hug of acceptance from business, perhaps IT should look at whether data governance could be made easier?
I recently read two articles that suggests it is possible to simplify data governance by focusing less on bureaucracy and more on tactical, simpler steps. The first is "Seven Steps to Effective Data Governance," published in the TDWI's recent e-publication, "What Works in Data Integration." It's written by Vincent Lam, the product marketing director for Information Builders. Writes Lam:
Contrary to popular belief, data governance does not have to be a harrowing endeavor. Taking small, tactical steps will not only provide fast business value, but will also enable companies to avoid the pitfalls of both over and under reaching in their data governance strategies.
Lam recommends you start by prioritizing one or two areas for improvement, focusing on where data governance can bring the most immediate benefit. He also suggests how to break down the roles and responsibilities of data governance, offering guidelines for what business users should contribute and what should fall under IT's domain.
Although he's broken data governance into seven steps, some of these steps are still pretty darn big. For instance, step five is "establish an accountability infrastructure," by which he means you assign owners to each asset and define "policies and workflows that hold people responsible for the state of those assets." That's a pretty big chunk of data governance to wrap up in such a short paragraph and, as I've noted before, people aren't always rushing to accept accountability for data.
Still, the piece is full of good, safe advice. But if you're interested in really simplifying data governance, and you're open to a more unconventional point of view, check out Steven Adler's post, "Learn from my Mistakes," in which he outlines a mere six steps for data governance.
Adler has an impressive resume when it comes to data governance. He's IBM's leader and innovator of data governance. In 2004, he created the IBM Data Governance Council and he lead a team of 55 companies to create the Data Governance Maturity Model in 2006. He also created the Information Governance Community with 1400 members. So, as you might guess, for years he advised companies to form executive data governance councils. But he's done a 180 on executive councils and data governance since he saw how his advice played out at one firm. He writes:
At the end of the day, this is still a hierarchical power structure that cost time and money to organize and that resource can be better spent on easier targets. My advice: don't do it.
His post explains what situation made him change his mind and what he now recommends instead. I have to say, I love this post because it bypasses all the usual admonishments and explains how IT can enact data governance more or less on its own, without a lot of hassle or a bunch of bureaucratic meetings.
Mind you, he doesn't bypass business users, but instead suggests you recruit a very select group of business users to serve as "internal compliance officers":
They need to be in either either in operations or directly assigned to a business unit. They should understand data and how it is used. What it means and what it's worth. These are your local enablers that fix small problems every day and help business units get more value from their information. They are semantic experts and understand how glossaries are created and how politically challenging some definitions can be. They see the IT and business issues and help both sides understand each other.
Then, he adds without irony, "This role is hard to fill and these people are like gold in your program."
I suspect that's the data governance understatement of the year. Still, his approach calls for less fantasy than many others, which rely on the ever-elusive executive sponsor and a team of caring business users with tons of time to discuss rules, rights and policies - not to mention a data steward willing to be fired over the data. It relies more on technology, though and, conveniently, he recommends mostly IBM solutions (although he also suggests a free tool).
Check out both pieces. At the very least, you might find something that will work for your organization and finally move data governance off the "to do, someday, maybe" pile.