How to identify master data in a multi-domain MDM program

Identifying domains

The concept of master data and how this data is identified and managed needs to be consistent across a company's systems and processes.

Although certain domains such as Customer, Product, Locations and Employee are the most commonly referenced, the domain types and mix can vary due to a company's industry orientation and business model. They may also be influenced by system architecture, such as if a company has implemented an integrated business suite of applications that has an underlying data architecture and predefined data models.

Here are some industry-oriented examples of how domains are often defined:

• Manufacturing domains: Customers, Product, Suppliers, Materials, Items, Locations
• Healthcare domains: Members, Providers, Products, Claims, Clinical, Actuarial
• Financial services domains: Customers, Accounts, Products, Locations, Actuarial
• Education domains: Students, Faculty, Locations, Materials, Courses

Identifying master data

Regardless of how the domains are determined, the concept of master data and how this data is identified and managed needs to be consistent across a company's systems and processes. Master data should be clearly defined and distinguished from or related to other types of data, such as reference data and transactional data. Here are definitions for these types of data:

• Master data: Data representing key data entities critical to a company operations and analytics because of how it interacts and provides context to transactional data.
• Transactional data: Data associated with or resulting from specific business transactions.
• Reference data: Data typically represented by code set values used to classify or categorize other types of data, such as master data and transactional data.
• Metadata: Descriptive information about data entities and elements such as the definition, type, structure, lineage, usage, changes and so on.

While each of these types of data will be used together for operational and analytical purposes, and all may be in the scope of a data governance charter, the source control and quality management of the master data will have different priorities, requirements, challenges and practices than will the other data types. MDM is the application of discipline and control over master data to achieve a consistent, trusted, and shared representation of the master data. Therefore, reference data and metadata associated with a master data element should also be included in the MDM scope if any control or consistency problems with the reference data or metadata data will affect the integrity of the master data element. For example, many code sets act as reference data to qualify a master data element or provide a list of values expected to be populated in the master data field. In such cases, the reference data associated with the master data element should be in the MDM scope.

The MDM and data governance programs work together to focus on managing and controlling the elements, definitions and business processes that influence the creation and change of master data. Clearly recognizing and defining this are perhaps the most challenging and foundational actions within a MDM program. MDM and data governance efforts can be and often are initiated with objectives to pull the business entities and definitions together, but this is a much more complicated process that requires attention from many resources to ensure a coordinated approach. If the MDM Program Management Office (PMO) and data governance are not prepared with sufficient resources and support to help pull this information together and coordinate the analysis process, the progress and maturity of the MDM program will be impeded until this work can be completed. The MDM PMO scope and its relationship with data governance are discussed in more detail in Chapter 4.

To fully evaluate the master data and the master data characteristics within a domain, the following artifacts should be inventoried, gathered and reviewed for each domain:

• Data models: Conceptual, logical and physical models that organize and document business concepts, data entities and data elements and the relationships between them
• Data dictionary: A listing of the data elements, definitions and other metadata information associated with a data model
• Functional architecture: Depicts how systems and processes interact within each other within a functional scope
• Source to target mapping: Describes the data element mapping between a target system and source system
• Data lifecycle: Depicts the flow of data across application and process areas from data creation to retirement
• CRUD analysis: Indicates where permissions to create, read, update and delete have been assigned to various groups for certain types of data

All of these artifacts are extremely valuable for evaluating the scope, consistency and use of master data. Unfortunately, not all these artifacts are likely to be available or in a complete form for each data domain in scope. The data governance or MDM program management office should consider opportunities to assist with the initiation or completion of any of these artifacts where needed.

These artifacts should also be the basis for defining key metrics that will demonstrate the value and progress for how MDM practices can drive the alignment and consistency of the master data across these areas and artifacts. For example, an initial analysis of these types of artifacts and data assets is likely to reveal many gaps or conflicts with master data definitions, alignment, lineage, usage and control. From this type of assessment, current state baselines can be determined, leading to quality improvement objectives that can be implemented and tracked as ongoing quality metrics for each domain. This type of data asset inventory and analysis by domain should also be leveraged to help scope the data governance, data quality management and metadata management practices needed for the MDM plan and approach for each domain.