In-Depth

Q&A: As Enterprises Mature, Data Governance Remains Challenging

As enterprise data management has matured, companies are beginning their data governance programs with a better understanding of what the term means, but plenty of questions and confusion remains.

• By Linda L. Briggs
• 10/18/2011

"I think the biggest challenge for companies in the next one to two years is going to be taking a project, applying data governance principles to it, and showing the value," says Daniel Teachey of DataFlux. As companies have matured in their data management strategies, he sees more enterprises tackling data governance -- only to discover that the challenge is bigger than anticipated. In this two-part interview, Teachey discusses how data governance has changed, where to start a governance project, and how to demonstrate returns quickly.

Teachey is senior director of marketing at DataFlux, where he manages global marketing efforts along with PR, product marketing, and customer relations. He joined DataFlux in 2003, having held positions with IBM, MicroMass Communications, and Datastream Systems.

Along with TDWI research director for data management Philip Russom, Teachey spoke on data governance at a TDWI Webinar on Sept. 14, Lifecycle Stages for Data Governance: Plan Ahead for Success and Sustainability.

BITW: What are some of the biggest challenges today in data governance? Have data governance issues changed in the last few years?

Daniel Teachey: I think that where people are starting out has changed somewhat. Four or five years ago, people were researching what data governance was and what it meant. They knew they needed things like compliance driving them toward data governance, but they weren't really aware of how to get started. Now, lots of companies have started; they now understand that this issue may be bigger than they anticipated and may involve more types of data than they anticipated. They're also often seeing that they don't have the internal structures in place to support it.

The problems and drivers behind data governance are probably still the same. The average maturity of organizations has gone up, but there is still a lot of confusion. I think the biggest challenge for companies in the next one to two years is going to be taking a project, applying data governance principles to it, and showing the value. It will be the challenge of testing out some of the processes, some of the technologies, some of the human resources, and seeing if they're delivering what they need to provide value. Ultimately, of course, that's what determines if the project was successful or not.

One question that was asked during the recent Webinar was: How should we structure a data governance committee or board? Who do we put on it and what kind of goals do we give them?

That's a good question. Earlier today, I was on a call with a panel for our upcoming user conference, and the focus was a business and IT collaboration. It's a term that is being used in many different settings, but data governance is probably the best place where you can apply this idea of business and IT collaboration. That's because historically, people have viewed data as IT's problem, as a sort of leave-behind by the applications that IT manages. So, in that view, a company does all this work, and the data serves as the historical record.

What's been changing in the last couple of years is that people are starting to look at data and say, "There's value to the data itself, so how can we make the better?" I'd answer the question this way: data governance boards [need] to be a mixture.

They need to include business people who understand how the data is represented in the IT systems and what they need to run the business. Business people are the ones who understand what the data should look like. Their job is impacted if there's an invoice missing a complete invoice number. Their job is impacted if they can't get a single view of the customer because it inhibits customer engagement campaigns.

IT has a seat at the table because they understand how the systems work. If there have been efforts to consolidate information, either from a data warehouse, the creation of data marts, or a master data management, IT has been heavily involved. You're going to have a systems analyst -- people who actually know how the hash is made -- and an IT director. They are going to have a say if it's a data governance program for the purpose of business improvement -- developing cleaner data about your customers or your products to support better processes.

If you're trying to create a data governance program for compliance reasons, you'll have compliance officers, business analysts, and someone from maybe the legal side at the table.

If your business includes a supply chain, you'll have your supply chain and operations people as the business representatives.

What about master data management (MDM)?

Data governance is showing up a lot more often because of MDM. When you build a master repository of customer data, you're essentially saying, "We're going to take all this disconnected data about our customers and manage it as a single entity in a repository." That has a data governance implementation from start to finish because everybody has to agree: this is what we mean by "customers," this is what we mean by "product," this is what we mean by "asset." That's not trivial; it can take a while to work out.

Also at the data governance table in that situation, if there are five applications that have been storing customer data, usually all five of those [data owners] will have a seat at the table. If there are two data warehouses -- one from a company you've just acquired and one from your original company -- maybe both of those groups are going to be at the table.

Data governance boards and teams can be even bigger if you're looking at it from a MDM perspective. I wouldn't say the stakes are higher, but the scope of the project tends to blow up a little bit at that point.

I've heard you say that the best way to start data governance is with a smaller project -- a pilot.

Absolutely! Find the area of the greatest need and try to solve it.

There are a number of different ways you can crack it, but if you can find an area where you can say, for example, "If we can clean up customer data, maybe we can lower the amount of time that someone is on the phone with a customer because they don't have to pull out as many details. Everything will kind of pop up there for them." If you can put a metric behind that, maybe that every piece of direct mail costs you $3.50 and every hour spent by the compliance team is $75, then there's your return on investment. Then you're speaking executive language, when it's a number proceeded by a dollar sign.

What's the difference between top-down and bottom-up data governance? Which is best for an organization?

Top-down is an acknowledgement that in someone's organizational chart, data governance is an executive issue -- this is where we want to go, and we need to clean up this process or this data source because it's inhibiting our ability to conduct business. Top-down would be a scenario where you have an executive open things up and say, "This is our plan of attack and you 12, 15, 18 people – whatever, you're going to go make this happen."

Bottom-up is the grassroots approach, where a set of business analysts, data stewards, or IT people have come together and said, "What we've been doing in the past isn't working. We're already working 50 hours a week, but we're going to slot this in as another project to take on."

In order to go up, you have to say, "We were at x percent bad data. Now, we're at y percent, which is an improvement of z percent. Look at what we've done. Let's try to roll this out across more business units." There's this work to prove the value of the program, and to build upward, rather than having an executive say, "Make it so," and everybody else scrambles.

What about a competency center? How does that tie in to data governance? Should data governance be part of an organization's competency center?

Competency centers are absolutely a good place to tap into. You will still want to have a data governance board, probably -- some sort of a stewardship committee that has a view across it all.

BI competency centers, typically, will be talking about the types of models you want to represent or the types of regressions needed in some specific instance. The governance board can have a representative saying, "If you're pulling customer data, make sure to run through this process first because this is where the good data is. Make sure that we're tying all these things together, so there's no garbage in -- garbage out scenario."

Governance can be a very good compliment to that process. I don't think it should be consumed by other processes, because data governance can straddle BI and master data management, data quality, data integration, and data modeling. It has a number of different areas it touches. Even in security and privacy, you may have a privacy or security competency center, and there may be some interaction with data governance there.