BeyeBLOGS | BeyeBLOGS Home | Get Your Own Blog

February 20, 2008

Why doesn't the business care about data governance?

Howdy folks. Back again after a little time off from the blog.


I have as usual, been to a lot of trade shows on Data Governance and MDM. And in the past month or so, I have run into more unemployed Directors of Data Governance than I care to admit. They were all very intelligent, thoughtful, and new quite knowledgeable about data management in general. So why is it that so many of them are looking for jobs. After talking to quite a few of them, I have some thoughts on why is it that the tenure of these folks is short.

Quite of few of them were working in financial services, specifically in companies where the mortgage credit crisis forced quite a few layoffs When asked why they were laid off. Many of them commented that business management didn’t appreciate the importance of data quality and governance. When I asked what were the benefits they were presenting, they commented that the benefits were obvious, but never articulated a specific example where data governance had saved money, prevented a disaster or improved the business in a specific measurable manner.

All of this doesn’t mean that data governance isn’t valuable. However, I think that it is perceived by business managers as just another one of those overhead activities that IT wants to promote. It feels a lot like the general “quality” craze in the 80s that started with Japanese companies and at first, U.S. and European manufacturers didn’t really understand. They would try “quality” programs for a little bit, then fail, and the quality managers would lose their jobs.

Eventually, good product quality became expected by the consumer. You could buy a good quality product for the same as the cost of a bad quality product. So quality manufacturing became an expected part of doing business.

Unfortunately, most companies don't seem ready to think about data quality in the same we think about product quality. Actually, if you turn it around, and thought about product quality the way we think about data quality, I doubt you could drive your car out of the driveway in the morning. The wheels would fall off, the steering wheel wouldn't turn and the car probably wouldn't even start if the quality level of your automobile were as bad as most data environments.

Anyway, so what can anyone do about this? Well here is my short list of thoughts on the topic:

- Stop talking about data governance and data quality as an objective in and of itself.
-Focus on business value: What if we could reduce the number of miss-configured products? What if we could more easily measure the risk of our financial portfolio so we could keep less cash reserves on hand? What if we could more easily cross-sell and up-sell our customers?
- When you create value from good data governance, market that internally. Remind people the savings you are achieving every day as a result. If you don’t market the success, people won’t notice. This is one of the hardest things for an IT professional to do. We aren’t extroverts by nature.
- Don’t call what you are doing data governance. Just do it, measure it, measure the value, then declare your success from the mountain top later. Then go ask for more resources to do more of the good stuff you just did.

What other ideas do you all have about this? I know my list is pretty short, but I am sure that people reading this blog have additional thoughts, please share them.

Share: del.icio.us Digg Furl ma.gnolia Netscape Newsvine reddit StumbleUpon Yahoo MyWeb  

Posted by Todd Goldman at 10:45 PM | Comments (0)

December 2, 2007

Security and Data Management

Just thinking about how little has been done regarding the overlap in enteprise data management and data security. Why is it that these two disciplines are still management very separately from each other.

Perhaps that is what both Symantec and EMC are doing with their recent acquisitions?

Or, maybe it is just as simple as the fact that security cuts across everything, so as a discipline, it is one of the most diverse topics you can possibly think of. You have physical security, network security, identity management etc etc. So it really isn't a surprise that as enterprise data management is still kind of young, with MDM and data lineage deployments just now starting to take off, the overlay of how security of structured data is a little behind.

Ack. It's late and I am rambling. check back in with y'all later.

btw, this week I am in lovely Orlando Florida at the Data Governance Conference. So I will send you all my thoughts while I have them.

Also, a belated Happy Thanksgiving to all of my U.S. readers. And if those of you in the U.K. feel left out, then Happy Guy Hawkes day. :)

Share: del.icio.us Digg Furl ma.gnolia Netscape Newsvine reddit StumbleUpon Yahoo MyWeb  

Posted by Todd Goldman at 11:15 PM | Comments (0)

November 12, 2007

FIMA Europe (part II)

Last time I spoke about the first of two hot topics at FIMA London, Data Governance. Today I want to hit on the second area I repeatedly heard about which was integrating downstream applications to the security master.

This came up an incredible amount. Many companies have built their master or purchased their master. (Note for those of you who are not in the finance world, you can buy a pre-populated MDM system where the data sources are already pre-mapped to each other. This is because there are 100 or so companies in the industry that provide data feeds to financial firms and the financial MDM vendors not only sell the MDM software, but the model with the data feeds pre-integrated. ). Regardless, when it comes to integrating to the hundreds of downstream legacy applications that currently get their data directly from outside data vendors they find that the cost of this integration is too expensive.

This is clearly a case of “If you build it, they will [not] come.” (for your “Field of Dreams” and Kevin Costner fans!]. The problem is multifold:
a. The cost of integrating to the downstream applications is an expensive manual process
b. The IT group which built the master often publishes an interface to integrate with and tells the downstream groups to integrate with it. The problem is that the downstream application groups don’t have the skills or the budget to do the integration so it doesn’t happen.
c. The IT groups don’t want to map their data to the downstream applications themselves because they don’t know the data structure of the downstream applications and SMEs for the downstream apps aren’t available to help. Very Catch-22.

The result is that millions of dollars are spent building the reference master and they currently end up being underutilized.

My talk at FIMA was on this very topic. I went through a real example of a talented data analyst that had to map 6 columns of data to 3 different data sources and what was expected to take 3 weeks ended up taking 7 months. As it turned out, the 6 columns were overloaded columns that contained different codes depending on which of the 50 U.S states a customer might be located. The result was that it was more like 300 columns shoved into those 6 columns and sorting out the mess ended up being very time consuming. This is just an example of why no one wants to step up to doing this work. The second half of my presentation talked about a new approach that automates the discovery of the relationship between the master and the downstream application data and speeds up this process.

My thinking on this is that if financial institutions want to resolve this issue, their master data management IT groups will have to step up to the plate (“Field of Dreams” pun intended) and develop a competency to do this last mile of integration. It just doesn’t make sense to make the downstream app groups do the work. They would only do the work one time each for their application and it doesn’t make sense to staff up for that. But the central group can develop a competency in this and as there is technology now to help, there is really no longer an excuse for not providing full service to their users and developing repeatable processes to solve this problem.

Share: del.icio.us Digg Furl ma.gnolia Netscape Newsvine reddit StumbleUpon Yahoo MyWeb  

Posted by Todd Goldman at 12:30 PM | Comments (0)