Reference and Master Data Management for Data Professionals with Paul Grobler

Executive Summary

This webinar covers a variety of topics related to Master Data Management (MDM) such as survivorship in Data Management, implementation of MDM in a hospital group, party modelling, Data Management architecture, and more. Paul Grobler discusses the importance of reference models in data modelling, organisational consistency and governance, and the challenges of building a Master Data System with SAP. The webinar highlights the multifaceted application of reference models and Data Management, digital identification, and business party information.

Webinar Details

Title: Reference and Master Data Management for Data Professionals with Paul Grobler
Date: 2021-04-15
Presenter: Paul Grobler
Meetup Group: African Data Management Community
Write-up Author: Howard Diesel

Technical Content on Master Data Management (MDM)

Paul Grobler introduces Master Data Management (MDM), a system that primarily focuses on identity management by determining whether two entities are the same. MDM is geared towards professionals such as MDR/MDM architects, technical team members, or power users. In this context, a fictional character named Thandi Sithole illustrates the challenge of identity resolution when two records have similar but not identical information. The identity resolution process involves standardising, cleansing, and merging data to determine if the records refer to the same entity.

Figure 1 Webinar Info

Figure 2 Customer Information

Figure 3 A viable Source of Truth

Figure 4 Cleansing the Record

Survivorship in Data Management

Survivorship is crucial in Data Management, particularly when merging records from multiple sources. It involves identifying the most reliable source for specific data elements, such as addresses and email addresses, when there is overlapping information. After merging records, the data can be enriched by linking it to other systems to establish a single source of truth. This process helps discover additional information about a person or record, including connections to related individuals or locations. Effective survivorship and Data Management are vital for improving customer experience and eliminating discrepancies in financial statements. Master Data Management (MDM) is a fundamental aspect of survivorship, but it is not necessarily glamorous and is often compared to plumbing, which is essential for overall functioning.

Figure 5 Merged Record

Figure 6 Merged Record and Single Source of Truth

Figure 7 Relating to other Information

Figure 8 MDM in Context

Master Data Management

Master Data Management (MDM) is a process that enables good analytics, better decision-making, and reporting. It involves managing Master data, which is different from the usage of Master data and is usually done for compliance, operational efficiency, or better analytics. Informatica’s system is considered good at incorporating transactions and interactions into MDM for better insights. Modern technology enhances the classic MDM process by adding interactions and transactions, allowing for the discovery of relationship graphs, attitudes, sentiments, and actions while maintaining good Master Data Management.

Figure 9 A Unified View and Governance of Master Data is Key

Figure 10 Informatica Customer Insights

Figure 11 Case Study Mediclinic

Implementation of Master Data Management in a Hospital Group

Paul has been working on the project for about eight years and has tackled various business problems using MDM concepts. The hospital group’s first use case was implementing a standard classification system (e-class) for international procurement. They also implemented financial MDM, doctor’s list, Enterprise Reference Data, and identity and access management. Tibco EBX was used to implement various apps effectively within the organisation. The main challenge was standardising processes, classifications, and Data Management across the international hospital group’s operations. Another case study involved MediClinic in South Africa, where MDM solutions were used to manage doctors’ facilities, qualifications, specialities, accreditations, and marketing.

Figure 12 Our Data Management Journey

Master Data Management and Healthcare

Doctors work in different ways in different countries, such as hospital employees or having their own practice. The HR, legal, and ethical perspectives on healthcare workers vary between countries. In South Africa, Paul shares, MediClinic aims to ensure doctors know about their facilities and have updated information on qualifications, specialities, and accreditations. However, marketing was identified as an issue in MediClinic’s approach. It was addressed using the party model for Master Data Management (MDM) solutions design, which involves obtaining, curating, and sharing Master data related to people, places, or things.

Figure 13 “Challenges”

Figure 14 “Lay the Cornerstone to get Value from Data!”

Data Management and MDM Implementations

MDM involves three main steps: ensuring no duplicates, encapsulating various Data Management tasks, and addressing the ecosystem. It integrates different Data Management principles, practices, and knowledge areas, inherently considers data quality and integration, and references data and architecture modelling. Data governance is sometimes implemented as a step towards MDM. Becoming an MDM specialist requires experience and knowledge in various areas of Data Management. Interns pulled into MDM are exposed to many learning experiences, making it a valuable entry point into the field. There are three main data-sharing architectures: registry-shared architecture, centralised model, and distributed model. The registry-shared architecture involves the MDM system serving as an index to other record systems, directing users to the actual data source. It is relatively easy to implement in theory but can lead to complex data retrieval processes.

Figure 15 MDM Eco-system

Figure 16 Data Sharing Architecture – Registry and Transaction Hub

Data Management Architecture

Service-oriented architecture philosophy emphasises the centralisation of services and pulling things together. In this context, there are three types of architectures: the registry, which is a decentralised architecture; the transactional hub architecture, which is a centralised architecture; and the hybrid approach, which involves consolidating Master Data into the Master Data Management system. The system of record manages its Master Data but is consolidated into the Master Data Management system. Smaller data-sharing hubs can serve different applications, all managed by the Master Data Management system. A Data Management suite software package can evolve from an MDM architecture to become more of a hub and a system of record for specific data aspects.

Figure 17 Data Sharing Architecture

Store Management App for Retail Customers

Paul discusses a store management app designed for retail customers. He mentions registry hubs and data-sharing architectures, Neil Gage’s comments on the maturity levels of capabilities impacting the MDM journey, and the need for investment and a longer view of MDM initiatives. Paul suggests calling MDM something else to overcome challenges and highlights the importance of a clear use case and business problem to solve during MDM implementation.

Project Approach and Data Stewardship Model

MDM can be approached differently depending on the organisation’s needs and structure. The domain-based approach involves building the MDM project around establishing Master data for a specific domain, such as customer, employee, product, or financials. It requires a mature organisation with clear business definitions and divisions. The functional/departmental approach involves implementing MDM by looking at it through departmental plans. In contrast, the process-oriented approach is more suitable for process-driven businesses and focuses on identifying and controlling the scope of what is being done within each process. Finally, the system-based approach involves implementing MDM based on the systems in place, focusing on aspects of Master data crucial for system functionality.

Figure 18 Approach One Subject Area/ Domain

Figure 19 Approach Two Functional Area/ Department

Figure 20 Approach Three Process Driven

Master Data Management (MDM) and Party Modelling

MDM is essential for managing computer systems in organisations, especially insurance companies and finance institutions. The five basic approaches to running an MDM project are domain, project-based, introducing MDM into the organisation, establishing technology stack and teams, building practice and communities, and integrating MDM into the business. Party modelling is crucial in managing customer and employee data, and Len Silverston’s books from 2001, the Data Model Resource Book, remain relevant and useful for understanding party modelling and MDM architecture.

Figure 21 Approach Four System Based

Figure 22 Approach Five Project Based

Figure 23 Party Modeling

Party Relationship Model

The Party Relationship Model is important for managing customer and employee data. A Party can be an individual, organisation, franchise, or bot. Contact details for different parties may be stored separately within a franchise. Some parties, such as a supplier or company, can have individual and organisational characteristics. Bots may have key performance indicators and performance metrics. Parties are always connected to other parties through transient and temporary relationships, such as employment or customer agreements. Implementing a party relationship model can depend on the specific organisation, with possibilities including many-to-many relationships using a resolving entity like affiliation. MDM is essential for managing computer systems, especially in insurance companies and finance institutions. Party modelling is crucial in MDM architecture, and Len Silverston’s books from 2001 are still useful for understanding party modelling and MDM architecture.

Figure 24 Party Domain Conceptual Model

Figure 25 Archimate Example Healthcare

Modelling Relationships Between Parties in Business

In business, it is essential to differentiate between account customers and loyalty customers based on affiliations. The design of relationships between parties can adapt based on how you model them, and relationships can involve different roles that need to be modelled differently. Archi-mate can be used to aid conceptual thinking and data modelling. For instance, in a medical administration model, parties playing specific roles have relationships with other parties through their roles. Filtering out specific roles, such as healthcare provider roles, is crucial, and there are different types of roles within healthcare providers, including facilities, practices, suppliers, and professionals. Modelling relationships between parties helps not paint oneself easily into a corner when roles may change or expand.

Figure 26 In Context of a Business Scenario

Multi-Role Concept and Business Glossary

Party modelling is essential to business scenario mapping and identification of roles involved. Modelling accuracy can be achieved using a well-defined business glossary, which helps understand the actual business definitions and descriptions and links entities accordingly. Visual tools like Visual Paradigm can build up a glossary from models, which can then be published to a data governance platform or wiki. The modelling process is done to clarify business roles and thought processes, making the design process easier. However, CRM systems are criticised for oversimplifying people and their roles. Therefore, it is crucial to use party modelling to allow individuals or organisations to play more than one role in various contexts without limiting themselves. Additionally, data governance and Master data rely heavily on a well-defined glossary, and there is a relationship between conceptual modelling and glossaries.

Role Master and Technology Stacks in Business Scenarios

In a business scenario where a patient receives treatment from a healthcare provider in a relationship with a supplier, it is crucial to have a clear understanding of roles to ensure that data-supported scenarios can be narrated and worked out efficiently. Without this understanding, there may be questions and the need to re-analyse or re-interview people, which can cause pressure on the technical team to deliver the project on time. For such scenarios, a good MDM tool should be used to allow for easier modelling and merging. Additionally, an information reference model is necessary to segregate customer and market supply, partner products and services and lay the foundation for the logical model.

Figure 27 Role Master Example

Figure 28 “This is what we used…”

Figure 29 “Designed for Collaboration”

Multifaceted Application of Reference Models and Data Management

Paul discusses a reference model developed as a guide for different industries, including medical aid. While highlighting the importance of adapting these models to specific business contexts, he emphasises the usefulness of the models in creating solutions. With experience in a reserve bank setting, Paul encourages using reference models to create solutions. The reference model was praised for its ability to form different solutions while promoting a unified platform for all applications. Paul also mentions that Chip’s current Informatica is the preferred technology for building multiple solutions.

Figure 30 Making Master Data Personal

Figure 31 Master Data Generic Development Steps

Master Data System Development and Challenges

A Master data system is a complex platform of processes, modelling, and architectures that involves various components beyond just a database. It poses significant challenges, including harmonising domains from different systems, reconciling different terminologies and glossaries, and establishing a golden profile for data harmonisation. The development steps of a Master data system include identifying the system of record, obtaining a complete set of attributes, and determining the identity information for data matching.

Master Data Management and Governance

MDM is a complex platform that involves various components beyond just a database. Its development steps include identifying the system of record, obtaining a complete set of attributes, and determining the identity information for data matching. The MDM process involves establishing the authoritative source, modelling the data, managing quality, understanding matching and loading, and maintaining the golden profile. Collisions and survivorship must be managed when a system of record changes and data tries to re-enter the system. Data space versioning is crucial for maintaining the golden profile. After establishing the golden profile, data can be published to subscribers. Paul shares that the next step involves integrating the data within a business intelligence or dimensional system. Governance and stewardship are essential for managing reference and Master data as shared resources. Governance processes bring compliance and legal stakeholders together to understand consumers and risks. A key aspect of governance is the ability to review and consider new requirements and changes to MDM systems to facilitate the sharing and usage of data. Governance involves establishing principles, rules, and guidelines to guide the population of 360 views and centralised datasets.

Figure 32 Reference and Master Data Governance

Figure 33 Reference and Master Data Governance Two

Figure 34 “Metrics”

Metrics and Community of Practice in Master Data Management

MDM is crucial for enabling business processes and should not be undertaken solely for Data Management purposes. Metrics such as data quality, change management, integration, ingestion, coverage, ownership, and sharing volume and usage are used to measure MDM’s effectiveness. Establishing communities of practice in organisations with diverse business units can be an alternative to centralised control, as it enables the sharing of knowledge and conversion of implicit knowledge to tacit knowledge in data governance and MDM. A practice definition mind map is useful for building MDM policies, procedures, and standards, including references, responsibility, ownership, stewardship, and business alignment.

Figure 35 Digital Habits

Figure 36 Data Management Socialization

Figure 37 Reference & Master Data Practice Definition Mindmap

Building a Master Data System with SAP

Reno, an attendee, is collaborating with SAP to develop a Master Data System called MDG, which will serve as a central point for all data to be consolidated. The model presented includes creating a digital ID for business partners, incorporating individual and company information attributes, which will feed downstream systems like SAP HANA (High-Performance Analytic Appliance), BI, and target applications. The system aims to use a “party” concept as a central point to attach information, including identity information, electronic communication, and names, for employees and business partners while also using a golden profile to allow for flexibility and avoid having a single record.

Figure 39 MDM: Data Process & Application Consolidation

Figure 40 Party Identity Management Conceptual Model

Digital Identification and Business Party Information

Companies and individuals can be identified using various numbers, such as VAT, LEI, and registration numbers. BankServ aims to provide a digital ID for all individuals and companies in South Africa. The World Bank has allocated LEIs for companies in the global market. Individuals may have multiple identification records, such as passport numbers, driver’s licenses, or other accepted numbers. Different systems of record can be used to identify individuals in various ways. To identify authoritative sources for business party information, trustworthy systems must be evaluated to choose the best authority. The process involves building Master data, consolidating business partner information, and distributing it to different applications. The party model can be initially confusing for businesses, but they will get used to it over time.

Abstraction in Data Modelling

The party model is a complex data model that requires careful consideration to avoid overcomplicating or oversimplifying. Abstraction at a conceptual level can be powerful but also dangerous, as it provides flexibility but can cause pain for customers if not simplified for easy access. Therefore, using the party construct and simplifying the design is important when abstracting. The goal is to simplify database access for businesspeople and provide a simplified view of the data. Experience is valuable in understanding and implementing the party model, and it comes with different levels of abstraction that should be considered to ensure a successful implementation.

Business Strategies and Approaches

Adopting a system-based approach can benefit an organisation in the long run, but it may only initially benefit a few people. To illustrate, addressing a specific pain point in procurement led to improvements that could be applied in other areas. However, aligning the approach with the organisation’s culture is essential to gain support and avoid challenges. Data virtualisation and industry reference models, like IA, are helpful tools for simplifying complex models, presenting data in a useful way, and determining data structures and processes.

Importance of Reference Models in Data Modelling

The claims process of an insurer was redesigned to introduce a standardised flow and party model. However, the party model’s implementation led to inefficiency and unproductivity due to its numerous fields. Using reference models helps understand subject areas but should not replace critical thinking. The insurance company pruned the model to accommodate actual business requirements better, resulting in a leaner and more effective system. Finally, data modelling scorecards, including enterprise alignment, are essential for defining and aligning data models within an organisation.

Data Management and Industry Models

Large financial services and telecommunications companies require strict adherence to industry models, which generate numerous databases. These models are used to assess alignment with enterprise models and resolve conflicts around terminology and can be utilised to develop ontologies and business glossaries. However, differing approaches to Data Management in large organisations can lead to siloed decision-making, making it crucial to have robust governance and program oversight to ensure alignment with enterprise goals.

Lessons Learned in Master Data Management

Master Data Management is crucial for large enterprises, particularly in financial services and telecommunications industries, where strict adherence to industry models generates numerous databases. Consistency and control within a group, enforcing the use of a Master data system for data sharing, and aligning with enterprise goals are essential for robust governance and oversight. The strategy and business case determine the justification for the system, and it’s important to select battles and ensure the right support in the organisation. Context is also crucial, and finding a burning platform to dictate the approach to Data Management can lead to better outcomes. In summary, it’s important to have a strong business case, enforce the use of a Master data system for consistency, select battles carefully, and ensure alignment with enterprise goals.

Organisational Consistency and Governance

Achieving consistency across an organisation requires recognising the broader enterprise need and conducting good stakeholder reviews. However, building a business case for the enterprise need can be challenging, leading to a focus on specific business areas first. Governance and architecture are crucial in managing and solving enterprise problems, with solution architects working together to ensure access to the right resources. Despite annoying and difficult-to-fix problems, people may find ways to work around them if the business case is not compelling. Organisational styles vary, with some emphasising collaboration and others focusing on a singular focus but covering multiple domains. Culture can affect how people think about their business processes and domains, sometimes leading them to prioritise the system over other factors.

Master Data vs. Reference Data

Master and Reference Data are two types of information essential for businesses. Master data includes information about a business’s operations, such as what it sells, who it sells to, employees, suppliers, and raw materials or services it obtains. On the other hand, Reference Data provides more specific details about the products being sold, such as different types of coffee, and other contextual information like currencies used in transactions. Together, these two types of data help to define and describe the core aspects of a business’s operations, providing a comprehensive understanding of its activities.

Reference Data and Informatica

Reference Data and Master Data are two similar yet distinct concepts that can confuse, particularly in the insurance industry. Reference data is essentially a list or lookup table that can be found either inside or outside an organisation, and it includes both internal and external sources, such as standard country codes or product categories. Regarding big implementations like those in banks and large companies, Informatica and TIBCO are the top technologies used. For instance, Informatica, including companies like Sasol and MultiChoice, is widely used in South Africa. A seven-step process based on a Gartner model is recommended to design an MDM solution or any data system.

Management Solution and Tools

A successful management solution involves seven building blocks, with tools and technology being only one aspect. The key components of a management solution include actual requirements, vision alignment with business, data governance style, roles and responsibilities, and information architecture landscape. When choosing tools and technology, it is important to understand what is needed before selecting the right technology. MDM systems are crucial and have features that can expedite processes. Paul closes with the recommendation to determine needs before choosing a specific MDM system, as many options are available from top players like IBM and Microsoft.