Protecting and securing master data in a production environment can be achieved through various

methods. Encryption ciphers, static masking, trust model technologies, and dynamic masking are all

techniques used to safeguard data. However, usage agreements, while important for data

governance and legal compliance, are not a technical method for securing data in the same way that

the other options are. Usage agreements define the terms under which data can be accessed and

used, but they do not directly protect the data itself.

Reference:

DAMA-DMBOK2 Guide: Chapter 11 – Data Security Management

"Data Masking: A Key Component of a Secure Data Management Strategy" by Anjali Kaushik

A global identifier is used to link multiple

to the same entity across different systems or

datasets. Here’s why:

Purpose of Global Identifier:

Unique Identification: Provides a unique identifier that can be used to recognize the same entity

across disparate systems and datasets.

Consistency: Ensures that different references or records pointing to the same entity are consistently

identified and managed.

Linking Equivalent Reference:

Equivalent Reference: Global identifiers link references that are equivalent, meaning they represent

the same real-world entity even if the data is stored differently in various systems.

Entity Resolution: Helps in resolving different records to a single entity, ensuring data consistency

and accuracy.

Example:

Customer Records: A customer might be listed in different systems (CRM, billing, support) with

slightly different details. A global identifier links these records to recognize them as the same

customer.

Reference:

Data Management Body of Knowledge (DMBOK), Chapter 7: Master Data Management

DAMA International, "The DAMA Guide to the Data Management Body of Knowledge (DMBOK)"

An Operational Level Agreement (OLA) is used for detailing collaboration principles, escalation, and

dispute resolution processes between MDM and its data suppliers. Here’s why:

Purpose of an OLA:

Collaboration Principles: Defines how MDM teams and data suppliers will collaborate, including

roles, responsibilities, and communication protocols.

Escalation Processes: Outlines the steps for escalating issues when standard resolution mechanisms

are insufficient, ensuring timely and effective problem resolution.

Dispute Resolution: Specifies methods for resolving disputes between parties, fostering a

cooperative and constructive working relationship.

Other Documents:

Business Requirements Document: Defines business needs and requirements but doesn’t typically

focus on operational collaboration.

Metadata Catalog: Describes metadata and data dictionaries, not collaboration principles.

Warranty: Provides guarantees on products or services, irrelevant to operational collaboration.

Operations Run Book: Details operational procedures and workflows, not specifically focused on

collaboration and dispute resolution.

Reference:

Data Management Body of Knowledge (DMBOK), Chapter 8: Data Quality Management

DAMA International, "The DAMA Guide to the Data Management Body of Knowledge (DMBOK)"

The Reference Data Change Request Process typically involves the following sub-processes:

Receive Change Request:

Initiation: The process begins with the receipt of a change request, formally logged and

acknowledged.

Identify Stakeholder:

Stakeholder Identification: Identifying all relevant stakeholders who need to be involved or informed

about the change.

Identify Impact:

Impact Analysis: Assessing the potential impact of the requested change on existing systems,

processes, and data.

Decide and Communicate:

Decision Making: Reviewing the change request, making a decision, and communicating the

outcome to stakeholders.

Excluded Step - Monitor Database Change: While monitoring database changes is important for

overall data management, it is not typically part of the specific change request process for reference

data. This step pertains more to ongoing operational monitoring rather than the change request

workflow.

Reference:

Data Management Body of Knowledge (DMBOK), Chapter 6: Data Development & Maintenance

DAMA International, "The DAMA Guide to the Data Management Body of Knowledge (DMBOK)"

Planned control activities are not considered master data. Here’s why:

Master Data Examples:

Categories and Lists: Master data typically includes lists and categorizations that are used repeatedly

across multiple business processes and systems.

Examples: Product categories, account codes, country codes, and currency codes, which are

relatively stable and broadly used.

Planned Control Activities:

Process-Specific: Planned control activities pertain to specific actions and checks within business

processes, often linked to operational or transactional data.

Not Repeated Data: They are not reused or referenced as a stable entity across different systems.

Reference:

Data Management Body of Knowledge (DMBOK), Chapter 7: Master Data Management

DAMA International, "The DAMA Guide to the Data Management Body of Knowledge (DMBOK)"

Master data metadata provides crucial information about the master data, offering context and

supporting its management and use within the organization.

Who, What, and Where Context:

Metadata provides descriptive information about the master data, including details about who

created or modified the data, what the data represents, and where it is used.

This contextual information is essential for understanding the origins, purpose, and usage of the

master data.

Includes a Sample of Content:

While metadata might include examples or samples of the data, this is not its primary purpose.

Improving Fit-for-Purpose Choices:

Metadata helps improve the application and governance of master data by providing context and

supporting data management decisions.

Securing the Content:

Metadata itself is not primarily focused on security, though it can support data governance and

access control processes.

Technical or Business Perspectives:

Metadata can encompass both technical and business perspectives, providing a holistic view of the

data's context and usage.

Reference:

DAMA-DMBOK (Data Management Body of Knowledge) Framework

CDMP (Certified Data Management Professional) Exam Study Materials

Implementing Master Data Management (MDM) involves several challenges, but the disparity

between data sources is often the most significant.

Disparity Between Sources:

Different systems and applications often store data in varied formats, structures, and standards,

leading to inconsistencies and conflicts.

Data integration from disparate sources requires extensive data cleansing, normalization, and

harmonization to create a single, unified view of master data entities.

Data Quality Issues:

Variability in data quality across sources can further complicate the integration process. Inconsistent

or inaccurate data must be identified and corrected.

Defining Requirements for Master Data:

While defining requirements is crucial, it is typically a manageable step through collaboration with

business and technical stakeholders.

DBA Cooperation:

Getting Database Administrators (DBAs) to share table structures can pose challenges, but it is not as

critical as dealing with disparate data sources.

Complex Queries and Indexes:

While important for performance optimization, complex queries and indexing issues are more

technical hurdles that can be resolved with appropriate database management practices.

Reference:

DAMA-DMBOK (Data Management Body of Knowledge) Framework

CDMP (Certified Data Management Professional) Exam Study Materials

Master Data Management (MDM) lifecycle management encompasses the processes and practices

involved in managing master data throughout its lifecycle, from creation to retirement. It ensures

that master data remains accurate, consistent, and usable.

Reconciling and Consolidating Data:

This process involves merging data from multiple sources to create a single, unified view of each

master data entity.

It ensures that duplicate records are identified and consolidated, maintaining data consistency.

Identifying Multiple Instances of the Same Entity:

This involves detecting and resolving duplicate records to ensure that each master data entity is

uniquely represented.

Tools and algorithms are used to identify potential duplicates based on matching criteria.

Identifying Improperly Matched or Merged Instances of Data:

This step involves reviewing and correcting any errors that occurred during the matching or merging

process.

Ensures that data integrity is maintained and that merged records accurately represent the

underlying entities.

Maintaining Cross-Reference to Enable Information Integration:

Cross-

link related data entities across different systems, enabling seamless information

integration.

This ensures that data can be consistently accessed and used across the organization.

Establishing Recovery and Backup Rules (NOT part of MDM Lifecycle Management):

While important for overall data management, recovery and backup rules pertain more to data

protection and disaster recovery rather than the specific processes of MDM lifecycle management.

Reference:

DAMA-DMBOK (Data Management Body of Knowledge) Framework

CDMP (Certified Data Management Professional) Exam Study Materials

Registry style MDM involves maintaining a central registry that stores

to master data

while allowing the actual data to remain in the source systems. This approach requires technologies

that support data integration and real-time access without physically moving the data.

JSON Mapping:

JSON mapping is useful for data exchange but does not specifically support the registry style MDM

approach.

ETL Toolset:

ETL (Extract, Transform, Load) tools are typically used for batch data processing and integration,

which may not align with the real-time data access requirements of a registry style MDM.

Columnar Database:

Columnar databases are optimized for analytical queries but are not specifically designed for

supporting registry style MDM.

Complex Queries:

While complex queries can be part of the data access strategy, they are not a comprehensive solution

for registry style MDM.

Data Virtualization:

Data virtualization provides a unified view of data from multiple sources without physically moving

the data. It supports real-time data access and integration, making it well-suited for registry style

MDM.

It enables organizations to access and manage master data across different systems while

maintaining a central registry for reference.

Reference:

DAMA-DMBOK (Data Management Body of Knowledge) Framework

CDMP (Certified Data Management Professional) Exam Study Materials

Master and Reference Data are forms of Data Architecture. Here’s why:

Data Architecture Definition:

Structure and Design: Data architecture involves the structure and design of data systems, including

how data is organized, stored, and accessed.

Components: Encompasses various components, including data models, data management

processes, and data governance frameworks.

Role of Master and Reference Data:

Core Components: Master and Reference Data are integral components of an organization’s data

architecture, providing foundational data elements used across multiple systems and processes.

Organization and Integration: They play a critical role in organizing and integrating data, ensuring

consistency and accuracy.

Reference:

Data Management Body of Knowledge (DMBOK), Chapter 7: Master Data Management

DAMA International, "The DAMA Guide to the Data Management Body of Knowledge (DMBOK)"