In Part 1, Six Sigma and MDM, published earlier in Enterprise Data Journal, I discussed applying Six Sigma methodology and principles to Master Data Management (MDM) programs. Although we can never expect to achieve Six Sigma perfection in our master data we can still benefit from using the rigorous methodology and many of the tools like metrics, SIPOC and fishbone cause/effect diagrams to make our MDM projects successful.
In this Part 2, Framework for Integrating MDM into Enterprise Architecture (EA), I will examine a framework for MDM that includes architecture, process and governance tasks. As part of this framework I build a case for integrating MDM into your overall Enterprise Architecture. This article goes on to examine the processes of implementing MDM and concludes with some concrete suggestions for implementing master data governance.
Figure 1 shows the minimum required components and services of MDM. These were analyzed in Part 1 but these critical MDM components are worth repeating.
The second layer, Unique ID Service, Attribute Management of Facts, Hierarchy Management and Data Quality Service are all implemented in the Master Data Registry. The MDM Registry gives the business the flexibility of comparing, cleansing and de-duplicating different sources of master records as the business becomes ready to deal with downstream issues. As multiple sources are merged the registry becomes the new hub for those downstream systems.
Governance: Master Data Governance is the authority that decides how master data is maintained, what it contains, how long it is kept and how changes are authorized and audited.
Consistent Unique ID Service: Each MDM system assigns a common Master ID that is mapped to every source master record. This cross-reference is maintained in the Master Data Registry.
Attribute Management of Factual Master Data: The consolidated master contains factual information that is common across all sources in the enterprise, including data values, relationships and hierarchies.
Hierarchy Management: MDM includes the capability to manage hierarchies or structures of master data; for example customers and their sub-units and sites and products and their component BOM’s.
Data Quality Service: MDM includes the capability of measuring and improving the quality of master data specified by the data stewards and owners.
Master Data Registry: The MDM Registry is where the Common Master ID is assigned and maintained. The registry should have the capability to compare, merge & de-duplicate master records in order to normalize redundant data records.
Data Stewardship: Stewards are appointed by the owners of each master data source; they have knowledge of the current source data and the ability to recommend how to transform the source into the master data format.
Business Rules: Master Data Stewards establish common business rules for updating and maintaining master data in each domain.
Data Management Workflow: Master Data Stewards define a Workflow for creating and updating their master data according to the Business Rules for that domain.
Process Integration Services: Master data for each domain is integrated into the business processes of each business unit using a common workflow subscription.
Master Data Integration Services: Each Master Data domain exposes common data integration services for creating, updating and synchronizing master data for that domain with other operational and analytic systems.
Framework for Integrating MDM into EA
Integrating Master Data Management into an overall Enterprise Architecture consists of work in three broad areas:
Although many of the tasks in each of these areas are often interrelated you could begin planning your MDM program using these three parallel threads.
MDM has implications for your Enterprise Architecture because your MDM data models should be incorporated into your Enterprise data model.
First we position the MDM data architecture into the overall Enterprise Architecture.
Figure 2 shows how high level domain models should be integrated into the EA CRUD matrix.
While the typical EA data models may be at the conceptual (entity only) level it makes sense to take your MDM domain data models down to the logical level, showing business attributes and definitions. Master data is so central to the business that showing fully attributed data models and their definitions will help implementation and adoption.
Figure 3 shows a logical view of Customer based on Oracle’s Trading Community Architecture (TCA) and the Party entity.
Next, take the high level MDM data and process models and fit them into the appropriate places in the EA data and service function models. Your EA data, application and process models should reflect the same high level conceptual structures as your MDM models. Likewise, your MDM models should take advantage of your EA models to help with scope and integration project planning.
As you drill further down in your data and application models you should designate which systems will maintain your Master data and which systems will be slaves.
Your MDM program should be a set of repeatable processes that can be reused for subsequent domains. In other words if you start with the Customer domain you should design repeatable MDM project tasks that can be reapplied to remaining domains like Product and Vendor/Supplier. The archetypical MDM processes are:
1. Develop plans to create Data Hubs for all master data domains within scope such as Customer, Product, Vendor/Supplier. If you are doing multiple domains at the same time each domain will have its own project plan.
2. Leverage Master Data Hubs for maintaining and propagating consistent identifiers and clean master attributes across operational and analytic applications.
3. Implement Business Process Management and workflow to ensure data integrity between operational systems <=> Master Data Hubs <=> Analytic application.
4. Leverage Data Quality metrics to ensure the effectiveness and continuous improvement of the MDM process.
The first step in MDM governance is to assess the current master domain control organizations. Look into the business organization and identify the business processes that create new master data records in the current environment. For example, the Accounts Receivables department probably creates new customer records after receiving a request from sales & marketing. They may have a defined work flow that involves routing the request to the Legal Dept before they create new Customers. This entire work flow needs to be documented. If there are multiple points where master records can be created, the appropriate business organizations must be brought together to create a new shared business process.
Once the new business process has been defined data governance must be established to manage the discovery and removal of duplicate master records. The Data Stewards on the Governance Board will define appropriate Data Quality metrics that can be automated by the MDM DQ service. Finally, the Governance Board must establish an escalation procedure for resolving conflicts when they occur.
Figure 4 shows a typical Data Governance organization structure.
It should be obvious that separate Data Governance organizations need to be setup for each MDM domain; one for Customer, another for Product, etc. This is because the business processes for each MDM domain are very different. The AR department doesn’t need to work on Product MDM de-duplication rules; likewise, the Product Configuration Management business people don’t need to participate in discussions around merging Customer master records.
Duplicate governance organizations need to be setup for each domain because the business personnel at the Strategic, Tactical and Operations level will be different in Customer Data Governance than the business people in Product Data Governance. However, the IT Technology Team should be shared across multiple data governance organizations to leverage MDM technical expertise and promote consistent MDM practice.
Conclusions for Applying Six Sigma Principles to MDM
Integrating Master Data Management into Enterprise Architecture helps to institutionalize your MDM program. If you already have an established Enterprise Architecture group it should be relatively straightforward to adopt this integration approach. If you don’t have an EA group this is your change to jump start your effort to build EA.
While Master Data may never approach Six Sigma quality due to our inherent tolerance for error, we can still benefit from using Six Sigma methodologies and tools to manage our MDM projects and programs. Data Governance establishes and enforces the data quality thresholds that are necessary to manage data as a strategic asset.
Callaos, N. & Callaos B. (2002).Toward a Systemic Notion of Information: Practical Consequences. Informing Science. Vol 5, No 1
LeBlanc, Andrew. (2008). Enterprise Data Management with SAP NetWeaver MDM. Boston, MA: SAP Press [ISBN 978-1-59229-115-1]
Oracle Trading Community Architecture. User Guide Release 11i Part No. B12310-02 August, 2004.
ABOUT THE AUTHOR
Joe Danielewicz spent 28 years at various business units of Motorola in IT data architecture and enterprise architecture. Mr. Danielewicz is now an independent consultant in Enterprise Architecture and ERP Integration Planning.