Close

Master Data Management

Master Data Management (MDM) provides processes for collecting, aggregating, matching, consolidating, quality-assuring, persisting and distributing critical business data throughout an organization to ensure a common understanding, consistency, accuracy and control of those critical business data. At a basic level, master data management seeks to ensure that an organization does not use multiple (potentially inconsistent) versions of the same master data in different parts of the organization. Critical business data can be products, processes, customers or services on the one hand and reference data with a set of permissible values on the other. Technically, MDM uses a central master file as a common point of reference.

There are several ways in which master data may be collated (compared) and distributed to other systems. This includes:

  • Data Consolidation. The process of capturing master data from multiple sources and integrating into a single hub (Operational Data Store) for replication the same masterdata through-out the organization.
  • Data Federation. The process of providing a single virtual view of master data from one or more sources to one or more destination systems.
  • Data Propagation. The process of copying master data from one system to another, typically through point-to-point interfaces (not preferred).

Master Data Management is strongly related to Product Data Management (PDM) and Product Information Management (PIM). PDM is about product information within a company. PIM is about distributing up-to-date product information to external customers, resellers and partners. Example: InRiver PIM.

Another example is SyncSort Customer360. This tool is used to get a trusted single view of the customer and can be used both on-premises and in the cloud. This MDM contains:

  • Kernel information about the customer, such as name, address, etc.
  • References to account and transactional data stored in an ODS or maintained in other systems.
  • Interaction data from various channels such as call center, phone, website, social platforms, webchat, email and mobile. Note that omni-channel service and marketing is only possible of this functionality is included.

Microsoft currently has no on-prem or cloud offering for MDM. SQL Server On Prem contains Master Data Services (MDS) and Data Quality Services (DQS), which offer part of the solution.

In the cloud, Microsoft recommends to use the product of its partner Profisee. Profisee is a Microsoft Partner focused on delivering enterprise MDM capabilities through its Master Data Management platform. Leveraging the Microsoft technology stack, Profisee is able to deliver Microsoft MDM solutions on-premises, in the Azure cloud, or in a consumption model via the Azure Marketplace (VM offering). Out-of-the-box adapters for Dynamics CRM and Dynamics AX accelerate deployment and time-to-value for Microsoft-centric organizations, delivering a single view of Customer and Product data across the enterprise.

I always used to advise clients to make a single application responsible for maintaining a certain entity. As an example, Dynamics CRM can be given the sole responsibility for maintaining customer data. You can even take this one step further. In an ideal world, entity data are not only maintained in one place, but also stored in only one place. That means for example, that applications must always call a CRM Customer service when they need access to customer data. But unfortunately, the world is not always ideal. Let’s say I have a portal application with very high performance demands. In that case, performance can be optimized by duplicating customer data to the portal application. This can lead to data inconsistency, but data dupplication may be inevitable when trying to fulfill customer requirements. That’s the reason I’m talking about MDM in this post. MDM is a distinct approach that must be contrasted to the “one entity in one box” approach.

I came across a MDM solution for customer data at one of my clients. Here we have a central system labeled the Central Data Hub (CDH). This system has one golden record (master) and a sibling record per source system. Customer changes in all primary systems are sent to CDH. The customer data in CDH are updated to reflect the latest changes. The specific customernumber is stored per primary system. CDH also holds a revision number for the last update. Periodically a data synchronization process is called that checks the latest revision in the primary systems against the latest revision in CDH. Any revision updates are sent to each primary system to keep customer data of all primary systems in sync. Below is an example of a datarecord you can get from CDH.

{
  "revision": 1557458,
  "records": [
    {
      "source": "sysa",
      "key": "123456",
      "type": "organization",
      ...
     },
      "golden_record": [
        {
          "source": "system",
          "key": "0000000001284761"
        }
      ],
      "sibling": [
        {
          "source": "sysa",
          "key": "123456"
        },
        {
          "source": "sysb",
          "key": "BBB123"
        }
      ],
    }
  ]
}