june 19, 2012 · 2012. 6. 26. · golden record back office implementation customer information...

June 19, 2012

SCALING & PERFORMANCE SCOPING MDM ARCHITECTURES WORKSHOP

Global Data Competency Adam J. White – President

3

© 2012 Global Data Competency

Agenda

Implementing MDM Twice to Support the Organization

Ensuring MDM Supports Transactions

The MDM ID Can be Leveraged for Transactions

Transactions have SOA Architecture Behavior

The Data Model Supports Transactions

Represented MDM Data Models Lack Functionality

The Ability to Support Hierarchies and Relationships

Unable to Support Oracle or SQL/Server Functionality

Middleware – ETL vs Transactional

Questions

4


Current MDM Implementation Issues

MDM Implementations Are represented to support the Enterprise

• But do not meet Enterprise Requirements • Are not extensible • Are not scalable

Enterprise MDM

5



MDM Implementations are Executed Twice MDM is licensed and the initial project is

executed A year later it is attempted to expand it to

support additional applications • It is discovered that it lacks the ability to

support the enterprise going forward • A different MDM vendor is implemented • Or the same product is implemented and has

two places in the enterprise architecture

MDM Implemented Twice

6



Implementing MDM is very expensive Implementing 2x is a waste of corporate resources A single implementation with correct configuration

will support the organization

MDM Implemented Twice

7


What is MDM

Mastering Data Taking the same information from multiple

sources Normalizing that information

Master Data Management

8


What is MDM

Customer Data Integration (CDI) aka (MDM) Product Information Management (PIM) Business Rules Engine (such as Blaze) Data Governance

MDM Components

9


What is MDM

CDI Mastering Customer Information

• Information pertaining to People • Information pertaining to Organizations

Customer Data Integration

10


What is MDM

PIM Mastering Product Information

• Utilizes attributes pertaining to products • Color • Size • SKU • Weight

Product Management Information

11


What is MDM

Business Rules Engine • Contains the Business Rules Product

• Controls Product Definition • Manages Product Components (Items) and their

relationship to Product

Customer • Rules supporting Hierarchy • Rules supporting Customer Relationships

Customer and Product • Customer and Product Relationships

Business Rules Engine

12


MDM End State

Master Data Management

Objectives • Competitive Advantage Ability to Add

Products Ability to Change

Products • In Hours, not Months

13


What is Driving MDM

Government Reporting Requirements Heath Industry

• Socialization of US Medical Practices • Expenditures on Health Care

• Doctors • Medical Services • Medical Products

Not Driven by Business Needs

USA

14


MDM Implementation Styles

Transactional / Source of Record Golden Record / Best Record Hybrid (Transactional / Best Record) Registry

Four Main Implementation Styles

15


Transactional

Front end implementation Customer information

captured at time of entry Applications receive their

customer info from CDI Customer information may

or may not reside in applications

Mature state

Transactional / Source of Record Attributes

16


Golden Record

Back office implementation Customer information

provided by the applications

Can be used to support business operations

Mainly used to support Marketing and Analytics

Customer information resides in applications

Golden Record from trusted sources

Golden Record / Best Record Attributes

17


Hybrid

Mainly an implementation model

Both a front end and back office implementation

Begin with Transactional supporting one application

Golden / Best Record utilized until other applications move to Transactional

Hybrid (Transactional and Best Record) Attributes

18


Registry

Back office implementation

Only pointers to customer information are stored

Customer information, after identified, is used from the application where the information resides

Limited or no customer information resides in the Registry

Registry Attributes

19


Batch vs Real Time MDM Processing

MDM Configured Batch Supports IDL Supports Daily Batch

Processing Doesn’t Support

Transactional Processing Initially Configured to Support

Best Record Approach reduces scope Additional functionality comes

in subsequent phases

MDM Configured Batch

20



Decision to go RealTime Configuration effort is high Batch must be regression

tested RealTime requirements are

different than batch

MDM Configured Batch

21



• Supporting Transactional • Fine Tune for IDL • Supports Daily Batch • Supports Daily Transactions

• Call Center • Single Point of Entry

MDM Configured Transactional

22



So, we’ve discussed MDM Batch or Transactional The Same Issues and Behavior Apply to Middleware

Middleware

23



• IDL are architected for ETL • Daily Batch uses the same

interfaces

ETL Middleware

24



• Daily Transactions go through the Transactional Middleware

Transactional Middleware

25



Interfaces are Built Twice

26



• Expensive to build the interface twice to support the same data

• Maintenance now supports two types of interfaces • Or one set (the IDL interfaces) is throw away

Duplicate Interfaces ETL and Transactional

27



• Architect Interfaces Once • Supports Batch • Supports Transactional

• Limitation is not the

middleware • But the consuming

application (MDM)

Transactional Middleware

28


MDM 360

Components Customer Information (MDM) Products and / or Services the customer has with your

organization (Legacy Systems) Cross Sell / Up Sell Opportunities (CRM) Customer Quality / Customer Status (CRM)

Utilized at Customer Touch Points Call Centers Customer Web Sites Sales Agents Branches

Ultimate Goal of MDM

29


Role of SOA Architecture with MDM

30


MDM Data Models

Industry Specific Customer Data Doesn’t Exist It is a selling feature

• Forced upon the vendors by the business Your MDM should support all of your businesses

• Banking • Insurance • Membership • Medical

Industry Specific MDM Data Model

31


MDM Data Models

● Implement an MDM Data Model ● That supports both People Customers and

Organizations ● People are a customer type ● And Organizations are a customer type

● Implementing Two MDM Data Models ● One with People ● One with Organizations

● Results in configuration issues for Relationships and Hierarchies

Person Model vs Business Model

32


MDM Data Models

● Ensure that the MDM Data Model Supports Intersecting Tables

Intersecting Tables

33


MDM Data Models

● This functionality lets you see: ● Addresses of a

Customer ● Customers at an

Address ● Otherwise you’ll only

be able to see Customers at an Address

Intersecting Tables

34


MDM Data Modle

● Vendor Data Model ●Must configure to support your functionality

● Do not crowbar your data into their model ● Loss of functionality

MDM Data Model

35


Implementation of the MDM ID (Customer ID)

Proper Implementation of MDM ID

MDM Keys

36



Proper Leverage of MDM ID for Change

MDM Keys

37



Incorrect Leverage of MDM ID for Change

MDM Keys

38


CRM VS MDM vs Application Info

Prospects ● MDM or CRM

● Customer? ● Service?

CRM VS MDM

39


SOA Architecture Support

● Whole Row vs Changed Data ● Ability to Support SOA Architecture

●Just the data that has changed ●Not all of the original posting and the changed

data

Implementation

40


MDM Data Models

The Conversation with the Vendor Q - Does your product support multiple addresses A – Yes

Q – How many addresses? A – 3 addresses. We find Companies don’t need more.

Q – If I want to add an address what do I need to do? A – It’s easy, you just add another address on the row.

WRONG ANSWER You want to store addresses by type You want your table to go deep not horizontal Addresses by type allows you to add addresses without

changing your data model AND you have no limitation on the number of address you

can store for a Customer

Example Enterprise Data Modeling

41


Critical Implementation Path

● Determine where customer data resides in your organization ● Conduct an application inventory ● Focus on core business applications

● Cull from this list the core business applications that will strategically reside in MDM

Implementation

42



● For each of these applications update the data dictionary ● Only customer information needs to be updated

● Define your Customer Data Model ● Define the Customer Services that support your Customer

Data Model ● Reduce Scope to a single application (Roadmap remaining

Applications)

Implementation

43



● Determine the Solution Architecture ● Use Cases / Process Flows ● Integration Specifications ● Select the MDM Vendor

● Do this after you have your requirements in place!!!! ● Select your SI – the vendor to implement your solution

Implementation

44



● Determine Matching Rules ● Configuration Specifications (Hierarchies, etc) ● Vendor Data Model Changes ● Data Steward Specifications

Implementation

45


Summary

● Critical path is knowing your requirements

●BEFORE picking the product to support your business

● The vendor will represent that they have the functionality, but it may not support your business or your requirements

46


Questions

Questions

Contact Info

Adam J. White Global Data Competency Phone 925-788-5295 [email protected]

mailto:[email protected]

june 19, 2012 · 2012. 6. 26. · golden record back office implementation customer information...

Documents