Building a Data Governance Organization
digg this | 
del.icio.us | 
Reddit | 
Stumble It!
I’m often asked how many data stewards a company needs.
A rule of thumb I’ve used for quite a while is “one data steward per $1 billion in annual revenue”, but of course that can’t be a hard and fast rule.
Depending on the company, the degree of automation, what data quality tools are available, and the major processes around the enterprise, that number is going to vary.
Here are some thoughts to keep in mind as you build your data governance organization:
- Build the business case and secure your funding. Don’t forget this is a multi-year effort. Several times, I’ve seen data governance teams and MDM initiatives that never thought beyond their first year’s funding, and who were surprised when funding for Year 2 and beyond wasn’t forthcoming.
- You’ll probably need a multi-layer, cross-functional approach. Start with a high level group that sets data policy, usually called a Data Governance Steering Committee or Data Governance Council (DGC). Your executive sponsor(s) should be involved with the DGC. Then you’ll probably have a small group of data stewards which handle day-to-day data management, which reports to the Data Governance Council.
- Focus on your data governance processes, including relevant metrics that show the impact to the business, and on communicating those metrics and their impact to the rest of the enterprise. Create a communications and education strategy to get the word out.
- Look for IT people who “speak business” and business people who “speak IT”. These liaison-type people are going to be crucial to your data governance organization. Although I believe that data governance should be driven by the business, there’s no question that you’re going to need a lot of support from IT. So look for the “bi-lingual” folks in your company – they’re out there and they can be incredibly valuable in understanding the business impact of data issues, and in providing the technology support that the data stewards will need.
- Don’t forget about metadata. In your travels as a data governance organization, you’re going to run into a lot of metadata (information about information). Develop a disciplined approach to cataloging and maintaining the metadata you come across. In many ways, that will probably be one of the most useful outputs of your data governance initiative.
We’ll have more to say on data governance in this blog in the future, but let me leave you with one idea. Instead of describing your MDM initiative as (hopefully) including data governance, think of it as a data governance initiative that has an MDM component.
You’ll be doing data governance in your enterprise long after your current MDM hub implementation is over.
If you don’t agree, or you have a perspective on data governance you’d like to share, please comment here on this blog.
Consolidation of Data Quality and Data Integration
digg this | del.icio.us | Reddit | Stumble It!
In a recent article, we covered the importance of data integration to Master Data Management (MDM).
This article elaborates on that in the context of today’s software market, and talks about how the visionary data integration vendors are scrambling to acquire and offer data quality as part of their integration suites.
Historically, data quality initiatives have been rolled out only on a project-by-project basis, while integration initiatives have been point-to-point application integration projects.
But more recently, as MDM programs have started gaining momentum, there is a need being felt in the marketplace for a single platform that can integrate data from multiple sources across the enterprise (web, data warehouse, ERP, CRM, legacy systems and systems from acquired companies) as well as run sophisticated data quality processes on these sources.
This requirement allows for a single administration console and metadata repository, as well as common transformations, user interface and a unified developer workbench, all on a single, combined integration and data quality platform.
This vision is consistent with moving towards a Service-Oriented Architecture as well, and is very conducive to providing a single environment for “data as a service” that is trusted and consistent across sources.
The customer tends to love it, since an integrated platform like this generally implies lower Total Cost of Ownership and smaller IT costs than standalone integration and data quality investments, and more rapid software development cycles.
The MDM vendor, if not providing such a platform itself, loves it since it can focus on what it does best, i.e. matching, merging and building data hierarchy.
Recognizing the above need, California-based Informatica Corporation acquired identity resolution vendor Identity Systems, while Massachusetts-based Trillium Software acquired address cleansing vendor Global Address. These are just two examples of recent data integration and data quality market convergence.
And the acquisition of Group 1 Software by Pitney Bowes provides more evidence of this shift. In the process, niche data quality players are finding it more difficult to compete in such a dynamic marketplace.
If you’re considering acquiring a data quality tool for a corporate initiative, consider the above dynamics. And we’d love to hear your thoughts via comments on this article.
Guest Article on Identity Resolution Daily
digg this | del.icio.us | Reddit | Stumble It!
I wrote an article appearing today on the Identity Resolution Daily blog.
Here’s a quick excerpt:
In a recent post, I wrote about the importance of data integration to Master Data Management (MDM). Today, I’d like to dig into the importance of identity resolution. The question of identity resolution, or matching, is critical to a successful MDM initiative. There’s a good article by Roger Wolter and Kirk Haselden of Microsoft which says “the matching accuracy of MDM tools is one of the most important purchase criteria.”
Click on “The Importance of Identity Resolution to MDM” to continue reading.
And please let me know what you think by commenting here …
June Column in DM Review
digg this | del.icio.us | Reddit | Stumble It!
Here’s our latest “MDM Insights” column in the online edition of DM Review.
The technology industry is the mother lode of acronyms, and in the field of master data management (MDM), there are more than a few. We have the subsets of MDM known as customer data integration (CDI) and product information management (PIM). And in the closely related fields of middleware and integration, we’ve got enterprise information integration (EII); enterprise application integration (EAI); extract, transform and load (ETL); service-oriented architecture (SOA), among others. You get the point. Today, the acronym I’d like to focus on is business process management (BPM).
Click on “Master Data Management and Business Process Management” to continue reading.
And please let us know your thoughts by commenting here …
Importance of Integration to MDM
digg this | del.icio.us | Reddit | Stumble It!
We’ve discussed many other topics on this blog, such as data quality, best practices for Master Data Management, the five essential elements of MDM, and Master Data Management and the art of politics.
But one topic I don’t think we’ve given enough “airtime” to is integration. There are many different types of integration technology available today, and a veritable alphabet soup of acronyms to go with them.
There’s Extract-Transform-Load (ETL), Enterprise Application Integration (EAI), Enteprise Information Integration (EII) and Business Process Management (BPM).
In an upcoming piece in the online edition of DM Review magazine which I wrote last week, I go into more detail on the different types of integration and why I think Business Process Management offers some real advantages, due to the close fit with Service Oriented Architecture (SOA) and its flexibility and ability to model complex business processes that span multiple application silos.
But as I said, that’s a topic for another piece, and we’ll post a link to that here when it becomes available later this month.
In today’s piece, I want to urge MDM project team leaders, program managers, and “data champions” to think about the importance of integration itself, and the existence of certain typical requirements.
While integration doesn’t always have to be real-time, if you find yourself thinking solely in a batch-oriented mode, take a step back and ask yourself, “what will we be giving up by not providing for any real-time capabilities?”
And while straightforward, point-to-point XML data exchange may be all you need, ask yourself if you’ll be giving up anything important by not being able to model, deploy and manage business processes.
And try not to limit yourself by planning only for one-way integration into the hub. As hard as it is to convince the business owners to subscribe to the data quality improvements and external content that you typically do in an MDM hub project, you’ll make it much harder to achieve your expected ROI for the MDM initiative if the source system business owners don’t receive any of those improvements.
What are some of the integration “sticking points” you’ve run into on your MDM projects?
OAUG Collaborate 08 Presentation
digg this | del.icio.us | Reddit | Stumble It!
TechTarget recently had an article that quoted heavily from my presentation at the recent Oracle Applications Users Group (OAUG) conference, COLLABORATE 08.
The article discusses the Master Data Management program at Tektronix, Inc. and segues into an overview of MDM based on my presentation at the conference.
Here’s the full link:
http://searchoracle.techtarget.com/news/article/0,289142,sid41_gci1312492,00.html
Please let us know what you think of the article by commenting.
