International Journal of Information Management

International Journal of Information Management 32 (2012) 337 346 Contents lists available at SciVerse ScienceDirect International Journal of Information Management j our nal ho me p age: 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 Article history: Available online 29 December 2011 Keywords: Master data management Master data architecture Case study Architectural patterns Data architecture a b s t r a c t Master data management (MDM) is a topic of increasing prominence both in the scientific and in the practitioners information systems (IS) community. As a prerequisite for meeting strategic business requirements, such as compliance with regulations, business integration, or integrated customer management, MDM comprises numerous activities. One of the central activities is designing and maintaining the master data architecture. Interestingly, though, the scientific community has remained almost silent with regard to the question as to how companies should proceed when designing the master data architecture. In order to shed light on this unexplored topic, the paper at hand presents the findings of a case study at Bosch Group. The case study shows that designing the master data architecture is a multidimensional 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 1.1. Motivation Master data represents a company s key business objects. These key business objects form the foundation of the company s business purpose and must therefore be used unambiguously across the entire organization. Typical master data classes are supplier, customer, material, and product data, as well as employee and asset data (Dreibelbis et al., 2008; Loshin, 2008; Smith & McKeen, 2008). For quite some time now, the management of master data has been receiving increased attention both in the practitioners and the scientific IS community. A reason for that is the role master data plays in meeting a number of strategic business requirements, such as the 360-degree-view on the customer (Pula, Stone, & Foss, 2003), compliance with a growing number of regulations (Delbaere & Ferreira, 2007), or globally integrated and harmonized business processes (Loshin, 2008). In 2009, leading automotive supplier ZF Friedrichshafen, for example, established a new service business unit, integrating its formerly separated aftermarket, spare parts, and service operations on a corporate level (ZF, 2010). This strategic reorganization presupposed highly integrated and harmonized master data about customers, own products, and customers products (models and makes of cars ZF supplies parts and components for). E-mail address: Boris.Otto@unisg.ch Smith and McKeen (2008, pp. 65 66) define master data management (MDM) as an application-independent process which describes, owns, and manages core business data entities. It ensures consistency and accuracy of this data by providing a single set of guidelines for their management and thereby creates a common view on key company data, which may or may not be held in a common data source. This definition comprises as others also do (Loshin, 2008; Oberhofer & Dreibelbis, 2008; White & Radcliffe, 2008) three central concepts: MDM is not an application system, but rather an organizational function which involves ownership of master data. Performance measure for MDM is the data s quality. There are different architectural approaches for storing and distributing master data. The first two concepts are currently being discussed vividly in the IS community. Contributions regarding the organization of MDM have been made by Loshin (2008), Otto and Reichert (2010), Sarsfield (2009), and Swanton (2005). Studies on master data quality have their roots in research on data quality management (Wang, 1998), and are mainly conducted in the form of case studies (Knolmayer & Röthlin, 2006; Kokemüller, 2010; Otto, Ebner, & Hüner, 2010). 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), 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 use in companies. All three contributions tackle the topic only superficially. A comprehensive morphological analysis was conducted by Otto and Schmidt (2010). Their analysis, however, does not allow for in-depth insight as to how companies should approach the multiple decisions related to the design of their master data architectures. 1.2. Research problem and contribution The paper at hand has been motivated by the lack of scientific knowledge regarding a contemporary phenomenon. It aims at shedding light on the unexplored question as to how companies should proceed when designing their master data architecture. In particular, the paper wants to illustrate what design decisions companies need to make and what options companies have. Case study research was chosen as a research method because the phenomenon to be studied cannot be separated from its context, and because only little knowledge about the phenomenon exists so far (Benbasat, Goldstein, & Mead, 1987; Yin, 2002). The study uses a single-case design, investigating the master data architecture design at Bosch Group (in the following referred to as Bosch), a multinational and multidivisional engineering company headquartered in Stuttgart, Germany. Single-case study designs are frequently used in IS to study unique or extreme cases. Examples are the work on IT Governance presented by Brown (1997) and the investigation of industry-wide IS standardization by Markus, Steinfield, Wigand, and Gabe (2006). The paper is structured as follows: Section 2 presents a review of the literature related to master data architecture design. Section 3 outlines the research design, before Section 4 presents the case study at Bosch. Section 5 analyzes the findings of the case. The paper concludes with a summary of the major results and an outlook on further research. 2. Literature review 2.1. Master data and master data management Master data identifies and describes central business objects in a company. Frequently cited examples are customer master data, supplier master data, product master data, and material master data (Dreibelbis et al., 2008; Loshin, 2008). But master data may also comprise a shared chart of accounts, employee data, and organizational data (e.g. cost center information). Many attempts have been made to define master data by distinguishing it from other types of data, such as transactional data, contractual data, or inventory data (Knolmayer & Röthlin, 2006; Wieczorek, Stefanescu, & Schieferdecker, 2008). However, this distinction, due to its ambiguity, does not seem to be helpful if one looks beyond individual cases. Contractual data, for example, might be considered master data in the utility industry, because of its stability over time, but might be treated as transactional data in the telecommunications industry, due to contracts being frequently updated or cancelled by online-service customers. Despite the lack of a common understanding of master data both in the scientific and in the practitioners community this paper defines the term for the further course of the investigation as follows: Master data is data about the characteristics of key business objects in a company and is unambiguously defined as well as uniquely identified across the organization. In recent years MDM has received much attention in the practitioners community. To a certain extent, this development has been fostered by large software vendors, who developed dedicated MDM systems. Examples are IBM InfoSphere Master Data Management (IBM, 2011), SAP NetWeaver MDM (SAP, 2008), and TIBCO Collaborative Information Manager (TIBCO, 2008). There is consensus, however, that MDM does not simply refer to a class of information systems, but rather constitutes an application-independent (Smith & McKeen, 2008) business function. According to DAMA International (DAMA, 2009), MDM wants to achieve three goals, namely providing an authoritative source of high-quality master data ( golden record ), lowering cost and complexity through standards, and supporting business intelligence and information integration. Activities to accomplish these goals include, among others, understanding master data integration needs, identifying master data sources and contributors, defining and maintaining the master data architecture, and managing changes in master data. The nature of master data as referring to business objects which are used across the company requires MDM to be organized as a central or corporate function (Otto & Reichert, 2010). Roles such as data stewards and data owners have been introduced to ensure Data Governance within the organization (Khatri & Brown, 2010; Loshin, 2008; Weber, Otto, & Österle, 2009). While data stewards are concerned with ensuring the quality of a certain master data class, data owners have decision making rights with regard to business requirements, use and definition of master data (DAMA, 2008; Loshin, 2008). Bitterer and Newman (2007) use a metaphor to differentiate between the two roles, comparing the data owner to a king who owns the land, but does not do anything with it, apart from riding horses on the land, whereas the data steward is compared to a farmer who takes care of the land by growing crops, watering plants, ploughing fields and so on. 2.2. Master data architecture Design and maintenance of the master data architecture is one of the activities of MDM. The master data architecture controls shared access, replication, and flow of data in order to ensure data quality (DAMA, 2009, p. 181). The scientific body of knowledge regarding the topic of the master data architecture is not very comprehensive. Early contributions can be found in the field of Data Warehousing, which considers the master data architecture to be a prerequisite for standardized and accurate reporting dimensions (Inmon, 1992). In the mid-1990s researchers discussed intensively the concept of Strategic Data Planning, resulting, among other things, in a data architecture (Goodhue, Kirsch, Quillard, & Wybo, 1992; Shanks, 1997). Albeit not using the term master data explicitly, Strategic Data Planning refers to data that is used on a company-wide level. More recent studies addressing the topic of the master data architecture have been a case study on multidimensional databases (Hasan et al., 2000) and an investigation of the product information supply chain in the consumer goods industry (Legner & Schemm, 2008). Furthermore, Allemang made the distinction between linked data enterprise architecture and master data architecture (Allemang, 2010) without specifying the latter any further. The most comprehensive scientific contribution to the topic has been made by Otto and Schmidt (2010). They refer to master data architectures as information architectures the scope of which is restricted to master data. These authors use the notion of information architecture not only to include shared data sources and data flows between data bases into the concept, but also to emphasize the demand for authoritative data standards and definitions (requiring a business perspective on the topic). In their understanding, the master data architecture comprises both a conceptual master data model and the application architecture for master data. The application architecture for master data can be further divided into source and target systems of master data on the one hand and data flows on the other hand. Moreover, the authors identify a set 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 community addressing the general data architecture topic (Brackett, 1994). Numerous architecture frameworks the Zachman Framework (Zachman, 1987), The Open Group Architecture Framework (TOGAF) (Open Group, 2007), Enterprise Architecture Planning (EAP) (Spewak & Hill, 1993), and the Enterprise Architecture Cube (Bernard, 2005), just to name a few consider the data architecture to be part of the overall enterprise architecture. Otto and Schmidt (2010), however, show that these frameworks by definition (due to their overarching approach) are not useful in providing both the conceptual breadth and depth required to investigate, analyze and design a master data architecture in detail. As mentioned earlier, master data architecture is a topic of discussion also in the practitioners community. A prominent aspect in this regard is the question for the right architectural style (Dreibelbis et al., 2008; Oberhofer & Dreibelbis, 2008; Radcliffe, White, & Newman, 2006). Analyst company Gartner, for example, distinguishes between three styles (White & Radcliffe, 2007). Design/construct MDM (1) is needed if a new business is created, operational MDM (2) supports regular operations of existing businesses, and analytical MDM (3) is mainly used for reporting purposes. Oberhofer and Dreibelbis (2008) propose a similar categorization, describing also operational and analytical approaches, but identifying a collaborative method use in addition. Differences between these architectural styles relate to the flow of data between a golden record and data source systems. An analytical architecture, for example, uses a unidirectional flow of data from the source systems to the golden record, using extract, transform and load (ETL) processes before importing the data. Unlike the operational approach, no data is fed back to the source systems in the analytical approach. 3. Research approach 3.1. Research design The paper uses case study research as a methodological approach to examine the contemporary phenomenon of master 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 limited understanding of master data architecture design in companies. Therefore, the central research question is: How should companies proceed when designing the master data architecture? Due to the limited amount of scientific knowledge with regard to this question, the study is of exploratory nature. Yin concedes that in such cases it is unlikely to base one s research on clear propositions (2). However, he stipulates that case study research should have some purpose (Yin, 2002, p. 22) as well as a number of criteria guiding the investigation. The paper at hand uses a simple conceptual framework (as shown in Fig. 1) as a guide for the investigation. This framework is based on findings from practitioners and researchers (see Section 2.2), suggesting that designing a master data architecture comprises decisions on a technical level (e.g. architectural styles) and cannot be isolated from organizational aspects (e.g. allocation of decision-making rights regarding data standards). The unit of analysis (3) sets the boundaries for the case with regard to generalizability of its results. The paper at hand uses a single-case design, studying how Bosch approaches the issue of finding the right master data architecture design. The conceptual framework shown in Fig. 1 functions also as the logic which links the data to the propositions (4), and it represents the criteria to interpret the findings (5). Hence, the conceptual framework serves as a lens through which the evidence from the case is studied and analyzed. 3.2. Case selection and data collection Single-case designs have limitations with regard to replicability of findings, because they do not support theoretical sampling (Benbasat et al., 1987; Eisenhardt, 1989; Yin, 2002). However, the uniqueness of the case (Yin, 2002, pp. 40 41) justifies the design of the study. In contrast to many other companies, Bosch looks back on a relatively long history of having MDM as a corporate function and designing the master data architecture on a company-wide level. In 2006, Bosch introduced a group guideline setting out binding principles for MDM. The group guideline includes an organizational and a technical part. This information together with access to various carriers of knowledge in the organization were available to the author over a period of more than three years. Also, Bosch was invited as a reference to present the basic principles of their master data architecture design at a meeting of the MDM Working Group of the German-speaking SAP User Group (DSAG), which took place on June 17, 2010, in St. Leon-Rot, Germany. The case of Bosch can therefore be considered as highly explorative and suitable for laying the foundations for further, multiple-case research. Data was collected from different sources, as shown in Table 1. The main data source, however, were interviews with experts of Bosch. Transcripts of the interviews were created based on the field notes from the researchers involved. The final case study report was sent to Bosch for approval. 4. Master data architecture at Bosch 4.1. Company overview Bosch is a leading technology and service company with an overall revenue of 47.3 billion Euros and 283,500 employees in 2010. Headquartered in Stuttgart, Germany, Bosch operates in three business sectors, namely Automotive Technology, Industrial Technology, and Consumer Goods and Building Technology. The business sectors span 17 divisions with operations in more than one hundred countries around the world. 4.2. MDM at Bosch Bosch has many years of experience in managing master data on a divisional level. In 2006, though, the company made a first step to organize MDM on a corporate level by introducing a group guideline, aiming at the specification of a company-wide set of goals of MDM instead of going on dealing with MDM by means of rather uncoordinated activities. The group guideline constitutes a binding framework for the management of group master data. Group master data follows the definition in Section 2.1. It is all master data which is used on a group level, i.e. by more than one division. The group guideline does not apply for master data used by single divisions only. The group guideline introduces two roles, namely Master Data Owner (MDO) and Master Data Officer (MDF). The responsibilities of the MDO are the same as outlined in Section 2.1. The MDF role corresponds with the general understanding of the data steward role. The group guideline identifies a set of MDM activities which are divided into organizational/functional activities and technical activities (see Fig. 2). Whereas the former are under the responsibility of the MDO, the latter are under the responsibility of the corporate information technology department. Fig. 2 shows the MDM reference framework at Bosch. It consists of four components, namely Governance System, MD Provisioning, MD Utilization, and MD Concepts & Projects.

340 B. Otto / International Journal of Information Management 32 (2012) 337 346 Organizational Design Decisions Master Data Architecture Design Technical 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 master data class as well as MD Controlling activities, which assess the maturity of MDM for each master data class and measure the quality of the master data. MD Provisioning includes the design and maintenance of an organization for MDM (including MDOs and MDFs), the design and maintenance of master data processes (e.g. creation or update of master data), the design and maintenance of a master data model, and the design and guidance of the application systems used to store and distribute master data. The master data model has a conceptual view (MDO responsibility) and a physical view (IT responsibility). MD Utilization includes the use of master data in business processes and the business application systems supporting the business processes at Bosch. Finally, the framework component MD Concepts & Projects takes a lifecycle perspective on the different master data classes. Related activities include the management of business requirements regarding master data, the design of functional and technical specifications, and the organizational and technical implementation of the specifications through projects. Table 2 summarizes the organizational/functional and technical activities. In 2006, seven master data classes were within the initial scope of the implementation based on the group guideline, namely chart Governance System MD Strategy MD Controlling MD Provisioning MD Utilization MD Concepts & Projects MD Org. MD Processes Business Processes Requirements Management conceptual physical MD Model Business Application Systems functional technical MD Concept MD Applications Systems Implementation Projects Legend: org./functional 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 master data, certain material master data including product hierarchies, and a subset of so-called group elements, which comprise reference data, such as country and language codes. 4.3. Master data architecture context and goals Master data had been managed, of course, by the different business sectors and divisions long before MDM was established on a corporate level at Bosch. Hence, for the management of master data a variety of business processes and application systems had emerged. In the process of implementing master data architectures for the different data classes according to the group guideline, MDM at Bosch encountered difficulties when discussing the introduction of a standard architecture. A standard approach would have meant either migrating all data from existing application systems to a newly installed system (which is not a feasible option in the majority of cases due to cost and organizational constraints), or living with the heterogeneity and not following the policies specified by the group guideline. Moreover, the requirements on the master data architecture, which are derived from the demand from the business units, differ significantly across the various master data classes. Summarizing, three factors prevent a one size fits all architectural design at Bosch. First, there are different business requirements across different divisions and functional departments. Unique supplier master data, for example, is mainly required for reporting purposes in purchasing and compliance with regulations such as being able to block suppliers for purchasing that allow child labor whereas consistent and complete material master data is needed from an operational perspective in sales, manufacturing and distribution. A second factor is the variety of existing applications in different divisions and functional departments. The application system landscape follows a group-wide framework, but, of course, shows differences when it comes to details. Examples are the use of different software vendors for the same class of application systems and different releases of the same system. These differences lead to technical barriers regarding the use of a one size fits all architectural design. Third, there are different levels of organizational maturity with regard to MDM in different divisions and functional departments. Some functional departments have a clear understanding of the requirements with regard to master data quality and the master data lifecycle, while others are in early analysis stages. As a consequence, the idea was developed to offer a set of reference master data architectures the MDOs and other persons responsible could choose from on a case-wise basis. The reference architectures are supposed to support the following objectives: Vendor-neutral representation of master data architecture approaches at Bosch. Accelerated time to market from business requirements to implemented solutions. Support of internal (between central units and user departments) and external (with software vendors) communication. 4.4. Technical perspective In general, master data architecture design at Bosch must be aligned with three parameters, namely the group-wide application system architecture framework, the data governance framework, and the product strategy of the preferred application system vendor. Taking into account these parameters, Bosch identified four basic approaches for master data architectures (see Fig. 3). Approach A is referred to as the analytical approach. It assumes that all master data maintenance activities, i.e. creation, update, and deletion of master data, are performed by local source systems. In case of creation of new master data, the primary key attribute is also assigned by the local system. Data is then periodically imported into a central Master Data Server (), which assigns a global, i.e. company-wide unique, identification number to all imported master data records, and optionally holds references to local key attributes. Duplicate records are identified by the. Approach A is used to support business scenarios which require ongoing data quality assurance and a general overview of distributed and heterogeneous master data in a certain domain. It is used in post-merger situations and in preparation of data migration projects. Approach B is referred to as the transactional approach. It assumes that maintenance of global master data attributes is performed by the. Also, the provides functionality for assigning global identification numbers, workflow support for data maintenance, duplicate checks upon data entry, and export and distribution to local target systems. Global master data can only be read by the target systems; updating or changing, however, is not allowed. Approach B is used in business scenarios with high liability requirements on data. An example of Approach B is the company-wide chart of accounts following the International Financial Reporting Standards (IFRS), where data maintenance is performed by a limited number of subject matter experts. Approach C (coexistence) is a combination of the analytical and the transactional approach. Master data is maintained by local systems, which also assign primary keys to master data records. The data is then imported into a central and assigned with a globally unique identification number. In a next step the data is consolidated by a small number of subject matter experts, handed back to the source systems, and (on request) further distributed to other target systems. Approach C is used in business scenarios which are characterized by highly heterogeneous local business requirements and/or a need for company-wide data integration. An example of Approach C is human resources master data, which needs to comply with local standards but must also be consolidated centrally for identity management as well as for corporate human resources functions, such as competence management and training management. Approach D, the parallel approach, is characterized by dividing up central master data maintenance functionality between a central and local application systems. Users of local systems are supported by workflow management in creating, 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 System 2 System 2 C Coexistence D Parallel Approach System 2 System 2 System 2 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 atomicity, conistency, isolation, and durability of database transactions (Haerder & Reuter, 1983), are synchronized with the central, which also assigns globally unique identification numbers to master data records, checks for duplicate records, and validates the data. In contrast to Approach C, which uses corporate subject matter experts, the parallel approach uses the expertise of local users to consolidate the master data. The parallel approach is therefore used in business scenarios which are characterized by many heterogeneous business rules to be checked during data maintenance and/or a demand for high master data quality. An example of Approach D is master data for machinery spare parts, as this data combines local (e.g. local manufacturer part numbers) with global requirements (e.g. company-wide inventory level visibility). 4.5. Organizational perspective Besides the technical perspective on the master data architecture, the group guideline at Bosch also includes organizational design activities, namely a common definition of master data classes, a definition of their organizational validity, and the conceptual data model. Apart from that, the group guideline also identifies the need for further organizational design activities, namely the definition of maintenance processes (related to the ), the data distribution and deployment processes (related to the target processes and systems), and the assignment of organizational roles. Bosch identified three general organizational approaches, as shown in Table 3. Approach I (central approach) is characterized by a central responsibility for all functional and organizational design decisions related to a certain master data class and also partially by central execution of master data maintenance. Approach II (hybrid approach) combines central and local responsibility, i.e. business unit responsibility for design activities. The execution of master data maintenance activities is assigned completely to the business units. And Approach III (local approach) is characterized by almost complete local responsibility for all functional and organizational design decisions related to a certain master data class. Only the definition of guidelines for maintenance activities is assigned to the central MDO role. Bosch always allocates the ownership of master data classes and the design of the conceptual data model to a central role, i.e. the MDO, even under the hybrid and the local approach. This is a consequence of the policies outlined in the group guideline, which understands MDM as a central function. Therefore, local ownership and local conceptual data models would be contradictory to the objectives of MDM for group master data at Bosch. 4.6. Integrated assessment Based on the identification of both technical and organizational approaches to the master data architecture, Bosch identified a number of feasible architecture patterns, i.e. combinations of both perspectives. As Table 4 shows, Bosch considers five combinations (out of twelve theoretically possible) as feasible. Approach A (analytical approach), for example, is deemed feasible only in combination with Approach III (local approach). The rationale behind this is that there is no need to dictate business units the design of the data maintenance process when the master data is used on a corporate level for reporting purposes only. Instead, it just must be ensured that master data can be consolidated by a central. All other technical approaches may be combined with the hybrid organizational approach, ensuring a balance between local and central business requirements. While the transactional approach is preferable because of its relatively limited technical complexity, 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 (Central approach) II (Hybrid approach) III (Local approach) Organizational allocation of responsibility for master data class Design of data maintenance process MDO defines company-wide maintenance process (standard) MDO, together with business unit representatives and MDF Execution of data maintenance process Central MDO organization, together with business units Design of conceptual data MDO model Examples Customer hierarchy data Customer master data, machinery spare parts, human resources master data MDO Master Data Owner and MDF Master Data Officer. MDO defines principles for No central principles by MDO; company-wide maintenance maintenance processes processes, detailed definition designed by business units done by business units Business units Business units Product hierarchy to Approach I. In general, the technical approach for the hybrid organizational approach (II) depends on the following four factors: Diversity of business processes and systems to be connected. Heterogeneity of data and data models. Timelines of prioritized business requirements ( customers of master data). Feasibility and cost of implementation (as a result of the three factors above). In general, Bosch prefers the parallel approach to the coexistence approach. The latter may be followed, however, when business processes and application systems related to a certain master data class are too heterogeneous, making the parallel approach become economically unreasonable. An example of the coexistence approach is human resources master data. Main reasons for using this approach are: Variance of business processes (including master data maintenance) in combination with country specific legal requirements: while the fact that most human resource departments at Bosch are using SAP systems basically supports the implementation of almost all approaches, the obstacle of diverse business processes remains. Master data could only be cleansed in downstream activities (which prevents the use of synchronous data processes approaches such as the parallel approach). Timeline constraints: users of global human resources master data could not wait for the implementation of the transactional or parallel approach. In this regard, the coexistence approach was used to meet prioritized business requirements when needed, serving as a first step toward the final master data architecture. For other master data classes (customer and supplier data, for example), the factors mentioned above are different (strict central master data maintenance, for example), leading to the preference of the transactional approach from the very beginning of the implementation. Moreover, the parallel approach is preferred to the transactional approach for master data classes which require intensive knowledge from the local business units. An example is material master data, which often requires the knowledge of local plant managers and which is managed through a variety of different business processes. In cases like this, the parallel approach offers more flexibility to the business units than the transactional approach. Bosch uses these five master data architecture patterns as a reference for the various master data classes. Bosch considers these approaches as a means to balance the need for flexibility in the business on the one hand and the demand for reduced technical complexity on the other hand. At present, Bosch is in the process of successively applying the concept to the master data classes. 5. Case analysis 5.1. The nature of master data architecture design patterns The case of Bosch shows that patterns can be very useful when it comes to designing the master data architecture. In general, architectural design patterns are very common in software engineering as they represent a problem-solution pair not only for specific but for classes of architectural design problems (Avgeriou & Zdun, 2005; Buschmann, Meunier, Rohnert, Sommerlad, & Stal, 1996, p. 3). Furthermore, patterns allow balancing standardization on the one hand and flexible design on the other. The current state of research and practice with regard to design patterns for the master data architecture is still at an early stage of development. Otto and Schmidt (2010) identify relevant design decisions and options, but do not come up with comprehensive architectural patterns. And the practitioners community is discussing different architectural styles, such as analytical and operational MDM (see Section 2.2). These styles, however, are too simplistic to explain the architectural patterns in the case of Bosch. Table 4 Feasible master data architecture patterns. Technical approach Organizational 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 main aspects. First, the question of architectural design must not be reduced to technical aspects only, but should rather balance both organizational and technical considerations. This is even more important as such a comprehensive approach would allow to identify feasible patterns. Organizational and technical aspects show strong interdependencies the analysis of which could pave the way for identifying feasible master data architecture patterns. Second, the Bosch case also shows that design patterns for the master data architecture are used as an approach to manage the complexity of the issue at hand. Complexity dimensions are, for example, the number and heterogeneity of different master data classes, the organizational structure, and the use case (White, 2010). However, this point has not been discussed sufficiently in order to be able to explain the case of Bosch. The Bosch case shows the need to include further complexity dimensions when designing the master data architecture. Among those are the separation of functional and technical design responsibilities (see Fig. 2), the diversity of business processes to be supported, and the urgency of action as in the case of human resources master data, for example. It is the combination of this extensive set of dimensions which has led to the design of the parallel approach at Bosch an approach which has not been considered either in research or in practice so far. Of course, the paper does not want to generalize from one case at this point. It is, however, quite likely that the approach of Bosch could be adopted by companies with similar characteristics. 5.2. The organizational fit of master data architecture design The case of Bosch suggests the assumption of the master data architecture being dependent on organizational factors. There seems to be the issue of an organizational fit of master data architecture design. Contingency theory, in general, claims that there is no one size fits all approach to corporate organization. A number of researchers have demonstrated its applicability to enterprise architecture management (Lahrmann, Winter, & Fischer, 2010; Leppänen, Valtonen, & Pulkkinen, 2007; Ylimäki, 2006). These contributions, however, remain very unspecific when it comes to contingencies of the master data architecture. The case of Bosch is novel, as it explicitly addresses the issue of organizational fit of master data architecture design. Apart from that, the Bosch case shows that contingency factors for enterprise architecture management such as modeling capabilities, adopted design paradigms, organizational penetration (Riege & Aier, 2009) are not appropriate to explain the organizational fit of master data architecture design. Contingency factors for the master data architecture are rather business process diversity, urgency of action, heterogeneity of data classes and models, knowledge about master data classes in the business units, and the relationship between group-wide and local MDM activities. Furthermore, the Bosch case shows the tight relationship between master data governance and master data architecture. The group guideline is the overarching reference for data governance questions at Bosch. It sets out roles and responsibilities, also related to the design of the master data architecture. The guideline is considered to be a prerequisite without which the use of master data architecture design patterns would not be possible (see Section 4.6). The silence of the research community, though, stands in contrast to the importance of this aspect. While data governance has received some attention lately (Khatri & Brown, 2010; Otto & Reichert, 2010; Weber et al., 2009), none of the contributions investigates the relationship between data governance and master data architecture in detail. The group guideline at Bosch does not only identify and describe the roles and responsibilities, but it also specifies the collaboration between business and IS/IT departments. The explicit definition of master data architecture related responsibilities between those two communities within Bosch helped manage such a complex issue as master data architecture in a comprehensive i.e. organizational/functional and technical way. This aspect has not been addressed by literature so far either. Some papers exist which examine the roles of business and IS/IT departments in enterprise architecture management in general (Gregor, Hart, & Martin, 2007; Winter & Schelp, 2008), but they do not focus on the master data architecture issue. 5.3. An evolutionary perspective on master data architecture design The case study addresses another important question, namely how master data architecture design is evolving over time. Bosch prefers the parallel approach to the coexistence approach unless there are urgency constraints and the parallel approach to the transactional approach in cases of master data classes which require intensive local knowledge. The fact that preferences are subject to certain conditions implies that architectural design evolves over time. Organizational fit of master data architecture patterns seems to be dynamic rather than fixed. Evolutionary theory has been used frequently in IS research, mainly to explain change with regard to IS artifacts. In general, a combination of evolutionary theory and contingency theory allows to investigate alternative evolutionary paths (Teo & King, 1997). Thus, it might explain when and under what conditions a certain master data architecture design is preferable for an organization. Master data has long since been managed on a local level at Bosch, while the group guideline for MDM is relatively new. In cases like this, a certain carrot-and-stick approach seems appropriate for master data architecture design. Analyst company AMR Research recommends to use central MDM facilitation, not control (Swanton, Hagerty, & Cecere, 2007) which is often easier said than done. However, Bosch follows this idea, using a group guideline as a stick and the provisioning of reference architecture patterns including workflow support and data quality assurance as carrots for local business units. In the course of the evolution of MDM at Bosch in general and the ongoing adaptation of master data architecture patterns, demand for central or hybrid approaches might increase at the expense of local approaches. 6. Conclusions The paper at hand reports on the design of the master data architecture at Bosch. The case shows that designing the master data architecture is a task which combines both technical and organizational aspects. Bosch has specified four technical and three organizational approaches, and has identified five feasible combinations of these approaches out of twelve theoretically possible. The analysis of the case suggests three major findings. First, design patterns for the master data architecture have to include a variety of both organizational and technical design options. Existing contributions from related fields such as enterprise architecture management are not sufficient to explain master data architecture design. Second, master data architecture design is contingent to a number of factors. Due to the nature of master data and the organization of MDM in companies, existing theories should be extended to explain master data architecture design. Important factors which have not been discussed in literature so far but which are specific to MDM include the variety and heterogeneity of master data classes, the adoption of data governance, and the distribution of knowledge about master data across the organization. Third, an evolutionary perspective seems to be required in order to explain master data architecture design comprehensively. Preferences for certain master 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 master data architecture design. Neither the scientific body of knowledge nor the practitioners community so far has reported about a case which allows as much insight into the issue as the case of Bosch does. Thus, the paper s main contribution to the scientific body of knowledge is yielding insight into and understanding of a contemporary phenomenon, which is, at present, rather unexplored. The paper lays the foundation for future research, in particular for multiple-case studies and empirical investigation. Practitioners may benefit from the paper because it offers direction and guidance in the complex task of designing the master data architecture. Limitations exist with regard to generalizability of results. Single-case studies by definition do not allow for theoretical sampling. Hence, the findings of the paper must be triangulated with similar cases. Triangulation must take into account the general characteristics of Bosch, namely the size of the company, the industry, and the multi-national and multi-divisional organization. In addition to that, replication of the findings should also consider the specific characteristics of MDM at Bosch, namely the long experience with master data both on a local and group level, the existence of the MDM reference framework (see Fig. 2) and the adoption of the group guideline across the company. Acknowledgements The research presented in this paper is a result of the Competence Center Corporate Data Quality (CC CDQ). The CC CDQ is a consortium research project and part of the research program Business Engineering at the Institute of Information Management at the University of St. Gallen (BE HSG). References Allemang, D. (2010). Semantic web and the linked data enterprise. In D. Wood (Ed.), Linking enterprise data (pp. 3 23). Berlin, Germany: Springer. Avgeriou, P., & Zdun, U. (2005). Architectural patterns revisited A pattern language. Paper presented at the 10th European Conference on Pattern Languages of Programs, Irsee, Germany. Benbasat, I., Goldstein, D. K., & Mead, M. (1987). The case research strategy in studies of information systems. MIS Quarterly, 11(3), 369 386. Bernard, S. A. (2005). An introduction to enterprise architecture (2nd ed.). Bloomington, IN: Authorhouse. Bitterer, A., & Newman, D. (2007). Organizing for data quality. Stamford, CT: Gartner, Inc. Brackett, M. H. (1994). Data sharing using a common data architecture. New York, NY: John Wiley. Brown, C. V. (1997). Examining the emergence of hybrid IS governance solutions: Evidence from a single case site. Information Systems Research, 8(1), 69 94. doi:10.1287/isre.8.1.69 Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., & Stal, M. (1996). Patternoriented software architecture: A system of patterns. Chichester, UK: John Wiley. DAMA. (2008). The DAMA dictionary of data management. Bradley Beach, NJ: Technics Publications. DAMA. (2009). The DAMA guide to the data management body of knowledge. Bradley Beach, NJ: Technics Publications. Delbaere, M., & Ferreira, R. (2007). Addressing the data aspects of compliance with industry models. IBM Systems Journal, 46(2), 319 334. doi:10.1147/sj.462.0319 Dreibelbis, A., Hechler, E., Milman, I., Oberhofer, M., van Run, P., & Wolfson, D. (2008). Enterprise master data management: An SOA approach to managing core information. Upper Saddle River, NJ: IBM Press. Eisenhardt, K. M. (1989). Building theories form case study research. Academy of Management Review, 14(4), 532 550. Goodhue, D. L., Kirsch, L. J., Quillard, J. A., & Wybo, M. D. (1992). Strategic data planning: lessons from the field. MIS Quarterly, 16(1), 267 274. Gregor, S., Hart, D., & Martin, N. (2007). Enterprise architectures: enablers of business strategy and IS/IT alignment in government. Information Technology & People, 20(2), 96 120. doi:10.1108/09593840710758031 Haerder, T., & Reuter, A. (1983). Principles of transaction-oriented database recovery. Computing Surveys, 15(4), 287 317. doi:10.1145/289.291 Hasan, H., Hyland, P., Dodds, D., & Veeraraghavan, R. (2000). Approaches to the development of multi-dimensional databases: Lessons from four case studies. The Data Base for Advances in Information Systems, 31(3), 10 23. IBM (2011). InfoSphere master data management server. Retrieved on 2011-02-18 from <http://www-01.ibm.com/software/data/infosphere/mdm server/>. Inmon, W. H. (1992). Data architecture: the information paradigm (2nd ed.). Boston, MA: QED Technical Publishing Group. Khatri, V., & Brown, C. V. (2010). Designing data governance. Communications of the 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 on the usefulness of distributed ERP systems. In J. F. Roddick (Ed.), Advances in conceptual modeling Theory and practice (pp. 362 371). Berlin, Germany: Springer. Kokemüller, J. (2010). Master data compliance: The case of sanction lists. Paper presented at the 16th Americas conference on information systems, Lima, Peru. Lahrmann, G., Winter, R., & Fischer, M. M. (2010). Design and engineering for situational transformation. In F. Harmsen, E. Proper, F. Schalkwijk, J. Barjis, & S. Overbeek (Eds.), Practice-driven research on enterprise transformation (pp. 1 16). Berlin, Germany: Springer. Legner, C., & Schemm, J. (2008). Toward the inter-organizational product information supply chain Evidence from the retail and consumer goods industries. Journal of the AIS, 9(3/4), 120 152. Leppänen, M., Valtonen, K., & Pulkkinen, M. (2007). Towards a contingency framework for engineering an enterprise architecture planning method. Paper presented at the 30th Information Systems Research Seminar in Scandinavia, Tampere, Finland. Loshin, D. (2008). Master data management. Burlington, MA: Morgan Kaufmann. Maedche, A. (2010). An ERP-centric master data management approach. Paper presented at the 16th Americas Conference on Information Systems, Lima, Peru. Markus, M. L., Steinfield, C. W., Wigand, R. T., & Gabe, M. (2006). Industrywide information systems standardization as collective action: The case of the U.S. residential mortgage industry. MIS Quarterly, 30(SI), 439 465. 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/>. Open Group. (2007). The Open Group Architecture Framework TOGAF 2007 Edition (Incorporating 8.1.1). Zaltbommel, The Netherlands: Van Haren. 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 systems, Lima, Peru. Otto, B., & Reichert, A. (2010). Organizing master data management: Findings from an expert survey. In B. R. Bryant, H. M. Haddad, & R. L. Wainwright (Eds.), Proceedings of the 25th ACM symposium on applied computing Sierre, Switzerland, (pp. 106 110). Otto, B., & Schmidt, A. (2010). Enterprise master data architecture: Design decisions and options. Paper presented at the proceedings of the 15th international conference on information quality, Little Rock, AR. Pula, E. N., Stone, M., & Foss, B. (2003). Customer data management in practice: An insurance case study. Journal of Database Marketing, 10(4), 327 341. Radcliffe, J., White, A., & Newman, D. (2006). How to choose the right architectural style for master data management. Stamford, CT: Gartner, Inc. Riege, C., & Aier, S. (2009). A contingency approach to enterprise architecture method engineering. In G. Feuerlicht, & W. Lamersdorf (Eds.), Serviceoriented computing ICSOC 2008 workshops (pp. 316 326). Berlin, Germany: Springer. SAP (2008). SAP library SAP netweaver master data management (MDM). Retrieved on 2009-02-19, from <http://help.sap.com/saphelp mdm550/helpdata/ en/43/d7aed5058201b4e10000000a11466f/frameset.htm>. Sarsfield, S. (2009). The data governance imperative: A business strategy for corporate data. Cambridgeshire, UK: IT Governance Publishing. Shanks, G. (1997). The challenges of strategic data planning in practice: an interpretive case study. Journal of Strategic Information Systems, 6(1), 69 90. doi:10.1016/s0963-8687(96)01053-0 Smith, H. A., & McKeen, J. D. (2008). Developments in practice XXX: Master data management: Salvation or snake oil? Communications of the AIS, 23, 63 72. Spewak, S. H., & Hill, S. C. (1993). Enterprise architecture planning Developing a blueprint for data, applications and technology. New York, NY: John Wiley. Swanton, B. (2005). Master data management organizations: A balance of control and responsibility. Boston, MA: AMR Research, Inc. Swanton, B., Hagerty, J., & Cecere, L. (2007). MDM strategies for enterprise applications. Boston, MA: AMR Research, Inc. Teo, T. S. H., & King, W. R. (1997). Integration between business planning and information systems planning: An evolutionary-contingency perspective. Journal of Management Information Systems, 14(1), 185 214. TIBCO. (2008). Managing master data with TIBCO collaborative information manager: A technical overview. Palo Alto, CA: TIBCO Software Inc. Wang, R. Y. (1998). A product perspective on total data quality management. Communication of the ACM, 41(2), 58 65. doi:10.1145/269012.269022 Weber, K., Otto, B., & Österle, H. (2009). One size does not fit all A contingency approach to data governance. ACM Journal of Data and Information Quality, 1(1) doi:10.1145/1515693.1515696 White, A. (2010). The five vectors of complexity that define your MDM strategy. Stamford, CT: Gartner, Inc. White, A., & Radcliffe, J. (2007). Four dimensions of MDM: Understanding the complexity. Stamford, CT: Gartner, Inc. White, A., & Radcliffe, J. (2008). Mastering master data management. Stamford, CT: 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 ERP systems. Paper presented at the 2008 international conference on software testing, verification, and validation, Lillehammer, Norway. Winter, R., & Schelp, J. (2008). Enterprise architecture governance: the need for a business-to-it approach. Paper presented at the 23rd annual ACM symposium on applied computing, Fortaleza, Brazil. Yin, R. K. (2002). Case study research: design and methods (3rd ed.). Thousand Oaks, CA: Sage Publications. Ylimäki, T. (2006). Potential critical success factors for enterprise architecture. Journal of Enterprise Architecture, 2(4), 29 40. Zachman, J. A. (1987). A framework for information systems architecture. IBM Systems Journal, 26(3), 454 470. doi:10.1147/sj.263.0276 ZF. (2010). Annual report 2009. Friedrichshafen, Germany: ZF Friedrichshafen AG. Boris Otto is Assistant Professor at the University of St. Gallen, Switzerland, and Visiting Research Fellow at the Tuck School of Business at Dartmouth College in Hanover, NH. His main areas of research are Data Governance, Data Quality Management, and Master Data Management. His research has been published in numerous international journals and he is member of the Scientific Advisory Board of ecl@ss, the international classification and product description standard. Prior to his current positions he worked for Fraunhofer IAO, PricewaterhouseCoopers, and SAP.