Transcription

California Enterprise Architecture FrameworkMaster Data Management (MDM) ReferenceArchitecture (RA)Version 1.0 FinalJanuary 2, 2014

Master Data Management (MDM) Reference Architecture (RA)This Page is Intentionally Left BlankVersion 1.0 FinaliiJanuary 2, 2014

Master Data Management (MDM) Reference Architecture (RA)TABLE OF CONTENTS12Introduction . 11.1Purpose . 11.2Limitations. 11.3Intended Users . 11.4Document Organization . 21.5Future Directions . 2Master Data Management Overview . 32.1Definitions . 32.2Business Benefits . 62.3MDM Usage Scenarios . 72.4MDM Implementation Styles . 82.4.12.4.22.4.32.4.42.5Key Capabilities of MDM Solution . 92.5.12.5.22.5.32.64Master Data and Metadata-Related Capabilities. 9Integration- and Interoperability-related Capabilities . 10Supporting Capabilities . 10Components of MDM Solution . 102.6.12.6.22.6.32.6.42.6.52.6.63Registry Style. 8Consolidation Style. 8Transaction Style . 9Coexistence Style. 9Master Data Repositories . 11Master Data Management Services . 11MDM Analysis and Discovery Services . 12Enterprise Information Integration (EII). 13MDM Presentation Services . 14MDM Integration Services . 15MDM Reference Architecture Description . 163.1MDM RA Conceptual View . 163.2MDM RA Logical View . 183.3MDM RA Deployment View . 21MDM Implementation Guidelines . 22Version 1.0 FinaliiiJanuary 2, 2014

Master Data Management (MDM) Reference Architecture (RA)4.1MDM Implementation Lessons . 224.2A Step-wise Approach for Introducing MDM. 235Glossary . 256References and Bibliography . 267Document History . 27Version 1.0 FinalivJanuary 2, 2014

Master Data Management (MDM) Reference Architecture (RA)LIST OF FIGURESFigure 2-1 Master Data and Other Types of Organizational Data . 3Figure 2-2 Enterprise Context of Master Data Fragmentation and Duplication . 4Figure 2-3 Organizational and Technical Facets of MDM . 5Figure 2-4 MDM Components Overview . 10Figure 2-5 Master Data Repositories in MDM RA . 11Figure 2-6 Master Data Management Services in MDM RA . 12Figure 2-7 Analysis and Discovery Services In MDM RA . 13Figure 2-8 Enterprise Information Integration in MDM and BI RA . 14Figure 2-9 Presentation in MDM RA . 15Figure 2-10 Integration Services in MDM RA . 15Figure 3-1 MDM Reference Architecture – Conceptual View. 17Figure 3-2 Service and Component Interactions when Accessing Master Data . 19Version 1.0 FinalvJanuary 2, 2014

Master Data Management (MDM) Reference Architecture (RA)LIST OF TABLESTable 2-1 Aspects of Quality in Master Data . 6Table 3-1 Accessing Master Data, Application’s Perspective . 20Table 4-1 Common MDM Implementation Lessons . 22Table 4-2 Step-wise Approach for Introducing MDM . 23Table 7-1 Document History . 27Version 1.0 FinalviJanuary 2, 2014

Master Data Management (MDM) Reference Architecture (RA)This Page is Intentionally Left BlankVersion 1.0 FinalviiJanuary 2, 2014

Master Data Management (MDM) Reference Architecture (RA)1IntroductionOf all important types of data in the enterprise, there is a type of data that is more important forthe organization than others. This group of data is called “Master Data”, and is widely believedto be the most important data assets owned by an organization. It is this Master Data on whichenterprise business transactions are executed. Enterprise business analytics often involveanalysis of other data in relation to this Master Data. Master Data is also involved in informationsharing within an organization and with partners and is crucial to interoperability.Today’s organizations are faced with ever growing abundance of data. The data comes fromvarious sources (external and internal to the organization, involving potentially multiple systemsof record); unfortunately, the data often are of uncertain quality. Not being able to deal withabundant yet scattered and uncertain data is likely to lead to major operational challenges andfaulty decisions.Master Data Management (abbreviated as “MDM”) is an effort to tame problems related toMaster Data in an organization in a reliable and repeatable way, and to provide for clean andauthoritative source of Master Data. This document presents a Reference Architecture (RA) foran SOA-based enterprise-level architectural approach to MDM, as part of CEAF 2.0.1.1PurposeThe Master Data Management (MDM) Reference Architecture (RA) document providesguidelines and options for making architectural decisions when implementing MDM solutions.The objectives for the document include the following: 1.2To introduce key terms and distinctions relevant for the topicTo provide inputs for creating or evaluating architectures for MDM from enterpriseperspectiveTo identify building blocks (architectural layers, services, components) for integratingelements of an MDM solutionTo communicate the key architectural decisions relevant for creating or evaluating MDMsolutionsTo communicate opportunities for solution and/or platform sharing at agency, cross-agencyand/or state levelsLimitationsThe document focuses on MDM and related concepts at the enterprise architectural level in thecontext of CEAF 2.0. It is not intended to serve as the MDM-related product guide, or a guide fororganizational aspects of MDM solutions. It is also not intended as an endorsement of anyproduct. Its overall perspective remains CEAF-centric.1.3Intended UsersThe primary intended users of this document are Enterprise Architecture practitioners and otherarchitects that contribute to enterprise architecture. This broad group includes architects fromother domains/disciplines such as Security, Application, Information, Business, Technology,Version 1.0 Final1January 2, 2014

Master Data Management (MDM) Reference Architecture (RA)Infrastructure, and Solution Architects. It is also beneficial to Managers, at senior or operationallevels, who are involved with MDM or related areas, such as Enterprise Application Integration,Business Intelligence, SOA, and similar areas.1.4Document OrganizationThe MDM Reference Architecture documentation is organized as follows: 1.5Section “MDM Overview” provides background for the MDM RA by introducing descriptionsand definitions of MDM, discusses the main usage scenario types found in MDMimplementations, and identifies architectural components for respective usage scenarios.The section “MDM Reference Architecture Description” elaborates RA for MDM using thefollowing architectural views:o The Conceptual View (in the subsection ”MDM RA Conceptual View”) introduces thenecessary capabilities for an MDM architecture and how they are supported byArchitectural Building Blocks (ABBs)o The Logical View (in the subsection “MDM RA Logical View”) describes key interactionsamong Layers and/or ABBs to realize functionality specific to MDM systemso The Deployment View (in the subsection “MDM RA Deployment View”) focuses onsystem topologies and deployment facets of MDM in the state.The section “Glossary” provides description of the terms and abbreviations used in thedocumentThe section “References” lists publications used for preparation of the document. Note thatliterals in square brackets that appear in the document (e.g., [A], [5], [d]) are references topublications listed in this sectionFuture DirectionsFuture evolution of the document includes the following steps: Addition of existing best-practice-based realizations of the MDM RAIdentification and elaboration of solution sharing opportunitiesFormulation of implementation guidelines for MDM RAVersion 1.0 Final2January 2, 2014

Master Data Management (MDM) Reference Architecture (RA)2Master Data Management OverviewThis section provides a description of Master Data Management (MDM), including clarificationof key terms and concepts. It identifies MDM’s intended business benefits and summarizes itsmain usage scenarios. A set of key capabilities of an MDM solution are identified and keycomponents of the solution are described at a high level.2.1DefinitionsIn the context of the enterprise, data is understood as raw information required for everydayoperations and for adequate decision making. Broadly, this information is about the domain inwhich the enterprise operates.Master Data (further abbreviated as “MD”) can be defined as data “referring to core businessentities an organization uses repeatedly across many business processes and systems” [5]. MD“captures the key things that all parts of an organization must agree on, both in meaning and inusage” [4]. Master data includes the business objects, definitions, classification, and terminologythat constitute business information; consequently, master data forms the basis for businessprocesses.MD is sometimes referred to as “the single source of truth” – that is, the authoritative source orthe “system of record”; given that function, MD is critical business information that containsdetails of internal and external business entities involved in business transactions and businessanalytics of the enterprise. MD also explains the context within which an organization does itsbusiness and holds the business rules.The following figure shows Master Data among other types of organizational data:Organizational DataMetadataInformationalOperationalDomain DataMaster DataReferenceDataTransactional DataAnalytical DataFigure 2-1 Master Data and Other Types of Organizational DataVersion 1.0 Final3January 2, 2014

Master Data Management (MDM) Reference Architecture (RA)In the above figure, “Metadata” are the data about other data, typically about Domain Data –such as database catalogs or XML schemas. The area of Domain Data contains TransactionalData, analytical data, and Master Data. Master Data are different from Transactional Data in anumber of respects; the following list main differences: Master Data objects are independent of other objects (for example, a customer isindependent of a sale, but not vice versa), whereas transactional data contains dependentdata objectsMaster Data have low volatility compared to Transactional Data in terms of their schema –the structure of master data objects rarely changes over their lifetime, and the structure ofTransactional Data can change significantly depending on the transactions they representMaster Data have constant or limited changes in the volume, at least compared toTransactional Data, with quickly growing volumes.In addition to above characteristics, specific data entities can serve as Master Data dependingon the needs of a specific domain. However, there are commonalities that can be pointed out.As a rule of thumb, Master Data involve the following types of data objects: Data related to Parties of the relationships in the enterprise – such as customers, citizens,suppliers, or employeesData related to Things that are present in the relationships with the Parties, such as services,products, assets, and similar. Things can form hierarchies and groupingsData related to Locations involved in Parties and Things – such as places, sites, regions, etc.Data representing cross-domain relationships (for example, between an employee, alocation and a service to be rendered).The following figure depicts a typical context of multiple data sources, data definitions, qualityrules and governance, which typically create fundamental challenges with respect to masterdata maintenance and its lApplicationsOtherApplicationsMaster DataMaster DataMaster DataMaster DataMaster DataMaster tionalTransactionalTransactionalAnalytical DataAnalytical DataAnalytical DataAnalytical DataAnalytical DataAnalytical BusinessPartnerSupplierProductAccountFigure 2-2 Enterprise Context of Master Data Fragmentation and DuplicationAs suggested in the above figure, today’s organizations operate using high volumes of datacoming from various sources, ranging from mainframe applications, client-server systems toVersion 1.0 Final4January 2, 2014

Master Data Management (MDM) Reference Architecture (RA)web and on-line applications. In functioning of many of those systems, the overlap in using corebusiness data is unavoidable, and if unchecked it leads to multiple formats and/or versions ofcore business data objects. It is not uncommon for a single data entity (such as customer) to bepresent in a dozen or more of separate systems.Master Data Management (MDM) is a collection of best data management practices thatorchestrate key stakeholders, participants, and business clients in incorporating the businessapplications, information management methods, and data management tools to implement thepolicies, procedures, services, and infrastructure to support the capture, integration, andsubsequent shared use of accurate, timely, consistent, and complete master data. [1]The first main task for MDM is to address data quality problems, typically caused by fragmentedsystem and application environments. In turn, data quality problems pose challenges forbusiness, not only on the operational level, but also on the strategic level, where analytics onreliable data are required to make right decisions.In addition to Master Data quality, other areas that need to be taken into account whenintroducing an MDM solution to the organization include Master Data structure and processes,Master Data systems architecture, and Masters Data governance. The following figureschematically shows these areas:MDM Technical AspectsMaster Data StructureMaster DataSystems ArchitectureMaster Data QualityMaster DataProcessesMaster DataGovernanceMDM Organizational AspectsFigure 2-3 Organizational and Technical Facets of MDMAs shown in the above figure, both organizational and technical aspects of MDM contribute to asuccessful implementation. The central place in the facets of MDM belongs to quality of MasterData. The following table summarizes attributes of quality of Master Data [3].Version 1.0 Final5January 2, 2014

Master Data Management (MDM) Reference Architecture (RA)Table 2-1 Aspects of Quality in Master DataAttributeDescriptionAccuracyData are accurate when a stored piece of information is conformant withits actual valueCompletenessData are complete when it contains all relevant entities, attributes, andvalues required to represent the real-life master constructs such ascustomers, products, or accountsConsistencyData are consistent when it has the same values for the same entitiesregardless of the location or manner of their retrieval.TimelinessData are timely if the propagation of changes to data values acr