Enterprise Master Data Architecture
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Enterprise Master Data Architecture

on

  • 2,963 views

This presentation elaborates on design decisions and design options when it comes to designing the master data architecture. ...

This presentation elaborates on design decisions and design options when it comes to designing the master data architecture.

The presentation was given at the 16th Americas Conference on Information Systems (AMCIS 2010) in Lima, Peru.

Statistics

Views

Total Views
2,963
Views on SlideShare
2,957
Embed Views
6

Actions

Likes
3
Downloads
163
Comments
0

2 Embeds 6

http://www.linkedin.com 5
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Enterprise Master Data Architecture Presentation Transcript

  • 1. Enterprise Master Data ArchitectureDesign Decisions and OptionsAlexander Schmidt, Boris OttoLima, August 13, 2010Institute of Information ManagementChair of Prof. Dr. Hubert Österle
  • 2. Motivation: Increasing Attention for Master Data on Enterprise Level Process Industry: Fulfillment of REACH provisions (EU guideline regulating registration, evaluation, authorization, and restriction of chemical substances) forces companies to gather data and give evidence of properties of their chemical substances across the entire supply chain Insurance Companies: With fierce competition in a highly saturated market, need to be able to view their customers from a 360° perspective, i.e. all customer master data, contract data, and performance data must be available in a consistent, up-to- date, and complete form across the company Procurement: In order to be able to conduct a comprehensive spend analysis in multi-divisional companies, the central procurement department has to have access to consistent supplier master data and product group codes. Also, ownerships structures of suppliers and their affiliates must be transparent so that purchasing volumes of all subsidiaries can be taken into account in an evaluation? What design decisions do companies have to make with regard to master data management in general and, more specifically, with regard to their enterprise master data architecture and which design options do they have? © CC CDQ2 – Lima, 13.08.2010 / 2
  • 3. Defining Master Data  Represents the business objects which are agreed on and shared across the enterprise, i.e. the “core business data entities”Master Data  Typical master data is material and product master data, supplier and customer master data, and master data regarding employees and assets [Dreibelbis et al. 2008, p. 35], [Smith and McKeen 2008, pp. 65-66] Data Master Data Inventory Data Transaction Data Low reference to time High reference to time High reference to time Low change frequency High change frequency Relatively low change frequency Constant in volume Relatively constant in Increasing volume volume Existentially independent Existentially dependent Existentially dependent  referenced e.g. by  reference master data  reference master data transaction data © CC CDQ2 – Lima, 13.08.2010 / 3
  • 4. Components of an Enterprise Master Data Architecture Enterprise Master Data Architecture Application Conceptual Master Architecture for Data Model Master Data Application Data Flows Systems [Periasamy and Feeny 1997, p. 198], [Pienimäki 2005, p. 39] © CC CDQ2 – Lima, 13.08.2010 / 4
  • 5. Literature Review: Appropriateness of Existing Architecture Frameworks Zachman TOGAF EAP FEAF EAC DAMA Enterprise master data architecture focus q q q q q qCoverage of all enterprise master data architecture q q q q q q componentsReference to master data q q q q q q Specification of relevant design decisions q q q q q q Identification of concrete design options q q q q q qLegend: TOGAF.… The Open Group Architecture Framework EAC…….. Enterprise Architecture Cube EAP…….. Enterprise Architecture Planning DAMA…… Data Management Association FEAF…….Federal Enterprise Architecture Framework © CC CDQ2 – Lima, 13.08.2010 / 5
  • 6. Case A (DB Netz): Inventory of Infrastructure Assets (Tracks, Tunnelsetc.) Infrastruktur planen Trassen/Anlagen vermarkten Betrieb Simulations- Konzern- EVU- Statistik SNB IBL Dienstplan verfahren anwendungen Anwendungen LeiPro-A Infrastruktur beschreiben Projektbau Konzern- TPS APS TPN ESF + sonst. Anw. anwendungen IZ-Plan Spurplan Gesamt- Trassen- Druckliste angebot bestellung NFLS Neigung 1 VZG ZuGe Fahrplan- GFD-Z Betris LST- statistiken Systeme Verzeichnis d. zulässigen GFD-I Geschw. Buchfahrplan EBuLa RUT-K BuMV BIP StreDa La DB GIS La- Buchfahrplan Csv-Dateien Bildfahrplan Druckstück BAUPLAN Dokumente Bildliche NSS LKD Fahrzeug-DB Zub-Info DB Brücken bei TFZ 56 Übersicht IIS R/3 Netz BBP VERONA ZFIS BFO-FfZ Genehmigung Schwerlast- Örtliche FPLO für Fahrplan für Betra transporte R/3 Werke FPLO Einzelzüge Zugmeldest. Infrastruktur instandhalten Baumaßnahmen planen Trassen planen/disponieren  What is a common definition of the business object ‘station track’? (master data object definition)?  Which of the business object’s attributes must be used in a standardized way across different processes, and which need not? (master data validity, master data object definition)  Which of the business object’s attributes are currently stored, altered, and distributed in which application systems? (metadata management)  How do data flows between application systems look like? (master data application topology and distribution)  Who is responsible for which data? (master data ownership)  What data is created, used, changed in which activity of the business process? (master data lifecycle, master data operations)  Should data describing station tracks be stored in a central system or in several, distributed systems? (master data application topology) © CC CDQ2 – Lima, 13.08.2010 / 6
  • 7. Case B (SBB Cargo): Identifying and Describing Master Data Objects Absolute Number Percentage Identified data objects 303 with owner 279 92 owner still to be clarified 23 8 Identified data objects (per data type) 303 Transaction data objects 62 20 Master data objects 47 16 Reference data objects 114 38 Synonym terms 78 25 still to be clarified 2 1 Data objects with master process 204 93 Data objects with identified master system 121 54  Determine common uniform definitions and structures for the company’s master data objects (master? data object definition, conceptual master data model) as well as unique identifiers for each master data class for unambiguous identification (master data validity).  Establish a central organizational unit responsible for carrying out changes on master data objects (master data operations, master data ownership).  Determine the “leading system” for each master data class and optimize architecture of applications administrating master data (master data application topology).  Create a Master Data Map depicting assignment of master data objects to applications and the data flows between them (master data application topology and distribution).  Design and implement tool-supported master data management processes (master data lifecycle, master data operations) © CC CDQ2 – Lima, 13.08.2010 / 7
  • 8. Case C (Deutsche Telekom): Integrated Enterprise Master Data Modelling Architecture Layer Architecture Model Data Model Process Model Produktkauf z p o g l le d u e tL u b r n p f i e n A T s -K a p u e s ri z o s e o g rBusiness Process N I: Produktions- N II: Business Object Glossary ... auftrag bis ... n u g s r Annahme ztArchitecture ... I. 2 Produktion planen ... (Definition of Master Data Objects) GbE-Verfügbarkeits- ... ... prüfung Group Domain Business Object Model Model Lokation +id : string KontaktDaten +id : long Strategic +gueltigkeit : Zeitabschnitt +kommentar : string Management +fremdId : string Product Supply TeleKontaktDaten Life Cycle Mgmt. . GeografischeLokation +abweichenderName : string Mgmt .. +anschlussNummer : stringLogical Architecture Billing Partner Mgmt.. +vorwahl : string +laenderKennzeichen : string CRM +nummer : Telefonnummer Service & GeografischesLokationsElementGlobal AbstrakteGeografischeAdresse Resource Service Production Management Lifecycle Mgmt. Resource Management OrtsNetzBereich +ortsNetzKennzahl : string +name : string +nameZusatz : string FlexProd Typ Feldlänge / Pattern G12-Lokations-ID Onkz Char [2-9] {1} [0-9] {1,4}Application / System Rufnummer Char [0-9] {1,10} MEGAPLAN LeistungsKey Char 14 G1-ProduktanfrageArchitecture FlexProd Kontes-Orka … LokationId ProduktinstanzId String String 60 38 Technisches Produkt String 20 ProduktgruppenListe String 4 VonDatum String; dd.mm.yyyy 16 BisDatum String; dd.mm.yyyy 16 Application Landscape (Logical) Application Data Models  Origin and distribution of master data objects on its current application architecture (master data ? application topology and distribution)  Semantics of master data objects leading to ambiguous understandings and inconsistent usage (master data definitions, metadata management)  Business requirements on enterprise-wide data quality of certain master data objects (master data validity) © CC CDQ2 – Lima, 13.08.2010 / 8
  • 9. Morphological Box: Options for Enterprise Master Data Architecture Design Decision Design Options Cases Defined enterprise-wide Defined locallyArchitecture Business Enterprise-wide Specific business unit Specific business process Centralized execution (by central unit) Local execution (by the owner) Centrally standardized Hybrid Local designArchitecture DataArchitectureApplication Master Data Distribution A, B and CArchitecture Integration Master Data Processing B and C © CC CDQ2 – Lima, 13.08.2010 / 9
  • 10. Enterprise Master Data Architecture Patterns Master Data MDM Creation / System Maintenance Separate Central master data System server central Existing Leading Business System Application Enterprise Master Data Coexistence Architecture Bi-directional Hub Consolidation Uni-directional De-central Hub none Registry Consolidation (Data Flow) Peer-To-Peer- Architecture [Dreibelbis et al. 2008], [Spath et al. 2009] © CC CDQ2 – Lima, 13.08.2010 / 10
  • 11. Evaluating Different Architecture Patterns Central Leading Coexistence Consolidati Registry Peer-To- System System Hub on Hub PeerAdequacy foroperative MDM q q q q q qLittleimplementation / q q q q q qmaintenance effortConsistency /Controlled q q q q q qRedundancyTimeliness ofmaster data q q q q q qScalability /Performance q q q q q qAbility to improvemaster data quality q q q q q q © CC CDQ2 – Lima, 13.08.2010 / 11
  • 12. Contact Person Dr. Boris Otto University of St. Gallen Institute of Information Management E-mail: boris.otto@unisg.ch Phone: +41 71 224 3220 http://cdq.iwi.unisg.ch Alexander Schmidt University of St. Gallen Institute of Information Management E-mail: alexander.schmidt@unisg.ch Phone: +41 71 224 3784 © CC CDQ2 – Lima, 13.08.2010 / 12