IT infrastructure in tight coordination with their software landscape, business strategy and processes. Since Zachman developed a first framework for modeling ...
PREPRINT, DOI FINAL VERSION: http://dx.doi.org/10.1109/EDOCW.2014.12
From Enterprise Architecture to Business Ecosystem Architecture Stages and challenges for extending architectures beyond organizational boundaries
Paul Drews, Ingrid Schirmer Department of Informatics University of Hamburg Hamburg, Germany {drews, schirmer}@informatik.uni-hamburg.de
Abstract—Today, Enterprises act in an increasingly interconnected world and in different kinds of collaborative networks. They are part of business ecosystems in which they interact with their customers, partners and competitors. The processes of analyzing and planning the intertwinement of business and IT architecture within enterprises has been successfully supported by enterprise architecture management (EAM) approaches. In this paper, we analyze four cases from different industries (health care, logistics, retail, and education) and argue that the intra-organizational concepts of enterprise architectures (EA) and EAM need to be extended to grasp the challenges of the enterprises’ interconnectedness. Beyond the known concepts of extended enterprise architecture and federated architectures, we define five stages of extended architectures. Additionally, we describe challenges and existing solutions, which are relevant for this extended perspective. Keywords—enterprise architecture; business ecosystem; collaborative network; inter-organizational architectures
I.
INTRODUCTION
Enterprises face the challenge of strategically planning their IT infrastructure in tight coordination with their software landscape, business strategy and processes. Since Zachman developed a first framework for modeling entities and the relations among the different layers of an enterprise architecture (EA) [39], a lot of knowledge has been generated in research and practice on how to manage enterprise architectures [15][32]. Today, many companies try to leverage the use of enterprise architecture management (EAM) to better support the tasks of strategic alignment, business-IT alignment and project portfolio management [42]. Documenting relevant parts of an enterprise architecture and keeping the documentation up to date are time consuming tasks. Additionally, interfaces to other processes have to be implemented [42]. While more and more firms seek to establish and extend their EA activities and management, they often do not take into account that their company is not isolated from other companies in terms of IT and processes. Instead, companies today are to an increasing degree intertwined with their business partners in collaborative networks and act in complex business ecosystems.
During the last decades, many companies became part of one or many forms of collaborative networks like virtual enterprises, global value chains, holdings or trade cooperatives [7]. These forms can be observed in practice, but they have also attained attention in research. Information systems (IS) research has taken these inter-organizational forms of collaboration into account as they are often supported or even enabled by the use of IT and IS [14][16][41]. Though concepts like extended enterprise architectures [36] or federated architectures [40] address inter-organizational issues, they do not support the extension towards business ecosystems so far. In this paper, we address the question of what challenges emerge, if EA and EAM are extended to a business ecosystem perspective. Furthermore, we seek to define stages of extending EA and EAM towards the business ecosystem perspective. To tackle this task, we first introduce the basic terms and then summarize the state-of-the-art of interorganizational EA and EAM by discussing related research. This is followed by the description and discussion of four case studies we conducted in health care, logistics, retail and education sectors. These case studies are used to identify challenges that emerge in inter-organizational scenarios in these domains. In the next step, we draw on existing approaches to identify possible solutions for those challenges. We close with selected open research questions for analyzing, understanding and managing business ecosystem architectures. II.
RELATED RESEARCH
In this chapter, we introduce basic terms and definitions of EA and EAM. Afterwards, we describe the origin and perspective of the business ecosystem approach as published by Moore and others. In the third part, we summarize our findings on similar approaches in the literature that seek to extent the horizon of EA and EAM beyond the organizational borders. A. Enterprise Architecture and its Management The concept of enterprise architecture has been a research subject for more than 20 years [39][15][32]. Though some similar ideas have been published earlier, the Zachman framework is often referred to as a great first milestone for
grasping and modeling the complexity of the business-IT relationship in companies [39][15]. Research and practice pushed the development in this field forward during the last two decades [13][32]. However, during the last decade, EA and EAM gained more attention in research and practice [23]. One of the main reasons is the degree of complexity that IT and process landscapes in large companies have reached today. Making strategic decisions and tracing their implementation can profit from a transparency on the interrelation of strategy, processes and IT [42]. As more and more processes today rely on IT, it is a necessity to analyze strategies and processes in relation to the IT and to understand their interdependencies.
ecosystems, enterprises accept, share and follow the visions of a few leading companies and align their own portfolio of services, investments and strategic decisions with it [11][19]. The resulting relations among the ecosystem members are usually long lasting and follow generally agreed rules. Yet, the ecosystem is deliberately left open for new members and niche players and for flexible new services being composed out of different partners' services, i.e. by using common platforms or brands [11][19]. This way, Business Ecosystem members mutually influence each other and develop themselves further in co-evolutionary processes.
According to the IEEE standard 42010:2011, architecture is defined as “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” [13]. Enterprise architectures have been defined in various ways in the literature. According to Winter and Fischer’s literature review [37], five general layers of enterprise architectures build a common basis in the existing literature: business architecture, process architecture, integration architecture, software architecture and technology architecture. Beyond an information system architecture, it also includes business artifacts like goals, products and services, markets, business processes, etc. [37].
C. EA and EAM in Collaborative Networks and Business Ecosystems Though most research and literature in the field of enterprise architecture and its management focusses on single enterprises, some publications address issues of inter-organizational use of EA and EAM. In this section, we look at TOGAF, a literature analysis on the applicability of TOGAF for network organizations, a literature review on layers and artifacts of EA, the business model approach, business processes in the large, inter-organizational information systems and the federated enterprise architecture approach as related work for our topic.
The goals and benefits of enterprise architecture management (EAM) are described as achieving transparency, improving business IT alignment and strategically controlling the IT [1][9][36]. Transparency can be realized on each of the above-mentioned layers and across the layers by documenting and structuring the components of an EA. Though IT has often been developed from an IT perspective, it is also seen as a mean to provide a common language for business and IT [36]. This common language can lead to a better understanding of the business-IT relationship and improve the business-IT alignment as the IT black box is opened. The function of enterprise architecture management is supposed to acquire the data needed to document the as-is architecture as an important input for strategic as well as for operative decisions in the company. Furthermore, it should gather information and plan a to-be architecture of the company in the future and the transformation steps leading to the new status (roadmap) [24]. B. Collaborative Networks and Business Ecosystems For capturing and understanding the extended environment in which enterprises act today, several concepts are discussed in the literature. While many of them focus on the collaboration of enterprises in different forms of collaborative networks like virtual organizations, supply chains or industry clusters [7], others also include competitors and customers as important actors. One concept, which received increasing attention during the last years is the concept of business ecosystems, which was introduced by Moore in the 1990s [18][19]. The concept links basic principles of natural ecosystems to capitalist economies [31] and includes a diversity of actors ("inhabitants" of different size, influence and tasks) and roles [11][12], co-evolution, emergent behavior, self-organization, adaptability, decentralized governance, collaboration, competition and co-opetition [4]. In business
TOGAF, as one of the most elaborated and widespread frameworks for EA, states in its 9.1 version that it may be applied in so-called extended enterprise scenarios [36]. In these business-to-business scenarios, partners, suppliers, and customers are integrated into the architecture analysis and planning. In TOGAF’s core document, the term extended enterprise is only referred to in a few parts. It is mainly considered as a part of the interoperability (29.2) and enterprise operating model sections (29.3). The focus lies on the integration of processes and data across enterprise boundaries. While TOGAF names the possibility of including such entities in the architecture development process, they are only described from the perspective of a single central enterprise. Defining TOGAF as the standard framework is described as a way to support cooperation among different enterprises [36]. A common language and architecture layers are seen as means for supporting integrated processes and IT support across large companies and between different enterprises. Müller et al. performed a literature review on the applicability of TOGAF 9.1 for network organizations [20]. They found out that the challenges, which arise in network organizations, are only partly covered by the TOGAF framework. While challenges in areas like process and data integration, governance, infrastructure and application integration are covered to a certain extent, this does not hold true for organizing the network and social issues [20]. For the two lastmentioned areas, TOGAF only states that it may be used as a common language and perspective, which may help different actors to communicate and negotiate on architectural issues. Some meta-models in the literature include entities in the business architecture, which are not part of the enterprise itself like partners or customers. Aier et al. present the results of a literature analysis on EA [1]. In their combined model, the strategy layer comprises elements like ‘market segments’, ‘interaction with the customer’ and ‘interaction with suppliers’.
While all these elements refer to entities outside of the company, they are all integrated into the strategy layer. Hence, the elements are looked at from an inside perspective. These elements are needed, for example, when the enterprise architecture comprises business models for answering business model related concerns [29]. As business processes are a central part of enterprise architecture, considering approaches for extending traditional viewpoints on business process management (BPM) turns out to be useful. By coining the term of “BPM-in-the-large”, Houy et al. summarize challenges to BPM, which occur due to the high number of processes in large companies, due the use of BPM in value chain networks and because of the adoption of new technologies like mobile devices or sensor technology [10]. Houy et al. identify categories of challenges like strategy development, definition and modelling. As a perquisite for integration, they also address the issue of common ontologies, which is also relevant for integrating EA data across different organizations. During the last decades, IS research has intensively discussed the chances and challenges of inter-organizational information systems (IOS) [14]. These systems are used to connect the systems of several actors in a supply chain or network organization with each other. However, the approaches of IOS and EA have not been integrated on a general level so far. Distinct cases describe the use of EA for the supply chain of a bookseller [35] or systems-of-systems in healthcare [3]. In the federated architecture approach, the architectures of semi-autonomous and decentral organizations are linked to each other by a common language [40]. Like in TOGAF, Zachman recommends to use a common framework in such settings. His focus lies on complex enterprises with “a number of business units that are grouped into clusters in which there is high probability of commonality” [40]. Among these different business units and their sub-units, the framework should be used to define “slivers of sameness” to align parts of the units’ architectures while keeping other parts different from each other. Here, the governance of the architecture comes into play. To identify parts of the different architectures that should be made explicit and to decide, which parts should be subject to a redesign, Zachman argues for “a governance process […] at the cluster and enterprise levels as well as at the business unit level” [40]. The main task in these processes is to decide on which parts (or “cells”) should be reused and standardized. This governance perspective fits to the subject the federated architecture approach addresses: complex, multi-business unit enterprises. It is not directly applicable to network organizations, collaborative networks and business ecosystems. To conclude, the literature on EA and EAM today already includes steps of extending the horizon beyond the organizational borders. It mainly provides three important insights: (1) External entities should be included in the EA for answering concerns that require the consideration of customers, customer segments, partners, or business models. (2) The EA should be enriched with data of the processes and technical integration layer for analyzing and designing the “extended enterprise”. (3) A common language and a common framework help to support the alignment of architectures of
different actors whether internal or external of the enterprise. However, none of these approaches describes means for dealing with the task of aligning and interconnecting architectures when no common framework is available. Furthermore, it is not yet clear, how architectures of other actors in an ecosystem can be analyzed, documented and taken into account in a focal companies’ strategic IT management tasks. Lastly, the literature does not deal with the issues arising when IT interventions are planned for large business ecosystems and these interventions need to analyze and plan the business ecosystem architecture. III.
METHODOLOGICAL APPROACH: FOUR CASE STUDIES
Our research is based on four case studies [38] we conducted in different industries. The first case is located in the health care system and analyzes the usefulness of EA and EAM in the context of the German national health card project. The second case analyzes the introduction of IT innovations in the logistics industry. The focal organization of this case is a container terminal operator in an international harbor. In the third case, we analyze the use of EA and EAM from the perspective of a company, which develops software for the educational sector. The last case is located in the retail sector. Its focal actor is the IT service provider of a large trade cooperative. We selected these cases, as the focus of EA goes beyond the boundaries of a single organization in each of them. The cases provide different challenges for making EA and EAM approaches useful in inter-organizational settings of business ecosystems. To gather the information needed for describing the cases, we conducted expert interviews [22], co-developed models of the EA with the experts and considered further material like documents, publications and existing EA models [2][21]. IV.
FOUR CASE STUDIES ON ENTERPRISE ARCHITECTURES IN BUSINESS ECOSYSTEMS
A. Health Care: Building a National Health IT Infrastructure Setting the scene: For several years, the German government is planning and implementing a national healthcare infrastructure as a part of the electronic health card project. This projects aims at establishing an infrastructure for providing services like electronic patient record, secure transmission of electronic documents, electronic prescription, emergency record, and drug safety checking [34]. The project lacks several years behind the original schedule. Though the introduction of the electronic health card should – according to the law – start in 2006, the insurance companies issued most of the cards in 2012. Today, it is not clear which of the planned applications will be implemented at what date. Since the project started, many actors are actively trying to influence it according to their interests. Focal project: For our case description, we focus on a subproject, which aimed at implementing an electronic prescription nationwide. The paper-based prescription process should have been transferred to a chip-card based process in which the prescription data was to be stored on the card in a
first step and in the telematics infrastructure in a second step. The implementation of the electronic health card and the telematics infrastructure is part of a law, which has been passed by the German legislation. While the implementation of the electronic health card is lacking years behind the original time plan, the introduction of the electronic prescription is completely stopped today and it remains unclear if and when it will be continued. We have analyzed this case from a research perspective to identify the reasons for failure in this project. This project affects a multitude of actors and definitely requires an architectural perspective, which is much broader than that of a single organization or an individual actor. Current use of EA & EAM: Though this project has not yet taken steps to actively modeling an EA and establishing an EAM, the central service provider established by the government (gematik) provides many documents describing artifacts on the different layers of an EA. Many of those artifacts describe the exchange of information among different participants of the health care system. However, the documents on the telematics infrastructure are mainly normative and technical documents. From an external perspective, it is unclear which kind of modeling the gematik uses for planning the telematics infrastructure internally. There is no information available to the public, which shows that the gematik uses EA like approaches. Towards an extended perspective of EA & EAM: In the project, the gematik as the central actor did not take account for the other actors’ local architectures. The introduction of the electronic prescription mainly failed because of two reasons: First, the project planning did not thoroughly analyze the local enterprise architectures of physicians and hospitals. The new prescription process included a digital signature that need to be performed by the physician. While the new process takes approximately half a minute longer than the old process, this turned out to be a problem as several hundred million prescriptions are issued each year. Therefore, a small change in this process had a tremendous effect. The whole planning process also did not take notice of the heterogeneity of processes in hospitals (e. g. centralized vs. decentralized admission), the need for installing new network outlets for the card terminals or the encryption capacity of the ‘connector box’ and its chip card. Though the central actor gematik should have analyzed and understood the architectures of the hospitals and physicians’ practices, it failed in doing so. The reason for this problem is partly based on the governance structures of the German health care system. The interests of the physicians and hospitals were brought into this project by their national interest organizations (German hospital foundation, German medical association). However, these organizations did not have sufficient information on their own members’ architectures and did not actively shape the project due to a lack of IT competence. Furthermore, the application of the electronic health card had – according to a leaked cost/benefit-analysis – the lowest net benefit of all applications. Additionally, the distribution of costs and benefits was not balanced among the actors. Instead, the additional work had to be done by the physicians and pharmacists while the health insurance companies would profit
from the electronic prescription. Identifying and analyzing such local impacts of global changes requires the consideration of process details and quantities on each layer and aggregations of such data for gaining an overview. B. Logistics: Introducing IT Innovations in Container Handling Setting the scene: Our second case is located in the container logistics sector, which is characterized by worldwide end-to-end transportation services being composed out of single services. Several large forwarders as well as container and vessel operators cooperate with thousands of small transportation providers, often on an ad-hoc basis. Accordingly, the information flow, which is separated from the container flow, uses different media: paper, fax, phone, email and electronic interfaces based on standard protocols. Due to the plethora of actors and the diversity of media, this heterogeneity causes media discontinuities and redundancies. Hence, improving data quality is an important issue here. Focal project: In our case, we take the perspective of a container terminal at an international harbor. The terminal acts as a pivot between land and sea transportation with the yard as its center. The yard buffers the incoming containers before they can be shipped (or picked up). It also serves as an optimization device for the speedy uploading of containers to large vessels. Hence, for the terminal, it is of high important to receive a container’s destination as early as possible in order to optimize its position in the yard. Usually, two different channels of information are used. The first and authorative stream stems from the container operators, cooperating with the terminal on the basis of long-term contracts. Container operators provide lists of containers to be uploaded on a certain vessel. This information is often received too late for optimization purposes. The second stream stems from truckers arriving at the terminal’s gate. In order to be allowed to pass, truckers have to provide information about the containers they deliver. In former time, this information was provided on paper. Checking this information required valuable time at the gates, which are of limited capacity (regarding the many trucks that should pass it quickly). More important, the media discontinuity by typing the given information in information systems for checking was error-prone. Furthermore, for the incoming truckers (that share the wish of crossing the gate as quickly as possible), the quality of information is not in their concern. They are paid for the number of tours they perform, not for the information they deliver. The terminal's interest was to intervene into parts of its business ecosystem in order to improve the timely information flow and its quality. In order to accomplish this, the terminal had to understand the information flow outside its own realm. It needs to identify redundancies, possible sources of failure and poor information channels. In addition, it had to be aware of the different relationships (in terms of influence, power, dependency, etc.) to the actors involved. This information can be used to identify the most promising “spots” for intervention. Furthermore, it had to take into account the actors’ perspectives and interests. The starting point, as briefly
mentioned above, was paper-based information, which had to be delivered at the gate. Since the paper-based information had to be electronically processed and matched with background data before a truck was allowed to pass, this procedure caused waiting times, was personally intensive and error-prone due to the change of media. The first intervention was transforming the process by using self-service terminals. Instead of delivering papers, truck drivers were asked to deliver the respective information by typing it into the self-service terminals offered at the gate. Not all truck drivers used the devices and others - as known well from socio-technical approaches about the interpretative flexibility of IS use in organizations [25][26][27] - entered partly non correct data (e.g. data from the last tour) - so that the data quality was not sufficient. Again, this less successful intervention caused the terminal to gain more knowledge about the external partners (in this case: about the situation of the truck drivers and their working situation). Similar to ethnographic methods, the terminal analyzed this situation by accompanying truck drivers on their sequence of tours. Furthermore, the terminal analyzed the information flow between truck drivers and the truck companies’ dispatchers. This analysis directed the second intervention towards different channels for information flow. In a second intervention, other channels for information flow were chosen. Instead of truck drivers, the truck companies' dispatchers now should deliver the information in advance electronically. This has the further positive effect, also for the truck companies and their interests, that failures in tours (e.g. wrong terminal, wrong time) can be handled in advance. Due to the shared interests, the terminal could convince the truck companies to agree to the change. In a third intervention, the still needed matching from trucks/containers with the incoming information is now altered from human to machine recognition using OCR (optical character recognition) gates which automatically identify trucks and containers. Interestingly, by analyzing these aspects, the terminal realized for the first time in depth that they are operationally depending on many service providers (involved in the overall end-to-end transportation services assigned and coordinated by forwarders) without being contractually related to them. Consequently, the terminal is not able to exert any direct pressure on these actors (e.g. truck drivers in delivering high quality information). Instead, they need to know their interests (e.g. quick passing of the gate) and have to value these or at least to consider these. Furthermore, the terminal had to position its own interests and strategies regarding actors on which they contractually depend. The terminals competitive advantage lies in delivering a quality service with high flexibility. This flexibility (e.g. last minute changes regarding uploading containers on vessels) even though possibly interfere with its own interests (for yard optimization) is a central demand of the customers. Based on a quite comprehensive analysis, the chosen leverage was to improve the second incoming stream of information stemming from truckers. The terminal tried to apply IT innovations to improve the situation. For successfully improving the situation at its gate, the terminal needed stepwise iterations, due to less successful outcomes of interventions or due to new IT innovations, which were
upcoming and applicable. Throughout the process that lasted over four years and is still ongoing, the terminal's insight in its business ecosystem still grew. Current use of EA & EAM: The terminal operator has established a basic EAM. Until now, the EA models do not include information on suppliers and the architectures. The terminal operator has started to develop models that go beyond the internal perspective and include details of the different contract types. However, these models are not yet integrated into the EA model. Towards an extended perspective of EA & EAM: Overall, the intervention iterations show that by intervening in processes outside of the own organizational realm a thorough understanding of (at least portions of) the business ecosystem is indispensable. The terminal had to understand, identify and measure: inter-organizational processes and information flow, business objects, electronic interfaces, quality of information flow, sources for errors, weak channels business/contractual relationships to several actor classes, dependencies on actor classes, their interests, numbers and size global IT innovations, adoptability in the respective business ecosystems “insight knowledge” of actor classes, excerpt of EAs of selected actor classes (in order to identify leverage for or plan concrete intervention) C. Education: Understanding the Customers’ and Partners’ Architectures for Becoming a Keystone Player Setting the scene and project focus: Our third case study is located in Germany's federally organized educational sector where a small software vendor is in need of an analytic framework to adjust and redefine its own strategic position, service portfolio and software engineering activities to the demands of his ambient business ecosystem. The software vendor tries to achieve a leading role by providing a web-based platform for schools. It also invites other vendors to contribute to this platform. With these steps, the company aspires to establish long-term partnerships with both customers (i.e. schools) and partners. Current use of EA & EAM: As a basis, the vendor has usually the following knowledge about its existing portfolio and related entities: as-is IT products and services with quantity structures such as market share, revenue streams over time, related development processes and used technologies (e.g. development environments, IT-infrastructure), skills, distribution and marketing channels, as-is customers and partners with quantity structures. In our case, the software vendor did not have a model with this information in place. Towards an extended use of EA & EAM: In order to develop their new strategic position by identifying/shaping tobe IT-products and -services (which will alter the above mentioned entities), they have often to gain more, enhanced
and in-depth, knowledge about the business ecosystem they are acting in. They have to understand and identify:
general influences on the educational sector, such as changes in population, directives from politics, characteristics stemming from federal differences, intended interconnections and interactions (e.g. shared data and educational services) between educational institutions, legal perspectives
IT innovations, their influences and upcoming trends in the educational sector, esp. regarding communication among pupils but also between teaching personnel and pupils or parents, new opportunities for IT products and IT services, extended or altered resources for developing them, such as required skills and changed development processes
categories of actors in the business ecosystem together with quantity structures/estimations/interests (number, size, (IT) budget, influence, intentions etc.), e.g. school types, decision makers in the educational system (being responsible for IT infrastructure and IT services), competitors, their product portfolio and its distribution
customer types, their interests and structure, i.e. demands/requirements in terms of new IT products and IT services, typical school EAs (either for identifying needs or in detail towards identified demands), estimation of transformation costs (effects) towards use of new products or services
competitor types, their influence and portfolio, dominators/niche players, age, evolution, potential, portfolio, distribution of IT products and services, market share, overlapping or complementary IT products and IT services (to the own portfolio), used technologies, standards and interfaces, as-is and possible to-be partners
For a small software vendor this means to iterate in analyzing these different ecosystem elements in order to receive an overview, which can be improved stepwise. On this basis, to-be business models, i.e. IT products and services, can be discussed, developed and evaluated. Required resources regarding consequential internal transformations can be estimated. Expected results of related external interventions can be discussed based on the information available. D. Retail: Alining Architectures of Autonomous Orgnizations in a Trade Cooperative Setting the scene: Our fourth case study was conducted at the internal IT service provider of a leading trade cooperative in Germany. The supermarket cooperation has a special legal structure that makes it different from other large companies. Autonomous merchants own the supermarket stores. These merchants are organized in regional cooperatives. These cooperatives own the trade cooperatives central organization and half of the regional organizations. The other half of the regional organizations is held by the central organization. This
bottom-up structure of autonomous store traders and the regional organizations are a difficult terrain for implementing standardized IT and governance processes. However, the central organization decided to implement a standard enterprise resource planning system for the whole organization. Because of the traders’ and regional organizations’ autonomy, the systems adoption was only directly controllable for the central organization. The regions had to be convinced to adopt the new system; they could not be forced to do so. Project focus and current use of EA & EAM: In 2012, the internal IT service provider of this trade cooperation started an EAM implementation project. While the project mainly focuses on describing and managing the EA of the internal IT service provider, it should have the perspective to be extensible for a future extension of EAM for the whole organization. However, the central IT service provider does not have the means for creating an EA model for the whole organization, which includes the regions and individual stores. The first reason is, that each region can decide on their own whether they like to participate in the project or not. The second reason is that the central IT provider cannot gather the data needed for an EA model without the regions’ permission to do so. Hence, establishing a comprehensive EA model within this setting requires the involvement of actors, which can act autonomously. The IT service provider therefore needs to convince the regions to participate in the project by demonstrating the usefulness of EAM. This situation is different from the one that is classically assumed for establishing EAM in single enterprises. Towards an extended use of EA & EAM: During the project, process models from several regions were analyzed and compared with each other. Though some regions use the same modeling tool for their processes, there were no modeling conventions. Consequently, different terms were used for the same processes and the number of process layers varied across the models. This situation may be cleared by defining standards for documenting processes (which not necessarily need to be adopted and applied by the regions). However, the need for linking the regions different models still exists. While this problem became visible on the process layer, it can be assumed that it does also exist on other EA layers. Due to the similar structure of all seven regions, some interesting questions regarding the EA can be formulated for identifying differences among the regions’ architectures. Another interesting architectural aspect in this project emerged from the use of a central ERP-System. As a part of the project, a special kind of reference model has been developed for the regions. This reference model is called template. None of the regions applies this template as it is. Instead, it is implemented in modified versions. From an EA viewpoint, this template can be considered as a virtual EA with no real instantiations. Like comparing the differences among the regions’ EA, this template architecture can be used to compare the situation in different regions. This special template model needs a proper tool support to be used for this purpose.
V.
STAGES OF EXTENDING EAM TO BEAM
Based on the four cases described above, we have identified five stages between EA / EAM and BEA / BEAM (see Table I.). The first stage describes EA and EAM as it is generally understood in the literature with an internal perspective of single organizations. In the second stage, external entities like customers, partners, and suppliers are included into the EA of a central actor. These entities are connected to the business layer of the EA. Therefore, additional concerns such as business models, innovative channels to the customer, and supply chains that include partners or customers can be addressed by the extended EA. Though models like TOGAF 9.1 [36] or the model of Winter and Fischer [36] refer to those entities, they are not yet used intensively when defining EA concerns [6] or EAM management practices [42]. TABLE I. Stage Enterprise Architecture (EA) Extended Enterprise Architecture (EEA) Federated or Collaborative Network Architecture (FA/CNA) Focused Business Ecosystem Architecture (FBEA) Business Ecosystem Architecture (BEA)
STAGES FROM EA TO BEA (Extended) Focus
core business, internal focus EA + customers, partners, and suppliers – modeled and managed from a focal actor’s perspective EEA + several actors in a network are exchanging selected parts of their EA and negotiate about standards, interfaces, inter-organizational processes, etc. due to a common interest or project FA/CNA + EA of selected customers, partners, and suppliers / reference EA, to-be/reference EA of customers modelled by a software vendor FBEA + general overview of infrastructure and interfaces to all connected EA, including details of many actors’ EA
If the situation in the retail case or the logistics case develops further, the actors involved might agree on exchanging and aligning certain parts of their architectures (“boundary architectures”). Information is shared to discuss common initiatives for improving the situation for all participants. A central player might take a leading role and get the mandate to organize this information exchange. Based on the concept of federated architecture, we call such a viewpoint a federated or collaborative network architecture. The fourth stage is called focused business ecosystem architecture. In this stage, a central actor decides to analyze details of its customers’, partners’ or suppliers’ EA in order to plan and accomplish interventions that will affect these actors. However, the analysis does only include the EA of selected actors (from a whole actor class). For example, the different EA of customers may be analyzed be selecting a representative actor (or a small number of those actors) from each customer segment. In the education case we have presented above, the software vendor analyzes the EA of schools for gaining insights into their architectures. This information is used in a second step for defining the focal actor’s strategy and product planning, which in the end (the resulting product) will cause a transformation of the school’s EA. Furthermore, the vendor tries to surmise the EA of its competitors and their influence on
the school’s EA. This information can be used for defining a platform initiative (to either win competitors to become partners or estimate the possible success of the initiative/intervention) to become a keystone player in the respective ecosystem. In successfully intervening with a platform initiative, interfaces, standards and processes have to be aligned with those of its customers and partners. If the software vendor manages to implement a platform in the ecosystem, it does not only need to model and analyze to-be architectures but it also needs to model the transformation of the operational architecture. With an established platform, this as-is architecture has to consider and include elements from the customers’ and partners’ architectures (“boundary architectures”). In the fifth stage, a central actor is willing to or has the obligation to get an overview on a whole ecosystem. We call this stage the business ecosystem architecture. In the electronic health card case, the gematik was founded to define standards for the central telematics infrastructure and to supervise its operation. To accomplish this task, it needs to analyze and understand not only a few selected actors in the ecosystem and their individual architectures. Instead, it needs to develop an overview of the whole ecosystem (hospitals, practices, etc.) and keep it up-to-date. VI.
CHALLENGES OF EXTENDING EA(M) TO BUSINESS ECOSYSTEM ARCHITECTURE (MANAGEMENT)
The four cases presented above all address challenges related to EA and EAM. While some of those challenges are known from past EA research and practice, others address new issues as a consequence of the extended perspective. In this section, we describe the challenges for business ecosystem architecture management (BEAM) as derived from the four cases. We identified 16 challenges and grouped them into four categories (see Table II.). In the first category, we identified challenges which address the (meta-)modeling of the EA. Second, some challenges affect the tool support for modeling and managing the extended EA. With the extended scope of business ecosystems, the management of the architecture faces several limitations due to the autonomy of the actors involved. Fourth, we see socio-technical challenges for BEAM. This category summarizes challenges that need to be considered due to the increasing amount of actors involved in the architecture. A. Challenges regarding the (meta-)modelling of EEA and BEA In the category of (meta-)modeling, we identified the challenge of extending meta-models by including entities from partners, customers, and other relevant actors throughout the layers of the enterprise architecture. Adding them to the strategic layer is not sufficient. Processes, applications and infrastructure of other actors need to be considered to answer concerns that require further details on the lower layers (e. g. which processes of whom will be effected by a project aiming at exchanging a certain application). The second challenge in this category is relevant for collaborative networks that seek to standardize certain parts of
its actors’ architecture, as we have seen in the retail case. A central actor or an actor who is assigned to do so may generate a virtual to-be architecture or template (e. g. for a large enterprise resource planning system). TABLE II.
CHALLENGES FOR EEAM AND BEAM
Category
Challenges inter-organizational interfaces on all layers, finding the right level of abstraction, identifying shared business objects templates (virtual architectures), applying pattern
Modeling EEA and BEA
EA vs. “EA light” for selected different actor types ultra-large scale architectures with a large number of actors in BEA alignment of existing models shared ontologies open standards for data exchange (import/export)
Tools tool support for ontologies autonomy of actors / lacking governance identify inter-organizational opportunities Management
information governance inter-organizational tasks, roles and processes business ecosystem architecture service provider citizens and consumers as actors
Sociotechnical
lifeworld of customers and partners, etc. internet of things / smart objects
The discussion of differences between the as-is architectures in the individual organizations and the virtual tobe architecture (or template architecture) may provide useful insights. These differences can also be analyzed when the template architecture has been used as a basis for or concrete implementation in one of the regions. The actors than can identify best practices, question decisions that were made to deviate from the standard or use the common structure to discuss the effects of planned changes for each actors local architecture. If a focal company seeks to include greater parts of other actors’ architecture into their own models, they have to decide how detailed a model of the other actors architecture should be. In the education case, we have seen that the software vendor tries to get an in-depth overview of the schools’ architecture. This is not the case for the software partners and competitors. Due to limited access to the required information and distrust, that information will not be available in a similar degree of detail. Hence, some of the other actors’ architecture may be modelled in detail while the architecture of other actors is only modelled in an “EA light” version, e. g. comprising only general processes, applications and their relations. When an actor strives for building a model of a business ecosystem, this will in many cases result in an ultra-large
scale architectural model. In the health care case, several thousand actors in the ecosystem and their respective architectures have to be considered. Companies that plan or run an infrastructures with dimensions like the German telematics infrastructure need to generate and keep an overview on relations in processes, data flow, interfaces and at least parts of the other actors’ architecture. This leads to ultra-large models for which processes have to be established to keep the data up to date and which allow a “zooming in” and “zooming out” between an overview and details on the lower levels. A distributed creation and maintenance of the model has to be organized. When partners, customers, and suppliers come together to discuss changes or interventions in an ecosystem or they seek to strengthen cooperation, they need to align their models to a certain extent. This alignment may be supported by choosing a common framework, as it has been suggested by Zachman and the TOGAF framework. However, with a growing number of actors, an agreement on a common framework will be unlikely. For example, larger companies will rather use larger standardized frameworks while smaller companies may seek to build their own simplified meta-model without drawing on any standards. Even if a decision on a common framework may be hard to reach, it can be useful to spend some work on building shared ontologies including major general concepts that are the most necessary ones regarding common concerns. Barriers for reaching such a goal may be similar to those from other fields that seek to build a common ontology. Standardization bodies or inter-trade organizations may support the process of building a common ontology. B. Challenges regarding the tool support In the cases we have described above, and in the stages we have identified, there are several challenges that arise regarding the tool support. As large models of enterprise architectures and its extended versions can only be handled with the help of proper tools, these tools need to provide better support for inter-organizational matters. Though EAM tools today support different ways of data import and export, the exchange of data among different tools today is not easy. The tools support standard formats like XML to exchange data. However, the underlying structures in the import and export files are not compatible and need to be transformed with complex operations. While common frameworks might be a solution in organizations that cooperate closely, the support for ontologies in the meta-models might be a step toward making the data of different meta-models compatible. C. Challenges regarding the management of EEA and BEA Many (especially larger) organizations have established structures for IT governance, today. Without a proper integration into other processes, the benefits of EAM cannot be realized [42]. Other processes need to be informed regularly and should consume information from the EAM to meet betterinformed decisions. In inter-organizational settings, governance structures are often determined by the inherent autonomy of the actors involved. Depending on the type of cooperation (or competition), forums for the exchange on EA issues have to be established. In the retail case, regular
meetings between units dealing with process management were established before the EAM project started. Though there were no central guidelines, the people involved found it useful to share the insights on their experiences. Such a forum might be a first step for building trust and semi-formal structures to support the exchange of EA related information. If an inter-organizational exchange on EA issues is established, the involved actors can draw upon this for identifying opportunities for improving each member’s architecture. In the logistics case, the forwarders had to understand the effects of their own information management behavior on the terminal operator to implement changes in their IT systems and processes. Though it seems to be a demanding task, it might be necessary to establish an overarching information governance for certain ecosystems (e. g. for a certain harbor), to identify and address shortcomings in the inter-organizational information flow. Each company involved in such inter-organizational activities has to define its own tasks, roles and processes. The people involved in these processes do not only need to understand the complexity and details of their own architecture but they also need to see it in relation to the complete extended enterprise or business ecosystem. In some cases, it might be an option to explicitly transfer the tasks of analyzing and improving an ecosystems architecture to a service provider for business ecosystem architecture management. While in some settings, a large central actor may establish such a unit to coordinate its own ecosystem, other settings with more diverse actors and diffused power may require transferring this task to a new entity, which can act more independently without harming the interests of other actors. D. Challenges regarding the socio-technical dimension By extending the focus beyond the organizational border, external actors are not necessarily other companies or organizations. Instead, the entity of customers may comprise millions of people (all different in their interests, abilities and technological infrastructure). The terms processes and applications do have a different meaning in the world of citizens and consumers. If a retail company seeks to establish a mobile payment system, it needs to understand the “processes” and “infrastructure” of its customers. For example, it has to analyze which kind of mobile devices is currently been used by the customers. This infrastructure changes with the speed of consumer electronics, which is much faster than the classical decision processes and design cycles in companies. Extended approaches are also needed to understand the interests and activities of an ecosystem’s “inhabitants”. In the logistics case, the terminal operator had to analyze and understand the truck drivers’ lifeworld to design a solution that adequately addresses the needs of this diverse group of people. In addition to these social entities, ecosystem architectures of the future might also need to include a myriad of smart objects, which are capable of receiving or generating information. In the logistics scenario, the proliferation of the internet of things will have a severe impact on the architectures of the involved business ecosystem.
E. From EAM to BEAM: Existing Solutions and Open Issues In the previous sub-sections, we described several challenges arising from the extended perspective of business ecosystem architecture. Based on these challenges, we searched for existing approaches, which might be a solution to these challenges. First, we draw on the ideas already presented by Zachman and the TOGAF framework. When leaving the organizational level, a common ontology and a common framework are a good foundation for supporting projects that affect other actors [40][36]. Depending on the companies involved, the power structure and other factors, in some cases the definition of a common standard ontology and framework might be a possible solution. Some EAM tools support existing frameworks like TOGAF, Zachman or ArchiMate and therefore make a future exchange of data with other actors easier. Second, defining common standards for data exchange is a well-known task with several years of experience in many industries. The structures and experiences resulting from this cooperation might be a suitable starting point for agreements on common standards in the field of architectures. Third, in case the partners involved cannot agree on a common framework, they nevertheless can draw on experiences gained from building ontologies as a common vocabulary. By using semantic technologies, these ontologies can be used in the modeling process and tools (if these tools support the use of such ontologies). Fourth, general mechanisms for data import and export and respective management processes are required to exchange data on the (sub-)architectures of partners or customers. VII. CONCLUSION AND OUTLOOK In this paper, we have argued for extending the perspective of EA and EAM towards BEA and BEAM. As enterprises today are interconnected to an increasing degree, they have to consider their complex environment and should analyze it thoroughly. Though many companies are still struggling with the process of establishing their internal EA and EAM, we have argued for thinking of the next stages to extend the core EA and EAM towards a business ecosystem perspective. Based on four cases from different industries, we have identified five stages for extending EA and EAM to BEA and BEAM. Furthermore, we extracted a set of challenges, which arise from the extended perspective. Our research is limited, as the ideas we have developed here have not been applied in practical settings and are not yet filled or challenged by actual data from existing architectures. The challenges for extending EA modeling were only sketched briefly. Though the four cases we have selected include a broad spectrum of possibilities for extension, other settings may exist which require other types of extensions for EA and EAM beyond the organizational horizon. Furthermore, we have not developed any new solutions to the challenges that we have identified, yet. For future research, the ideas we have presented in this paper have to be tested with real meta-models, data and tools. In order to evaluate its usefulness, enterprises need a mature EA model which can be used as a basis for including the extended entities and relations. Concerns need to be defined, which underline the need for this extended perspective.
REFERENCES [1]
[2] [3]
[4] [5]
[6]
[7] [8]
[9]
[10]
[11]
[12] [13]
[14]
[15]
[16]
[17]
[18] [19] [20]
[21] [22]
S. Aier, C. Riege, and R. Winter, „Unternehmensarchitektur – Literaturüberblick und Stand der Praxis,“ Wirtschaftsinformatik, vol. 50, no. 4, pp. 292-304. G. A. Bowen, „Document Analysis as a Qualitative Research Method,” Qualitative Research Journal, vol. 9, no. 2, pp. 27-40. P. J. Boxer and S. Garcia, “Enterprise Architecture for Complex Systems-of-Systems Contexts,” in Proceedings of IEEE SysCon 2009, Vancouver, Canada, 2009. A. Brandenburger and B. Nalebuff, Co-opetition, New York: Doubleday, 1996. C. Braun and R. Winter, "A Comprehensive Enterprise Architecture Metamodel and Its Implementation Using a Metamodeling Platform," in Proceedings of Enterprise Modelling and Information Systems Architectures, Klagenfurt, 2005, pp. 64-79. S. Buckl, A. M. Ernst, J. Lankes, and F. Matthes, “Enterprise Architecture Management Pattern Catalog”, technical report, Technische Universität München, Munich, Germany, 2008. L. M. Camarinha-Matos and H. Afsarmanesh, Collaborative Networks: Reference Modeling, New York: Springer, 2010. R. Fischer, „Organisation der Unternehmensarchitektur. Entwicklung der aufbau- und ablauforganisatorischen Strukturen unter besonderer Berücksichtigung des Gestaltungsziels Konsistenzerhaltung,“, Hamburg: Kovac. I. Hanschke, Enterprise Architecture Management einfach und effektiv – ein praktischer Leitfaden für die Einführung von EAM, München: Carl Hanser, 2012. C. Houy, P. Fettke, P. Loos, W. P. M. van der Aalst, and J. Krogstie, “BPM-in-the-large – Towards a Higher Level of Abstraction in Business Process Management,” in Proceedings of EGES/GISP 2010, M. Janssen et al., Eds., 2010, pp. 233-244. M. Iansiti and R. Levien, The keystone advantage. What the new dynamics of business ecosystems mean for strategy, innovation, and sustainability, Boston: Harvard Business School Press, 2004. M. Iansiti and R. Levien, “Strategy as ecology,” Harvard Business Review, vol. 82, no. 3, 2004, pp. 68–78. ISO/IEC/IEEE, “Systems and software engineering – architecture description,” ISO/IEC/IEEE 42010:2011(E), International Standard, 2011. H. R. Johnston and M. R. Vitale, “Creating Competitive Advantage With Interorganizational Information Systems,” MIS Quarterly, June, 1988, pp. 153-165. L. Kappelman, T. McGinnis, A. Pettite, and A. Sidorova, „Enterprise Architecture: Charting the Territory for Academic Research,“ in Proceedings of AMCIS 2008, Toronto, 2008, Paper 162. M. Madlberger and N. Roztocki, “Cross-Organizational and CrossBorder IS/IT Collaboration - A Literature Review,” in Proceedings of AMCIS 2008, Toronto, 2008, Paper 200. S. J. Mäkinen, and O. Dedehayir, “Business Ecosystem Evolution and Strategic Considerations. A Literature Review, “ in Proceedings of the 18th International Conference on Engineering, Technology and Innovation, Munich, Germany, 2012. J. F. Moore, “Predators and Prey. A New Ecology of Competition,” Harvard Business Review, vol. 71, no. 3, 1993, pp. 75-86. J. F. Moore, The death of competition. Leadership and strategy in the age of business ecosystems, New York: Harper Business, 1996. T. Müller, D. Schuldt, B. Sewald, M. Morisse, and J. Petrikina, „Towards inter-organizational Enterprise Architecture Management Applicability of TOGAF 9.1 for Network Organizations,” in Proceedings of AMCIS 2013, Chicago, 2013. M. D. Myers, Qualitative Research in Business & Management, London: Sage, 2009. M. D. Myers and M. Newman, “The qualitative interview in IS research: Examining the craft,” Information and Organization, vol. 3, no. 3, pp. 226.
[23] M. Mykhashchuk, S. Buckl, T. Dierl, and C. Schweda, “Charting the landscape of enterprise architecture management,” in Proceedings of Wirtschaftsinformatik 2011, Zürich, pp. 570-577. [24] M. Op’t Land, E. Proper, M. Waage, J. Cloo, and C. Steghuis, Enterprise architecture. Creating value by informed governance. Berlin: Springer, 2009. [25] W. J. Orlikowski, “The Duality of Technology - Rethinking the Concept of Technology in Organizations,” Organization Science, vol. 3, no. 3, 1992, pp. 398-427. [26] W. J. Orlikowski, . “Using Technology and Constituting Structures - A Practice Lens for Studying Technology in Organizations,” Organization Science, vol. 11, no. 4, 2000, pp. 404-428. [27] W. J. Orlikowski and D. C. Gash, “Technological Frames - Making Sense of Information Technology in Organizations,” ACM Transactions on Information Systems, vol. 12, no. 2, 1994, pp. 174-207. [28] M. Peltoniemi and E. Vuori, “Business ecosystem as the new approach to complex adaptive business environments,” in Proceedings of Frontiers of e-business research 2004, Tampere, Finland, 2004, pp. 267281. [29] J. Petrikina and K. Zimmermann, “Towards an Integrated Management of Business Models and Enterprise Architecture – Potentials and Conceptual Model,” in Digital Enterprise Design & Management, P.-J. Benghozi, D. Krob, A. Lonjon, and H. Panetto, Eds. Cham: Springer, 2014, pp. 149-150. [30] J. W. Ross, P. Weill, and D. C. Robertson, Enterprise architecture as strategy. Creating a foundation for business execution, Boston, Mass.: Harvard Business School Press, 2006. [31] M. Rothschild, Bionomics: Economy as Ecosystem, New York: Henry Holt and Company, 1990. [32] D. Simon, K. Fischbach, and D. Schoder, „An Exploration of Enterprise Architecture Research,“ Communications of the AIS, vol. 32, article 1, 2013. [33] J.F. Sowa and J.A. Zachman, "Extending and Formalizing the Framework for Information Systems Architecture," IBM Systems Journal, vol. 31, no. 3, 1992, pp. 590-616. [34] A. Sunyaev, S. Göttlinger, C. Mauro, J. M. Leimeister, and H. Krcmar, “Analysis of the Applications of the electronic Health Card in Germany,” in Proceedings of Wirtschaftsinformatik 2009, Vienna, Austria, 2009, pp. 749-758. [35] T. Tambo and C. Koch, “Enterprise Architecture in the Supply Chain,” in Proceedings of 9th IEEE/ACIS International Conference on Computer and Information Science, 2010, pp. 881-886. [36] The Open Group, TOGAF® Version 9.1, U.S.: The Open Group, 2011. [37] R. Winter and R. Fischer, “Essential Layers, Artifacts, and Dependencies of Enterprise Architecture,” in Proceedings of 10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW'06), Hong Kong, China, pp. 1-30. [38] R. K. Yin, Case Study Research: Design and Methods, Thousand Oaks: Sage, 2013. [39] J. A. Zachman, “A Framework for Information Systems Architecture,” IBM Systems Journal, vol. 26, no. 3, 1987, pp. 276–292. [40] J. A. Zachman, “Federated Architecture,” Whitepaper, Intervista Institute, 2006. [41] N. Zarvic, M. Fellmann, and O. Thomas, “Managing Changes in Collaborative Networks: A Conceptual Approach,” in ICIS 2011 proceedings, 2011, Paper 1. [42] K. Zimmermann, “Referenzprozessmodell für das Business-ITManagement – Vorgehen, Erstellung und Einsatz auf Basis qualitativer Forschungsmethoden,” Dissertation, Fachbereich Informatik, Universität Hamburg, 2013.
