Establishing 'Making it Happen' as a 'Formal & Predictable' Discipline

Master Data Management definition- What is MDM-CDI?	Master-Data-Management CDI Architecture Modeling

ENCYCLOPEDIA→ Enterprise Intelligence → - Master Data Management → - Master Data Management- Overview →

Master-Data-Management CDI Objectives components

MDM objectives include Data Quality, Standardization, Single point of reference and high availability. MDM components are centered on integrating master data in MDM-Hub.

Master Data Management- CDI Objectives

We will refer customer MDM as an example. MDM adopts Quality Assurance Methods, Customer Data Searching & Matching, Correction, Augmentation and Enrichment, Data Extraction and Data Transformation (most of the physical extraction and transformation activities are same as we do in Data warehouse) to achieve a high degree of Data Quality, Data Standardization, Consistency and Completeness.

NOTE- Physical Data Extraction and Transformation from source systems and placing it in a central physical MDM repository is one type of MDM architecture (called as transactional or persistent architecture). You can also have 'Registry' MDM-CDI architecture, whereby all the descriptive data lying in the source systems. In Registry style architecture, you will only have the unique identifier fields (also called classification fields) of master data in the Hub. The rest of the fields (called descriptive fields) will stay in the source system.

Data Quality

Data quality has various dimensions and MDM should be able to address all those dimensions.

Data Accuracy: Ensure that Master Data is what it is real-life. A customer address is same as is in real-life.
Data Consistency: There is only one version of truth on the Master.
Data Completeness: Master Data through MDM is most comprehensive source of information on Master data, as it tries to create the super set of information on a specific master record, pulled from various sources. For example Risk Management System and Sales Management system will have different set of data on the same customer. MDM will merge this data to create a comprehensive record.
Data Auditability: MDM will be able to provide an audit trail on the source(s) of master data and the extraction/transformation activities it has gone through.
Data Distinction- No duplicate records (even if they contain different type of data) related to a specific Master Data record.

Standardization

You can achieve most of the Data Quality objectives, without having Data Standards for the master data. For example, in MDM-CDI hub, you can have 100000 customer master records as per one data structure (customer_ID being of 10 alphanumeric characters) and other 100000 as per other data structure (cust_ID being 8 Alphanumeric characters). However, this approach does not make the MDM future-ready and extensible. The important thing is to enforce common standards for the master data.

Some common data standards (including examples) to be ensured are:

Data format and structure
Units of measurement- Age has to be in years, height has to be in inches
Domain value- The age value has to be between 18 and 99 years
Mandatory vs. Null Value rules- Customer address is Mandatory, whereas Telephone can be mandatory

You can refer Data Domain and Data Model controls on the kind of controls and standards, which can be enforced through MDM.

Single point of Reference

Either by centralized, physical MDM repository (called persistent style MDM hub) or by registry model (whereby master data is lying in source systems and the hub contains only the unique identifier field and pointers to that data), there should be a single point of reference for master data. If there are two MDM sources for particular type master data (say customer data lying in two different repositories), it nullifies the purpose.

The Single point of reference has two aspects-

Ability to access data from varied sources (data inflow)
Systems should be able to access data from MDM platform (data outflow)

This is achieved mainly by having open platform and ability to use varied access interfaces protocol.

NOTE- You will not be able to have ALL source systems for a master data (say customer master data) to be placed in an MDM-CDI hub on day1. However, the true objective of MDM is not achieved till you have all the core or major source systems linked to the MDM Hub.

Response Time and Availability

MDM is used extensively real-time, and for operational purposes. Therefore it needs to be available and provide high response time. As you will see in the various architecture styles, the level of availability depends upon the objective you want to achieve through MDM.

Components of MDM- CDI

Data Sources

This is very much like Data Warehouse. MDM picks data from the source systems. Refer Source Systems for a possible list. Data sources can range from robust ERP systems to an excel sheet residing in a desk-top. One will need to go through source system mapping to identify the best source(s) of master data.

Master Data Model and Business Rules

One has to create the standard Data Model for each type of Master Data in MDM. This standard data model should be so designed to absorb the data from different data models being used by different source systems. For example, a standard customer MDM data model should have all possible customer attributes to absorb the varied data models existing in the source system. As you create these data models, one needs to:

Study the data models in the source systems, to understand the type of information contained. Your data model should ideally be able to absorb all the master attributes existing in the source systems. This also gives opportunity to do away with redundant attributes, which are not needed or for which the information is impossible to get.
Look at the needs of the customer data in the organization. This is essentially future driven. Though the data might not be available at this point of time, it will be beneficial to model for it.
Use industry best standards. This helps you to make you MDM more suitable for standard application packages (which you have or you may buy).

Business Processes linked to Master Data

One needs to standardize not only the data models, but also the business processes, which are acquiring, processing and using the master data. This objective is never accomplished in completion, but needs to be maximized. The core reason for data quality issues and lack of data standards is non-standard business processes. Standard business processes form the foundation for data quality. You require following standard business processes as part of MDM:

Master Data acquisition process (customer data acquisition process)
Master Data processing process (The triggers, which bring change in the customer data and how the change is done)

Integration Services

As practitioners of DW would have seen, ETL or integration is most challenging and effort-guzzling phase. The same applies to MDM. However, there is one more demand- the integration in MDM needs to be on real-time basis. Therefore, data recognition, transformation and loading need to be done on real-time (or nearly real-time) basis. This will require messaging, real-time synchronization, real-time cross-referencing, real-time replication etc..., to make it happen.

Data Quality Services

These include Data Searching and Matching, Data Correction/Merging and Augmentation services. These services can be acquired by stand-alone tools or should be integral part of MDM platform.

Transformation Services

This is part of the overall MDM suite, and contains capability to do transformation operations. The transformation operations include data correction services and much more.

Middleware and Tiered architecture

An enterprise MDM solution will generally worked with a tiered architecture, whereby it uses front-end user interface layer, middleware application server layer and database layer.

EAI

An MDM platform can be well-enabled by SOA and also typical EAI systems using messaging services through an enterprise service bus.

CDI Hub

CDI hub is the central master data reference point to be accessed by the served applications. Like a data warehouse, it contains:

Staging area, where all the extracted data lands, and all the transformation and massaging of data happens
Loaded area, where final authoritative data is placed.

As mentioned before, a CDI hub can follow the following architectures:

Physical integrated repository (persistent style): the data is physically extracted and transformed and loaded into the Hub.
Registry style- the descriptive data stays in the source system and the Hub contains only the unique identifier fields for Master records and pointers to the data records in the source system.
Hybrid: a combination of persistent and registry style.

Metadata

MDM platform should be having a Metadata repository, which can be either specific to MDM platform or part of enterprise level metadata. This metadata repository will contain many details including: