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.

1. Enterprise Master Data Architecture
Design Decisions and Options
Alexander Schmidt, Boris Otto
Lima, August 13, 2010
Institute of Information Management
Chair 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 q
Coverage of all enterprise
master data architecture q q q q q q
components
Reference 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 q
Legend: 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, Tunnels
etc.)
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 r
Business Process N I:
Produktions- N II:
Business Object Glossary
...
auftrag bis ...
n
u
g
s
r
Annahme
zt
Architecture
...
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 : string
Logical 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-Produktanfrage
Architecture 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 locally
Architecture
Business
Enterprise-wide Specific business unit Specific business process
Centralized execution (by central unit) Local execution (by the owner)
Centrally standardized Hybrid Local design
Architecture
Data
Architecture
Application
Master Data Distribution A, B and C
Architecture
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 Peer
Adequacy for
operative MDM
q q q q q q
Little
implementation / q q q q q q
maintenance effort
Consistency /
Controlled q q q q q q
Redundancy
Timeliness of
master data
q q q q q q
Scalability /
Performance
q q q q q q
Ability to improve
master 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