"All the technology in the world does not, by itself, constitute MDM. The technology has to be accompanied by a strong set of organizational rules, business rules, and well-defined data elements that can be universally understood by the user community."

The Mystery of the Cubes

Vendors try hard to maintain the mystique associated with any technology. They come up with snippets that are designed to sound great and sell well at the C level. With the advent of BI and BPM tools, it has become easier than ever to create the elusive one version of the truth. All an organization needs to do is create a magic cube of information for all its ills to go away. But what are the hidden issues behind the claims?

Go, Speed Racer

Business and IT are clashing as companies move toward creating a single version of the truth. Though BI and BPM vendors claim their products will solve business woes, the tools themselves, while much improved, do not offer complete solutions. Therefore, it’s up to IT organizations to make the vendor promises come true. Through a mix of IT resources and business users working together, the race is on.

Opening Statement

DECIPHERING MDM

Navigating the sea of master data management (MDM) has become extraordinarily complex and needlessly treacherous for most enterprises. There seems to be an ever-increasing array of definitions, issues, and marketing initiatives as vendors in the space attempt to convince clients that their particular solution will solve all of an enterprise's MDM woes. If an individual tries to peel through the onion of definitions and get to the core, what is really being debated? The answer is that there are basic arguments about:

• Fundamental data usage
  
  
• Data ownership
  
  
• Data distribution
  
  
• Data organization and integration
  
  

The key point is that no matter which tool is implemented, what MDM is focusing on is an organization's biggest asset -- the information locked away within its operational and analytical systems. The choice of tool will be dictated by the key issues and heartaches an organization is trying to fix. Without doubt, using an MDM solution will facilitate and maximize use of existing business intelligence (BI) and business performance management (BPM) toolsets, but unless an organization follows up the use of an MDM tool with business rules and a disciplined approach to data usage, the benefits will be limited.

The concept of MDM is not magically new, nor should it be organizationally complex. Dealing with the issues that arise from an organization's lack of MDM is the fundamental point. Organizations that successfully navigate the MDM waters have done so because they have demystified the task and come to grips with the fact that master data management is essentially a philosophy that has been implemented by applying technological solutions. All the technology in the world does not, by itself, constitute MDM. The technology has to be accompanied by a strong set of organizational rules, business rules, and well-defined data elements that can be universally understood by the user community.

FUNDAMENTAL DATA USAGE

Vendors are constantly bemoaning the fate of any organization that cannot produce and maintain information from one single source of the truth. Vendors continue to formulate what constitutes the "one version" of the truth and try to convince clients that their products create and maintain that sole source. The concept sounds simple -- and even reasonable -- on the surface. If everyone in the organization uses the enterprise MDM solution, then there will be only only one source of key organizational data from which to draw information. It stands to reason, then, that only one source of the truth will exist in the organization.

The fallacy of this argument is that it fails to take into account that organizations can only control the source of the information, not the way end users extract and use the information from that single source of the truth. Organizational use of the information is diffused based on why and by whom the information is being sought. Within an organization, operational data is used to run the daily operations of the enterprise. Organizations sell products and services, invoice for those items, and collect and disburse cash. They use terms such as "total sales," "net profit," "total production," and so on. These terms have diverse meanings within the organization and depend on whether the user is trying to present operational (tactical) or metric performance (strategic) perspectives.

In addition, the operational systems that enterprises use for customer relationship management (CRM), finance, and human resource functionality have greatly improved. Couple these systems with BI applications, and organizations will have an excellent methodology for reporting historical information and measuring it against set goals and objectives. To go a step further, organizations have undertaken a new category of systems; namely, enterprise performance management (EPM) tools. These tools have provided a dimension of true real-time management because of their ability to provide real-time or near-real-time dashboards and to quickly identify and monitor key performance indicators for the organization.

The advent of EPM tools has greatly accelerated and increased the need for MDM solutions. While these solutions may not offer a single source of the truth, they do provide the ability to:

• Store key information about critical master data elements
  
  
• Make updates to that data in a central repository
  
  
• Quickly and automatically move those critical changes into the appropriate systems for their use
  
  

DATA OWNERSHIP

When speaking about an organization, it almost feels ridiculous to delve into the question of data ownership. It seems logical that all of the data belongs to the organization and should therefore be open to and available for use by any member of the organization. In truth, there are wide-ranging debates on this topic. The areas that are responsible for the various operational functions that make up an organization must maintain autonomy over their individual pieces of organizational data. That said, there has always been an internal struggle between the technical keepers of the data and the business users of the organization. IT secures, manages, and runs the operational systems, and it owns responsibility for the hardware, software, and infrastructure needed to do that. The individual business owners own the data, because they are the ones who understand what is stored in the bits and bytes on the massive storage devices.

The classic struggle often occurs, for example, between the database administrator and the business users. Yet the distinction should be very clear-cut. The DBA should maintain the metadata aspects of the information contained in the systems, as he understands the issues around data types, data access, and storage organization for the vast amounts of the organization's data. The DBA should assume responsibility for numerics being numerics and for alphas being alphas. The business users, on the other hand, should maintain both jurisdiction and control over what data is collected, because they are the ones using the information to operate and manage the organization.

Again, MDM can play a vital role in minimizing this struggle. An MDM system should maintain a class of "business metadata" that differs from the DBA's "functional metadata." The business metadata relates to structures used throughout the organization and maintains validation of business rules that are applied across the organization (e.g., ensuring that a vendor number is seven digits long or that an address is standardized and cleansed according to postal regulations). This will ensure that the information has been validated using a single point of entry employing uniform business rules and that the data passed to downstream systems is valid and in the standard formats.

An additional issue arises when different operational systems are purchased at different times or have differing key requirements. An MDM repository can be used as a storage location for an organization's cross-reference information about related data keys. Oftentimes, different systems store information about similar entities, such as persons, vendors, organizations, and so on. Each independent system retains information using its own record key. An MDM repository can create a central organizational key that can be used across the organization and serve as a repository for the independent system keys, thus providing a handy cross-reference by which BI and BPM tools can gather vital information from diverse systems.

DATA DISTRIBUTION

The benefits of having a central repository of key business metadata should be obvious. Whether the information consists of keys or actual values, having all of the information entered into one repository using a consistent set of business rules will improve the data quality.

Enterprises that have a large amount of operational systems but don't have MDM solutions find that key information must be entered into numerous systems. The risk is that each time the information is entered, it is subject to change -- either intentionally or accidentally. Information in today's world changes very rapidly. As information flows through the organization, changes that follow initial data entry must then continue to be propagated throughout the system. Enterprises that use MDM strategies make the changes in one system and push the information to all the upstream systems where that information is pertinent. The end result is that MDM solutions reduce the need to do multiple data entry, improve data quality by ensuring consistent application of business rules, and allow changes within an organization to be made very rapidly, thus producing a much-improved set of timely data.

DATA ORGANIZATION AND INTEGRATION

Organizations today have a variety of disparate operational systems, each with its own purpose. These systems spread across an organization like a spider web. Each system maintains some piece of information about entities that cross operational systems. For example, information about an organization's vendors may be contained in the accounting system but also in the ERP systems. BI and BPM tools need information from many different systems to gather a complete organizational picture, and trying to gather information across this spider web of systems can sometimes prove very challenging unless there is a central repository that stores key master metadata.

Storing vital business data in a central repository facilitates access to key information from any system within the organization that requires that data. The repository serves as a roadmap, providing details of what data is available and where it is stored. Moreover, if the repository is built correctly, it will also provide any system within the organization that requires information the method needed to access that data.

WHAT TO LOOK FOR IN THIS ISSUE

In this issue, we will discuss several topics of interest for those seeking to implement an MDM solution for the first time or looking to extend existing MDM solutions in order to improve data integration and data quality within their organization. Each of the authors has attempted to define and move forward with his or her concept of master data management, ranging from the theoretical "solution" to practical advice for implementation. The topics covered should provide some extremely useful insights into the MDM culture and will acquaint the reader with the issues, arguments, and views surrounding master data management.

In our first article, Cutter Senior Consultant Larissa Moss outlines a bit of the history and some of the fallacies associated with MDM. She states that the true focus of MDM is an organization's biggest asset, its data. Moss goes on to lay out the requirements for best managing that data and discusses how to use MDM as a critical part of that process. As the article amply demonstrates, this entails significantly more than simply buying and implementing a software tool. Moss writes, "All too often, [previous] data integration initiatives put too much emphasis on technology and not enough focus on basic information management principles, such as data governance, enterprise information management, enterprise data modeling, data administration, and master metadata management." She addresses each of these essential MDM disciplines in turn, ending with a discussion of the roles and responsibilities required to successfully deploy an MDM strategy.

In our next article, Mike Dayton makes a very strong case for using MDM as the foundation upon which an organization can build its EPM environment. He begins the article with an automotive metaphor, likening an EPM system to a car's speedometer. When a car owner changes the size of her car's tires, the speedometer will need to be recalibrated, lest the driver find herself going too fast or too slow. Similarly, if a company does not "recalibrate" its EPM systems to reflect changing business information, its executives will be making critical business decisions based on faulty data.

Unfortunately, recalibration is no trivial task, because as Dayton explains, "For many companies today, the process of updating master data is a manual one.... Not only is this manual process costly and inefficient, it is prone to human error and creates a lag between the time a change is actually made to the business and when that change is reflected in reporting and EPM systems." Enter MDM, which automates the process of updating master data across multiple applications, thus saving costs and improving the quality -- and timeliness -- of business information. Dayton discusses three "entry points" companies can use to begin practicing MDM and concludes by making the case for a strategic MDM system that uses service-oriented architecture (SOA) "to transcend the functional and system boundaries present in today's MDM systems."

Next, Scott Ambler proposes a number of agile strategies for implementing MDM. There are several reasons for taking such an approach, he argues, but the most compelling one has to be that "the traditional data management track record is poor" while "the agile track record is pretty good" -- a claim he backs up with persuasive statistics.

Some of Ambler's recommendations will doubtless be familiar to proponents of agile software development, but he is quick to show their particular relevance to the world of data management. Take, for example, "work in an evolutionary manner." Ambler contends that this practice (which enables development teams to adapt to changing project requirements so they can deliver the highest-value software at any given time) is even more critical in MDM efforts. Why? Because, as he observes, "You simply can't do all of the requisite legacy analysis and metadata collection up front without it changing underneath you before you can make it available." Acquisitions and partnerships, a changing competitive landscape, and simple human error mean that data definitions will have to change over time. Ambler demonstrates how an iterative approach to master data definition, along with the other agile practices he advocates, will increase your MDM initiative's chances of success.

In our next article, Mark Fung-A-Fat of the Massachusetts Medical Society (MMS) takes on the critical challenge of the "single version of the truth" and explains why organizations face difficulties when they try to impose it. He differentiates between the "ideal" and "real-world" scenarios that exist as a result of ever-changing business environments. Part of the data gap between ideal and real is due to the fact that every organization implementing MDM must review all major data entities (groups or elements) from all source and consumer systems. This inevitably leads to the identification of data with multiple definitions. Traditional implementations attempt to reduce the various definitions down to one "official" definition. This is often a lengthy, politically driven process that threatens the success of the MDM effort.

MMS has taken another approach. Fung-A-Fat notes that each department is allowed to maintain its definition of, for example, a sale, "while in the background the IT group has added an extra descriptor column to handle the various definitions of a sale as the data element flows between departments." This tactic allows each department to use the definition that makes sense in its context yet still provides the "single" definition management requires.

We conclude this issue with an article by Aparna Joshi of Infosys, who explores data governance as it relates to an MDM solution. Joshi discusses the components within an organization that make up the core elements of MDM and what is required in order to successfully implement MDM across the enterprise. She suggests a unified approach to MDM data governance based on four dimensions of MDM: business processes, BI components, technology, and people (on both the IT and business sides). Creating an MDM solution requires discipline and governance, and the article discusses the individual contributors and how the organization benefits from a unified team approach.

We're confident that this issue will provide you with a broad range of MDM definitions and implementation options. Our authors will tell you why an enterprise needs MDM, offer alternate approaches for implementing MDM, explain how MDM interfaces with EPM and other BI tools, discuss some of the data issues that arise as a result of using and maintaining an MDM solution, and provide a practical view of an MDM implementation. Most importantly, they will give you insight into the disparate issues surrounding master data management so you can determine the best MDM course for your own organization.

ABOUT THE AUTHORS

Al Moreno is cofounder and coprincipal of Sinecon, a business intelligence consultancy specializing in data integration for BI/DW solution architecture design. He has more than 20 years of data warehouse and business intelligence experience and has implemented many large-scale solutions in both the US and European markets. Mr. Moreno can be reached at amoreno@sinecon-llc.com.

Greg Mancuso is, with Al Moreno, cofounder and coprincipal of Sinecon. Prior to founding Sinecon in 2003, Mr. Mancuso was responsible for managing the DW solutions and data integration services group at Hyperion. He has been published in DM Review, is a columnist for DM Review Online, has coauthored pieces for Cutter Consortium, and speaks at industry conferences in the US and Europe. Mr. Mancuso can be reached at gmancuso@sinecon-llc.com.