TDWI | Training & Research | Business Intelligence, Analytics, Big Data, Data Warehousing

Practices and Processes

Defining Master Data Management

We break down MDM by looking at the processes, practices, architecture components, and goals of the discipline, and offer recommendations that will enhance your MDM success.

• By Philip Russom, Ph.D.
• November 24, 2008

Master data management (MDM) is difficult to define because its real-world applications are so diverse. For example, the most common starting points for MDM are ERP applications and data warehouses. The requirements for these two contexts are radically different, so their practices are, too. As another example, most MDM solutions focus on a particular data domain, the most popular being data about customers, financials, or products. Again, diverse domains have differing requirements. Finally, an MDM solution architecture usually has a system of record at its core, but the system can vary tremendously.

Before we attempt a definition of master data management, we need to step back and define some of the processes, practices, architecture components, and goals of MDM. We’ll discuss these MDM subsets in the order you might encounter them while implementing MDM.

Focus on an MDM practice and starting point

Depending on where and how it’s practiced, MDM solutions fall into three broad categories. Operational MDM is built into and/or used to integrate operational applications for ERP, CRM, financials, and so on. Analytic MDM is typically practiced in support of a data warehouse and business intelligence platforms. Enterprise MDM is far broader in scope than operational and analytic MDM and, in fact, may encompass them. Operational and analytic MDM are typical starting points, whereas most organizations grow into enterprise MDM over time.

Define core business entities

Sometimes called reference data, master data consist of facts that define a business entity -- facts that may be used to model one or more definitions or views of an entity. Entity definitions based on master data provide business consistency and data integrity when multiple IT systems across an organization (or beyond) identify the same entity differently.

In an Internet-based survey TDWI conducted in mid-2006, the business entity most often defined in master data is the customer (74%), followed by financials (56%) and products (54%). Other entities include business partners (49%), employees (45%), locations (41%), sales contacts (25%), and physical assets (21%). Since entities usually exist in hierarchies and other relationships, users may employ tools for data modeling, business modeling, and process modeling.

Establish a central system of record or hub

-- System of record. Common across the many approaches to MDM is the creation (or selection) of a system of record (sometimes called a trusted source). The point is to establish a central, authenticated master copy from which entity definitions (and perhaps physical data, too) are propagated among all IT systems integrated via the MDM solution.

-- MDM hubs, master files, and application databases. The system of record can take many forms. Many users build a central database (like a data warehouse or operational data store) as a hub through which master data, metadata, and physical data are synchronized. And some hubs are simply master files or master tables that collect and collate records. Sometimes a pre-existing application (typically for ERP or CRM) has the needed definitions already, so it’s selected as the system of record and the basis for entity modeling elsewhere.

Use integration techniques to acquire, improve, and share master data

-- Master data integration. Regardless of the technology approach, the goal of the system of record is to provide a central mechanism for collecting and sharing consistent definitions, usually across otherwise unrelated IT systems. Obviously, this requires technologies and best practices for system integration, data integration, and application integration. Hence, many technical users consider MDM to be an integration practice, enabled by integration tools and techniques for ETL, EAI, EII, and replication. When the system of record is a hub that connects many diverse systems, multiple integration technologies may be required, including newer ones like Web services and service oriented architecture (SOA).

-- Consistent entity definitions. MDM practices are quite diverse. Regardless of the approach, all MDM solutions share a common goal: consensus-driven definitions of common business entities, such as customers, products, and financials, applied consistently across multiple IT systems and business units.

Definitions of Master Data Management

Now that you’ve seen what MDM does and you know some of its technology and process pieces, we can define MDM in a fairly detailed manner:

MDM is the practice of defining and maintaining consistent definitions of business entities, then sharing them via integration techniques across multiple IT systems within an enterprise and sometimes beyond to partnering companies or customers.

That’s quite verbose, so here is a more succinct definition:

MDM is the practice of acquiring, improving, and sharing master data.

Tips and Recommendations

MDM is about sharing. If you’re not sharing data, you don’t need MDM. If you are, you’ll need to define how applications and databases should represent shared business entities, such as customer, financials, products, and so on. To reach the goal of sharing data, you’ll need to share definitions of data first, plus establish teams, policies, and procedures for sharing.

Enlist business people. For master data to achieve its primary goal—consensus-driven definitions applied consistently -- the consensus must be driven by a cross-functional team of technical and business people. For business entity definitions to be valid and useful, most organizations need business people to be involved in creating them. Furthermore, the way business people handle data through applications should comply with the definitions.

Create your own definition of MDM. Just about every organization has its own definition because MDM is enabled by diverse technologies and varying amounts of business participation. In addition, the number of applications and business units involved varies greatly, and every organization needs to strike its own balance between operational and analytic MDM.

- - -

Editor’s note: Part of this article was drawn from TDWI’s Best Practices Report, Master Data Management: Consensus-Driven Data Definitions for Cross-Application Consistency, by Philip Russom. Read the full report at www.tdwi.org/research/reportseries.