Enterprise architecture patterns for business process ...

The Journal of Systems and Software 84 (2011) 1480–1506

Contents lists available at ScienceDirect

The Journal of Systems and Software journal homepage: www.elsevier.com/locate/jss

Enterprise architecture patterns for business process support analysis ˇ sa ∗ , Marjan Krisper Ana Saˇ Information Systems Laboratory, Faculty of Computer and Information Science, University of Ljubljana, Trˇzaˇska 25, 1000 Ljubljana, Slovenia

a r t i c l e

i n f o

Article history: Received 30 August 2010 Received in revised form 17 February 2011 Accepted 24 February 2011 Available online 17 March 2011 Keywords: Enterprise architecture Enterprise architecture pattern Business process support analysis Business process Business object

a b s t r a c t The field of enterprise architectures lacks architecture patterns that would support analysis of a given enterprise architecture, comparison of different enterprise architecture solutions and provide guidelines for development of a target enterprise architecture based on the analysis of existing enterprise architecture. In this paper, we focus on business process support analysis using information derived from enterprise architecture description. We give a systematic overview of important aspects. We establish and formally define foundational enterprise architecture patterns for business process support analysis. They are implementation independent and enable more efficient qualitative architecture analysis of business process support, which is the basis for achieving more optimal business operation. We have defined the patterns using the standard enterprise architecture language – ArchiMate. They are formalized in a way that enables their implementation in enterprise architecture tools. This is an important characteristic that allows for efficient work by automatic detection of different, more or less suitable, architecture structures. We have derived the patterns based on real-world enterprise architecture descriptions and have used and verified them in enterprise architecture analysis and planning projects for four large organizations. The enterprise architecture analysis patterns address an important research issue in the field of enterprise architectures that has so far not been systematically researched. © 2011 Elsevier Inc. All rights reserved.

1. Introduction Enterprise architecture represents a knowledge base that comprises elements of internal and external business environment and ˇ sa and Krisper, 2010). With increasing relations between them (Saˇ requirements for business system agility and business-IT alignment, enterprise architectures have become an important field (Wilkinson, 2006) and have drawn attention of many researchers and experts from IT and business domains (Jonkers et al., 2006; Johnson et al., 2007). Enterprise architectures represent a means for achieving coherency and consistency of a business system, for relating strategic elements with business processes, for relating the business mission and goals with IT mission and goals, and for ensuring more informed decisions about important topics, such as integration with internal and external information systems and business process optimization (Doucet et al., 2009; Lankhorst, 2009; Ross et al., 2006; The Open Group, 2009b). Enterprise architecture analysis represents the basis for achieving the potential enterprise architecture benefits. It is important especially for decision support, for planning and for enterprise architecture optimization. Whenever a change is required in an

∗ Corresponding author. Tel.: +386 1 4768 704; fax: +386 1 4768 198. ˇ sa), [email protected] E-mail addresses: [email protected] (A. Saˇ (M. Krisper). 0164-1212/$ – see front matter © 2011 Elsevier Inc. All rights reserved. doi:10.1016/j.jss.2011.02.043

enterprise architecture, architecture analysis should play the central role. It enables evaluation of different variants of the target architecture, study of the impact of change in the existing enterprise architecture, and more informed decisions, for example when making compromises between costs, quality, and efficiency (Lankhorst, 2009). Without enterprise architecture analysis, the enterprise architecture can be used mainly for representation and communication purposes, whereas other potential applications and benefits are not realized or realized with difficulty. Study of related work has shown that existing enterprise architecture analysis approaches lack architecture patterns for qualitative evaluation of architecture solutions. Our vision is to develop enterprise architecture patterns that would represent a foundation for analysis of enterprise architectures, for comparison of different enterprise architectures and for development of guidelines and blueprints. The goal of such patterns is to enable examination of an enterprise architecture in terms of a sound architecture, detection of typical architecture structures which indicate a more or less optimal solution based on different perspectives, to enable examination of possible improvements, and to allow for evaluation and comparison of different target architectures. In this paper we focus on the aspects of business process support analysis with regard to business process execution support and support for business objects that are used in a business process. We have derived the patterns based on real world enterprise architecture descriptions and have used and improved them

A. Sˇ aˇsa, M. Krisper / The Journal of Systems and Software 84 (2011) 1480–1506

throughout projects for four large Slovenian organizations. Our work is based on the ArchiMate enterprise architecture language due to its ability to provide a common base for concepts of different architecture domains and cross-domain relationships, which are important characteristics for business process support analysis. However, since only a subset of the ArchiMate language constructs is used, the patterns can be applied to other enterprise architecture descriptions that do not use ArchiMate, provided that the metamodel they are based on comprises the constructs used in pattern definitions. The paper is organized as follows. In the next section, we introduce and explain the basic concepts in the field of enterprise architectures. In Section 3, we present the related work and the motivation of our research. In Section 4, we present our approach and how the concept of patterns plays the central role in our work. In Section 5, we introduce the ArchiMate metamodel and concepts that we use in pattern definitions. In Section 6, we discuss and define the enterprise architecture analysis patterns for business process support: we define different business process support analysis perspectives, present relations between different perspectives, define the enterprise architecture patterns for each of the perspectives and compare them. In the seventh section, the proof of concept is presented. Section 8 discusses implications and further work. The last section contains the concluding remarks. 2. Preliminaries Conceptual foundation in the field of architectures was established with the IEEE 1471-2000 standard in the year 2000 (IEEE Recommended Practice for Architectural Description of SoftwareIntensive Systems) (IEEE Computer Society, 2000). The standard represents a theoretical foundation for creation, analysis, and sustainment of architectures of software-intensive systems and comprises definitions, conceptual framework and architectural description practices (Krisper and Roˇzanec, 2005). The conceptual model that the standard defines is given in Fig. 1. The standard was accepted by the organization ISO as the ISO/IEC 42010:2007 (ISO – International Organization for Standardization, 2007). In the field of enterprise architectures a consensus about different elements and definitions regarding enterprise architectures still has not been achieved. Therefore, the ISO/IEC 42010:2007 represents an important foundation also for enterprise architectures. It defines an enterprise architecture (EA) as the fundamental conception of a system [the enterprise] in its environment embodied in its elements, their relationships to each other and to its environment, and the principles guiding its design and evolution (ISO – International Organization for Standardization, 2007). Another commonly referenced definition of the term enterprise architecture was given by The Open Group, which considers enterprise architecture as having two meanings depending upon the context (The Open Group, 2009b): • EA is a formal description of a system, or a detailed plan of the system at component level to guide its implementation. • EA is the structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time. An enterprise architecture description is usually very complex, because it comprises a large set of components and relationships between them. Based on stakeholders’ concerns, different parts of an enterprise architecture are relevant for different stakeholders (Lankhorst, 2004; van der Raadt et al., 2008). It is important that enterprise architecture can be represented with relevant information and at the appropriate level of detail for individual

1481

stakeholders. For this purpose, most of enterprise architecture approaches define viewpoints and views related with different stakeholders. Based on the viewpoint definition and a given enterprise architecture, a view for the target stakeholder can be derived (Fig. 1).

3. Related work and motivation Numerous approaches, methods and frameworks have been developed in the field of enterprise architectures. We distinguish between domain specific and generic approaches. One of the earliest origins of domain specific approaches can be found in the field of production and manufacturing systems, where reference architectures and methods have been developed since 1980s. Examples are the Integration Definition method (IDEF) (Mayer et al., 1995), GRAI Integrated Methodology (GRAI-GIM) (Zanettin and Doumeingts, 1992), Open System Architecture for CIM (CIMOSA) (ESPIRIT Consortium AMICE, 1993; Zelm et al., 1995), Purdue enterprise reference architecture (PERA) (Williams, 1992), and TOronto Virtual Enterprise (TOVE) project (Fox, 1992). Williams et al. (1994) present a summary of the IFAC/IFIP Task Force on Architectures for Integrating Manufacturing Activities and Enterprises technical report. They discuss recommendations for achieving a complete and a sound architecture by selecting and combining the best available architectural features. A study of these approaches can be found in Chalmeta et al. (2001). Mertins and Jochem (2005) present one of the latest contributions related to enterprise architectures in manufacturing. They provide an overview of architectures, methods and tools for enterprise engineering, propose the integrated enterprise modelling (IEM) method, and a software tool that supports the method. Another important area of domain specific enterprise architecture frameworks is government. Examples are: Federal Enterprise Architecture Framework (FEAF) (The Chief Information Officers Council, 1999), Enterprise Architecture framework of the Federal Deposit Insurance Corporation (FDIC EA) (The Chief Information Officers Council, 2008), Treasury Enterprise Architecture Framework (TEAF) (Department of the Treasury Chief Information Officer Council, 2000) in the USA; the cross-Government Enterprise Architecture (xGEA) (Cabinet Office Chief Information Officer Council, 2010) in UK; NORA (ICTU, 2007) in the Netherlands; and the Danish cross governmental enterprise architecture framework (OIO EA) (National IT and Telecom Agency, 2009) in Denmark. Several EA frameworks can also be found in the defence industry, such as AGATE (Délégation Générale pour l’Armement, 2007) in France, NATO Architecture Framework (NATO Consultation, Command and Control Board, 2007) and Department of Defence Architecture Framework (DoDAF) (Department of Defense, 2009) in the USA, and Ministry of Defence Architecture Framework (MoDAF) (Ministry of Defence, 2008) in UK. We do not try to develop a reference architecture, a complete enterprise architecture framework or a methodology; we focus on systematic examination of different aspects of business process support that can enhance existing achievements in the field of enterprise architectures. Our work is applicable to arbitrary domains. There are several domain independent enterprise architecture approaches; the most recognized among them are the Zachman framework (Zachman, 2010), Generic Enterprise Reference Architecture and Methodology (GERAM) (Bernus and Nemes, 1996), The Open Group Architecture Framework (TOGAF), Model Driven Architecture (MDA), Gartner Enterprise Architecture Method (GEAM) (Bittles and Kreizman, 2005; James et al., 2005), and ArchiMate (Lankhorst, 2009; The Open Group, 2009a). The Zachman framework originated in 1987 and is one of the oldest enterprise architecture frameworks. It is a widely recognized schema for classification of enterprise architecture artefacts. It defines different

1482


Fig. 1. Conceptual model of architectural description (IEEE 1471-2000) (IEEE Computer Society, 2000).

stakeholder views of a business system based on their concerns. GERAM (Bernus and Nemes, 1996) was developed in order to unify previously analysed architectures, such as the PERA, GRAIGIM, CIMOSA, and TOVE. TOGAF is a standard framework that has been evolving since the 1990s. It covers a wide variety of aspects regarding enterprise architectures, ranging from the Architecture Development Method (ADM) to guidelines, reference models, and a metamodel (The Open Group, 2009b). MDA aims to provide an open and independent approach to interoperability and builds upon the Object Management Group’s modelling standards (Miller and Mukerji, 2003). GEAM has two main parts: the Gartner Enterprise Architecture Process Model (Bittles and Kreizman, 2005) and the Gartner Enterprise Architecture Framework (GEAF) (James et al., 2005). The Process Model focuses on enterprise architecture as a process discipline, and the GEAF describes an enterprise context layer that overlays the enterprise architecture to ensure alignment with the business strategy. The most recent development in the field of enterprise architectures is ArchiMate. Other approaches, such as the Zachman Framework and TOGAF, offer high-level guidance in identifying which areas of business and technology should be considered when creating an enterprise architecture, but they provide little assistance in creating the architectural artefacts themselves (Jonkers et al., 2006). ArchiMate addresses these aspects and is therefore complementary to other frameworks. It comprises an enterprise architecture modelling language and guidelines for modelling,

visualization and architecture analysis (Lankhorst, 2009). The ArchiMate enterprise architecture modelling language is the key part of the framework and was accepted as a standard by The Open Group (2009a). The main motivation for development of the language was to surpass the gap between different architecture domains, for example business process domain, information systems domain and technical domain (Lankhorst, 2004). In comparison with previous approaches, an important advantage is that the ArchiMate language is a common enterprise architecture modelling language for all architecture domains. As there had been no common enterprise architecture language, an enterprise architect had to rely on existing methods and techniques from disparate domains, for example, the BPMN notation (OMG, 2009) for the business process domain, and UML notation (Staron et al., 2006) for the information systems domain (Lankhorst, 2009). Even though this enables communication, presentation and analysis within each domain, the relations between concepts from different domains are often unclear or undefined. Furthermore, different domains may overlap by addressing the same concepts, frequently in a different manner. This may cause difficulties when determining relationships between domains and is a serious drawback for holistic management and governance of the business system, for strategic planning, and impact-of-change analysis through different architectural domains. By providing a common enterprise architecture modelling language, ArchiMate alleviates these problems. As such it represents an important achievement in the field of enterprise


architectures. It introduces a basis for architecture analysis techniques, which can focus on inter-domain relationships, which were previously hindered and limited. These relationships are very important for business process support analysis, especially the business-IT inter-domain relationships which give us information about application support of business processes and about business process automation. These are the main reasons that the analysis patterns proposed in this paper are based on ArchiMate. It is important to note that since our approach is focused on business process support analysis, the entire ArchiMate metamodel is not required to support the patterns. We have identified the relevant subset of the ArchiMate’s elements and relationships in Section 5. Therefore, recognition of the patterns can also be implemented for non-ArchiMate based enterprise architecture descriptions, if their underlying metamodel comprises the elements and relationships used in our approach. The importance of enterprise architectures as a means of bridging the gap between different enterprise domains and resulting integration difficulties has been also pointed out by other authors. Kang et al. (2010a) propose ontology-based enterprise architecture in order to surpass communication problems which prevent enterprises from implementing integration and collaboration with other enterprises. Their enterprise architecture ontology has three main levels: (1) ontologies of business terms, (2) ontologies of enterprise architecture components, and (3) ontologies of relationships among enterprise architecture components. Related to this work, Kang et al. (2010b) point out that business processes should be executed for the business strategies flexibly, and proper enterprise resources should support the business processes systematically. They emphasise the importance of explicit knowledge about relationships among business strategies, business processes and enterprise resources. In order to tackle this issue, they propose strategy and business enterprise architecture alignment, and a metamodel using fact-based ontologies. In contrast, our work focuses on analysing business process support using enterprise architectures, which concerns other alignment areas, such as business-IT alignment. For this we do not propose a new metamodel, but build upon the standard metamodel of the ArchiMate language in order to define enterprise architecture patterns that can be used as foundation for better support for business processes. We have studied different uses of enterprise architectures based on several important approaches (Chief Information Officer Council, 2001; Bittles and Kreizman, 2005; James et al., 2005; Schekkerman, 2006; Jonkers et al., 2006; Pulkkinen et al., 2007; Lankhorst, 2009; The Open Group, 2009b; van der Raadt et al., 2010) and grouped them into three main categories: C1. An instrument for representation: Enterprise architecture descriptions provide a holistic view of a system. Different EA models are used by different stakeholders for representation of the part of the system that concerns them in order to achieve a common understanding and to enable communication between stakeholders. C2. An instrument for planning: Enterprise architecture description can comprise existing and target states of the system. As such it can be used for planning, e.g. what should be changed, added, adapted, etc. to reach the target state. Enterprise architecture can also comprise transition architectures, which represent different stages of transforming the existing (baseline) architecture into the target architecture. Analysis techniques play an important role in planning, for example gap analysis and impact of change analysis. C3. An instrument for ensuring coherency and consistency of different parts of a business system: Using enterprise architecture description, business mission, vision, goals and strategies are related with business processes and organizational structure.

1483

Strategies and goals of different parts of a business system can be aligned with the strategy and goals of the overall business system. This allows for a focused functioning of different parts of the system in achieving the overall business vision and goals. An important area of enterprise architecture application that requires all three categories, is business-IT alignment. Enterprise architectures help guide and optimize an organization’s IT investments and translate business strategies into implementable technology solutions (Jonkers et al., 2006). On the other hand, one of the most crucial fields that also address all three categories, is strategic planning, because it involves planning of the future business system that will be coherent, consistent and focused on achieving the vision and strategic goals. In order to point out the problems of the existing system and solutions of the planned system, representation of issues to different stakeholders is an important part of strategic planning. Therefore, strategic planning and IT strategic planning represent one of the key areas of application of enterprise architectures (Bittles and Kreizman, 2005; Jonkers et al., 2006; Chen et al., 2008). In 2003, the authors of this paper have developed an IT strategic planning methodology (EMRIS) (Krisper et al., 2003a, 2003b), which was published by the Government Centre for Informatics of the Government of the Republic of Slovenia. It was used in different Slovenian companies and Government agencies. We have recently enhanced this methodology to explicitly include the enterprise architecture ˇ sa et al., 2009; Roˇzanec and Krisper, 2010). aspects (Saˇ Architecture analysis is the basis for two of the three categories, viz. C2 and C3. In order to develop well-founded plans, they have to be based on rational decisions. The discipline of enterprise architecture advocates the use of models to support decision-making on enterprise-wide information system issues (Johnson et al., 2007). Such decisions can be supported by appropriate analysis techniques that show why a certain architectural solution is better than the others. Architecture analysis is also important to detect incoherencies and inconsistencies that exist in the business system. In our work, we strive to improve effectiveness of architecture analysis by establishment of architecture patterns that enable detection of suboptimal structures in the architecture and more informed decisions. Several other authors have proposed approaches for analysis of enterprise architecture solutions. Lagerström et al. (2009) discuss that in order for enterprise architecture models to support decision making, they should be amenable to analysis of various properties. They propose a method for creating metamodels for such analysis. They formalize enterprise architecture models using probabilistic relational models. Related to this work, Lagerström et al. (2010) present instantiated architectural models based on a metamodel for enterprise systems modifiability analysis, i.e. for assessing the cost of making changes to enterprise-wide systems. Lankhorst (2009) describes different architecture analysis techniques that can be used with the ArchiMate language. Quantitative and functional (qualitative) architecture analysis techniques are distinguished. Quantitative architecture analysis focuses on the quantitative aspect of relationships between different enterprise architecture elements and layers. It can be used for optimization by quantifying the effect of alternative design choices, to obtain measures to support impact-of-change analysis, and for capacity planning. In qualitative architecture analysis, Lankhorst differentiates between static analysis, which focuses on the static structure of the architecture, and dynamic analysis, which focuses on the dynamics of an architecture. Description logic formalisms are used for static analysis. Knowledge representation languages based on description logic are adapted for capturing knowledge about concepts and concept hierarchies. The most important application of description logic for static analysis of enterprise architectures is

1484


impact-of-change analysis. For dynamic analysis techniques formal approaches, such as process algebra and data flow networks, are used. Suboptimal parts regarding the logics of an architecture can be discovered with these techniques, for example two concurrently active roles with incompatible activities (e.g. overwriting, destroying each other’s work). Dynamic analysis improves consistency and focuses on logical aspects of the models. The enterprise architecture patterns proposed in this paper are intended for qualitative architecture analysis. However, they are not intended for the impact of change analysis. Their aim is to provide support for recognition of several important properties for a given enterprise architecture, and for evaluation and comparison of different architecture solutions with respect to business process support. As far as we know, there has been no other approach that addresses this issue. Since business process support is one of the most important aspects in enterprises, we believe that this is one of the main deficiencies of the domain of qualitative enterprise architecture analysis. The patterns proposed in this paper can be used to analyse the structural aspects of the architecture in order to improve either the dynamical (for example improved business process execution with improved business process flow automation), or static aspects (for example fewer redundant data objects) of the enterprise architecture in supporting business processes. Our patterns are formalized in a way that is implementation independent and allows for implementation of the patterns in tools that support the underlying metamodel. Related to enterprise architecture analysis is also the field of analysis of enterprise architecture function. In the USA, there are two well known enterprise architecture maturity models, viz. the Enterprise Architecture Capability Maturity Model (USDoC, 2007) and the NASCIO Maturity Model for Enterprise Architecture (NASCIO, 2003). Morganwalp and Sage (2004) discuss methods for demonstrating effectiveness of enterprise architecture and suggest strategies for measuring the effectiveness of enterprise architectures. van der Raadt and van Vliet (2009) observe that enterprise architecture assessment models typically focus on enterprise architecture delivery function, even though they do not include all elements of the enterprise architecture function, such as bodies, roles, structures and processes involved with ratifying, enforcing and conforming to the EA products. The authors propose an enterprise architecture efficiency assessment model that covers these issues. van der Raadt et al. (2010) have extended this model by considering EA stakeholder satisfaction and EA effectiveness. Other enterprise architecture patterns have been proposed, even though not in the field of architecture analysis. Lankhorst and Luttighuis (2009) describe a catalogue of patterns for multichannel management. They use the ArchiMate modelling language to define functional structures for designing organizational and technical solutions. The purpose of their patterns is to support architecture design and not to provide a basis for enterprise architecture analysis. Another field where several enterprise architecture patterns were proposed is enterprise architecture management, for example (Buckl et al., 2009a,b; Moser et al., 2009). Other authors have proposed different patterns within different enterprise architecture subdomains, and not for the domain of the enterprise architecture as a whole. For example, a very exhaustive and well-known research in the field of workflow patterns was performed by Aalst et al. (2003, 2009). They defined various workflow patterns for several workflow perspectives: the control perspective, the data perspective, the resource perspective, and the exception handling perspective. Their research provides a thorough examination of the various perspectives that need to be supported by a workflow system or a business process modelling language. Sarnikar and Zhao (2008) propose an approach of pattern-based knowledge workflow that can enable the automation of knowledge flows across an organization. In the software community, one of the

most common types of patterns is design pattern. Important contributions of design patterns in the field of software were given by Gamma et al., for example (Gamma et al., 2002; Fraser et al., 2006). They developed a mechanism for expressing object-oriented design experience in the form of design patters describing recurring solutions to common problems in software design. Another common type of patterns in the software community is analysis pattern. Analysis patterns are sets of concepts that represent a common construction in business modelling (Fowler, 1997). In this paper we do not talk about design patterns, which are directed towards solving problems in design (Riehle and Züllighoven, 1996; Gamma et al., 2002), nor do we discuss analysis patterns, which are directed towards solving problems with modelling (Fowler, 1997). In contrast, our approach is based on recognition of patterns in enterprise architecture which are important from business process support point of view and indicate properties important for business process support analysis. Furthermore, we do not discuss issues in separate enterprise architecture subdomains, such as different possible workflow types and software design. We discuss different enterprise architecture solutions for business process support by the business and application domain elements. 4. Approach Enterprise architecture descriptions of real world enterprises are usually very complex and comprise a large number of components and relationships between them. These components cover various aspects of a business system and they include business processes, organizational structure, information systems, etc. As such, enterprise architecture descriptions comprise important information that can be valuable for business process support analysis. However, throughout different real-world projects for companies and government organizations, we found that one of the main problems when analysing business process support using enterprise architectures is a lack of an approach that would point out which properties of enterprise architectures should be considered, and consequently, what information they carry, and how to efficiently derive this information from the complex enterprise architecture descriptions. Consequently, several problems can be encountered, such as difficulties in extracting the information which could be valuable for assessing the current solution with respect to business process support, incomplete information for planning a target solution, and difficulties in comparing potential solutions. Our approach is intended to alleviate these difficulties and to enable more informed decisions and argumentation. The approach originates in our work for an electric distribution company, and has been later successfully applied to several large Slovenian organizations. In order to address these difficulties, we have systematically analysed the elements of the enterprise architecture and extracted the information that was of interest for the business process support. Through this work, we have observed that the different parts of the enterprise architecture that are meaningful for analysis of business process support are based on several different reoccurring structures in the enterprise architecture. We analysed the structures, researched the dependencies between them, analysed the perspectives of the enterprise architecture to group the structures, and developed a formalization of the structures. The objective was to analyse and formalize these structures in a way that would enable their automatic identification for any given business process in an enterprise architecture description. Therefore, this formalization had three main goals: • to define enterprise architecture perspectives that are important for business process support analysis (business process support analysis perspectives),


1485

Fig. 2. An extract of the ArchiMate metamodel that comprises the EA elements of the two business process support aspects.2

• to define characteristics of enterprise architecture description that address the business process support analysis perspectives, and • to establish a mechanism to automatically recognize these characteristics. In order to define these characteristics and to enable their recognition in a given enterprise architecture description, we use the concept of patterns. As described in Riehle and Züllighoven (1996), a pattern is the abstraction from a concrete form which keeps recurring in specific non-arbitrary contexts. We use the term enterprise architecture pattern for business process support analysis as a set of enterprise architecture elements that reflect specific architectural structures which are meaningful for business process support analysis. These patterns are not traditional design or analysis patterns, which are commonly used in software community. They are not intended for solving problems with software design or business modelling, but as a basis for analysis of a given enterprise architecture description. The objective is to recognize which patterns can be found in a given enterprise architecture description: if an element exhibits a pattern, this indicates important information for the analyst. Thus, our approach is based on detection of enterprise architecture patterns. The detected patterns provide input information for business process support analysis. For example, this information can be helpful when analysing whether the current enterprise architecture solution supports business goals and requirements, for determining what are its strengths and weaknesses, or if it is suitable from the business process support point of view or should be improved. Therefore, we represent a pattern by a set of elements and formalize it with its membership conditions. If an enterprise architecture element corresponds to the membership conditions of a pattern, then it is a member of the set and it is said that it exhibits the pattern or corresponds to the pattern. An enterprise architecture element can exhibit one or more patterns. Due to a large set of elements and relationships that an enterprise architecture description usually comprises, one of the goals was to define the patterns in a way that enables their implementation in enterprise architecture tools and automatic pattern detection. Definition of patterns with their membership set conditions is formalized in a way which enables their implementation using an enterprise architecture tool that supports the underlying metamodel of our approach and provides a form of a script/query language. This is the case with most of the existing ArchiMate compatible tools, such as BiZZdesign Architect (BiZZdesign, 2009), ARIS

ArchiMate Modeler (IDS Scheer AG, 2009), and IBM Rational System Architect (IBM, 2009). Support for patterns in an enterprise architecture tool can be applied in different ways, for example automatic alarms in case of detected suboptimal structures, or for decision support when comparing different potential target architectures. The metamodel our approach is based on is presented in the following section. 5. Business process support elements of the ArchiMate metamodel In ArchiMate, the concept of a service plays the central role. ArchiMate defines a service as a unit of essential functionality that an entity exposes to its environment, and provides a certain value, which thus provides the motivation for the service’s existence. ArchiMate distinguishes between three enterprise architecture layers (The Open Group, 2009a): 1. The Business Layer offers products and services to external customers, which are realized in the organization by business processes performed by business actors. 2. The Application Layer supports the business layer with application services which are realized by (software) applications. 3. The Technology Layer offers infrastructure services needed to run applications, realized by computer and communication hardware and system software. The research described in this paper addresses elements in the first two layers. The ArchiMate metamodel categorizes enterprise architecture elements into three main categories: active structure elements, behavioural elements and passive structure elements. Active structure elements are those elements that display behaviour, i.e. the ‘subjects’ of activity. They are assigned to behavioural concepts, to show who or what performs the behaviour. A business process is a behavioural element. Passive structure elements are the objects on which behaviour is performed. In the domain of informationintensive organizations, which is the main focus of the language,

2 This figure does not show composition and aggregation relationships, because every element in the language can have composition and aggregation relations with elements of the same type.

1486


Table 1 ArchiMate language constructs and their symbols (Remark: Only the concepts used in enterprise architecture patterns given in this paper are presented). Symbol

Name and short description Business process: A unit of internal behaviour or collection of causally related units of internal behaviour intended to produce a defined set of products and services. It is a specialization of a business behaviour element Service: An externally visible unit of functionality, which is meaningful to the environment. ArchiMate distinguishes between three types of services: a business service (realized by a business process, business function, or business interaction), an application service (provided by one or more components) or an infrastructure service (provided by one or more computational resources) Business role: A named specific behaviour of a business actor participating in a particular context

Business event: A business event is something that happens (internally or externally) and influences behaviour (business process, business function, business interaction) Business interaction: A unit of behaviour performed as a collaboration of two or more business roles

Business function: A unit of internal behaviour that groups behaviour according to, for example, required skills, knowledge, resources, etc., and is performed by a single role within the organization Application component: A modular, deployable, and replaceable part of a system that encapsulates its contents and exposes its functionality through a set of interfaces Object: ArchiMate distinguishes between two types of objects. A business object is a unit of information that has relevance from a business perspective. A data object is a coherent, self-contained piece of information suitable for automated processing. It is accessed by an application service Representation: A perceptible form of the information carried by a business object, such as a document Triggering: The temporal or causal relationship between processes, functions, interactions, and events Realization: A relationship between a logical entity with a more concrete entity that realizes it Used-by: A relationship indicating the use of services by processes, functions, or interactions and the access to interfaces by roles, components, or collaborations Assignment: A relationship between a unit of behaviour with an active element (e.g. role, component) that performs it, or between a role and an actor that fulfils it Access: A relationship indicating access of behavioural concepts to business or data objects Aggregation: A relationship indicating that an object groups a number of other objects Composition: A relationship indicating that an object consists of a number of other objects

these are usually information or data objects, but they may also be used to represent physical objects (Lankhorst, 2009). A business process is executed by human process participants and/or by application systems (Havey, 2005). In ArchiMate, this is represented by assigning a business process to a business role, or an application component. These elements represent active structure elements. There are two types of possible relationships between a business process and an application component: a business process can be assigned to an application component that automates it or can use an application component, for example when a business role uses an application to accomplish the work required for the business process. In order to specify what kind of behaviour is required by the application component, ArchiMate provides the concept of an application service that can be realized by an application component and can be used by a business process. Business objects are passive structure elements accessed by business processes. A business object is an abstract concept that can be realized in different ways, such as in a perceptible form (representation) or with a data object operated by an application component. In order to ensure the behaviour defined with the business process model, business process execution and business objects accessed by the business process need to be appropriately supported. Based on this, we distinguish between two main aspects of business process support analysis: business process execution

support analysis and business object realization analysis. The first aspect concerns a business process with relation to the active structure elements that execute them. It addresses issues such as automation and role assignment. The second aspect focuses on business objects accessed in the analysed business processes and on the way they are realized. The following Fig. 2 represents the part of the ArchiMate metamodel (The Open Group, 2009a) that represents a business process with relation to its active structure and passive structure elements. Since the examples throughout this paper are given in the ArchiMate language, the legend of the corresponding ArchiMate language constructs is given in Table 1. Enterprise architecture approaches that do not use the ArchiMate notation are based on using different notations to represent different aspects of the business systems (Section 3). The presented approach is based on the elements and relationships given in the extract of the ArchiMate metamodel. Since only a subset of the ArchiMate constructs is required, recognition of the enterprise architecture patterns presented in this paper can be also implemented for non-ArchiMate based enterprise architecture descriptions, provided that the notations comprise the elements of the presented extract of the ArchiMate metamodel. In this case automatic recognition can be implemented, if a common repository is used. In case not all the relationships between the elements are supported, the information about them can be captured with matrices. The main difference between the ArchiMate based and


1487

Table 2 Symbols for pattern formalization. PIA BP BF BI BE BBE BO DO R BR AS AC AnBP AnBO X (a,b) ∈ Realization (a,b) ∈ Used by (a,b) ∈ Assignment (a,b) ∈ Access (a,b) ∈ Composition (a,b) ∈ Aggregation

The set of all the elements and relations of an enterprise architecture description The set of all business processes in the enterprise architecture description The set of all business functions in the enterprise architecture description The set of all business interactions in the enterprise architecture description The set of all business events in the enterprise architecture description The set of all business behaviour elements in the enterprise architecture description: BBE = BP ∪ BF ∪ BI ∪ BE The set of all business objects in the enterprise architecture description The set of all data objects in the enterprise architecture description The set of all representations in the enterprise architecture description The set all business roles in the enterprise architecture description The set of all application services in the enterprise architecture description The set of all application components in the enterprise architecture description The set of all analysed business processes in the enterprise architecture description: AnBP : AnBP ⊆ BP The set of all analysed business objects in the enterprise architecture description: AnBO : AnBO ⊆ BO From the business process support perspective, the set contains the following business objects: AnBO ={x|x ∈ BO, ∃ bp ∈ AnBP : (bp, x) ∈ Access} A transitive closure of relationship X a is related to b with the Realization relationship: a realizes b a is related to b with the UsedBy relationship: a is used by b a is related to b with the Assignment relationship: a is assigned to b a is related to b with the Access relationship: a accesses b a is related to b with the Composition relationship: a is composed of b a is related to b with the Aggregation relationship: a aggregates b

the non-ArchiMate based implementation of our enterprise architecture patterns is that in the latter case the viewpoints that we define for visualization of the patterns cannot be used. The reason for this is that they are based on the ArchiMate visual notation and they span different enterprise architecture layers. This has so far not been supported by any other available notation apart from ArchiMate (Section 3).

SPAnBP = {x|∃y ∈ AnBP ∧ x ∈ SP(y)}

(FD2)

• SO(bo) is a function that maps a business object bo ∈ BO into a set of its aggregate and composite elements: SO(bo) = {so|so ∈ BO : (bo, so) ∈ Composition v(bo, so) ∈ Aggregation }

6. Enterprise architecture patterns for business process support analysis

(FD3)

• SOAnBo is a set of all aggregate and composite elements of the analysed business objects:

In this section we present the perspectives of enterprise architectures which are relevant for business process support analysis and define enterprise architecture patterns based on these perspectives. The perspectives and patterns are given based on the two aspects of business process support, viz. business process execution support analysis and business object realization analysis. Therefore, we distinguish between business process execution support analysis patterns and business object realization analysis patterns. Every business process support analysis pattern definition is given with pattern identification, description, membership set definition, and an example architecture structure in ArchiMate. If a pattern is a specialization of another pattern, its identification is composed of the identification of the generalized pattern and the specialization identificator delimited by a “.” sign. For example, identification “X.Y” indicates that the pattern X.Y is a specialization of the pattern X. Every pattern definition is given with a definition of a pattern membership set. If a business process or a business object is a member of pattern A’s membership set then it corresponds to the pattern A. Symbols used in formalization of patterns are introduced in Table 2. We also define the following functions and sets which will be used in subsequent definitions: • SP(bp) is a function that maps a business process bp ∈ BP into a set of its behaviour subelements (subprocesses, business functions, business events, and business interactions that are part of the process): SP(bp) = {sp|sp ∈ BBE : (bp, sp) ∈ Composition v(bp, sp) ∈ Aggregation }

• SPAnBP is a set of all behaviour subelements of the analysed business processes:

(FD1)

SOAnBO = {x|∃y ∈ AnBO ∧ x ∈ SO(y)}

(FD4)

The section is organized as follows. First, we define analysis viewpoints that represent a basis for pattern visualization. In the second and the third subsections business process execution support and business object realization analysis patterns are described and formally defined. In the last subsection, a discussion and comparison of the patterns is given. 6.1. Enterprise architecture business process support analysis viewpoints The ArchiMate standard defines several basic architecture viewpoints, such as the application usage viewpoint and the business process viewpoint. A basic viewpoint in ArchiMate is defined as a selection of a relevant subset of the ArchiMate concepts (and their relations) and the representation of that part of an architecture that is expressed in different diagrams (The Open Group, 2009a). For the purpose of pattern-based business process support analysis, we define two basic viewpoints that correspond to the two main groups of enterprise architecture patterns: business process execution support viewpoint and business object realization viewpoint. We formalize them in a way that is consistent with pattern definitions. The goal of such viewpoints is to ensure that the corresponding views that originate from the viewpoint, illustrate exactly those elements that are relevant for the analysis. They enable the analyst to focus on the problem domain without redundant information. As a basis for explanation of the viewpoints, we first introduce three basic definitions: • We define a viewpoint with a set of elements and relationships that the corresponding views should comprise. If PIA represents a


1488

set of all the elements and relations of an enterprise architecture description, then a viewpoint can be defined as a function vp that maps a given enterprise architecture into a subset of its elements and relations between them: p(PIA) = P,

P ⊆ PIA,

(FD5)

where P represents a view of the enterprise architecture from the viewpoint vp. • Function Elt(x), where x ⊆ PIA, is a function which returns all elements in a given enterprise architecture description x or in a given (FD6) view x of an enterprise architecture. • Function Rel(x), where x ⊆ PIA is a function which returns all relationships in a given enterprise architecture description x or in a given view x of an enterprise architecture. (FD7) For example, Elt(PIA) designates all the elements of a given enterprise architecture description PIA, and Rel(PIA) designates all its relationships. In the remainder of the section, the business process execution support viewpoint and business object realization viewpoint are defined. 6.1.1. Business process execution support viewpoint Business process execution support viewpoint concerns business processes that we analyse and all elements of the enterprise architecture that support their execution. In the ArchiMate language, this is presented by the following two relationships: • Used by relationship: Indicates that a business process uses a business or an application service. • Assignment relationship: Indicates that a business process is assigned to an application component or a business role. The first case represents that the business process is completely automated by the application component; the second case indicates that the business process is performed by a business actor that is assigned the corresponding business role. Besides the business process execution support relationships, the viewpoint also addresses the following: • the business process flow: in ArchiMate this is represented by the Triggering relationship; • the Realization relationships between application components and application services: a business process execution support view explicitly shows which application component realizes the service used by the business process. As a basis for the business process execution support viewpoint definition, we define three other viewpoints: business process usage, business process assignment, and business process flow viewpoint. The business process usage viewpoint addresses the elements and relationships of the set BPUSVAnBP ⊆ PIA. The set is defined with the following: Elt(BPUSVAnBP ) = {x|(x ∈ AnBP ∪ SPAnBP ) ∨ (x ∈ AS, ∃b ∈ AnBP ∪ SPAnBP : (x, b) ∈ Used By)}, Rel(BPUSVAnBP ) = {(x, y)|x ∈ AnBP ∪ SPAnBP : (x, y) ∈ Used By}

(FD8)

The business process assignment viewpoint addresses the elements and relationships of the set BPASVAnBP ⊆ PIA, which is defined with the following: Elt(BPASVAnBP ) = {x|(x ∈ AnBP ∪ SPAnBP ) ∨ (x ∈ AC ∪ BR, ∃b ∈ AnBP ∪ SPAnBP : (x, b) ∈ Assignment)}, Rel(BPASVAnBP ) = {(x, y)|x ∈ AC ∪ BR, y ∈ AnBP ∪ SPAnBP : (x, y) ∈ Assignment} ∪ {(t, z)|t, z ∈ AnBP ∪ SPAnBP : (((t, z) ∈ Composition) ∨ ((t, z) ∈ Aggregation))}

(FD9)

The business process flow viewpoint addresses the elements and relationships of the set BPFVAnBP ⊆ PIA. The set is defined with the following: Elt(BPFVAnBP ) = {x|x ∈ AnBP ∪ SPAnBP } Rel(BPFVAnBP ) = {(x, y)|(x, y ∈ AnBP ∪ SPAnBP ) ∧ ((x, y) ∈ Triggering)}

(FD10)

The business process execution support viewpoint addresses the elements and relationships of the set BPSVAnBP ⊆ PIA, which is defined with the following: Elt(BPSVAnBP )=Elt(BPUSVAnBP )∪Elt(BPASVAnBP ) Rel(BPSVAnBP )=Rel(BPUSVAnBP )∪Rel(BPASVAnBP ) (F11) ∪Rel(BPFVAnBP )∪{(x, y)|x ∈ AC ∧ y ∈ (AS ∩ Elt(BPSVAnBP )) ∧ ((x, y) ∈ Realization)} In example business process execution support views in this paper, we express the aggregation and composition relationships by nesting the model elements (The Open Group, 2009a). 6.1.2. Business object realization viewpoint Business object realization viewpoint concerns business objects that we analyse and all elements of the enterprise architecture that realize them. It also addresses the aggregate and composite elements of the analysed business objects and their realizations. In ArchiMate, business objects can be realized by data objects or representations. The business object realization viewpoint addresses the elements and relationships of the set BORVAnBO ⊆ PIA, which is defined with the following: Elt(BORVAnBO ) = {x|(x ∈ AnBO ∪ SOAnBO ) ∨ (x ∈ DO ∪ R ∧ ∃a ∈ AnBO ∪ SOAnBO : (x, a) ∈ Realisation)} Rel(BORVAnBO ) = {(x, y)|x ∈ DO ∪ R ∧ y ∈ AnBO ∪ SOAnBO ∧(x, y) ∈ Realisation} ∪ {(t, z)|t, z ∈ AnBO ∪ SOAnBO ∧ (((t, z) ∈ Aggregation) ∨ ((t, z) ∈ Composition))}

(FD12)

We also define the extended business object realization viewpoint, which demonstrates access relationships to objects together with the business process flow and aggregation and composition relationships. It combines the elements of the business process execution support viewpoint, the relationships of the business process flow viewpoint, and both elements and relationships of the business object realization viewpoint. In addition, it comprises access relationship between the behaviour elements and business and data objects. The extended business object realization viewpoint addresses the elements and relationships of the set EBORVAnBO ⊆ PIA, which is defined with the following: Elt(EBORVAnBO ) = Elt(BORVAnBO ) ∪ Elt(BPSVAnBP ) Rel(EBORVAnBO ) = Rel(BPFVAnBP ) ∪ Rel(BORVAnBO ) ∪{(x, y)|x ∈ AnBP ∪ SPAnBP , y ∈ AnBO : (x, y) ∈ Access} ∪ {(x, y)|x ∈ ((AC ∪ AS) ∩Elt(EBORVAnBO )), y ∈ (Do ∩ Elt(EBORVAnBO )) : (x, y) ∈ Access}

(13)

6.2. Business process execution support analysis patterns A business process execution support analysis pattern (BPESAP) indicates the way the business process execution is supported. We have identified three main perspectives which should be considered for business process execution support analysis: automation perspective, role assignment perspective, and business process support completeness perspective. The main business process execution analysis patterns for each of these perspectives are as follows:


1489

Fig. 3. Business process (BP) execution support analysis patterns and perspectives.

• Automation perspective: automated business process pattern, unautomated business process pattern. • Role assignment perspective: manually supported business process pattern, manually unsupported business process pattern. • Business process execution support completeness perspective: unsupported business process pattern, partially supported business process pattern, and fully supported business process pattern. The completeness perspective can also be considered within each of the other two perspectives. Based on this, we define several pattern specializations for the two perspectives. The automated business process pattern can be specialized either as a partially or as a fully automated business process pattern. Analogously, the manually supported business process pattern can be specialized either as a fully manually supported business process pattern or as a partially manually supported business process pattern. Patterns in the three perspectives are not exclusive. Fig. 3 illustrates the main patterns based on the different perspectives (dimensions), and how they intersect. The figure also demonstrates a more detailed classification of the fully supported business process patterns (fully supported, fully automated and fully manually supported business process patterns). Within the automation perspective, we thus distinguish between the full redundant and full non-redundant business process automation pattern. The full redundant business process automation pattern means one or more of the following: (1) a fully automated process is assigned to more than one application component, (2) a process that is assigned to

an application component also uses an application service, or (3) at least one of its behaviour subelements is assigned to more than one application component or uses an application service. An example of such a process can be found in a business system where the order processing business process is performed by a CRM system for mobile products, and a CRM system for home audio appliances. This situation can occur in business systems that have traditionally had separate sales domains, and even though they have consolidated the business process models, the process is still performed using two different application systems. Another example is when an old and a new application system are used concurrently in the time period between introduction of the new system and dismissing the old system. The full redundant business process automation pattern is rare and represents a suboptimal structure. It is prone to application system maintenance difficulties and increases the time required to implement a business change in the application system (IT gap time). Within the role assignment perspective, we distinguish between the fully manually supported business process with single and multiple role-assignment patterns. The latter represents a business process which is assigned to more than one role. It is a suboptimal structure that usually indicates a problematic organizational structure, and can cause problems with responsibility. The full redundant business process automation pattern and the fully manually supported business process with multiple role-assignments are specializations of the fully redundantly supported business process pattern. This pattern also applies to business processes that are both automated and manually supported to an extent that causes business process support overlaps. This pattern (and its spe-

1490


cializations) is uncommon and represents suboptimal structures. However, it can be useful in enterprise acquisition situations and in situations when enterprises merge, as a basis for consolidation of business processes and their support. The strictly unsupported and partially supported business process patterns represent an incomplete enterprise architecture description. There are several possible reasons for such architecture description, for example (1) the business process is planned and the responsibilities have not yet been assigned, (2) the business process has been dismissed, (3) the architecture description is still under development, (4) incorrect architecture description (it does not describe the actual situation), (5) correct enterprise architecture description of an erroneous business model. If the reason is (1), these patterns represent a useful basis for planning, as they reveal important business process aspects that have not yet been determined. If the reason is (5), the pattern reflects an actual situation for an existing business process (not planned or dismissed), and means that responsibilities are not clear and the process is performed ad hoc, or cannot be performed. If the strictly unsupported or the partially supported business process pattern is detected, the reason should be examined. If the reason is either (4) or (5), appropriate action should be taken. The most common pattern is the fully non-redundantly supported business process pattern and its specializations based on the automation and role-assignment perspectives. Besides completeness, another important aspect within the automation perspective is heterogeneity of application components used in a business process. Based on this, we identified another classification of the automated business process pattern: heterogeneous application support of a business process pattern and homogenous application support of a business process pattern. In the following subsections, we present different business process execution support analysis patterns in more detail. The examples given are presented from the business process execution support viewpoint. 6.2.1. Fully automated business process pattern Identification: BPESAP.AL1.A1 Description: Business process is assigned to an application component, which completely automates the process. Membership set definition: A subset of analysed business processes that correspond to the fully automated business process pattern is defined as: FABPAnBP = {a|a ∈ AnBP ∧ ((∃b ∈ AC : (b, a) ∈ Assignment) ∨(∀sp ∈ SP(a) : ∃ac ∈ AC ∧ (ac, sp) ∈ Assignment (FD14)

Fig. 4. Fully automated business process pattern (BPESAP.AL1.A1).

∈ Assignment) ∨ (∃sp2 ∈ SP(a), ∃as ∈ AS : (as, sp2) ∈ Used By))}

(FD15)

Example: Fig. 5 represents an example business process execution support view for the business process B, which is partially automated by using two application services. 6.2.3. Unautomated business process pattern Identification: BPESAP.AL2 Description: Business process does not have any support in the application layer. Membership set definition: A subset of analysed business processes that correspond to the unautomated business process pattern is defined as: UABPAnBP = {a|a ∈ AnPB\(FABPAnBP ∪ PABPAnBP }

(FD16)

Example: Fig. 6 illustrates an example business process execution support view that represents a business process D which corresponds to the unautomated business process pattern. 6.2.4. Fully manually supported business process pattern Identification: BPESAP.MS1.1 Description: Business process is assigned to one or more business roles. Business actors who fulfil the roles wholly perform the business process without using application services. Membership set definition: A subset of analysed business processes that correspond to the fully manually supported business

Example: Fig. 4 represents an example business process execution support view for the business process A, which is fully automated with the application component AC1. 6.2.2. Partially automated business process pattern Identification: BPESAP.AL1.A2 Description: A business process corresponds to the partially automated business process pattern if it is not fully automated and one or both of the following are true: (1) business process uses at least one application service, (2) at least one of its behaviour subelements is assigned to an application component (is fully automated) or uses an application service. Membership set definition: A subset of analysed business processes that correspond to the partially automated business process pattern is defined as: PABPAnBP = {a|a ∈ AnBP\FABPAnBP ∧ ((∃b ∈ AS : (b, a) ∈ Used By ∨ (∃sp1 ∈ SP(a), ∃ac ∈ AC : (ac, sp1)

Fig. 5. Partially automated business process pattern (BPESAP.AL1.A2).


Fig. 6. Unautomated business process pattern (BPESAP.AL2).

Fig. 7. Strictly unsupported business process pattern (BPESAP.S2).

process pattern is defined as: FMBPAnBP = {a|a ∈ AnBP ∧ (((∃r ∈ BR : (r, a) ∈ Assignment) ∧(as ∈ AS : (as, a) ∈ Used By)) ∨ (∀sp ∈ SP(a) : (∃r1 ∈ BR : (r1, sp) ∈ Assignment) ∧ (as1 ∈ AS : (as1, sp) ∈ Used By)))}

(FD17)

Example: Fig. 6 illustrates an example business process execution support view that represents the fully manually supported business process pattern. It comprises a business process D, which is assigned to the business role BR1 and does not have any support in the application layer. 6.2.5. Partially manually supported business process pattern Identification: BPESAP.MS1.2 Description: A business process is partially manually supported if it is not fully manually supported and one or more of the following are true: (1) it is assigned to a business role, and business actor who fulfils the role uses one or more application services to perform the process, (2) if some of its behaviour subelements (but not all) are assigned to business roles, or if (3) if at least one of its behaviour subelements is assigned to a business role and uses one or more application services. Membership set definition: A subset of analysed business processes that correspond to the partially manually supported business process pattern is defined as: PMBPAnBP = {a|a ∈ AnBP\FMBPAnBP ∧ (((∃r ∈ BR : (r, a) ∈ Assignment) ∧ (∃as ∈ AS : (as, a) ∈ Used By)) ∧ (∃sp1 ∈ SP(a) : ((∃br1 ∈ BR : (br1, sp1) ∈ Assignment) ∧ (∃as1 ∈ AS : (as, sp1) ∈ Used By))) ∨ (∃sp2, sp3 ∈ SP(a) : ((sp2 = / sp3) ∧ (br2 ∈ BR : (br2, sp2) ∈ Assignment) ∧ (∃br3 ∈ BR : (br3, sp3) ∈ Assignment))))

1491

(FD18)

Example: Fig. 5 illustrates an example business process execution support view that corresponds to the partially manually supported business process pattern. It comprises a business process B, which is assigned to the business role BR1 and uses two application services.

6.2.6. Manually unsupported business process pattern Identification: BPESAP.MS2 Description: Business process is not assigned to any business roles. If the business process is an aggregation or a composition of behaviour subelements, none of them is assigned to a business role. Membership set definition: A subset of analysed business processes that correspond to the manually unsupported business process pattern is defined as: MUSBPAnBP = {a|a ∈ AnBP\(FMBPAnBP ∪ PMBPAnBP }

(FD19)

Example: Fig. 4 illustrates an example business process execution support view that represents the manually unsupported business process pattern. 6.2.7. Strictly unsupported business process pattern Identification: BPESAP.S2 Description: Business process does not have application support nor is it assigned to a business role. Membership set definition: A subset of analysed business processes that correspond to the strictly unsupported business process pattern is defined as: USBPAnBP = (UABPAnBP ∩ MUSBPAnBP )

(FD20)

Example: Fig. 7 illustrates an example business process execution support view that represents the strictly unsupported business process pattern. 6.2.8. Partially supported business process pattern Identification: BPESAP.S1.2 Description: Business process is partially supported if at least one of its behaviour subelements is assigned to a business role or to an application component, and at least one of its behaviour subelements is not assigned to neither a business role nor an application component. Business process is also partially supported if the process or at least one of its behaviour subelements uses at least one application service, but is not assigned to a business role. Membership set definition: A subset of analysed business processes that correspond to the partially supported business process pattern is defined as: PSBPAnBP = {a|a ∈ (AnBP\(FABPAnBP ∪ FMBPAnBP ∪ USBPAnBP )) : ((∃as ∈ AS : (as, a) ∈ Used By) ∧ (br ∈ BR : (br, a) ∈ Assignment)) ∨ (∃sp ∈ SP(a) : (br1 ∈ BR : (br1, sp) ∈ Assignment) ∧ (ac ∈ AC : (ac, sp) ∈ Assignment)))} (FD21)

1492


Fig. 8. Partially supported business process pattern (BPESAP.S1.2).

Fig. 9. Heterogeneous application support of a business process pattern (BPESAP.AL1.H1).

behaviour subelements: Example: Fig. 8 illustrates an example business process execution support view that represents the partially unsupported business process pattern. 6.2.9. Fully supported business process pattern Identification: BPESAP.S1.1 Description: Business process is fully supported if (1) it is either assigned to at least one business role or application component, or if (2) every one of its behaviour subelements is assigned to at least one business role or application component. Membership set definition: A subset of analysed business processes that correspond to the strictly unsupported business process pattern is defined as: FSBPAnBP = AnBP\(USBPAnBP ∪ PUSBPAnBP )

(FD22)

Example: Figs. 4–6 illustrate an example business process execution support view that represents the fully supported business process pattern. 6.2.10. Heterogeneous application support of a business process pattern Identification: BPESAP.AL1.H1 Description: Business process is supported by several different application components. Membership set definition: In order to define the membership set for the pattern, we first define three functions that are used in the membership set definition of this and several other subsequently defined patterns. We define a function ACU(bp) as a function that maps a business process bp ∈ BP into a set of application components that are used by bp and its behaviour subelements: ACU(bp) = {ac|ac ∈ AC ∧ (((ac, bp) ∈ Used By) ∨ (∃sp ∈ SP(bp) : (ac, sp) ∈ Used By))}

(FD25) A subset of analysed business processes that correspond to the heterogeneous application support of a business process pattern is defined as: HeASBPAnBP = {a|a ∈ AnBP ∧ |ACU(a) ∪ ACA(a) ∪ ACSPA(a)| ≥ 2} (FD26) Example: Fig. 9 represents an example of a business process execution support view showing a business process C, which corresponds to the heterogeneous application support of a business process pattern. 6.2.11. Homogenous application support of a business process pattern Identification: BPESAP.AL1.H2 Description: A business process with homogenous application support is supported by one application component. The application component may use application services provided by other application components; however this is transparent from the business process point of view. Membership set definition: A subset of analysed business processes that correspond to the homogenous application support of a business process pattern is defined as: HoASBPAnBP = {a|a ∈ AnBP ∧ (|ACU(a) ∪ ACA(a) ∪ ACSPA(a)| = 1)} (FD27) Example: Figs. 4 and 5 represent examples of business process execution support views showing the homogenous application support of a business process pattern.

(FD23)

Let us also define a function ACA(bp) as a function that maps a business process bp ∈ BP into a set of application components that are assigned to bp: ACA(bp) = {ac|ac ∈ AC ∧ ((ac, bp) ∈ Assignment)}

ACSPA(bp) = {ac|ac ∈ AC ∧ (∃sp ∈ SP(bp) : (ac, sp) ∈ Assignment)}

(FD24)

and a function ACSPA(bp) as a function that maps a business process bp ∈ BP into a set of application components that are assigned to bp’s

6.2.12. Full redundant business process automation pattern Identification: BPESAP.AL1.A1.1 Description: Business process corresponds to the full redundant business process automation pattern if it is assigned to more than one application component or if it is fully automated and at least one of its behaviour subelements is assigned to more than one application component. Membership set definition: A subset of analysed business processes that correspond to the full redundant business process


automation pattern is defined as: RFABPAnBP = {a|a ∈ FABPAnBP ∧ ((|ACA(a)| > 1) ∨ ((|ACA(a)| > 0) ∧ (|ACU(a)| > 0)) ∨ ((|ACA(a)| = 1) ∧ (∃b1 ∈ SP(a) : (|ACA(a) ∪ ACA(b1)| > 1) ∨ (|ACU(b1)| > 0))) ∨ ((|ACA(a)| = 0) ∧ (∃b2 ∈ SP(a) : (|ACA(b2)| > 1) ∨ ((|ACA(b2)| = 1) ∧ (|ACU(b2)| > 0)))))} (FD28)

1493

is assigned to a business role and an application component, or (4) if it is fully supported and there exists at least on behaviour subelement that is at the same time assigned to an application component and uses an application service. Membership set definition: Let us define a function BRA(bp) as a function that maps a business process bp ∈ BP into a set of business roles that are assigned to bp: BRA(bp) = {a|a ∈ BR : (a, bp) ∈ Assignment}

(FD32)

A subset of analysed business processes that correspond to the fully redundantly supported business process pattern is defined as: 6.2.13. Full non-redundant business process automation pattern Identification: BPESAP.AL1.A1.2 Description: Business process corresponds to the full nonredundant business process automation pattern if it is assigned to exactly one application component. It also corresponds to this pattern if it is not assigned to an application component, but every one of its behaviour subelements is assigned to exactly one application component. Membership set definition: A subset of analysed business processes that correspond to the full redundant business process automation pattern is defined as:

RFSBPAnBP = MFMBPAnBP ∪ RFABPAnBP ∪ (FSBPAnBP ∩ PMBPAnBP ∩PABPAnBP ∩ {a|a ∈ AnBP : ∃sp ∈ SP(a) ∧ ((|BRA(a) ∪ACA(a) ∪ BRA(sp) ∪ ACA(sp)| > 1) ∨ (|ACA(sp) = 1 ∧ |ACU(sp)| ≥ 1))})

(FD33)

6.2.14. Fully manually supported business process with multiple role-assignments pattern Identification: BPESAP.MS1.1.1 Description: Business process corresponds to the fully manually supported business process with multiple role-assignments pattern if it is assigned to more than one business role or if it is fully manually supported and at least one of its behaviour subelements is assigned to more than one business role. Membership set definition: A subset of analysed business processes that correspond to the fully manually supported business process with multiple role-assignments pattern is defined as:

6.2.17. Fully non-redundantly supported business process pattern Identification: BPESAP.S1.1.2 Description: Business process is fully non-redundantly supported if it is assigned to either one business role or one application component and none of its behaviour subelements are assigned to any other role or application component and none of its behaviour subelements uses an applications service. A business process is also fully non-redundantly supported if it is not assigned to a business role or an application component, but every one of its behaviour subelements is either (1) assigned to one business role and is not assigned to an application component, or (2) is not assigned to a business role, but is assigned to one application component and does not use an application service. Membership set definition: A subset of analysed business processes that correspond to the fully non-redundantly supported business process pattern is defined as:

MFMBPAnBP = {a|a ∈ FMBPAnBP ∧ ((|BRA(a)| > 1) ∨ ((|BRA(a)|

NRFSBPAnBP = FSBPAnBP \RFSBPAnBP

NRFABPAnBP = FABPAnBP \RFABPAnBP

(FD29)

= 1) ∧ (∃b1 ∈ SP(a) : (|BRA(a) ∪ BRA(b1)|

6.3. Business object realization analysis patterns

> 1))) ∨ ((|BRA(a)| = 0) ∧ (∃b2 ∈ SP(a) : (|BRA(b2)| > 1))))}

(FD30)

6.2.15. Fully manually supported business process with single role-assignment pattern Identification: BPESAP.MS1.1.2 Description: Business process corresponds to the fully manually supported business process with single role-assignments pattern if it is assigned to exactly one business role. It also corresponds to this pattern if it is not assigned to a business role, but every one of its behaviour subelements is assigned to exactly one business role. Membership set definition: A subset of analysed business processes that correspond to the fully manually supported business process with single role-assignments pattern is defined as: SFMBPAnBP = FMBPAnBP \MFMBPAnBP

(FD34)

(FD31)

6.2.16. Fully redundantly supported business process pattern Identification: BPESAP.S1.1.1 Description: Business process is fully redundantly supported (1) if it corresponds to the full redundant business process automation pattern, (2) if it corresponds to the fully manually supported business process with multiple role-assignments pattern, (3) if it is fully supported and there exists at least on behaviour subelement that

With increasing amounts of data, it is important that business objects are supported by the application layer and that data is not redundant. In the ArchiMate language, business object support is represented with the Realization relationship. A business object can be realized with a representation or a data object. In this context, a representation is regarded in terms of a concrete medium. We have identified three main business object realization analysis perspectives and the main patterns for each of them: • Business object application layer realization perspective: business object realized by application layer pattern, business object without application layer realization pattern. • Concrete business object realization perspective: concrete business object realization pattern, business object without concrete realization pattern. • Business object realization completeness perspective: unrealized business object pattern, partially realized business object pattern, fully realized business object pattern. The application layer realization perspective patterns indicate whether a business object is realized by data objects in the application layer. The concrete realization perspective patterns indicate whether a business object is realized by a concrete (physical) object, for example by a paper document. The realization completeness perspective indicates whether a business object is realized or not,

1494


Fig. 10. Business object (BO) realization analysis patterns and the corresponding perspectives.

and to what extent. The realization completeness perspective can also be considered within each of the other two perspectives. Based on this, we define several pattern specializations. The business object realized by application layer pattern can be specialized either as a business object partially or business object fully realized by application layer pattern. Similarly, the concrete business object realization pattern can be specialized as a full or partial concrete business object realization pattern. To a large extent these perspectives are analogous to the three main business process execution analysis perspectives, i.e. automation, role-assignment and business process execution support completeness perspectives, respectively. Patterns in the three perspectives are not exclusive. Fig. 10 illustrates the main patterns based on the different perspectives (dimensions), and how they intersect. Fig. 10 also demonstrates that for each of the fully realized business object patterns, we distinguish between the multiple and single realization patterns. The multiple application layer business object realization pattern represents business objects that are realized by more than one data object. An example of such business object is Customer, which is realized by a data object in a CRM system, an accounting application system and an order processing system. Multiple application layer business object realization pattern is very common and usually originates in systems where functional silos are present (or were present in the past). In such systems they often use separate application systems for different functional silos, even though important business objects are used in several or all parts of a business system. If these application systems are integrated, the integration usually occurred subsequently after the systems had been used for some time. Business objects

often remain realized in different systems. The multiple application layer business object realization pattern usually indicates suboptimal structures and data redundancies, which can cause well-known problems, such as complex data management and higher risk of data inconsistency. On the other hand, the multiple concrete business object realizations pattern represents business objects that are realized by more than one concrete representation. This pattern is common, because many organizations utilize concrete representations for storage purposes, for example for historical logging and backup purposes. This is often due to legal requirements for having paper documentation, such as invoices. This pattern can also be found historically, when IT was not yet commonly used. The most common is the fully realized business object pattern (and its specializations). The strictly unrealized and partially realized business object patterns represent business objects that are not or are not completely supported in the business system. Reasons are similar to those for the partially supported and strictly unsupported business process patterns: (1) business object is planned and its realizations are not yet determined, (2) the architecture description is still under development, (3) incorrect architecture description (it does not describe the actual situation), (4) correct architecture description of a suboptimal or erroneous business model. In the last case, the pattern reflects a situation in which a business process accesses a business object that is not fully realized. This means that the business object either represents tacit information associated by the business role responsible for the business process or that the process cannot access the required business process. This may be a reason for a faulty or improper business process execution. In case the reason is (3) or (4), this situation should be appropriately addressed.


1495

Description: A business object can be an aggregation or a composition of several business objects. In ArchiMate, this is modelled with the Aggregation or the Composition relationship, respectively. If a business object is partially realized by application layer, then it is not fully realized by the application layer and at least one of its aggregated or composite parts is realized by a data object. Membership set definition: A subset of analysed business objects that correspond to the business object partially realized by application layer pattern is defined as: PABOAnBO = {a|(a ∈ AnBO\FABOAnBO ) ∧ (∃b ∈ BO : ((a, b) ∈ Composition ∨ (a, b) ∈ Aggregation) ∧ (∃c ∈ DO : (c, b) ∈ Realization))}

Fig. 11. Business object fully realized by application layer pattern (BORAP.AL1.1).

In the following subsection, we present different business object realization analysis patterns in more detail. The examples given are presented from the business object realization viewpoint. 6.3.1. Business object fully realized by application layer pattern Identification: BORAP.AL1.1 Description: Business object is completely realized by data objects. It is realized by at least one data object. Membership set definition: A subset of analysed business objects that correspond to the business object fully realized by application layer pattern is defined as: FABOAnBO = {a|a ∈ AnBO ∧ ((∃b ∈ DO : (b, a) ∈ Realization) ∨ (∃bo ∈ BO : (((bo, a) ∈ Composition) ∨ ((bo, a) ∈ Aggregation)) ∧ (∃c ∈ DO : (c, bo) ∈ Realization))} (FD35)

Example: Fig. 11 represents an example of a business object realization view showing a business object BO1.A that is realized by the data object DO1. Business objects BO1.B and BO1.C compose the business object BO1.A. Therefore, BO1.A, BO1.B, and BO1.C correspond to the business object realized by application layer pattern.

(FD36)

Example: Fig. 12 represents two examples of a business object realization view. The business objects that correspond to the business object partially realized by the application layer pattern are business objects BO2.1 and BO2.2. 6.3.3. Business object without application layer realization pattern Identification: BORAP.AL2 Description: If a business object is not realized with the application layer, there is no data object that realizes it or any of its aggregate or composite parts. Membership set definition: A subset of analysed business objects that correspond to the business object fully realized by application layer pattern is defined as: UABOAnBO = AnBO\(FABOAnBO ∪ PABOAnBO )

(FD37)

Example: Fig. 13 represents an example business object BO3 which is not realized with the application layer. 6.3.4. Full concrete business object realization pattern Identification: BORAP.C1.1 Description: A business object with full concrete support is realized with at least one representation. Membership set definition: A subset of analysed business objects that correspond to the full concrete business object realization pattern is defined as: FCBOAnBO = {a|a ∈ AnBO ∧ ((∃b ∈ R : (b, a) ∈ Realization) ∨ (∃bo ∈ BO : (((bo, a) ∈ Composition) ∨ ((bo, a)

6.3.2. Business object partially realized by application layer pattern Identification: BORAP.AL1.2

∈ Aggregation)) ∧ (∃c ∈ R : (c, bo) ∈ Realization))}

Fig. 12. Business object partially realized by application layer pattern (BORAP.AL1.2).

(FD38)


1496

not comprised with the business objects BO2.3a and BO2.3b that is comprised within the BO2.3. 6.3.6. Business object without concrete realization pattern Identification: BORAP.C2 Description: If a business object does not have a concrete realization, there is no representation that realizes it or any of its aggregate or composite parts. Membership set definition: A subset of analysed business objects that correspond to the business object without concrete realization pattern is defined as: UCBOAnBO = AnBO\(FCBOAnBO ∪ PCBOAnB )

(FD40)

Example: Figs. 11 and 12(B) represent example business object realization views showing business objects that correspond to the business object without concrete realization pattern. Fig. 13. Business object without application layer realization pattern (BORAP.AL2).

Example: Fig. 13 represents an example business object BO3 that corresponds to the full concrete business object realization pattern. It is fully realized with a (paper) document D1. 6.3.5. Partial concrete business object realization pattern Identification: BORAP.C1.2 Description: If a business object is partially realized by application layer, then it does not correspond to the full concrete business object realization pattern and at least one of its aggregated or composite parts is realized by a representation. Membership set definition: A subset of analysed business objects that correspond to the partial concrete business object realization pattern is defined as: PCBOAnBO = {a|(a ∈ AnBO\FCBOAnBO ) ∧ (∃b ∈ BO : ((a, b) ∈ Composition ∨ (a, b) ∈ Aggregation) ∧ (∃c ∈ R : (c, b) ∈ Realization))}

6.3.7. Fully realized business object pattern Identification: BORAP.S1.1 Description: Business object is fully realized if it is realized by at least one data object and/or if it has at least one concrete realization. Membership set definition: A subset of analysed business objects that correspond to the fully realized business object pattern is defined as: FRBOAnBO = {a|a ∈ AnBO ∧ ((∃b ∈ (R ∪ DO) : (b, a) ∈ Realization) ∨ (∃bo ∈ BO : (((bo, a) ∈ Compositon) ∨ ((bo, a) ∈ Aggregation)) ∧ (∃c ∈ (R ∪ DO) : (c, bo) ∈ Realization)))}

(FD41)

Example: Examples of business objects that correspond to the fully realized business object pattern are represented in business object realization views shown in the following figures: Figs. 11 and 13.

(FD39)

Examples: Figs. 12(A) and 14 represent example business object realization views showing the partial concrete business object realization pattern; business objects that corresponds to this pattern are BO2.1b and BO2.3. Even though every composite business object of the business object BO2.3 is realized, the business object as a whole is not fully realized. There may be other information

6.3.8. (Strictly) unrealized business object pattern Identification: BORAP.S2 Description: Business object does not have a concrete realization nor an application layer realization. There is no representation or a data object that realizes the business object or any of its aggregate or composite parts. Membership set definition: A subset of analysed business objects that correspond to the strictly unrealized business object pattern is defined as: URBOAnBO = AnBO\(FCBOAnBO ∪ PCBOAnBO ∪ FABOAnBO ∪ PABOAnBO ) (FD42) Example: Fig. 15 represents an example business object realization view showing the strictly unrealized business object pattern of a business object BO4. 6.3.9. Partially realized business object pattern Identification: BORAP.S1.2 Description: Business object is partially realized if it is not fully realized and at least one of its aggregate or composite parts are realized. Membership set definition: A subset of analysed business objects that correspond to the partially realized business object pattern is defined as:

Fig. 14. Partial concrete business object realization pattern (BORAP.C1.2).

PRBOAnBO = AnBO\(FRBOAnBO ∪ URBOAnBO )

(FD43)


1497

Description: A business object may have more than one realization, for example in different documents, different data bases, etc. Membership set definition: Let us define a function BOR(bo) which maps a business object bo ∈ AnBO into a set of elements that realize it: BOR(bo) = {rdo|(rdo ∈ R ∪ DO) ∧ (((rdo, bo) ∈ Realization) ∨ (∃bo1 ∈ BO : (((bo1, bo) ∈ Composition) ∨ ((bo1, bo) ∈ Aggregation)) ∧ (rdo, bo1) ∈ Realization))}

(FD44)

Business objects that correspond to the multiple business object realization pattern can be defined as elements of the following set: MFRBOAnBO = {a|a ∈ AnBO ∧ |BOR(a)| ≥ 2} Fig. 15. Strictly unrealized business object pattern (BORAP.S2).

Example: Figs. 12(A), (B) and 14 represent an example business object realization view showing the partially realized business object pattern of business objects BO2.1, BO2.2, and BO2.3. 6.3.10. Multiple business object realization pattern Identification: BORAP.S1.1.1

(FD45)

Example: Fig. 15(A–D) represents different examples of the multiple business object realization pattern: 6.3.11. Single business object realization pattern Identification: BORAP.S1.1.2 Description: The single business object realization pattern corresponds to business objects that have exactly one realization (either with a representation or a data object, but not both).

Fig. 16. Multiple business object realization pattern (BORAP.S1.1.1).

1498


Membership set definition: Business objects that correspond to the single business object realization pattern can be defined as elements of the following set: SFRBOAnBO = {a|a ∈ AnBO ∧ |BOR(a)| = 1}

(FD46)

Example: Examples of the Single business object realization pattern are illustrated in Figs. 11 and 13. 6.3.12. Multiple application layer business object realization pattern Identification: BORAP.AL1.1.1 Description: In comparison to the multiple business object realization pattern, this pattern refers only to realizations of business objects in the application layer. The pattern is a specialization of the multiple business object realization pattern and the business object realized by application layer pattern. Membership set definition: Let us define a function BOAR(bo) which maps a business object bo ∈ AnBO into a set of data objects that realize it: BOAR(bo) = {do|(do ∈ DO) ∧ (((do, bo) ∈ Realization) ∨ (∃bo1

(FD47)

Business objects that correspond to the multiple application layer business object realization pattern can be defined as elements of the following set: MFABOAnBO = {a|a ∈ AnBO ∧ |BOAR(a)| ≥ 2}

(FD48)

Example: Examples of the multiple application layer business object realization pattern are illustrated in Fig. 16(B) and (D). 6.3.13. Single application layer business object realization pattern Identification: BORAP.AL1.1.2 Description: In comparison to the single business object realization pattern, this pattern refers only to realizations at the application layer. The pattern is not a specialization of the single business object realization pattern nor vice versa (see Fig. 10). If a business object is realized a single time, it can be realized with a concrete representation or a data object. On the other hand, if a business object has a single application layer realization, it may or may not also have concrete realizations. Membership set definition: Business objects that correspond to the single application layer business object realization pattern can be defined as elements of the following set: SFABOAnBO = {a|a ∈ AnBO ∧ |BOAR(a)| = 1}

MFCBOAnBO = {a|a ∈ AnBO ∧ |BoNAR(a)| ≥ 2}

(FD49)

Example: Examples of the single application layer business object realization pattern are illustrated in Figs. 11 and 16(A). 6.3.14. Multiple concrete business object realization pattern Identification: BORAP.C1.1.1 Description: Business object that corresponds to the multiple concrete business object realization pattern has more than one concrete realization. The pattern is a specialization of the multiple business object realization pattern and the concrete business object realization pattern. Membership set definition: Let us define a function BONAR(bo) which maps a business object bo ∈ AnBO into a set of representations that realize it:

(FD51)

Example: Examples of the multiple concrete business object realization pattern are illustrated in Fig. 16(B) and (C). 6.3.15. Single concrete business object realization pattern Identification: BORAP.C1.1.2 Description: Business object that corresponds to the single concrete business object realization pattern have exactly one concrete realization. The pattern is a specialization of the concrete business object realization pattern, however it is not a specialization of the single business object realization pattern. Membership set definition: Business objects that correspond to the single concrete business object realization pattern can be defined as elements of the following set: SFCBOAnBO = {a|a ∈ AnBO ∧ |BONAR(a)| = 1}

∈ BO : (((bo1, bo) ∈ Composition) ∨ ((bo1, bo) ∈ Aggregation)) ∧ (do, bo1) ∈ Realization))}

Business objects that correspond to the multiple concrete business object realization pattern can be defined as elements of the following set:

(FD52)

Example: Examples of the single concrete business object realization pattern are illustrated in Figs. 13 and 16(A). 6.4. Discussion and comparison of business process support analysis patterns In this section we discuss the proposed enterprise architecture patterns in terms of a sound architecture solution. It is important to note that pattern-based comparison of different enterprise architecture solutions should not be regarded as a rule, but as a guideline, which has to be put in the overall context of the business system. Soundness of the enterprise architecture is only one of the aspects that should be considered when analysing an enterprise architecture, planning a target architecture or planning a migration to the target architecture. Choosing the most optimal architecture solution solely based on the pattern-based guidelines may not always be the best choice, because other aspects have to be taken into consideration, such as business plan, strategy, goals, problems, available and required resources, priorities, and quantitative analysis results.1 For example, even though an existing pattern P1 represents a less appropriate architecture solution than a possible pattern P2, migration to P2 is not necessarily a good decision. If the existing solution does not hinder reaching the business goals and the P2 pattern does not benefit to their achievement, then the migration is very likely unnecessary and would represent additional expenses of resources that could be used to provide better support for the business plan. On the other hand, if the existing architecture is not aligned with business goals, the enterprise architecture patterns can be used to detect the potential suboptimal structures and determine a more optimal solution that would enable reaching the goals. We first give guidelines for comparison of different architecture patterns based on the business process execution support and business object realization perspectives, and then describe the priority improvement areas based on the detected patterns of an existing architecture. Comparison of different business process support patterns is applicable within each of the two business process support analysis pattern groups, i.e. the business process execution support analysis patterns and the business object realization analysis patterns.

BONAR(bo) = {r|(r ∈ R) ∧ (((r, bo) ∈ Realization) ∨ (∃bo1 ∈ BO : (((bo1, bo) ∈ Composotion) ∨ ((bo1, bo) ∈ Aggregation)) ∧ (r, bo1) ∈ Realization))}

(FD50)

1 These and other aspects are discussed in various enterprise architecture approaches, such as (The Open Group, 2009b), and are beyond the scope of this paper.


Based on the completeness perspectives, the fully supported business process pattern and fully realized business object pattern are the most appropriate alternatives, while the unsupported business process pattern and unrealized business object pattern are the least appropriate (see Sections 6.2 and 6.3). Thus, the first priority in the business process execution support group is that the execution is completely supported. The second priority is that business process execution is supported without redundancies, i.e. that the business process exhibits the fully non-redundantly supported BP pattern. Redundancies usually represent suboptimal structures as discussed on Section 6.2. Within this pattern, in most cases the companies try to maximize the automation of process activities and the process flow. There are various well-known reasons for this, such as improved process execution time and reducing repetitive manual tasks. For example, Ross et al. have surveyed 103 U.S. and European companies about their IT and IT-enabled business processes. Thirty-four percent of those companies have automated their core processes. Relative to their competitors, these companies have higher profitability, experience a faster time to market, they get more value from their IT investments, they have lower risk of mission critical systems failures, and eighty percent higher senior management satisfaction with technology. Please notice, that for the fully non-redundantly supported business process pattern, the automation and manual support perspectives are inversely proportioned. When examining different patterns from the automation perspective, it is important to assess the nature of the analysed business process from the point of view of reasonableness of automation. Even though automation of business processes if often desirable, there are also exceptions where partially automated business process pattern is the preferred choice. Examples are business processes where security or responsibility is important issues and manual checks are a necessary precaution, and business processes that require planning or decision making. For such processes, the fully automated business process pattern is irrelevant and should be discarded. A more thorough discussion about levels of business process automation and their applicability can be found ˇ sa et al. (2008). in Saˇ In the business object realization group, the first priority for a business object is to be fully realized. The second is that it is

1499

realized in the application layer, because this allows for automatic processing of the object. Due to management and consistency issues, the single application layer business object realization is preferred over the multiple application layer business object realization. For similar reasons, when considering both application layer and concrete business object realization perspectives, full multiple business object realization pattern is generally inferior to full single business object realization pattern. However, there are exceptions where it is nevertheless a more suitable choice. The reason for this is the diverse nature of business objects and drivers within organizations. Often, paper documentation has to be present due to legal requirements. In such organizations, the full multiple business object realization pattern can be expected and cannot be avoided. Furthermore, the nature of some business objects requires that they are realized with several representations, for example customer address is realized with the (paper) order document and the (paper) invoice. On the other hand, many organizations strive towards paperless business. For these organizations, the business object that corresponds to both business object without concrete realization pattern and the business object fully realized by application layer pattern are the most appropriate. If concrete realizations are present, single concrete realization is preferred over the multiple realizations pattern. Some organizations strive towards the paperless business, but still keep concrete business object representations, usually also for legal reasons or to store backup copies. Comparison of architecture solutions based on the automation support heterogeneity perspective is only applicable for those architectures that correspond to the same business process automation completeness perspective pattern. The heterogeneous application support of a business process pattern can lead to bottlenecks, which can be critical if efficient business process performance supports the business goals. For example, this is the case if the process is only partially automated and business actors perform the rest of the activities using different application components. This means that business actors have to be trained to use different application systems, that they have to switch between different application systems during their work, and that the business process flow is not automated. Another important drawback with the heterogeneous application support is that the process flow is not

Table 3 Pattern ranking. Business process execution support analysis group

Business object realization analysis group

Group ranking

Business process execution support analysis patterns that business processes of the ranking correspond to

Group ranking

Business object realization analysis patterns that business processes of the ranking correspond to

1

The fully non-redundantly supported business process pattern The fully non-redundantly supported business process pattern and the full non-redundant business process automation pattern (region A in Fig. 3) The fully non-redundantly supported business process pattern and the partially automated business process pattern and the partially manually supported business process pattern (region B in Fig. 3) The fully non-redundantly supported business process pattern and the fully manually supported business process pattern (region C in Fig. 3) Fully redundantly supported business process pattern Partially supported business process pattern Strictly unsupported business process pattern

1

The single application layer business object realization pattern The multiple application layer business object realization pattern

1.1

1.2

1.3

2 3 4

2

3

The full business object realization pattern and the business object partially realized by application layer pattern

4

The full concrete business object realization pattern and the business object without application layer realization pattern Partially realized business object pattern Strictly unrealized business object pattern

5 6

1500


Table 4 Priority improvement areas based on the detected pattern. Business process execution support analysis group

Business object realization analysis group

Detected pattern

Priority improvement areas

Detected pattern

Priority improvement areas

The strictly unsupported business process pattern or the partially supported business process pattern

The most important aspect is to complete business process execution support. The second most important aspect is to maximize the automation without causing redundancies and with minimizing the application support heterogeneity The most important aspect is to eliminate redundancies while maximizing the automation perspective and minimizing the application support heterogeneity The most important aspects is to maximize the automation with respect to the nature of the process (based on the assessment of automation reasonableness) while avoiding redundancies and application support heterogeneity

The strictly unrealized business object pattern or the partially realized business object pattern

The most important aspect is to complete business object realization. The second most important aspect is to maximize the completeness of realization in the application layer without causing multiple application-layer realizations The most important aspect is to eliminate redundant application layer realizations while maximizing the completeness of realization in the application layer The most important aspects is to maximize the completeness of realization in the application layer without causing multiple application layer realizations

The fully redundantly supported business process pattern

The fully non-redundantly supported business process pattern

centralized. This hinders business process and business activity monitoring, and consequently measuring of the process-based key performance indicators. These are important aspects that should be considered, because they play an important role in achieving business goals. Homogeneous structures are also desirable to reduce costs of maintenance activities, software and hardware licenses, and to ensure that similar concerns are treated equally (Bucher et al., 2006). For these reasons, the homogenous application support of a business process pattern is usually preferred over the heterogeneous application support of a business process pattern. Based on these observations, one can establish there is no onefor-all ranking of different patterns that would be applicable for all types of business processes. Considering the nature of business processes, the pattern rankings should be established for individual domains of analysed business processes. However, in the remainder of the section we give an example ranking and priority improvement areas based on the most general business process optimization directions where redundancy is avoided, automation is preferred over manual process execution, and business objects should be realized by the application layer to enable automatic processing. We give a general ranking of different patterns within each of the two groups in terms of a sound architecture for this type of business processes. The ranking is given in Table 3 in descending order. For other types of business processes, it can be used as a baseline which can be adapted. For example, if full non-redundant business process automation pattern is not relevant for a given business process, the 1.1. ranking is also irrelevant and can be ignored. In this case, the ranking 1.2 is the best ranking in the business process execution support analysis group. When analysing an existing architecture, the patterns can be detected based on their definitions given in the preceding subsections. Based on patterns of a given analysed business process, the importance of aspects that should be considered and their priorities differ. Priority improvement areas based on detected patterns are given in Table 4. They refer to the same type of business processes as the pattern ranking in Table 3. One can observe that they correspond to increasing pattern ranking. 7. Proof of concept As a proof of concept, the proposed enterprise architecture patterns have been used for enterprise architecture analysis and planning in four large Slovenian organizations: the two largest electric distribution companies, the Employment Service of Slovenia,

The business object fully realized by application layer pattern

The business object fully realized and either the business object partially realized by application layer pattern or business object without application layer realization pattern

and an important financial institution. We have used them in the scope of IT strategic planning projects, which is one of the most important domains of enterprise architectures. The methodology used in the projects was the EMRIS IT strategic planning methodolˇ sa et al., 2009). ogy, which is based on enterprise architectures (Saˇ We have implemented the patterns in the ARIS ArchiMate Modeler and the BiZZDesign Architect using the script and query languages of the two tools. The enterprise architecture patterns described in this paper have served as a very beneficial tool in both of the main strategic planning phases: the strategic analysis and the planning phase. As part of the strategic planning we analysed the key business processes of the organizations using the enterprise architecture approach. The patterns enabled us to efficiently detect different suboptimal structures of the existing enterprise architecture. They were used as a formal basis to highlight the positive and the negative aspects of the existing business process support. In the planning phase they were used to evaluate and compare the different possible target architectures and to determine the most optimal architecture. They were also very useful to formally explain the decisions made from the architecture point of view. In the remainder of the section we present a business process that we analysed for the Employment Service of Slovenia. In the project, we analysed all the core business processes of the organization. For the purpose of this paper, we have chosen to represent the Unemployed person Registration and Preparation business process based on two main criteria: ease of understanding and demonstration of the main aspects of using the business process support analysis patterns. We demonstrate and compare a baseline and a target enterprise architecture from the business process point of view using the proposed enterprise architecture patterns. The process concerns the registration of an unemployed person (UP) into the unemployed persons registry, verification activities, preliminary counselling, categorization of the UP into an employment programme, and the informative and motivational seminar (IMS). Figs. 17 and 18 illustrate the baseline and the target business process execution support views. Figs. 19 and 20 illustrate the baseline and the target extended business object realization views. The process shown is slightly simplified in order to demonstrate the main concepts. When developing the target architecture, it is important to maximize the benefits for all the analysed business processes. Other aspects, such as the migration strategy and the transition architectures required to migrate from the baseline to the target architecture, are beyond the scope of the paper. In our projects,


1501

Fig. 17. Business process execution support view – baseline enterprise architecture.

we used our IT strategic planning methodology (Krisper et al., ˇ sa et al., 2003b) enhanced with enterprise architecture aspects (Saˇ 2009), even though other enterprise architecture approaches can be used. The corresponding business process execution support analysis patterns and the business object realization analysis patterns for the baseline and target architecture of the process and its subprocesses are listed in Tables 5 and 6, respectively. When analysing the existing architecture using the implemented pat-

tern analysis scripts, it was simple to confirm that none of the processes are incompletely or redundantly supported. The process and its subprocesses were fully non-redundantly supported, partially automated and partially manually supported. Similarly, the patterns confirmed that the business objects used in this process are fully realized. However, they all had multiple realizations: either multiple application layer realizations, or both single concrete realizations and (single or multiple) application layer realizations.

Fig. 18. Business process execution support view – target enterprise architecture.

1502


Fig. 19. Extended business object realization view – baseline enterprise architecture.

From the business process execution support point of view, the least optimal pattern in the baseline architecture was detected for the UPRPP.2 subprocess, and consequently also for the overall UP Registration and Preparation business process. Three services realized by three different external application systems and one service realized by an internal application component were used in this process (heterogeneous application support of a business process pattern – HeASBPAnBP ). In this subprocess, the registration administrator had to verify whether the UP meets the conditions for registration using functionalities of the four systems. The other potential drawback from the point of view of process execution was that all the processes corresponded to the partially automated business process pattern. Due to the nature of the process, complete automation was not a relevant goal. For example, preliminary counselling and IMS would be very difficult and inappropriate to automate. Furthermore, a business process cannot be automated if a business object that is accessed by the process has to access a concrete realization of the business object. However, from the business object realization point of view, paper documentation was required to be presented or used in the UPRPP.1, UPRPP.5 and UPRPP.6 subprocesses due to legal requirements. Therefore, the UPRPP.1 process could not be fully automated either. On the other hand, the assessment of the nature of the business processes from the automation perspective revealed that other subprocessess, i.e. UPRPP.2, UPRPP.3, and UPRPP.5, could be fully automated. The least optimal business object realizations were those with the multiple application layer business object realization pattern. The multiple business object realizations that were due to the con-

crete realizations were legally required and could not be avoided. The multiple application layer business object realization pattern was detected for the UP record business object and its aggregate parts. This structure coincides with the heterogeneous application support of a business process pattern that was detected as the most problematic pattern for the UPRPP.2 subprocess. In order to complete the process, the administrator had to compare the business object in four different application systems. In order to place the pattern guidelines into a wider business context, let us present some of the aspects of the business and IT strategy that were relevant for this business process. They establish the main drivers based on the perspectives for the main enterprise architecture pattern groups. One of the most important strategic goals was to improve efficiency of existing core processes of the Employment Service. As the UP Registration and Preparation process is one of their core processes, an important goal for the process as a whole (and therefore also its subprocesses) was to enable efficient business process execution. Among other aspects of the business and IT strategy that influence this goal, one of the identified problems was that too much human resources were used to gather information due to inappropriate application layer support. This problem hindered another business goal, i.e. to enable efficient resource management and decision making. Based on these goals and problems, (efficient and quality) business process automation was one of the IT goals (and consequently, minimization of manual work). Another one of the IT goals was to improve integration of the information system. From the business process perspective, the heterogeneous application support of a business process pattern is the most adverse to this goal. This coincides with the pattern


1503

Fig. 20. Extended business object realization view – target enterprise architecture.

Table 5 Business process execution support analysis patterns for the example business process. Business process

UPRPP.1 UPRPP.2 UPRPP.3 UPRPP.4 UPRPP.5 UPRPP.6 UP Registration and preparation process

Automation perspective

Role assignment perspective

Execution support completeness perspective

Baseline

Target

Baseline

Target

Baseline

Target

PABPAnBP HoASBPAnBP PABPAnBP HeASBPAnBP PABPAnBP HoASBPAnBP PABPAnBP HoASBPAnBP PABPAnBP HoASBPAnBP PABPAnBP HoASBPAnBP PABPAnBP HeASBPAnBP

PABPAnBP HoASBPAnBP NRFABPAnBP HoASBPAnBP NRFABPAnBP HoASBPAnBP HoASBPAnBP HoASBPAnBP NRFABPAnBP HoASBPAnBP PABPAnBP HoASBPAnBP PABPAnBP HoASBPAnBP

PMBPAnBP

PMBPAnBP

NRFSBPAnBP

NRFSBPAnBP

PMBPAnBP

MUSBPAnBP

NRFSBPAnBP

NRFSBPAnBP

PMBPAnBP

MUSBPAnBP

NRFSBPAnBP

NRFSBPAnBP

PMBPAnBP

PMBPAnBP

NRFSBPAnBP

NRFSBPAnBP

PMBPAnBP

MUSBPAnBP

NRFSBPAnBP

NRFSBPAnBP

PMBPAnBP

MUSBPAnBP

NRFSBPAnBP

NRFSBPAnBP

PMBPAnBP

PMBPAnBP

NRFSBPAnBP

NRFSBPAnBP

ranking and priority improvement areas given in Tables 3 and 4 for the examined business process. One can observe that the target architecture improves the architecture solution, because in comparison with the baseline architecture every pattern for the target architecture is either improved or the same. The main change was the integration of the external and internal systems. In the target architecture, the integration and an appropriate change to the ZPNet application component enabled automatic verification of conditions, and if the conditions are met, automatic UP registration. Thus, the integra-

tion enabled automation of the UPRPP.2 subprocess, elimination of application layer support heterogeneity (in the UPRPP.2 subprocess and consequently also in the overall process), and elimination of the multiple application layer realizations of the UP record business object. The other important change was to improve the ZPNet application component to enable automation of the subprocesses that were identified as appropriate for automation (UPRPP.2, UPRPP.3, UPRPP.5). With this, the target architecture maximized the automation of the UPRPP.2, UPRPP.3, UPRPP.5 subprocesses and the overall UP Registration and Preparation business process

1504


Table 6 Business object realization analysis patterns for the example business process. Business object

Registration data UP Employment History UP Employment Period Basic UP data UP record Invitation to IMS Attendees

Business object realization analysis patterns Application layer realization perspective

Concrete realization perspective

Realization completeness perspective

Baseline

Target

Baseline

Target

Baseline

Target

MFABOAnBo MFABOAnBo MFABOAnBo MFABOAnBo MFABOAnBo SFABOAnBo SFABOAnBo

SFABOAnBo SFABOAnBo SFABOAnBo SFABOAnBo SFABOAnBo SFABOAnBo SFABOAnBo

SFCBOAnBo SFCBOAnBo SFCBOAnBo SFCBOAnBo PCBOAnBo SFCBOAnBo SFCBOAnBo

SFCBOAnBo SFCBOAnBo SFCBOAnBo SFCBOAnBo PCBOAnBo SFCBOAnBo SFCBOAnBo

MFRBOAnBo MFRBOAnBo MFRBOAnBo MFRBOAnBo MFRBOAnBo MFRBOAnBo MFRBOAnBo

MFRBOAnBo MFRBOAnBo MFRBOAnBo MFRBOAnBo MFRBOAnBo MFRBOAnBo MFRBOAnBo

(considering the nature of the process and reasonableness of its automation), eliminated existing redundancies, and did not introduce new redundancies. An important property of the patterns is that they are formalized in a way which enables their implementation in the enterprise architecture tools. The implemented pattern analysis scripts that we used in the projects enabled us to work more efficiently. Even though the UP Registration and preparation business process is not very complex and only has 6 main subprocesses, there were 56 different patterns that the process and its subprocesses corresponded to in the business process execution support group, and 42 different patterns that the analysed business objects corresponded to. To analyse the process based on all the identified perspectives for the baseline and the various potential target architectures, would be a very complex task if the detection of patterns would not be implemented in the enterprise architecture system. For example, if the patterns had not been implemented in the overall system, the support completeness would have to be verified for every subprocess. If detection of the completeness perspective patterns is automated, the enterprise architect is only notified if a partially supported or unsupported pattern is detected, in which case, the architect can examine the situation. Furthermore, if the priority improvement areas are adapted for the given business processes, the resulting pattern ranking can be also automated. By applying the adapted priority improvement areas to the results of the pattern detection, potential directions for improvement of business process support can be obtained automatically. The proposed enterprise architecture patterns are intended to improve enterprise architecture analysis of business process support. They affect the enterprise architecture efficiency, which concerns the quality of the architecture process in terms of execution time and accuracy (van der Raadt and van Vliet, 2009). Before the introduction of our approach, the main enterprise architecture analysis methods used were impact of change analysis and gap analysis. Even though both of the techniques were valuable for their work, enterprise architecture analysis of business process support which is the basis for determining the positive and negative aspects of support for the given business processes and consequently the basis to determine the potential improvements (that are the inputs for impact of change and gap analysis), was not available. Therefore, the enterprise architecture analysis of business process support was performed process by process without any mechanism or method that would guide the business process analyst. We have performed an analysis of the time spent for enterprise architecture based business process support analysis before and after the introduction of our approach. We focused on the average amount of time required for a business process support analysis activity that takes an enterprise architecture description as an input and produces information about support of a given business process as an output. This information represents the input for decision making. The average time spent for this activity per

business process based on the information from all four organizations was 32.5 min without using our approach. When enterprise architecture patterns for business process support analysis were used, this activity was automated and the average time spent was 3.2 s. In all organizations, the activities were performed in the scope of strategic planning projects. The analysts that were responsible for business process support analysis observed that besides more efficient work, the information that is extracted from the architecture covers more aspects compared to their previous approach that mostly focused on determining missing support for business processes, and business object realization redundancies. To sum up, the enterprise architecture patterns enabled a systematic and powerful tool to analyse the appropriateness of enterprise architecture for the business process support and to analyse and select the most appropriate target architecture. They provided a rich foundation to analyse and compare different possible improvements in a simple and holistic way from different perspectives. Furthermore, by allowing for automatic pattern and improvement areas recognition, they contribute to enterprise architecture efficiency. 8. Implications and further work Business process support analysis is an integral part of many activities in organizations, such as business process optimization, planning activities on different levels of abstraction, development and integration of application systems, and management of responsibilities. The enterprise architecture patterns presented in this paper are intended to support these activities by providing a means for systematic analysis of different perspectives of business process support based on information from enterprise architecture descriptions. As far as we know, there is no other available approach or a mechanism that would provide this. On the one hand, it provides a higher level of support for business process analysis. On the other hand, it increases the scope of use of enterprise architectures in organizations. Since the patterns are formalized in a way that allows for their automatic recognition, they also represent an opportunity for providers of enterprise architecture tools to implement additional features for the users, such as guidance for the architect by providing automatic detection of the patterns to support business process support analysis activities, and of the patterns that represent incorrect or incomplete architectures. Besides the implications for the industry and organizations where enterprise architectures are used, and enterprise architecture tool providers, we see our work as a basis that can be built upon by other researchers in order to expand the set of enterprise architecture patterns to other domains of a business system to provide support for different types of enterprise architecture analysis. We believe that this would make a step closer to an important goal of enterprise architectures, i.e. to provide information of relevance to various stakeholders in order to support communication, decision making and planning activities.


In our forthcoming research, we will take two main directions where the existing enterprise architecture patterns will be used as a foundation. The presented research concerns the business and application layers of an enterprise architecture. In one of the directions of our research, we will intend to expand our current work with the enterprise architecture elements in the technology layer. We will try to identify business process support analysis patterns that span all three layers and formalize them. In the second direction of our research, we will use the presented patterns and try to identify composed patterns that cross both of the main identified business process support aspects, i.e. business process execution support aspect and business object realization aspect. By identification of such complex patterns, we could supply a means to efficiently derive additional information from enterprise architecture descriptions which is otherwise difficult to detect and extract from the complex enterprise architecture description. 9. Conclusion In this paper enterprise architecture patterns for business process support analysis were proposed. They enable systematic qualitative architecture analysis with the main goal to establish an enterprise architecture that soundly supports analysed business processes. As a basis for our approach, we have used the potential of the newly accepted standard enterprise architecture language – ArchiMate, and its ability to provide a common base for concepts of different architecture domains and cross-domain relationships. We have identified two main groups of business process support analysis patterns, the business process execution support patterns and the business object realization patterns. They address two main enterprise architecture based aspects of a business process: execution and business objects that the process accesses. In both groups we have identified three main perspectives and their sub-perspectives, which provide the basic dimensions for examination of different enterprise architecture solutions. In every perspective, we have formally defined possible patterns using the business process support elements of the ArchiMate metamodel. This allows for implementation of the patterns in the chosen enterprise architecture software system, which supports the ArchiMate language or the subset of its elements and relationships relevant for the business process support aspect. Applicability of the presented enterprise architecture patterns has been demonstrated with their use in four real world projects for important Slovenian organizations. They have been used as a formal foundation for decision making in the development of strategic plans, especially because they enabled efficient detection of important structures in the architecture, comparison of different target enterprise architectures, and served as a ground for explanation of decisions regarding the target architecture. The enterprise architecture patterns for business process support analysis enable (1) efficient qualitative analysis of the baseline enterprise architecture from the point of view of business process support, (2) establishment of the main directions for improvement of the existing enterprise architecture, and (3) comparison of potential target architectures. They represent a step forward for some of the most important research challenges in the field of enterprise architectures, such as evaluation of different architecture proposals, definition of architecture principles and patterns, and we therefore believe them to be a very valuable contribution to this field. References Aalst, W.M.P.V.D., Hofstede, A.H.M.T., Dumas, M., Wohed, P., 2009. Workflow Patterns Initiative: Workflow Patterns (WWW document) http://www.workflowpatterns.com. Aalst, W.M.P.V.D., Hofstede, A.H.M.T., Kiepuszewski, B., Barros, A.P., 2003. Workflow patterns. Distributed and Parallel Databases 14, 5–51.

1505

Bernus, P., Nemes, L., 1996. A framework to define a generic enterprise reference architecture and methodology. Computer Integrated Manufacturing Systems 9, 179–191. Bittles, S.R., Kreizman, R.A., 2005. Gartner Enterprise Architecture Process: Evolution 2005. Gartner. BiZZdesign, 2009. Architect (WWW document). http://www.bizzdesign.nl/ index.php/tools/bizzdesignarchitect. Bucher, T., Fischer, R., Kurpjuweit, S., Winter, R., 2006. Analysis and application scenarios of enterprise architecture: an exploratory study. In: 2006 10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW’06). Presented at the 2006 10th IEEE International Enterprise Distributed Object Computing Conference Workshops (EDOCW’06) , Hong Kong, China, pp. 28–128. Buckl, S., Ernst, A., Kopper, H., Marliani, R., Matthes, F., Petschownik, P., Schweda, C.M., 2009a. EA management patterns for consolidations after mergers. In: Patterns in Enterprise Architecture Management (PEAM2009) Workshop. Presented at the Patterns in Enterprise Architecture Management (PEAM2009) Workshop , Kaiserslautern, Germany. Buckl, S., Ernst, A.M., Matthes, F., Ramacher, R., Schweda, C.M., 2009b. Using enterprise architecture management patterns to complement TOGAF. In: Enterprise Distributed Object Computing Conference, IEEE International , IEEE Computer Society, Los Alamitos, CA, USA, pp. 34–41. Cabinet Office Chief Information Officer Council, 2010. xGEA Domains RefModel (WWW document). http://www.cabinetoffice.gov.uk/ erence cio/chief technology officer/revamp/xgea.aspx. Chalmeta, R., Campos, C., Grangel, R., 2001. References architectures for enterprise integration. Journal of Systems and Software 57, 175–191. Chen, D., Doumeingts, G., Vernadat, F., 2008. Architectures for enterprise integration and interoperability: past, present and future. Computers in Industry 59, 647–659. Chief Information Officer Council, 2001. A Practical Guide to Federal Enterprise Architecture, Chief Information Officer Council Version 1.0. Délégation Générale pour l’Armement, 2007. Le manuel de référence AGATE V3. DGA, Ministère de la Défense, Paris, France. Department of Defense, 2009. DoDAF Architecture Framework Version 2.0 (WWW document). http://cio-nii.defense.gov/sites/dodaf20/index.html. Department of the Treasury Chief Information Officer Council, 2000. Treasury Enterprise Architecture Framework. Department of the Treasury. Doucet, G., Gøtze, J., Saha, P., Bernard, S., 2009. Coherency Management: Architecting the Enterprise for Alignment, Agility and Assurance. International Enterprise Architecture Institute. ESPIRIT Consortium AMICE, 1993. CIMOSA: Open System Architecture for CIM. In: Research Reports Esprit/Project 688/5288 , 2nd ed. AMICE, Springer. Fowler, M., 1997. Analysis Patterns: Reusable Object Models. Addison-Wesley. Fox, M.S., 1992. The TOVE Project towards a common-sense model of the enterprise. In: Proceedings of the 5th International Conference on Industrial and Engineering Applications of Artificial Intelligence and Expert Systems , Springer-Verlag, pp. 25–34. Fraser, S., Gamma, E., Helm, R., Johnson, R., 2006. Design patterns: beginnings and futures. In: Companion to the 21st ACM SIGPLAN Symposium on Object-oriented Programming Systems, Languages, and Applications , ACM, Portland Oregon, USA, pp. 934–1934. Gamma, E., Helm, R., Johnson, R., Vlissides, J., 2002. Design patterns: abstraction and reuse of object-oriented design. In: Software Pioneers: Contributions to Software Engineering ,. Springer-Verlag New York, Inc., pp. 701–717. Havey, M., 2005. Essential Business Process Modeling, 1st ed. O’Reilly Media. IBM, 2009. IBM Rational System Architect (WWW document). http://www01.ibm.com/software/awdtools/systemarchitect/. ICTU, 2007. Nederlandse Overheid Referentie Architectuur, NORA 2.0. ICTU, Amsterdam, The Netherlands. IDS Scheer AG, 2009. ARIS ArchiMate Modeler (WWW document). http://www.idsscheer.com/en/ARIS/ARIS Platform/ARIS ArchiMate Modeler/21980.html. IEEE Computer Society, 2000. IEEE Recommended Practice for Architectural Description of Software-Intensive Systems, IEEE Standard 1471-2000. International Organization for Standardization (ISO), 2007. ISO/IEC 42010:2007, Systems and Software Engineering – Recommended Practice for Architectural Description of Software-intensive Systems. James, G.A., Handler, R.A., Lapkin, A., Gall, N., 2005. Gartner Enterprise Architecture Framework: Evolution 2005. Gartner. Johnson, P., Lagerström, R., Närman, P., Simonsson, M., 2007. Enterprise architecture analysis with extended influence diagrams. Information Systems Frontiers 9, 163–180. Jonkers, H., Lankhorst, M., ter Doest, H., Arbab, F., Bosma, H., Wieringa, R., 2006. Enterprise architecture: management tool and blueprint for the organisation. Information Systems Frontiers 8, 63–66. Kang, D., Lee, J., Choi, S., Kim, K., 2010a. An ontology-based enterprise architecture. Expert Systems with Applications 37, 1456–1464. Kang, D., Lee, J., Kim, K., 2010b. Alignment of business enterprise architectures using fact-based ontologies. Expert Systems with Applications 37, 3274–3283. Krisper, M., Roˇzanec, A., 2005. Obvladovanje informatike v poslovnih sistemih: pomen strategije in arhitektur. Uporabna informatika, 14. Krisper, M., Rupnik, R., Bajec, M., Roˇzanec, A., Zrnec, A., Vavpotiˇc, D., Osojnik, R., Tomaˇziˇc, R., 2003a. EMRIS – Enotna metodologija razvoja informacijskih sistemov (WWW document). http://www2.gov.si/mju/emris.nsf/. Krisper, M., Rupnik, R., Bajec, M., Roˇzanec, A., Zrnec, A., Vavpotiˇc, D., Osojnik, R., Tomaˇziˇc, R., 2003b. EMRIS – Enotna metodologija razvoja informacijskih sis-

1506


temov: Strateˇsko planiranje, 2nd ed. Government of the Republic of Slovenia, Government Centre for Informatics, Ljubljana. Lagerström, R., Franke, U., Johnson, P., Ullberg, J., 2009. A method for creating enterprise architecture metamodels-applied to systems modifiability analysis. International Journal of Computer Science and Applications 6, 89–120. Lagerström, R., Johnson, P., Höök, D., 2010. Architecture analysis of enterprise systems modifiability – models, analysis, and validation. Journal of Systems and Software 83, 1387–1403. Lankhorst, M., 2009. Enterprise Architecture at Work: Modelling Communication and Analysis, 2nd ed. Springer. Lankhorst, M., Luttighuis, P.H.O., 2009. Enterprise architecture patterns for multichannel management. In: Patterns in Enterprise Architecture Management (PEAM2009) Workshop. Presented at the Patterns in Enterprise Architecture Management (PEAM2009) Workshop , Kaiserslautern, Germany. Lankhorst, M.M., 2004. Enterprise architecture modelling-the issue of integration. Advanced Engineering Informatics 18, 205–216. Mayer, R.J., Crump, J.W., Fernandes, R., Keen, A., Painter, M.K., 1995. Information Integration for Concurrent Engineering (IICE) Compendium of Methods Report. Knowledge Based Systems, Inc., Texas, USA. Mertins, K., Jochem, R., 2005. Architectures, methods and tools for enterprise engineering. International Journal of Production Economics 98, 179–188. Miller, J., Mukerji (Eds.), 2003. MDA Guide Version 1.0.1. Object Management Group.. of Defence, 2008. MODAF 1.2 (WWW document). Ministry http://www.modaf.org.uk/. Morganwalp, J.M., Sage, A.P., 2004. Enterprise architecture measures of effectiveness. International Journal of Technology, Policy and Management 4, 81–94. Moser, C., Junginger, S., Brückmann, M., Schöne, K., 2009. Some process patterns for enterprise architecture management. In: Patterns in Enterprise Architecture Management (PEAM2009) Workshop , Kaiserslautern, Germany. NASCIO, 2003. NASCIO Enterprise Architecture Maturity Model, Version 1.3. National IT and Telecom Agency, 2009. OIO Arkitekturguiden (WWW document). http://ea.oio.dk/english-version/. NATO Consultation, Command and Control Board, 2007. NATO Architecture Framework, Version 3. OMG, 2009. Business Process Model and Notation (BPMN), Version 2.0 beta (WWW document). http://www.omg.org/cgi-bin/doc?dtc/09-08-14. Pulkkinen, M., Naumenko, A., Luostarinen, K., 2007. Managing information security in a business network of machinery maintenance services business – enterprise architecture as a coordination tool. Journal of Systems and Software 80, 1607–1620. Riehle, D., Züllighoven, H., 1996. Understanding and using patterns in software development. Theory and Practice of Object Systems 2, 3–13. Ross, J.W., Weill, P., Robertson, D., 2006. Enterprise Architecture as Strategy. Harvard Business Press. Roˇzanec, A., Krisper, M., 2010. How to define an IS/IT strategic plan with enterprise architecture? In: Slovenian Days of Informatics. Presented at the Slovenian Days of Informatics , Slovensko druˇstvo Informatika, Portoroˇz. Sarnikar, S., Zhao, J.L., 2008. Pattern-based knowledge workflow automation: concepts and issues. Information Systems and E-Business Management 6, 385–402. ˇ sa, A., Juric, M.B., Krisper, M., 2008. Service-oriented framework for human task Saˇ support and automation. IEEE Transactions in Industrial Informatics 4, 292–302. ˇ sa, A., Krisper, M., 2010. Analitski vzorci za poslovno-informacijske arhitekture. Saˇ Uporabna informatika XVIII. ˇ sa, A., Roˇzanec, A., Krisper, M., 2009. Enterprise architectures for strategic planning Saˇ and service-oriented architectures, Technical paper FRP6: 290223.

Schekkerman, J., 2006. How to Survive in the Jungle of Enterprise Architecture Framework. Trafford Publishing. Staron, M., Kuzniarz, L., Wohlin, C., 2006. Empirical assessment of using stereotypes to improve comprehension of UML models: a set of experiments. Journal of Systems and Software 79, 727–742. The Chief Information Officers Council, 1999. Federal Enterprise Architecture Framework, Version 1.1. CIO Council. The Chief Information Officers Council, 2008. Information Technology Strategic Plan 2008–2013. CIO Council. The Open Group, 2009a. ArchiMate 1.0 Specification. Van Haren Publishing. The Open Group, 2009b. TOGAF Version 9 TOGAF Series. Van Haren Publishing. US DoC, 2007. Enterprise Architecture Capability Maturity Model 1.2. United States Department of Commerce, Office of the Chief Information Officer, EnterpriseArchi- tecture ProgramSupport. van der Raadt, B., Bonnet, M., Schouten, S., van Vliet, H., 2010. The relation between EA effectiveness and stakeholder satisfaction. Journal of Systems and Software 83, 1954–1969. van der Raadt, B., Schouten, S., van Vliet, H., 2008. Stakeholder perception of enterprise architecture. In: Proceedings of the 2nd European Conference on Software Architecture , Springer-Verlag, Paphos, Cyprus, pp. 19–34. van der Raadt, B., van Vliet, H., 2009. Assessing the efficiency of the enterprise architecture function. In: Advances in Enterprise Engineering II, Lecture Notes in Business Information Processing ,. Springer, Berlin, Heidelberg, pp. 63–83. Wilkinson, M., 2006. Designing an ‘adaptive’ enterprise architecture. BT Technology Journal 24, 81–92. Williams, T., Bernus, P., Brosvic, J., Chen, D., Doumeingts, G., Nemes, L., Nevins, J., Vallespir, B., Vlietstra, J., Zoetekouw, D., 1994. Architectures for integrating manufacturing activities and enterprises. Computers in Industry 24, 111–139. Williams, T.J., 1992. The Purdue Enterprise Reference Architecture. Instrument Society of America, Industrial Computing Society, Research Triangle Park, NC. Zachman, J.A., 2010. Zachman International – The Official Home of the Zachman FrameworkTM (WWW document). http://www.zachmaninternational.com. Zanettin, M., Doumeingts, G., 1992. The GIM Method for CIM System Analysis. Advanced Studies in Systems Research and Cybernetics. International Institute for Advanced Studies in Systems Research and Cybernetics, Germany. Zelm, M., Vernadat, F.B., Kosanke, K., 1995. The CIMOSA business modelling process. Computers in Industry 27, 123–142. Ana Sˇ aˇsa received the B.Sc. degree in computer and information science, in 2005, and the Ph.D. degree in information systems and decision making, in 2009, from University of Ljubljana, Slovenia. She is currently employed as a researcher at the Information Systems Laboratory at the Faculty of Computer and Information Science, University of Ljubljana. Her primary research interests include enterprise architectures, business process modelling and execution, service-oriented architectures and decision support systems. Marjan Krisper received the M.Sc. in information systems engineering from University of Ljubljana, Slovenia, in 1977, and the Ph.D. in Expert Systems from University of Belgrade, Yugoslavia, in 1989. He is an associate professor, the Chair of Information Science and the Head of Information Systems Laboratory at the University of Ljubljana, Faculty of Computer and Information Science. His research interests include information systems, information systems development methodologies, information systems strategic planning, and electronic business. He is a member of Association of Information Systems and a senior member of Project Management Institute Slovenian Chapter.