I stumbled across a March 2008 paper written by Mike Ferguson of Intelligent Business Strategies a couple of weeks ago that looked really interesting, and I finally got around to reading through it this weekend. First looks were not deceiving! The paper is Getting Started with Master Data Management. The link I went through required a two-page registration form, which really is unacceptable, but this post isn’t about web registration form best practices!

It is worth it to wade through the process to get at the 22-page paper if you:

• Are struggling with data being managed in disparate repositories at your company and are thinking that this whole “master data” thing might be worth looking into
• Are new to a master data management initiative and are trying to wrap your head around the myriad issues
• Are deeply embedded in a master data initiative and would like some assurances that you are on the right track while also uncovering a new nugget or two that you can apply to your work

Some of the highlights that jumped out for me are below.

What Is Master Data Management?

The paper makes a very clear and clean distinction between two broad categories of structured business data:

• Master data — the data associated with core business entities such as customer, employee, supplier, product, partner, asset, etc. regardless of where that data resides
• Transaction data — the recording of business transactions such as orders in manufacturing, mortgage, loan, and credit card payments in banking, and premium payments and claims in insurance

I like the distinction, as it adds some nuance to the tendency to make a knee-jerk definition that master data is “all data that might need to be shared across systems or the enterprise.”

Early on, the paper also makes a very, very, very, VERY key point about MDM:

…MDM is not just about data. It is about putting processes and policies in place with respect to governing master data, as well as putting services in place that provide common ways to access, maintain and manage it. MDM is, therefore, about data and the processes associated with it.

The fundamental principle described in that paragraph is that it is a fatal mistake to assume that MDM is mostly about technology. IBM deserves a negative shout-out for their irresponsibility in perpetuating this misperception by actually naming their MDM-supporting technology “MDM.” Technology vendors in all areas tend to overplay the importance of “the tool” and underestimate the importance of “the process” and “the people.” But, still… shame on you, IBM!

Why Is Master Data Management Needed?

Again, highlighting a quote from the paper is useful:

The problem this causes is that master data is fractured and partially duplicated in many different places. In addition, there is often no complete master data system of record in existence within the enterprise, except perhaps in a data warehouse where its use is restricted to analysis and reporting.

The paper goes on to include a “spaghetti architecture” picture that illustrates where many companies find themselves when they hit the point that they need to develop a master data management strategy. And, the paper includes several lists of the “…and here’s why it ain’t as easy to solve as you might think” variety. Issues such as:

• Managing/reconciling data conflicts between different systems — is the first name for this customer “Tim” or “Timothy?” Our web site registration system has captured his name as “Tim,” while our billing system has captured it as “Timothy.” Which one should be recorded in the “master record” for the customer’s first name?
• How do you know if the data is complete and accurate? — in the registration form I had to fill out on bitpipe.com to download the white paper, I intentionally stated that I was at a company that generates less than $1 million in revenue every year, because I didn’t want their lead management team to pounce on the fact that I’m at a very large company and should be contacted immediately by a salesperson. At the same time, I was honest about where I work and my job title. With a little bit of research, bitpipe.com can figure out what’s accurate…but manual research is expensive to operationalize, and automated research can be expensive to develop and still be less than completely accurate.
• If changes happen to master data in one system, how long is it before these changes  get to all other parts of the enterprise that need to know about them? — this is another good one. Customers, for instance, typically have multiple entry points to interact with you: through your billing department, through your technical support department, through  your web site, etc. Each department may rely on a different operational system. Customers expect that, once they tell “the company” that they moved, that their name changed, that they had a life event that changed something relevant, that they bought a product or service, etc., that “the company” (and all of its systems) are aware. A key goal of master data management is to make that true…but it can be inordinately complex to actually pull that off across the entire enterprise.

This is just a subset of the questions and issues the paper lists. There are many more!

Getting Started with an MDM Project

The paper devotes several pages to how to build a business case for an MDM initiative. On the one hand, it’s a Business Case 101 summary — know your business, know your business’s competitive environment, build the case around relevant business value. But, it does call out some examples of where and how MDM can roll up to core business objectives.

The unwritten piece of this section is that MDM is typically expensive, requires a longer view than “this quarter,” and requires a certain degree of underlying business transformation. It’s not a case of “buy some software and install it and then the problem is solved.”

Scoping the MDM Initiative

There are lots of good tips about defining the different requirements and the potential scope — short-term and long-term — for the initiative. The paper includes a good explanation for why the goal-state architecture for the MDM system should be developed early on, even if it’s not fully realized in the first iteration. For more on the high-level alternatives on that front, I recommend pages 3-8 of Colin White’s paper that SAP commissioned back in 2007: Using Master Data in Business Intelligence (although his paper is geared a bit more towards the BI benefits of MDM, the different options for handling master data and the system-of-record vs. system-of-reference distinction is laid out really well).

The Importance of Data Governance in MDM

The paper explains why MDM should be part of a wider enterprise data governance program, going as far as saying that, “Adoption of data governance standards, policies and technologies are an essential part of any MDM project.” That data governance program needs to include data standards (shared business vocabulary, data integrity rules, taxonomies), common policies for enterprise data management and data integration development, an enterprise data governance technology platform, an enterprise data model, and processes for monitoring and managing enterprise data quality.

Conclusion

I’ve touched on some of the highlights from the paper. But, for a 22-page paper, it is packed with more information than can be easily summarized in a single blog post. It’s worth a download!