International Journal of Information Management 32 (2012) 337–346

Contents lists available at SciVerse ScienceDirect

International Journal of Information Management

journal homepage: www.elsevier.com/locate/ijinfomgt

How to design the master data architecture: Findings from a case study at Bosch
Boris Otto
University of St. Gallen, 9000 St. Gallen, Switzerland

a r t i c l e i n f o a b s t r a c t

Article history: Master data management (MDM) is a topic of increasing prominence both in the scientific and in the
Available online 29 December 2011 practitioners’ information systems (IS) community. As a prerequisite for meeting strategic business
requirements, such as compliance with regulations, business integration, or integrated customer man-
Keywords: agement, MDM comprises numerous activities. One of the central activities is designing and maintaining
Master data management the master data architecture. Interestingly, though, the scientific community has remained almost silent
Master data architecture
with regard to the question as to how companies should proceed when designing the master data archi-
Case study
tecture. In order to shed light on this unexplored topic, the paper at hand presents the findings of a case
Architectural patterns
Data architecture
study at Bosch Group. The case study shows that designing the master data architecture is a multidimen-
sional task which requires balancing the interests of various organizational stakeholders, managing an
array of technical opportunities, and meeting requirements of numerous master data classes. Also, the
case study suggests that taking advantage of architectural design patterns may be an appropriate way to
adequately address the complexity of the task.
© 2011 Elsevier Ltd. All rights reserved.

1. Introduction Smith and McKeen (2008, pp. 65–66) define master data man-
agement (MDM) as “an application-independent process which
1.1. Motivation describes, owns, and manages core business data entities. It ensures
consistency and accuracy of this data by providing a single set of
Master data represents a company’s key business objects. These guidelines for their management and thereby creates a common
key business objects form the foundation of the company’s busi- view on key company data, which may or may not be held in a
ness purpose and must therefore be used unambiguously across the common data source”. This definition comprises—as others also
entire organization. Typical master data classes are supplier, cus- do (Loshin, 2008; Oberhofer & Dreibelbis, 2008; White & Radcliffe,
tomer, material, and product data, as well as employee and asset 2008)—three central concepts:
data (Dreibelbis et al., 2008; Loshin, 2008; Smith & McKeen, 2008).
For quite some time now, the management of master data has • MDM is not an application system, but rather an organizational
been receiving increased attention both in the practitioners’ and function which involves ownership of master data.
the scientific IS community. A reason for that is the role master • Performance measure for MDM is the data’s quality.
data plays in meeting a number of strategic business requirements, • There are different architectural approaches for storing and dis-
such as the “360-degree-view” on the customer (Pula, Stone, & Foss, tributing master data.
2003), compliance with a growing number of regulations (Delbaere
& Ferreira, 2007), or globally integrated and harmonized business The first two concepts are currently being discussed vividly
processes (Loshin, 2008). in the IS community. Contributions regarding the organization
In 2009, leading automotive supplier ZF Friedrichshafen, for of MDM have been made by Loshin (2008), Otto and Reichert
example, established a new service business unit, integrating its (2010), Sarsfield (2009), and Swanton (2005). Studies on master
formerly separated aftermarket, spare parts, and service opera- data quality have their roots in research on data quality manage-
tions on a corporate level (ZF, 2010). This strategic reorganization ment (Wang, 1998), and are mainly conducted in the form of case
presupposed highly integrated and harmonized master data about studies (Knolmayer & Röthlin, 2006; Kokemüller, 2010; Otto, Ebner,
customers, own products, and customers’ products (models and & Hüner, 2010).
makes of cars ZF supplies parts and components for). Interestingly, though, the third concept, namely master data
architecture, has not been taken up largely so far. Among the few
scientific contributions on this subject are two case studies (Hasan,
Hyland, Dodds, & Veeraraghavan, 2000; Legner & Schemm, 2008),
E-mail address: [email protected] an investigation of ERP-centric approaches for MDM (Maedche,

0268-4012/$ – see front matter © 2011 Elsevier Ltd. All rights reserved.
doi:10.1016/j.ijinfomgt.2011.11.018
338 B. Otto / International Journal of Information Management 32 (2012) 337–346

2010), and an analysis by Allemang (2010) focusing on linked data (IBM, 2011), SAP NetWeaver MDM (SAP, 2008), and TIBCO Collab-
use in companies. All three contributions tackle the topic only orative Information Manager (TIBCO, 2008). There is consensus,
superficially. A comprehensive morphological analysis was con- however, that MDM does not simply refer to a class of informa-
ducted by Otto and Schmidt (2010). Their analysis, however, does tion systems, but rather constitutes an “application-independent”
not allow for in-depth insight as to how companies should approach (Smith & McKeen, 2008) business function. According to DAMA
the multiple decisions related to the design of their master data International (DAMA, 2009), MDM wants to achieve three goals,
architectures. namely providing an authoritative source of high-quality mas-
ter data (“golden record”), lowering cost and complexity through
standards, and supporting business intelligence and information
1.2. Research problem and contribution
integration. Activities to accomplish these goals include, among
others, understanding master data integration needs, identifying
The paper at hand has been motivated by the lack of scien-
master data sources and contributors, defining and maintaining the
tific knowledge regarding a contemporary phenomenon. It aims
master data architecture, and managing changes in master data.
at shedding light on the unexplored question as to how compa-
The nature of master data as referring to business objects which
nies should proceed when designing their master data architecture.
are used across the company requires MDM to be organized as a
In particular, the paper wants to illustrate what design decisions
central or corporate function (Otto & Reichert, 2010). Roles such as
companies need to make and what options companies have.
“data stewards” and “data owners” have been introduced to ensure
Case study research was chosen as a research method because
“Data Governance” within the organization (Khatri & Brown, 2010;
the phenomenon to be studied cannot be separated from its con-
Loshin, 2008; Weber, Otto, & Österle, 2009). While data stewards
text, and because only little knowledge about the phenomenon
are concerned with ensuring the quality of a certain master data
exists so far (Benbasat, Goldstein, & Mead, 1987; Yin, 2002). The
class, data owners have decision making rights with regard to busi-
study uses a single-case design, investigating the master data archi-
ness requirements, use and definition of master data (DAMA, 2008;
tecture design at Bosch Group (in the following referred to as
Loshin, 2008). Bitterer and Newman (2007) use a metaphor to dif-
Bosch), a multinational and multidivisional engineering company
ferentiate between the two roles, comparing the data owner to “a
headquartered in Stuttgart, Germany. Single-case study designs are
king who owns the land, but does not do anything with it, apart
frequently used in IS to study unique or extreme cases. Examples
from riding horses on the land”, whereas the data steward is com-
are the work on IT Governance presented by Brown (1997) and
pared to “a farmer who takes care of the land by growing crops,
the investigation of industry-wide IS standardization by Markus,
watering plants, ploughing fields and so on.”
Steinfield, Wigand, and Gabe (2006).
The paper is structured as follows: Section 2 presents a review
2.2. Master data architecture
of the literature related to master data architecture design. Section
3 outlines the research design, before Section 4 presents the case
Design and maintenance of the master data architecture is one of
study at Bosch. Section 5 analyzes the findings of the case. The paper
the activities of MDM. The master data architecture controls shared
concludes with a summary of the major results and an outlook on
access, replication, and flow of data in order to ensure data quality
further research.
(DAMA, 2009, p. 181).
The scientific body of knowledge regarding the topic of the mas-
2. Literature review ter data architecture is not very comprehensive. Early contributions
can be found in the field of Data Warehousing, which considers the
2.1. Master data and master data management master data architecture to be a prerequisite for standardized and
accurate reporting dimensions (Inmon, 1992). In the mid-1990s
Master data identifies and describes central business objects in researchers discussed intensively the concept of “Strategic Data
a company. Frequently cited examples are customer master data, Planning”, resulting, among other things, in a data architecture
supplier master data, product master data, and material master (Goodhue, Kirsch, Quillard, & Wybo, 1992; Shanks, 1997). Albeit
data (Dreibelbis et al., 2008; Loshin, 2008). But master data may not using the term “master data” explicitly, Strategic Data Plan-
also comprise a shared chart of accounts, employee data, and orga- ning refers to data that is used on a company-wide level. More
nizational data (e.g. cost center information). recent studies addressing the topic of the master data architec-
Many attempts have been made to define master data by dis- ture have been a case study on multidimensional databases (Hasan
tinguishing it from other types of data, such as transactional data, et al., 2000) and an investigation of the product information supply
contractual data, or inventory data (Knolmayer & Röthlin, 2006; chain in the consumer goods industry (Legner & Schemm, 2008).
Wieczorek, Stefanescu, & Schieferdecker, 2008). However, this dis- Furthermore, Allemang made the distinction between linked data
tinction, due to its ambiguity, does not seem to be helpful if one enterprise architecture and master data architecture (Allemang,
looks beyond individual cases. Contractual data, for example, might 2010)—without specifying the latter any further.
be considered master data in the utility industry, because of its The most comprehensive scientific contribution to the topic has
stability over time, but might be treated as transactional data in been made by Otto and Schmidt (2010). They refer to master data
the telecommunications industry, due to contracts being frequently architectures as information architectures the scope of which is
updated or cancelled by online-service customers. restricted to master data. These authors use the notion of “infor-
Despite the lack of a common understanding of master data mation architecture” not only to include shared data sources and
both in the scientific and in the practitioners’ community this paper data flows between data bases into the concept, but also to empha-
defines the term for the further course of the investigation as fol- size the demand for “authoritative” data standards and definitions
lows: Master data is data about the characteristics of key business (requiring a business perspective on the topic). In their under-
objects in a company and is unambiguously defined as well as standing, the master data architecture comprises both a conceptual
uniquely identified across the organization. master data model and the application architecture for master data.
In recent years MDM has received much attention in the practi- The application architecture for master data can be further divided
tioners’ community. To a certain extent, this development has been into source and target systems of master data on the one hand and
fostered by large software vendors, who developed dedicated MDM data flows on the other hand. Moreover, the authors identify a set
systems. Examples are IBM InfoSphere Master Data Management of design decisions related to the master data architecture.
 B. Otto / International Journal of Information Management 32 (2012) 337–346 339

Of course, many contributions can be found in the research com- 3.2. Case selection and data collection
munity addressing the general “data architecture” topic (Brackett,
1994). Numerous architecture frameworks—the Zachman Frame- Single-case designs have limitations with regard to replicabil-
work (Zachman, 1987), The Open Group Architecture Framework ity of findings, because they do not support theoretical sampling
(TOGAF) (Open Group, 2007), Enterprise Architecture Planning (Benbasat et al., 1987; Eisenhardt, 1989; Yin, 2002). However, the
(EAP) (Spewak & Hill, 1993), and the Enterprise Architecture Cube uniqueness of the case (Yin, 2002, pp. 40–41) justifies the design of
(Bernard, 2005), just to name a few—consider the data architecture the study.
to be part of the overall enterprise architecture. Otto and Schmidt In contrast to many other companies, Bosch looks back on a rel-
(2010), however, show that these frameworks by definition (due atively long history of having MDM as a corporate function and
to their overarching approach) are not useful in providing both the designing the master data architecture on a company-wide level.
conceptual breadth and depth required to investigate, analyze and In 2006, Bosch introduced a group guideline setting out binding
design a master data architecture in detail. principles for MDM. The group guideline includes an organizational
As mentioned earlier, master data architecture is a topic of dis- and a technical part. This information together with access to var-
cussion also in the practitioners’ community. A prominent aspect ious carriers of knowledge in the organization were available to
in this regard is the question for the right architectural style the author over a period of more than three years. Also, Bosch was
(Dreibelbis et al., 2008; Oberhofer & Dreibelbis, 2008; Radcliffe, invited as a reference to present the basic principles of their master
White, & Newman, 2006). Analyst company Gartner, for exam- data architecture design at a meeting of the MDM Working Group
ple, distinguishes between three styles (White & Radcliffe, 2007). of the German-speaking SAP User Group (DSAG), which took place
Design/construct MDM (1) is needed if a new business is cre- on June 17, 2010, in St. Leon-Rot, Germany. The case of Bosch can
ated, operational MDM (2) supports regular operations of existing therefore be considered as highly explorative and suitable for laying
businesses, and analytical MDM (3) is mainly used for reporting the foundations for further, multiple-case research.
purposes. Oberhofer and Dreibelbis (2008) propose a similar cate- Data was collected from different sources, as shown in Table 1.
gorization, describing also operational and analytical approaches, The main data source, however, were interviews with experts of
but identifying a “collaborative method use” in addition. Differ- Bosch. Transcripts of the interviews were created based on the field
ences between these architectural styles relate to the flow of data notes from the researchers involved. The final case study report was
between a “golden record” and data source systems. An analytical sent to Bosch for approval.
architecture, for example, uses a unidirectional flow of data from
the source systems to the “golden record”, using extract, transform
4. Master data architecture at Bosch
and load (ETL) processes before importing the data. Unlike the oper-
ational approach, no data is fed back to the source systems in the
4.1. Company overview
analytical approach.

Bosch is a leading technology and service company with an

3. Research approach overall revenue of 47.3 billion Euros and 283,500 employees in
2010. Headquartered in Stuttgart, Germany, Bosch operates in
3.1. Research design
three business sectors, namely “Automotive Technology”, “Indus-
trial Technology”, and “Consumer Goods and Building Technology”.
The paper uses case study research as a methodological
The business sectors span 17 divisions with operations in more than
approach to examine the contemporary phenomenon of master
one hundred countries around the world.
data architecture design. The research design orients itself at the
five guiding points proposed by Yin (2002, pp. 21–28). The research
question (1) is derived from the research problem, namely the 4.2. MDM at Bosch
limited understanding of master data architecture design in com-
panies. Therefore, the central research question is: How should Bosch has many years of experience in managing master data on
companies proceed when designing the master data architecture? a divisional level. In 2006, though, the company made a first step to
Due to the limited amount of scientific knowledge with regard to organize MDM on a corporate level by introducing a group guide-
this question, the study is of exploratory nature. Yin concedes that line, aiming at the specification of a company-wide set of goals of
in such cases it is unlikely to base one’s research on clear propo- MDM instead of going on dealing with MDM by means of rather
sitions (2). However, he stipulates that case study research should uncoordinated activities. The group guideline constitutes a bind-
have some purpose (Yin, 2002, p. 22) as well as a number of cri- ing framework for the management of group master data. Group
teria guiding the investigation. The paper at hand uses a simple master data follows the definition in Section 2.1. It is all master
conceptual framework (as shown in Fig. 1) as a guide for the inves- data which is used on a group level, i.e. by more than one division.
tigation. This framework is based on findings from practitioners The group guideline does not apply for master data used by single
and researchers (see Section 2.2), suggesting that designing a mas- divisions only.
ter data architecture comprises decisions on a technical level (e.g. The group guideline introduces two roles, namely Master Data
architectural styles) and cannot be isolated from organizational Owner (MDO) and Master Data Officer (MDF). The responsibilities
aspects (e.g. allocation of decision-making rights regarding data of the MDO are the same as outlined in Section 2.1. The MDF role
standards). corresponds with the general understanding of the data steward
The unit of analysis (3) sets the boundaries for the case with role.
regard to generalizability of its results. The paper at hand uses a The group guideline identifies a set of MDM activities which
single-case design, studying how Bosch approaches the issue of are divided into organizational/functional activities and technical
finding the right master data architecture design. The conceptual activities (see Fig. 2). Whereas the former are under the respon-
framework shown in Fig. 1 functions also as the logic which links sibility of the MDO, the latter are under the responsibility of the
the data to the propositions (4), and it represents the criteria to corporate information technology department. Fig. 2 shows the
interpret the findings (5). Hence, the conceptual framework serves MDM reference framework at Bosch. It consists of four components,
as a lens through which the evidence from the case is studied and namely “Governance System”, “MD Provisioning”, “MD Utilization”,
analyzed. and “MD Concepts & Projects”.
340 B. Otto / International Journal of Information Management 32 (2012) 337–346

Organizational Master Data Technical

Design Decisions Architecture Design Design Decisions

Fig. 1. Conceptual framework.

Table 1
Data sources.

Data source Description

Interviews 2010-07-19: 9.00 am to 4.00 pm, Stuttgart, Germany. Bosch participants:

• Director (Corporate User department), responsible for group master data;
• Director (IT), Responsible for Business Support Time to Market;
• Experts and Solution Architect MDM (Corporate User department/IT).
2010-07-19: 5.30 pm to 7.30 pm. Stuttgart, Germany. Bosch participants:
• Head of Corporate User department, responsible for group master data;
• Director (Corporate User department), responsible for group master data.
2011-03-14: 3.00 pm to 3.30 pm, conference call. Bosch participants:
• Senior Expert, Solution Architect Master Data Management (IT).
2011-03-29: 4.00 pm to 5.00 pm, conference call. Bosch participants:
• Experts and Solution Architect MDM (Corporate User department/IT).

Presentation • Presentation of Bosch at the DSAG MDM working group meeting on 2010-06-17 in St. Leon-Rot, Germany (available to working group
members only).

Internal documents • Group guideline on MDM at Bosch, of November 2006;

• Internal Bosch presentation on architectural approaches on MDM, dated 2010-12-14.

Observations • 2008-02-13: 08:30 am to 6:00 pm, Sindelfingen, Germany, Workshop of Working Group MDM at Bosch with over 15 participants
discussing four focus topics, namely MDM roadmap, MDM organization, MDM platforms, MDM maturity; author of the paper participated
as a moderator.

The “Governance System” contains the MD Strategy for each “MD Utilization” includes the use of master data in business
master data class as well as MD Controlling activities, which assess processes and the business application systems supporting the
the maturity of MDM for each master data class and measure the business processes at Bosch.
quality of the master data. Finally, the framework component “MD Concepts & Projects”
“MD Provisioning” includes the design and maintenance of an takes a lifecycle perspective on the different master data classes.
organization for MDM (including MDOs and MDFs), the design Related activities include the management of business require-
and maintenance of master data processes (e.g. creation or update ments regarding master data, the design of functional and technical
of master data), the design and maintenance of a master data specifications, and the organizational and technical implementa-
model, and the design and guidance of the application systems tion of the specifications through projects. Table 2 summarizes the
used to store and distribute master data. The master data model organizational/functional and technical activities.
has a conceptual view (MDO responsibility) and a physical view (IT In 2006, seven master data classes were within the initial scope
responsibility). of the implementation based on the group guideline, namely chart

Governance System

MD Strategy MD Controllin g

MD Provisioning MD Utilization MD Concepts &

Projects
MD Requirements
MD Org. Business Processes
Processes Management
conceptual Business Application f unctional
MD Model MD Concept
physical Systems technical

MD Applications Implementation
Systems Projects

Legend: org./f unctional responsibility; technical responsibility; MD – master data.

Fig. 2. MDM reference framework at Bosch.

 B. Otto / International Journal of Information Management 32 (2012) 337–346 341

Table 2
Organizational and technical MDM activities.

Organizational activities Technical activities

• Definition of master data classes • Design and maintenance of physical data models
• Specification of area of organizational validity • Design of data storage and data distribution architecture
• Design and maintenance of an organization for MDM • Support of MDOs
• Design and maintenance of data maintenance processes
• Design and maintenance of conceptual data models (attributes and values allowed)
• Design and maintenance of data distribution processes (functional perspective)

of accounts, customer hierarchy, customer master data, supplier • Support of internal (between central units and user departments)
master data, certain material master data including product hier- and external (with software vendors) communication.
archies, and a subset of so-called group elements, which comprise
reference data, such as country and language codes. 4.4. Technical perspective

In general, master data architecture design at Bosch must be

4.3. Master data architecture context and goals aligned with three parameters, namely the group-wide application
system architecture framework, the data governance framework,
Master data had been managed, of course, by the different busi- and the product strategy of the preferred application system
ness sectors and divisions long before MDM was established on vendor. Taking into account these parameters, Bosch identified
a corporate level at Bosch. Hence, for the management of master four basic approaches for master data architectures (see Fig. 3).
data a variety of business processes and application systems had Approach A is referred to as the analytical approach. It assumes
emerged. In the process of implementing master data architectures that all master data maintenance activities, i.e. creation, update,
for the different data classes according to the group guideline, MDM and deletion of master data, are performed by local source systems.
at Bosch encountered difficulties when discussing the introduc- In case of creation of new master data, the primary key attribute is
tion of a standard architecture. A standard approach would have also assigned by the local system. Data is then periodically imported
meant either migrating all data from existing application systems into a central Master Data Server (MDS), which assigns a “global”,
to a newly installed system (which is not a feasible option in the i.e. company-wide unique, identification number to all imported
majority of cases due to cost and organizational constraints), or liv- master data records, and optionally holds references to local key
ing with the heterogeneity and not following the policies specified attributes. Duplicate records are identified by the MDS. Approach
by the group guideline. Moreover, the requirements on the mas- A is used to support business scenarios which require ongoing data
ter data architecture, which are derived from the demand from the quality assurance and a general overview of distributed and hetero-
business units, differ significantly across the various master data geneous master data in a certain domain. It is used in post-merger
classes. situations and in preparation of data migration projects.
Summarizing, three factors prevent a “one size fits all” archi- Approach B is referred to as the transactional approach. It
tectural design at Bosch. First, there are different business assumes that maintenance of global master data attributes is per-
requirements across different divisions and functional depart- formed by the MDS. Also, the MDS provides functionality for
ments. Unique supplier master data, for example, is mainly assigning global identification numbers, workflow support for data
required for reporting purposes in purchasing and compliance with maintenance, duplicate checks upon data entry, and export and
regulations—such as being able to block suppliers for purchasing distribution to local target systems. Global master data can only
that allow child labor—whereas consistent and complete material be read by the target systems; updating or changing, however,
master data is needed from an operational perspective in sales, is not allowed. Approach B is used in business scenarios with
manufacturing and distribution. high liability requirements on data. An example of Approach B is
A second factor is the variety of existing applications in differ- the company-wide chart of accounts following the International
ent divisions and functional departments. The application system Financial Reporting Standards (IFRS), where data maintenance is
landscape follows a group-wide framework, but, of course, shows performed by a limited number of subject matter experts.
differences when it comes to details. Examples are the use of dif- Approach C (coexistence) is a combination of the analytical and
ferent software vendors for the same class of application systems the transactional approach. Master data is maintained by local sys-
and different releases of the same system. These differences lead to tems, which also assign primary keys to master data records. The
technical barriers regarding the use of a “one size fits all” architec- data is then imported into a central MDS and assigned with a
tural design. globally unique identification number. In a next step the data is
Third, there are different levels of organizational maturity with consolidated by a small number of subject matter experts, handed
regard to MDM in different divisions and functional departments. back to the source systems, and (on request) further distributed
Some functional departments have a clear understanding of the to other target systems. Approach C is used in business scenarios
requirements with regard to master data quality and the master which are characterized by highly heterogeneous local business
data lifecycle, while others are in early analysis stages. requirements and/or a need for company-wide data integration.
As a consequence, the idea was developed to offer a set of An example of Approach C is human resources master data, which
reference master data architectures the MDOs and other persons needs to comply with local standards but must also be consolidated
responsible could choose from on a case-wise basis. The reference centrally for identity management as well as for corporate human
architectures are supposed to support the following objectives: resources functions, such as competence management and training
management.
Approach D, the parallel approach, is characterized by divid-
• Vendor-neutral representation of master data architecture ing up central master data maintenance functionality between
approaches at Bosch. a central MDS and local application systems. Users of local
• Accelerated “time to market” from business requirements to systems are supported by workflow management in creating,
implemented solutions. updating and deleting master data. However, all transactions
342 B. Otto / International Journal of Information Management 32 (2012) 337–346

A Analytical Approach B Transactional Approach

Source Source Source

MDS
System 1 System 2 System n

Target Target Target

MDS
System 1 System 2 System n

C Coexistence D Parallel Approach

Source Source Source Source Source

System 1 System 2 System n System 1 System n

MDS MDS
MDS
MDS

Target Target Target Target Target Target

System 1 System 2 System n System 1 System 2 System n

Legend: local system; “global”, i.e. corporate-wide system (“golden record”)

Fig. 3. Architectural approaches at Bosch.

requiring compliance with the ACID principle, defining the atom- execution of master data maintenance activities is assigned com-
icity, conistency, isolation, and durability of database transactions pletely to the business units. And Approach III (local approach)
(Haerder & Reuter, 1983), are synchronized with the central MDS, is characterized by almost complete local responsibility for all
which also assigns globally unique identification numbers to mas- functional and organizational design decisions related to a certain
ter data records, checks for duplicate records, and validates the master data class. Only the definition of guidelines for maintenance
data. In contrast to Approach C, which uses corporate subject mat- activities is assigned to the central MDO role.
ter experts, the parallel approach uses the expertise of local users to Bosch always allocates the ownership of master data classes
consolidate the master data. The parallel approach is therefore used and the design of the conceptual data model to a central role, i.e.
in business scenarios which are characterized by many heteroge- the MDO, even under the hybrid and the local approach. This is a
neous business rules to be checked during data maintenance and/or consequence of the policies outlined in the group guideline, which
a demand for high master data quality. An example of Approach D is understands MDM as a central function. Therefore, local owner-
master data for machinery spare parts, as this data combines local ship and local conceptual data models would be contradictory to
(e.g. local manufacturer part numbers) with global requirements the objectives of MDM for group master data at Bosch.
(e.g. company-wide inventory level visibility).
4.6. Integrated assessment
4.5. Organizational perspective
Based on the identification of both technical and organizational
Besides the technical perspective on the master data architec- approaches to the master data architecture, Bosch identified a num-
ture, the group guideline at Bosch also includes organizational ber of “feasible” architecture patterns, i.e. combinations of both
design activities, namely a common definition of master data perspectives.
classes, a definition of their organizational validity, and the concep- As Table 4 shows, Bosch considers five combinations (out of
tual data model. Apart from that, the group guideline also identifies twelve theoretically possible) as feasible. Approach A (analytical
the need for further organizational design activities, namely the approach), for example, is deemed feasible only in combination
definition of maintenance processes (related to the MDS), the data with Approach III (local approach). The rationale behind this is that
distribution and deployment processes (related to the target pro- there is no need to “dictate” business units the design of the data
cesses and systems), and the assignment of organizational roles. maintenance process when the master data is used on a corporate
Bosch identified three general organizational approaches, as level for reporting purposes only. Instead, it just must be ensured
shown in Table 3. Approach I (central approach) is characterized that master data can be consolidated by a central MDS.
by a central responsibility for all functional and organizational All other technical approaches may be combined with the hybrid
design decisions related to a certain master data class and organizational approach, ensuring a balance between local and cen-
also—partially—by central execution of master data maintenance. tral business requirements. While the transactional approach is
Approach II (hybrid approach) combines central and local respon- preferable because of its relatively limited technical complexity,
sibility, i.e. business unit responsibility for design activities. The it is often applicable only in organizational environments similar
 B. Otto / International Journal of Information Management 32 (2012) 337–346 343

Table 3
Organizational approaches at Bosch.

Design parameters I II III

(Central approach) (Hybrid approach) (Local approach)

Organizational allocation of MDO, together with business unit representatives and MDF
responsibility for master
data class
Design of data maintenance MDO defines company-wide MDO defines principles for No central principles by MDO;
process maintenance process company-wide maintenance maintenance processes
(standard) processes, detailed definition designed by business units
done by business units
Execution of data maintenance Central MDO organization, Business units Business units
process together with business units
Design of conceptual data MDO
model
Examples Customer hierarchy data Customer master data, Product hierarchy
machinery spare parts, human
resources master data

MDO—Master Data Owner and MDF—Master Data Officer.

to Approach I. In general, the technical approach for the hybrid of the transactional approach from the very beginning of the imple-
organizational approach (II) depends on the following four fac- mentation.
tors: Moreover, the parallel approach is preferred to the transactional
approach for master data classes which require intensive knowl-
• Diversity of business processes and systems to be connected. edge from the local business units. An example is material master
• Heterogeneity of data and data models. data, which often requires the knowledge of local plant managers
• Timelines of prioritized business requirements (“customers” of and which is managed through a variety of different business pro-
master data). cesses. In cases like this, the parallel approach offers more flexibility
• Feasibility and cost of implementation (as a result of the three to the business units than the transactional approach.
factors above). Bosch uses these five master data architecture patterns as a ref-
erence for the various master data classes. Bosch considers these
approaches as a means to balance the need for flexibility in the
In general, Bosch prefers the parallel approach to the coex-
business on the one hand and the demand for reduced technical
istence approach. The latter may be followed, however, when
complexity on the other hand. At present, Bosch is in the process
business processes and application systems related to a certain
of successively applying the concept to the master data classes.
master data class are too heterogeneous, making the parallel
approach become economically unreasonable.
An example of the coexistence approach is human resources
5. Case analysis
master data. Main reasons for using this approach are:

5.1. The nature of master data architecture design patterns

• Variance of business processes (including master data mainte-
nance) in combination with country specific legal requirements: The case of Bosch shows that patterns can be very useful when it
while the fact that most human resource departments at Bosch comes to designing the master data architecture. In general, archi-
are using SAP systems basically supports the implementation of tectural design patterns are very common in software engineering
almost all approaches, the obstacle of diverse business processes as they represent a problem-solution pair not only for specific
remains. Master data could only be cleansed in “downstream” but for classes of architectural design problems (Avgeriou & Zdun,
activities (which prevents the use of synchronous data processes 2005; Buschmann, Meunier, Rohnert, Sommerlad, & Stal, 1996, p.
approaches such as the parallel approach). 3). Furthermore, patterns allow balancing standardization on the
• Timeline constraints: users of global human resources master
one hand and flexible design on the other.
data could not wait for the implementation of the transactional or The current state of research and practice with regard to design
parallel approach. In this regard, the coexistence approach was patterns for the master data architecture is still at an early stage
used to meet prioritized business requirements when needed, of development. Otto and Schmidt (2010) identify relevant design
serving as a first step toward the final master data architecture. decisions and options, but do not come up with comprehen-
sive architectural patterns. And the practitioners’ community is
For other master data classes (customer and supplier data, for discussing different architectural styles, such as analytical and
example), the factors mentioned above are different (strict central operational MDM (see Section 2.2). These styles, however, are too
master data maintenance, for example), leading to the preference simplistic to explain the architectural patterns in the case of Bosch.

Table 4
Feasible master data architecture patterns.

Technical Organizational approach

approach
I(Central) II (Hybrid) III(Local)

A (Analytical)  䊎 䊉
B (Transactional) 䊉 䊉 
C (Coexistence)  䊉 
D (Parallel)  䊉 

Legend: , no feasible approach (disadvantages outnumber advantages); 䊎, to be decided on a case-wise basis; 䊉, preferred approach.
344 B. Otto / International Journal of Information Management 32 (2012) 337–346

This paper takes this discussion further with regard to two of master data architecture related responsibilities between those
main aspects. First, the question of architectural design must not two communities within Bosch helped manage such a complex
be reduced to technical aspects only, but should rather balance issue as master data architecture in a comprehensive—i.e. organi-
both organizational and technical considerations. This is even more zational/functional and technical—way. This aspect has not been
important as such a comprehensive approach would allow to iden- addressed by literature so far either. Some papers exist which
tify feasible patterns. Organizational and technical aspects show examine the roles of business and IS/IT departments in enterprise
strong interdependencies the analysis of which could pave the way architecture management in general (Gregor, Hart, & Martin, 2007;
for identifying feasible master data architecture patterns. Winter & Schelp, 2008), but they do not focus on the master data
Second, the Bosch case also shows that design patterns for architecture issue.
the master data architecture are used as an approach to manage
the complexity of the issue at hand. Complexity dimensions are, 5.3. An evolutionary perspective on master data architecture
for example, the number and heterogeneity of different master design
data classes, the organizational structure, and the use case (White,
2010). However, this point has not been discussed sufficiently in The case study addresses another important question, namely
order to be able to explain the case of Bosch. The Bosch case shows how master data architecture design is evolving over time. Bosch
the need to include further complexity dimensions when design- prefers the parallel approach to the coexistence approach—unless
ing the master data architecture. Among those are the separation there are urgency constraints—and the parallel approach to the
of functional and technical design responsibilities (see Fig. 2), the transactional approach in cases of master data classes which
diversity of business processes to be supported, and the urgency of require intensive “local” knowledge. The fact that preferences
action—as in the case of human resources master data, for example. are subject to certain conditions implies that architectural design
It is the combination of this extensive set of dimensions which has evolves over time. Organizational fit of master data architecture
led to the design of the parallel approach at Bosch—an approach patterns seems to be dynamic rather than fixed.
which has not been considered either in research or in practice so Evolutionary theory has been used frequently in IS research,
far. Of course, the paper does not want to generalize from one case mainly to explain change with regard to IS artifacts. In general, a
at this point. It is, however, quite likely that the approach of Bosch combination of evolutionary theory and contingency theory allows
could be adopted by companies with similar characteristics. to investigate alternative evolutionary paths (Teo & King, 1997).
Thus, it might explain when and under what conditions a certain
5.2. The organizational fit of master data architecture design master data architecture design is preferable for an organization.
Master data has long since been managed on a local level at
The case of Bosch suggests the assumption of the master data Bosch, while the group guideline for MDM is relatively new. In
architecture being dependent on organizational factors. There cases like this, a certain “carrot-and-stick” approach seems appro-
seems to be the issue of an organizational fit of master data archi- priate for master data architecture design. Analyst company AMR
tecture design. Contingency theory, in general, claims that there Research recommends to use “central MDM facilitation, not con-
is no “one size fits all” approach to corporate organization. A num- trol” (Swanton, Hagerty, & Cecere, 2007)—which is often easier
ber of researchers have demonstrated its applicability to enterprise said than done. However, Bosch follows this idea, using a group
architecture management (Lahrmann, Winter, & Fischer, 2010; guideline as a “stick” and the provisioning of reference architecture
Leppänen, Valtonen, & Pulkkinen, 2007; Ylimäki, 2006). These con- patterns including workflow support and data quality assurance
tributions, however, remain very unspecific when it comes to as “carrots” for local business units. In the course of the evolu-
contingencies of the master data architecture. The case of Bosch tion of MDM at Bosch in general and the ongoing adaptation of
is novel, as it explicitly addresses the issue of organizational fit of master data architecture patterns, demand for central or hybrid
master data architecture design. approaches might increase at the expense of local approaches.
Apart from that, the Bosch case shows that contingency fac-
tors for enterprise architecture management—such as modeling 6. Conclusions
capabilities, adopted design paradigms, organizational penetration
(Riege & Aier, 2009)—are not appropriate to explain the organiza- The paper at hand reports on the design of the master data archi-
tional fit of master data architecture design. Contingency factors tecture at Bosch. The case shows that designing the master data
for the master data architecture are rather business process diver- architecture is a task which combines both technical and orga-
sity, urgency of action, heterogeneity of data classes and models, nizational aspects. Bosch has specified four technical and three
knowledge about master data classes in the business units, and the organizational approaches, and has identified five “feasible” com-
relationship between group-wide and local MDM activities. binations of these approaches out of twelve theoretically possible.
Furthermore, the Bosch case shows the tight relationship The analysis of the case suggests three major findings. First,
between master data governance and master data architecture. The design patterns for the master data architecture have to include a
group guideline is the overarching reference for data governance variety of both organizational and technical design options. Existing
questions at Bosch. It sets out roles and responsibilities, also related contributions from related fields—such as enterprise architecture
to the design of the master data architecture. The guideline is con- management—are not sufficient to explain master data architecture
sidered to be a prerequisite without which the use of master data design. Second, master data architecture design is contingent to a
architecture design patterns would not be possible (see Section 4.6). number of factors. Due to the nature of master data and the organi-
The silence of the research community, though, stands in contrast to zation of MDM in companies, existing theories should be extended
the importance of this aspect. While data governance has received to explain master data architecture design. Important factors which
some attention lately (Khatri & Brown, 2010; Otto & Reichert, 2010; have not been discussed in literature so far but which are specific to
Weber et al., 2009), none of the contributions investigates the rela- MDM include the variety and heterogeneity of master data classes,
tionship between data governance and master data architecture in the adoption of data governance, and the distribution of knowledge
detail. about master data across the organization. Third, an evolutionary
The group guideline at Bosch does not only identify and describe perspective seems to be required in order to explain master data
the roles and responsibilities, but it also specifies the collaboration architecture design comprehensively. Preferences for certain mas-
between business and IS/IT departments. The explicit definition ter data architecture approaches and their dependence on volatile
 B. Otto / International Journal of Information Management 32 (2012) 337–346 345

parameters suggest the existence of certain evolutionary paths of IBM (2011). InfoSphere master data management server. Retrieved on 2011-02-18
master data architecture design. from <http://www-01.ibm.com/software/data/infosphere/mdm server/>.
Inmon, W. H. (1992). Data architecture: the information paradigm (2nd ed.). Boston,
Neither the scientific body of knowledge nor the practitioners’
MA: QED Technical Publishing Group.
community so far has reported about a case which allows as much Khatri, V., & Brown, C. V. (2010). Designing data governance. Communications of the
insight into the issue as the case of Bosch does. Thus, the paper’s ACM, 53(1), 148–152. doi:10.1145/1629175.1629210
Knolmayer, G. F., & Röthlin, M. (2006). Quality of material master data and its effect
main contribution to the scientific body of knowledge is yielding
on the usefulness of distributed ERP systems. In J. F. Roddick (Ed.), Advances
insight into and understanding of a contemporary phenomenon, in conceptual modeling—Theory and practice (pp. 362–371). Berlin, Germany:
which is, at present, rather unexplored. The paper lays the founda- Springer.
tion for future research, in particular for multiple-case studies and Kokemüller, J. (2010). Master data compliance: The case of sanction lists. Paper
presented at the 16th Americas conference on information systems, Lima, Peru.
empirical investigation. Lahrmann, G., Winter, R., & Fischer, M. M. (2010). Design and engineering for sit-
Practitioners may benefit from the paper because it offers direc- uational transformation. In F. Harmsen, E. Proper, F. Schalkwijk, J. Barjis, & S.
tion and guidance in the complex task of designing the master data Overbeek (Eds.), Practice-driven research on enterprise transformation (pp. 1–16).
Berlin, Germany: Springer.
architecture. Legner, C., & Schemm, J. (2008). Toward the inter-organizational product informa-
Limitations exist with regard to generalizability of results. tion supply chain—Evidence from the retail and consumer goods industries.
Single-case studies by definition do not allow for theoretical sam- Journal of the AIS, 9(3/4), 120–152.
Leppänen, M., Valtonen, K., & Pulkkinen, M. (2007). Towards a contingency
pling. Hence, the findings of the paper must be triangulated with framework for engineering an enterprise architecture planning method. Paper
similar cases. Triangulation must take into account the general presented at the 30th Information Systems Research Seminar in Scandinavia,
characteristics of Bosch, namely the size of the company, the indus- Tampere, Finland.
Loshin, D. (2008). Master data management. Burlington, MA: Morgan Kaufmann.
try, and the multi-national and multi-divisional organization. In
Maedche, A. (2010). An ERP-centric master data management approach. Paper pre-
addition to that, replication of the findings should also consider the sented at the 16th Americas Conference on Information Systems, Lima, Peru.
specific characteristics of MDM at Bosch, namely the long experi- Markus, M. L., Steinfield, C. W., Wigand, R. T., & Gabe, M. (2006). Industry-
wide information systems standardization as collective action: The
ence with master data both on a local and group level, the existence
case of the U.S. residential mortgage industry. MIS Quarterly, 30(SI),
of the MDM reference framework (see Fig. 2) and the adoption of 439–465.
the group guideline across the company. Oberhofer, M., & Dreibelbis, A. (2008). An introduction to the master data
management reference architecture. Retrieved on 2011-03-18 from
<http://www.ibm.com/developerworks/data/library/techarticle/dm-
0804oberhofer/>.
Acknowledgements Open Group. (2007). The Open Group Architecture Framework TOGAF—2007 Edition
(Incorporating 8.1.1). Zaltbommel, The Netherlands: Van Haren.
The research presented in this paper is a result of the Compe- Otto, B., Ebner, V., & Hüner, K. (2010). Measuring master data quality: Findings from
a case study. Paper presented at the 16th Americas conference on information
tence Center Corporate Data Quality (CC CDQ). The CC CDQ is a
systems, Lima, Peru.
consortium research project and part of the research program Busi- Otto, B., & Reichert, A. (2010). Organizing master data management: Findings from
ness Engineering at the Institute of Information Management at the an expert survey. In B. R. Bryant, H. M. Haddad, & R. L. Wainwright (Eds.), Pro-
ceedings of the 25th ACM symposium on applied computing Sierre, Switzerland,
University of St. Gallen (BE HSG).
(pp. 106–110).
Otto, B., & Schmidt, A. (2010). Enterprise master data architecture: Design deci-
sions and options. Paper presented at the proceedings of the 15th international
References conference on information quality, Little Rock, AR.
Pula, E. N., Stone, M., & Foss, B. (2003). Customer data management in practice: An
Allemang, D. (2010). Semantic web and the linked data enterprise. In D. Wood (Ed.), insurance case study. Journal of Database Marketing, 10(4), 327–341.
Linking enterprise data (pp. 3–23). Berlin, Germany: Springer. Radcliffe, J., White, A., & Newman, D. (2006). How to choose the right architectural
Avgeriou, P., & Zdun, U. (2005). Architectural patterns revisited—A pattern language. style for master data management. Stamford, CT: Gartner, Inc.
Paper presented at the 10th European Conference on Pattern Languages of Pro- Riege, C., & Aier, S. (2009). A contingency approach to enterprise architecture
grams, Irsee, Germany. method engineering. In G. Feuerlicht, & W. Lamersdorf (Eds.), Service-
Benbasat, I., Goldstein, D. K., & Mead, M. (1987). The case research strategy in studies oriented computing—ICSOC 2008 workshops (pp. 316–326). Berlin, Germany:
of information systems. MIS Quarterly, 11(3), 369–386. Springer.
Bernard, S. A. (2005). An introduction to enterprise architecture (2nd ed.). Blooming- SAP (2008). SAP library—SAP netweaver master data management (MDM). Retrieved
ton, IN: Authorhouse. on 2009-02-19, from <http://help.sap.com/saphelp mdm550/helpdata/
Bitterer, A., & Newman, D. (2007). Organizing for data quality. Stamford, CT: Gartner, en/43/D7AED5058201B4E10000000A11466F/frameset.htm>.
Inc. Sarsfield, S. (2009). The data governance imperative: A business strategy for corporate
Brackett, M. H. (1994). Data sharing using a common data architecture. New York, NY: data. Cambridgeshire, UK: IT Governance Publishing.
John Wiley. Shanks, G. (1997). The challenges of strategic data planning in practice: an
Brown, C. V. (1997). Examining the emergence of hybrid IS governance solutions: interpretive case study. Journal of Strategic Information Systems, 6(1), 69–90.
Evidence from a single case site. Information Systems Research, 8(1), 69–94. doi:10.1016/S0963-8687(96)01053-0
doi:10.1287/isre.8.1.69 Smith, H. A., & McKeen, J. D. (2008). Developments in practice XXX: Master data
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., & Stal, M. (1996). Pattern- management: Salvation or snake oil? Communications of the AIS, 23, 63–72.
oriented software architecture: A system of patterns. Chichester, UK: John Wiley. Spewak, S. H., & Hill, S. C. (1993). Enterprise architecture planning—Developing a
DAMA. (2008). The DAMA dictionary of data management. Bradley Beach, NJ: Technics blueprint for data, applications and technology. New York, NY: John Wiley.
Publications. Swanton, B. (2005). Master data management organizations: A balance of control and
DAMA. (2009). The DAMA guide to the data management body of knowledge. Bradley responsibility. Boston, MA: AMR Research, Inc.
Beach, NJ: Technics Publications. Swanton, B., Hagerty, J., & Cecere, L. (2007). MDM strategies for enterprise applications.
Delbaere, M., & Ferreira, R. (2007). Addressing the data aspects of compliance with Boston, MA: AMR Research, Inc.
industry models. IBM Systems Journal, 46(2), 319–334. doi:10.1147/sj.462.0319 Teo, T. S. H., & King, W. R. (1997). Integration between business planning and infor-
Dreibelbis, A., Hechler, E., Milman, I., Oberhofer, M., van Run, P., & Wolfson, D. mation systems planning: An evolutionary-contingency perspective. Journal of
(2008). Enterprise master data management: An SOA approach to managing core Management Information Systems, 14(1), 185–214.
information. Upper Saddle River, NJ: IBM Press. TIBCO. (2008). Managing master data with TIBCO collaborative information manager:
Eisenhardt, K. M. (1989). Building theories form case study research. Academy of A technical overview. Palo Alto, CA: TIBCO Software Inc.
Management Review, 14(4), 532–550. Wang, R. Y. (1998). A product perspective on total data quality management. Com-
Goodhue, D. L., Kirsch, L. J., Quillard, J. A., & Wybo, M. D. (1992). Strategic data munication of the ACM, 41(2), 58–65. doi:10.1145/269012.269022
planning: lessons from the field. MIS Quarterly, 16(1), 267–274. Weber, K., Otto, B., & Österle, H. (2009). One size does not fit all—A contingency
Gregor, S., Hart, D., & Martin, N. (2007). Enterprise architectures: enablers of business approach to data governance. ACM Journal of Data and Information Quality, 1(1)
strategy and IS/IT alignment in government. Information Technology & People, doi:10.1145/1515693.1515696
20(2), 96–120. doi:10.1108/09593840710758031 White, A. (2010). The five vectors of complexity that define your MDM strategy. Stam-
Haerder, T., & Reuter, A. (1983). Principles of transaction-oriented database recovery. ford, CT: Gartner, Inc.
Computing Surveys, 15(4), 287–317. doi:10.1145/289.291 White, A., & Radcliffe, J. (2007). Four dimensions of MDM: Understanding the complex-
Hasan, H., Hyland, P., Dodds, D., & Veeraraghavan, R. (2000). Approaches to the devel- ity. Stamford, CT: Gartner, Inc.
opment of multi-dimensional databases: Lessons from four case studies. The White, A., & Radcliffe, J. (2008). Mastering master data management. Stamford, CT:
Data Base for Advances in Information Systems, 31(3), 10–23. Gartner, Inc.
346 B. Otto / International Journal of Information Management 32 (2012) 337–346

Wieczorek, S., Stefanescu, A., & Schieferdecker, I. (2008). Test data provision for ZF. (2010). Annual report 2009. Friedrichshafen, Germany: ZF Friedrichshafen AG.
ERP systems. Paper presented at the 2008 international conference on software
testing, verification, and validation, Lillehammer, Norway. Boris Otto is Assistant Professor at the University of St. Gallen, Switzerland, and
Winter, R., & Schelp, J. (2008). Enterprise architecture governance: the need for a Visiting Research Fellow at the Tuck School of Business at Dartmouth College
business-to-IT approach. Paper presented at the 23rd annual ACM symposium in Hanover, NH. His main areas of research are Data Governance, Data Quality
on applied computing, Fortaleza, Brazil. Management, and Master Data Management. His research has been published in
Yin, R. K. (2002). Case study research: design and methods (3rd ed.). Thousand Oaks, numerous international journals and he is member of the Scientific Advisory Board
CA: Sage Publications. of eCl@ss, the international classification and product description standard. Prior to
Ylimäki, T. (2006). Potential critical success factors for enterprise architecture. Jour- his current positions he worked for Fraunhofer IAO, PricewaterhouseCoopers, and
nal of Enterprise Architecture, 2(4), 29–40. SAP.
Zachman, J. A. (1987). A framework for information systems architecture. IBM Sys-
tems Journal, 26(3), 454–470. doi:10.1147/sj.263.0276