Principal MDM
Components and Capabilities
David Loshin Knowledge Integrity, Inc. www.knowledge-integrity.com
Agenda
Introduction to master data management
The MDM Component Layer Model
MDM Maturity
MDM Functional Services
The MDM Component Layer Model
Identification Management Governance Integration Business Process Management Data Standards Metadata Management Data Quality Data Stewardship Administration/ConfigurationHierarchy Management Identity Management Migration Plan
Record Linkage Merging and Consolidation Identity Search and Resolution
MDM Component Service Layer
Application Integration and Synchronization Service Layer MDM Business Component Layer
Business Rules
Mixing It Up…
Order of review:
1. Identification
2. Business Process Management
3. Management
4. Governance
5. Integration 6. Architecture
Identification
Every object subject to “mastering” is managed using a
unique representation within the master repository
Any time data intended to refer to that object is seen by an
application, its unique representation must be found,
verified, and presented back to the application by the MDM platform
Identification
Record Linkage Merging and Consolidation Identity Search and Resolution
Identity Search and Resolution
David Howard Loshin
Loshin, Howard
Howard David Loshin Howard David LoshinHoward David Loshin
Objective: Provide the services that will seek the matching record in the master index that represents the “queried” object
Record Linkage – Parsing and Standardization
Parsing
Identifying and tagging pieces of each data value within a
semantic context
Standardization
Correcting terms based on defined rules
Assembling components into recognized patterns
Transformation
Rule-based modifications into target canonical representations
Transformation into target format
Loshin, Howard D Howard D Loshin First Howard
Middle D
Merging and Consolidation
Knowledge Integrity, Inc. 301-754-6350
Loshin 301-754-6350 David
Howard
Knowledge Integrity Incorporated 301 754-6350 Lotion
David 1163 Kersey Rd
David Loshin
Knowledge Integrity 301-754-6350
Business Process Management
Business Process Modeling
Business Process Integration
Business Rules
Business Component Layer
Business Process Management MDM Business Component Layer
Business Rules
Mapping to the Business Processes
Business Objectives Business Policy Business Policy Business Policy Business Policy Terms Facts Business Logic Execution Model Application Application Application Application Application ApplicationBusiness Rules
Business Policy
Business rules contribute to the business process
model, and can be isolated and managed as
Business Component Layer
Services reflecting business process needs
“create new customer”
“locate matching products”
“find purchase order”
“remove supplier”
“modify vendor status”
Business layer built on top of business and component
object services
Business process models document the expected ways in
which the business operates
The business process model exposes candidate master data
objects and the components that use them
Business rules traditionally embedded within application
Management
Administration/Configuration Hierarchy Management Identity Management Migration Management Administration/ConfigurationHierarchy Management Identity Management Migration Plan
Management Issues
Configuration, administration, and ongoing maintenance
Identity management: For any object, enough identifying
information must be managed to determine that
A record exists and no more than one record for the object, or
No record exists and one can be created that can be uniquely
distinguished from all others
Hierarchy management – both historical and connectivity
Migration management
Governance
Data Standards Metadata Management Data Quality Data Stewardship Governance Data Standards Metadata Management Data Quality Data StewardshipMaster Object Resolution
Resolution of candidate master data types requires a
compete view of what composes the information architecture
This entails cataloging data sets, their attributes, data
domains, definitions, contexts, and semantics
This view must facilitate the resolution of:
Format at the element level,
Structure at the instance level, and Semantics across all levels
This introduces three challenges:
Collecting and analyzing master metadata
Resolving similarity in structure
Operationalizing Data Governance
Actualization of data governance activities enables:
The identification of explicit and hidden risks associated with
data expectations
The actualization of the implementation of business policy Oversight of the definition of critical data elements
Monitoring and auditing information quality rule compliance
Managing enterprise data ownership and stewardship
Coordination and oversight of enterprise data quality
In general, data governance provides management oversight for organizational observance of different kinds of
Stewardship: Remediation and Manual Intervention
Issues with addressing data quality events:
Immediate remediation of flawed data – does this imply data
correction?
Not all data flaws can be captured via automated processes –
this implies manual reviews
Accuracy may only be measured by comparing values
directly
Carefully integrate manual intervention when necessary in
Integration
Application integration
Synchronization
Component services
Integration MDM Component Service Layer
Business Application Functional Interface Data Business Application Functional Interface Data Wrapper Facade Business Application Wrapper Facade Service Layer
Phase 1 Phase 2 Phase 3
Synchronization and Coherence
Master Repository
EAI/EII
Federated Consolidated
Issues to consider:
• Frequency of updates to master object attributes • Performance impacts
• Bottlenecks • Attribute overlap
Component Service – Object Locate
“Object Locate”
Master Index
Architecture
Master data model
MDM system framework
Service layer architecture
Architecture Master Data Model MDM System Architecture
Master Data Model
Limited universe of common master objects
Party, customer, product, part, supplier, claim, instrument
Universal models may be suitable as starting points
Challenges:
Resolution of metadata in a consistent manner
Creating a model that accommodates all applications properly
CUST First VARCHAR(15) Middle VARCHAR(15) Last VARCHAR(21) Address1 VARCHAR(45) Address2 VARCHAR(45) City VARCHAR(30) State CHAR(2) ZIP CHAR(9) Nightingale-Patterson CUSTOMER FirstName VARCHAR(14) MiddleName VARCHAR(14) Nightingale-Patterso Last VARCHAR(21) LastName VARCHAR(20)
Architecture - Summary
Architecture decisions rely on the requirements identified
during the analysis of:
Business processes
Data requirements
Operational processing requirements
Levels of coherence and synchronization
Governance protocols
Questions?
If you have questions, comments, or suggestions, please
contact me David Loshin 301-754-6350
