Enterprise Architecture Management Pattern Catalog

Transcription

1 Enterprise Architecture Management Pattern Catalog Release 1. February 28 Software Engineering for Business Information Systems (sebis) Ernst Denert-Stiftungslehrstuhl Chair for Informatics 19 Technische Universität München

2

3 Enterprise Architecture Management Pattern Catalog Version 1. February 28 Technical Report TB 81 Sabine Buckl, Alexander M. Ernst, Josef Lankes, Prof. Dr. Florian Matthes Software Engineering for Business Information Systems (sebis) Ernst Denert-Stiftungslehrstuhl Chair for Informatics 19 Technische Universität München Boltzmannstraße, Garching b. München, Germany

4 About sebis sebis is the chair for Software Engineering for Business Information Systems at the Institute for Informatics of the Technische Universität München. sebis has been established in 22 with funding of the Ernst Denert-Stiftung and is headed by Professor Dr. Florian Matthes. The main research areas of sebis are: Software Cartography: Development of multi-faceted and formal models that help to manage (plan, build, operate, optimize) complex software application landscapes consisting of hundreds or thousands of information systems. Innovative technologies and software architectures for enterprise information and knowledge management (enterprise solutions, groupware and social software). Domain-specific and reflective languages and models for families of business applications. sebis is using software engineering methods (model construction & abstraction, analysis & design, construction & evaluation) and is working in close relationship with industrial partners and with organizations from the public sector. Professor Matthes puts particular emphasis on the knowledge transfer from academia to industry. For example, he is co-founder of CoreMedia AG, of infoasset AG, and of 2six Web log services AG, which at present employ a total of approx. 15 employees. Copyright Copyright c 28 Technische Universität München, sebis, Germany. All rights reserved. The information contained and opinions expressed herein may be changed without prior notice. Trademarks All trademarks or registered trademarks are the property of their respective owners. Disclaimer The information contained herein has been obtained from sources believed to be reliable at the time of publication but cannot be guaranteed. Please note that the findings, conclusions and recommendations that TU München, sebis delivers will be based on information gathered in good faith from both primary and secondary sources, whose accuracy cannot always be guaranteed by TU München, sebis. TU München, sebis disclaims all warranties as to the accuracy, completeness, or adequacy of such information. TU München, sebis shall have no liability for errors, omissions, or inadequacies in the information contained herein or for interpretations thereof. In no event shall TU München, sebis be liable for any damage of any kind (e.g. direct, indirect, special, incidental, consequential, or punitive damages) whatsoever, including without limitation lost revenues, or lost profits, which may result from the use of these materials. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. There will be no warranty that the results of this publication will be economically and technically exploitable and unencumbered by third-party proprietary rights. Sponsoring The Enterprise Architecture Management Viewpoint Survey has been sponsored by Siemens IT Solutions and Services within the context of the Center for Knowledge Interchange.

5 Contents 1 Introduction and Overview Objectives of the EAM Pattern Catalog Compilation of the EAM Pattern Catalog EAM Pattern Approach Miscellaneous Information Using the EAM Pattern Catalog Establishing an organization-specific EA Management through EAM Pattern Integration Inspiring and Assessing an already implemented EA Management approach EAM Pattern Catalog as a basis for academic research Integrating EAM Patterns Integrating M-Patterns Integrating V-Patterns Integrating I-Patterns How to Read the EAM Pattern Graph Concerns 1.1 Concern C Concern C Concern C Concern C c TU München, sebis, 28. All rights reserved. 5

6 CONTENTS.5 Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C Concern C c TU München, sebis, 28. All rights reserved.

7 CONTENTS.9 Concern C Concern C Concern C Concern C Concern C Methodology Patterns (M-Patterns) Technology Homogeneity Analysis of Standard Conformity of the Application Landscape (M-2) Management of Blueprint Conformity of the Application Landscape (M-4) Management of Homogeneity (M-) Analysis of standard vs. individual Software (M-1) Analysis of the Enterprise Knowledge (M-5) Business Processes Process Analysis (M-) Application Landscape Planning Analysis of the Application Landscape (M-1) Development of Plan and Target Landscapes (M-14) Management of the Application Lifecycle (M-15) Horizontal and vertical integration (M-18) Support of Business Processes High Level Process Support (M-29) Business Process Data Flow Analysis (M-) Project Portfolio Management Strategic Conformance Analysis of the Project Portfolio (M-24) Monitoring of the Project Portfolio (M-25) Decision for Project Approval (M-2) Infrastructure Management Infrastructure Failure Impact Analysis (M-4) Interface, Business Object, and Service Management Management of Business Objects (M-19) Management of Business Services and Domains (M-2) Management of Interfaces (M-21) Service Lifecycle Management (M-22) c TU München, sebis, 28. All rights reserved. 7

8 CONTENTS 5 Viewpoint Patterns (V-Patterns) Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Consequence Section c TU München, sebis, 28. All rights reserved.

9 CONTENTS 5.15 Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section c TU München, sebis, 28. All rights reserved. 9

10 CONTENTS 5.29 Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V c TU München, sebis, 28. All rights reserved.

11 CONTENTS Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Viewpoint V Solution Section Viewpoint V Solution Section Consequence Section Viewpoint V Solution Section Consequence Section Information Model Patterns (I-Patterns) I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section Consequence Section I-Pattern I Solution Section Consequence Section I-Pattern I c TU München, sebis, 28. All rights reserved. 11

12 CONTENTS.5.1 Solution Section I-Pattern I Solution Section Consequence Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section Consequence Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I c TU München, sebis, 28. All rights reserved.

13 CONTENTS.21.1 Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section Consequence Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section c TU München, sebis, 28. All rights reserved. 1

14 CONTENTS.8 I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section I-Pattern I Solution Section Consequence Section A Evaluation of the Questionnaire 29 A.1 Approach of the Evaluation A.1.1 Selecting Methodologies A.1.2 Viewpoints and Related Aspects A.2 Results of the Evaluation A.2.1 Analysis of Homogeneity of the Application Landscape (M-1) A.2.2 Analysis of Standard Conformity of the Application Landscape (M-2) A.2. Management of Homogeneity (M-) A.2.4 Management of Blueprint Conformity of the Application Landscape (M-4) A.2.5 Analysis of standard vs. individual software (M-1) A.2. Analysis of the enterprise knowledge (M-5) A.2.7 Process Analysis (M-) A.2.8 Analysis of the business processes in respect to customer needs (M-7) A.2.9 Alignment to Product Strategies (M-8) A.2.1 Process KPIs (M-9) A.2.11 Process Landscape Planning (M-12) A.2.12 Analysis of the Application Landscape (M-1) A.2.1 Development of Plan and Target Landscapes (M-14) A.2.14 Management of the Application Lifecycle (M-15) A.2.15 Horizontal and vertical integration (M-18) A.2.1 High Level Process Support (M-29) A.2.17 Business Process Data Flow Analysis (M-) c TU München, sebis, 28. All rights reserved.

15 CONTENTS A.2.18 Process Data Flow Analysis (M-2) A.2.19 Strategic Conformance Analysis of the Project Portfolio (M-24) A.2.2 Decision for Project Approval (M-2) A.2.21 Monitoring of the Project Portfolio (M-25) A.2.22 Alignment of Project Portfolio to Organizational Skills (M-28) A.2.2 Infrastructure Lifecycle Analysis (M-) A.2.24 Infrastructure Failure Impact Analysis (M-4) A.2.25 Management of Business Objects (M-19) A.2.2 Management of Business Services and Domains (M-2) A.2.27 Management of Interfaces (M-21) A.2.28 Service Lifecycle Management (M-22) A.2.29 Management of Service Levels Agreements (SLA) (M-2) A.2. Service Dependency Analysis (M-1) B Excluded EAM Patterns 28 B.1 Excluded M-Patterns B.1.1 Analysis of the business processes in respect to customer needs (M-7) B.1.2 Alignment of the business processes to product policy (M-8) B.1. Process KPIs (M-9) B.1.4 Planning the Process Landscape (M-12) B.1.5 Management of Service Levels Agreements (SLA) (M-2) B.1. Alignment of the Project Portfolio to Organizational Skills (M-28) B.1.7 Service Dependency Analysis (M-1) B.1.8 Detailled Analysis of Process Support (M-2) B.1.9 Infrastructure Lifecycle Analysis (M-) B.2 Excluded V-Patterns B.2.1 Viewpoint V B.2.2 Viewpoint V B.2. Viewpoint V B.2.4 Viewpoint V B.2.5 Viewpoint V B.2. Viewpoint V B.2.7 Viewpoint V B.2.8 Viewpoint V c TU München, sebis, 28. All rights reserved. 15

16 CONTENTS B.2.9 Viewpoint V B.2.1 Viewpoint V B.2.11 Viewpoint V B.2.12 Viewpoint V B.2.1 Viewpoint V B.2.14 Viewpoint V B.2.15 Viewpoint V B.2.1 Viewpoint V B.2.17 Viewpoint V B.2.18 Viewpoint V B.2.19 Viewpoint V B.2.2 Viewpoint V B.2.21 Viewpoint V B.2.22 Viewpoint V B.2.2 Viewpoint V B.2.24 Viewpoint V B. Excluded I-Patterns B..1 I-Pattern I B..2 I-Pattern I B.. I-Pattern I B..4 I-Pattern I c TU München, sebis, 28. All rights reserved.

17 CHAPTER 1 Introduction and Overview 1.1 Objectives of the EAM Pattern Catalog The objective of this document is to complement existing Enterprise Architecture (EA) management frameworks (see [Lei7], [Sch] for an overview of EA management frameworks), which provide a holistic and generic view on the problem of EA management by providing additional detail and guidance needed to systematically establish EA management in a step-wise fashion within a given enterprise. The EAM Pattern Catalog identifies the dependencies between individual management concerns (Which goal is to be achieved for which stakeholders?), management methodologies (Which activities are required to address a given concern?), supporting viewpoints (Which diagrams, figures, documents, etc. help stakeholders to collaboratively perform these activities?), and information models (Which information is required to generate a particular viewpoint?). Methodologies, viewpoints and information models are thus presented as patterns, so called EAM patterns: They describe possible solutions for recurring problems that can and may have to be adapted to a specific enterprise context. The EAM Pattern Catalog identifies best practices by focusing on concerns, methodology patterns, viewpoint patterns and information model patterns, which are considered relevant and useful by experienced practitioners and are also supported by literature. The EAM Pattern Catalog utilizes a consistent terminology and information organization to simplify the selection, adaption and integration of patterns. The EAM Pattern Catalog is organized in a way that it serves as a starting point for a pattern community, similar to the design pattern community in software engineering. Over time, the pattern catalog is meant to be expanded and revised based on the growing knowledge and practical experience gained in managing the EA. c TU München, sebis, 28. All rights reserved. 17

18 1. Introduction and Overview To summarize, the EAM Pattern Catalog should help practitioners introducing EA management in a given enterprise and should provide academia with a solid and extensive reference documenting current approaches in EA management and their rationale. 1.2 Compilation of the EAM Pattern Catalog The EAM Pattern Catalog has been compiled as part of the research on Software Cartography 1 (see e.g. [LMW5], [BEL + 7b], [Wit7], [BEL + 7a]) at the chair for Software Engineering for Business Information Systems (sebis) of Prof. Dr. Florian Matthes at the Technische Universität München. This research emphasizes the role of graphical maps to foster the communication between the different stakeholders (sponsors, users, developers, architects, administrators, etc.) of application landscapes, which often have different concerns and educational backgrounds. The catalog nicely demonstrates that viewpoints provide an eye-catching and easy to understand starting point for discussions about the goals and the scope of EA management initiatives. The EAM Pattern Catalog links these viewpoints with management methodologies, management objectives (concerns), and underlying information models and provides the basis for an incremental development of EA management processes and information models. In a first phase (October 2 until July 27), the EAM Pattern Catalog was initialized by our group based on input from the following sources: Research project Software Cartography, Technische Universität München, Chair for Informatics 19 (sebis) (e.g. [LMW5], [BEL + 7b], [Wit7], [BEL + 7a]) Partners of the research project Software Cartography EAM Tool Survey 25 [seb5] Enterprise Architecture at Work (ArchiMate), 25, Marc Lankhorst et al. (Telematica Institut) [JGBvB5] Management von IT-Architekturen (Edition CIO), 2, Gernot Dern [Der] IT-Unternehmensarchitektur, 27, Wolfgang Keller [Kel7] In a second phase (July 27 until February 28), the initial EAM Pattern Catalog was evaluated using an online questionnaire to identify methodologies and viewpoints that are considered relevant and useful by practitioners. Appendix A provides details of this selection process as well as relevance and usage statistics for each element. The EAM Pattern Catalog tries to find a balance between a green field approach and a completely predefined approach as provided by some EA management frameworks and EA management tools. It avoids a giant integrated information model but utilizes a consistent terminology and a common organization to permit an understanding and comparison of multiple approaches from different sources. Sample viewpoints help readers to grasp essential concepts. 1 For more information about the research project Software Cartography see (in German). 18 c TU München, sebis, 28. All rights reserved.

19 1. Introduction and Overview Representatives of the following companies participated in the online questionnaire: Allianz Group IT AXA BSH Bosch und Siemens Hausgeräte BMW Group BTC AG cirquent Softlab Group Credit Suisse Deutsche Bahn Deutsche Börse Systems Deutsche Post Deutsche Telekom EWE AG FJH AG FIDUCIA IT HVB Information Services Krones Kuehne + Nagel Münchener Rück Nokia Siemens Networks O2 Germany RWE AG Siemens CIO Siemens PG Siemens IT Solutions and Services Wacker Chemie AG Zollner Elektronik Based on the evaluation of the questionnaire results, the EAM Pattern Catalog in its present form covers 4 concerns (48 have been excluded due to the questionnaire evaluation), 2 methodologies (1 have been excluded due to the questionnaire evaluation), 5 viewpoints (21 have been excluded due to the questionnaire evaluation), and 47 information model fragments (19 have been excluded due to the questionnaire evaluation). To support navigation and search, we clustered the best-practice concerns and methodologies according to the following EA management topics (see Figure 1.1). Technology Homogeneity (Complex 1) describes methodologies analyzing and managing whether the application landscape relies on a homogeneous set of technologies and architectures. Business Processes (Complex 2) is concerned with analyzing the interaction of business applications, business processes, and related entities relevant to business at a high level of abstraction. c TU München, sebis, 28. All rights reserved. 19

20 1. Introduction and Overview Application Landscape Planning (Complex ) is concerned with planning and analyzing the structure and evolution of the application landscape, focusing on current, planned, and target landscapes. Support of Business Processes (Complex 4) introduces methodologies for analyzing, how a specific business process is supported by IT. Project Portfolio Management (Complex 5) is concerned with managing the portfolio of projects changing the application landscape. For example, technical, financial, and strategic aspects are addressed in selecting projects to be included in the portfolio and in the subsequent monitoring of the portfolio. Infrastructure Management (Complex ) analyzes the technical infrastructure, on which the application landscape relies, and what impacts this infrastructure can have on the support the business applications provide to the business. Interface, Business Object, and Service Management (Complex 7) summarizes methodologies concerned with analyzing and finding services in the context of service oriented architectures (SOA). Thereby, the data flows created by communication via services, and the business objects exchanged through service interfaces are important aspects of the analyzes. Complex Methodology Technology Homogeneity M-2 M- M-4 M-5 M-1 Business Processes Application Landscape Planning Support of Business Processes Project Portfolio Management Infrastructure Management Interface, Business Object, and Service Management M- M-1 M-14 M-15 M-18 M-29 M- M-24 M-25 M-2 M-4 M-19 M-2 M-21 M-22 Figure 1.1: EA management topics addressed by the methodology patterns of the catalog 1. EAM Pattern Approach This section details the EAM pattern approach, which has first been introduced by [BEL + 7b] contrasting the variety of approaches from academia and practice, which exhibit at least one of the following problems: EA management is usually introduced from scratch, not considering related initiatives already present in or outside the organization. EA management frameworks, like Zachman [Zac92], TOGAF [Gro], etc., are usually either too abstract and therefore not implementable, or too extensive to be used in real world. Lacking an actual starting point for the EA management initiatives, companies tend to call for proposal to a wide number of potential EA stakeholders. Consolidating their demands and integrating their information needs an all-embracing EA management approach is likely to develop, which would demand a vast amount of data to be gathered, although only a part of it would be needed to address the pain points of the company. 2 c TU München, sebis, 28. All rights reserved.

21 1. Introduction and Overview If an approach has been implemented, it is mostly not documented, why certain decision have been taken, e.g. why a special entity has been introduced to the information model. This leads to information models, which cannot be adapted or extended due to the fact that no one knows what aspects rely on which parts of the model. Approaches proposed e.g. by organizations or standardization groups are usually a complete or nothing approach, meaning that it is supposed to be introduced as one single piece instead of an incremental introduction. This results in an EA management approach that cannot evolve according to the maturity level of the company. The EAM pattern approach tries to address the problems stated above, as it is based on best practices, with precise instructions, e.g. an information model fragment, which exactly specifies which data has to be maintained to address a concern. Additionally, it is a concern driven approach, which is extendible as it is based on patterns and includes rationales for design decisions made. In addition to concerns clustered by topic (see Section 1.2), the EAM Pattern Catalog includes three types of EAM patterns: A Methodology Pattern (M-Pattern) defines steps to be taken in order to address given concerns. Furthermore, as a guidance for applying the method, statements about the intended usage context are provided, which include the concerns to which the M-Pattern can be applied. These concerns are addressed by procedures defined by the M-Pattern, which can be very different, ranging from e.g. visualizations and group discussions to more formal techniques as e.g. metrics calculations. Missing methodologies constitute a common issue in EA management information models. On the other hand, frameworks as e.g. TOGAF [Gro] provide a process model (e.g. the TOGAF ADM), but leave the details of the methodologies supporting the specific activities in the EA management process relatively open. We explicate the methodology as part of our approach to EA management support, in order to complement activities carried out in an ad-hoc manner or relying on implicit knowledge with activities carried out more systematically. A Viewpoint Pattern (V-Pattern) provides languages used by M-Patterns. A V-Pattern proposes a way to present data stored according to one or more I-Patterns. In our research project Software Cartography, we found that industrial users often specify viewpoints by example. This means that an exemplary view is provided for the viewpoint, possibly together with some textual explanations. While we do not contend that this may be sufficient in certain use cases, e.g. sketching concepts in presentations, we see problems arising, when the goal is providing official information to a wider audience for an extended period. In order to ensure the understandability of a view, we regard a legend to be mandatory. An Information Model Pattern (I-Pattern) supplies underlying models (the abstract syntax) for the data visualized in one or more V-Patterns. An I-Pattern contains an information model fragment including the definitions and descriptions of the used information objects. As described in [BEL + 7b], different languages are possible for describing an I-Pattern, varying in their degree of formality, including among others textual descriptions in natural language, Meta Object Facility (MOF), Unified Modeling Language (UML) class diagrams, ontology languages, and mathematical formalizations, or combinations of these approaches. Choosing a specific approach basically has to consider the needs of the use cases to be supported. While an object-oriented description might be sufficient for creating a software map or a tabular report, process simulation may only be reasonably possible on a more formal basis. Therefore, we propose using a language adequate to the problem to be addressed, thereby strongly considering UML as the default language, as it is widely understood and has been found by us to be problem-adequate in many situations in the context of EA management information models [BEL + 7b]. In case a language different from UML is chosen, complementing its specification with an UML-based description can yield advantages, especially as integrating information model patterns is simplified by them being available in a common language. c TU München, sebis, 28. All rights reserved. 21

22 1. Introduction and Overview Patterns of all three EAM pattern types are described uniformly using the notation described in Table 1.1. Overview section Id Name Alias Summary Version Solution Section Consequence Section An unique alphanumerical identifier A short and expressive name for the EAM pattern Names this EAM pattern is also known as (optional) A short summary of the EAM pattern Version number of the EAM pattern Detailed description of the EAM pattern Consequences resulting from the usage of the EAM pattern (optional) Table 1.1: Structure of the EAM patterns M-Pattern also include a Problem Section, which lists the concerns addressed by the respective M- Pattern. Due to reasons of brevity, empty consequence sections are omitted. Figure 1.2 provides a graphical overview of the elements of the EAM Pattern Catalog and their relationships, the so called EAM pattern graph 2 : Concerns (orange) are addressed by M-Patterns (blue), which utilize V-Patterns (green) for communication. V-Patterns visualize information specified by I-Patterns (red). Concerns and M-Patterns are clustered into topics (nested boxes). 2 A downloadable and navigable version of the EAM pattern graph can be found at the EAM Pattern Catalog homepage at 22 c TU München, sebis, 28. All rights reserved.

23 1. Introduction and Overview Figure 1.2: Graphical overview of EAM Pattern Catalog elements and their relationships: Concerns (orange), M-Patterns (blue), V-Patterns (green) and I-Patterns (red) c TU München, sebis, 28. All rights reserved. 2

24 1. Introduction and Overview This diagram is also the basis for a content management solution to maintain the EAM Pattern Catalog in digital form. The conceptual UML class diagram in Figure 1. shows the classes, associations and their cardinalities. adressed by utilizes for communication visualizes information of Concern 1..* 1..* M-Pattern 1..* 1..* V-Pattern 1..* 1..* I-Pattern * * * * * * uses results of is layer for uses concepts of Figure 1.: UML class diagram describing the structure of the EAM Pattern Catalog 1.4 Miscellaneous Information The homepage of the EAM Pattern Catalog can be found at This website includes additional information about the EAM Pattern Catalog and documents that have been created together with the catalog. The Enterprise Architecture Management Viewpoint Survey, which represents the basis of the EAM Pattern Catalog, also encompassed a survey of the current understanding and approaches taken to EA management in practice. This resulted in the Enterprise Architecture Management Report 28 Best Practices and Trends. Further information about the Enterprise Architecture Management Viewpoint Survey can be found at For questions and suggestions concerning the EAM Pattern Catalog and the Enterprise Architecture Management Viewpoint Survey, or if you want to join the EAM pattern community please do not hesitate to contact us at eamvs@softwarekartographie.de Figure 1. includes an association called uses concepts of, which is not used in this version of the EAM Pattern Catalog, as relationships between different I-Patterns have not yet been included. See Section 2.4. for possible usage scenarios of this extension, which will be introduced in a future release of the EAM Pattern Catalog. 24 c TU München, sebis, 28. All rights reserved.

25 CHAPTER 2 Using the EAM Pattern Catalog The EAM Pattern Catalog, as a collection of best practices in EA management, may support different activities with three of them detailed below. 2.1 Establishing an organization-specific EA Management through EAM Pattern Integration The EAM Pattern Catalog supports introducing a light-weight, organization-specific approach to EA management based on best practices. In this use case it is assumed that EA management is introduced in a green field approach. In this case, first of all the pain points of the company, the so called concerns have to be identified. This is supported by the list of concerns included in the EAM Pattern Catalog, which can be found in Section. The selected concerns include references to M-Pattern that can be used to address these concerns. According to the approach sketched in Section 1., the methodology described in the M-Pattern uses certain V-Pattern for visualizing aspects of the EA, which are referenced by the M-Pattern. Based on the selected V-Pattern the associated I-Patterns have to be selected. The last step is to integrate the EAM patterns to a organization-specific approach for EA management. Section 2.4 gives some hints on how to integrate the EAM pattern. This approach is the same as the generalized process on how to implement an EA management approach based on EAM patterns shown in Figure 2.1. One or more catalogs of EAM patterns, supplied by pattern designers, serve as a basis. From these catalogs, the developers for EA management support choose EAM patterns, that are perceived as adequate for addressing specific concerns of the respective organization, preferably under participation of the prospective users. After integrating EAM patterns, thereby creating a coherent organization-specific conceptual model, the respective concepts can be implemented, e.g. in an EA management tool or a suite of tools. This procedure offers the possibility to incrementally implement an EA management approach, starting c TU München, sebis, 28. All rights reserved. 25

26 2. Using the EAM Pattern Catalog EAM Pattern 1 EAM Pattern 2 EAM Pattern EAM Pattern Catalogue Selection Selection EAM Pattern 1 EAM Pattern 2 Integration Conceptual Model Implementation Figure 2.1: Implementing an EA management approach based on EAM pattern with an initial set of M-Patterns, V-Patterns, and I-Patterns, which on the one hand includes rationale for the decisions made, e.g. why certain elements of the information model have been selected and on the other hand can later be extended, when a higher maturity level has been reached. In this case the EAM pattern graph (see Figure 1.2) can be used to e.g. identify EAM patterns, which easily fit into the already selected EAM patterns due to being closely related. For example, it can be possible to create additional visualizations using the information already collected. In this case the I-Patterns, which are already in use have to be determined and then further V-Patterns have to be found, which use the same information model fragments. The same is true for M-Patterns, as they use V-Patterns. Therefore, it may be possible that V-Patterns, which are already in use, can be utilized to address additional concerns with M-Patterns. 2.2 Inspiring and Assessing an already implemented EA Management approach The second usage scenario for the EAM Pattern Catalog is to take it as a reference book for suggestions concerning the approach currently selected in a company. This offers the possibility to compare the own EA management approach with best practices in use elsewhere. The EAM Pattern Catalog can e.g. be used to look for typical concerns, which occur in other companies. This case may best be addressed by simply flipping through the EAM Pattern Catalog. Additionally the EAM Pattern Catalog can suggest visualizations that can be found in academia and practice, which may be helpful in the currently selected EA management approach. In this cases the EAM pattern graph (see Figure 1.2) can be used to find on the one hand M-Patterns to address the concerns and on the other hand to find I-Pattern, showing the information needed to be able to create the required visualizations. 2. EAM Pattern Catalog as a basis for academic research In addition to the application of the EAM Pattern Catalog in practice, it may also be seen as a basis for future academic research. Currently, there is no common ground for research on EA management, meaning that there is no approach for EA management, which may be iteratively enhanced and extended. There are punctiform approaches for specific EA management topics, but these lack the integration into a holistic EA management approach, and the acceptance in wider communities. 2 c TU München, sebis, 28. All rights reserved.

27 2. Using the EAM Pattern Catalog The pattern based approach addresses this deficiency as it offers the possibility to improve single EAM patterns without having to create a completely new approach. Furthermore, the existing EAM Pattern Catalog can easily be extended due to the openness of the pattern approach. Therefore, we are establishing a community, which will govern the future development, by e.g. performing reviews, improvement, extension, etc., of the EAM Pattern Catalog. 2.4 Integrating EAM Patterns Integrating the selected EAM patterns is an important aspect of using the EAM Pattern Catalog. Special attention has to be paid to potential conflicts, inconsistencies, or discrepancies, due to contradictory assumptions made by different EAM patterns, especially when using EAM patterns of different origins 1. Such diverging assumptions may be completely valid for the EAM patterns themselves, e.g. due to them being based on different theories, being designed for different environments, or addressing different concerns. However, when simultaneously contained in a specific approach to EA management, diverging assumptions may easily turn out to be damaging or depriving results coming from the approach of their validity. This motivates the need to carefully manage such discrepancies in integrating EAM patterns, preferably avoiding them altogether. Thus, the below elaborations on integrating EAM patterns pay special attention to this issue Integrating M-Patterns Selecting and integrating M-Pattern defines, how a specific set of methodologies interact in order to address a given set of concerns. This can be achieved via a process model, which provides the steps to be taken in EA management. Therein, it exhibits, according to [Kro9], a basic characteristic of a method itself. Integrating M- Pattern can rely both on general research in the field of process models, from systems [Kro9] or software engineering [Som4], and also specific process models for EA management, which are part of some EA management frameworks, e.g. TOGAF ADM [Gro]. Basically, different reasons can lead to a methodology relying on specific assumptions: An M-Pattern may have been tested under specific conditions, other conditions can be known to be detrimental to the M-Pattern. An example may be factors known to benefit or impede effective knowledge management [DDLB98]. An M-Pattern may be directly built on a specific (scientific) theory, which is valid under certain assumptions [SBK7]. These assumptions then also have to hold for the M-Pattern to be applicable. In order to be able to effectively integrate EAM patterns, these assumptions have to be documented with the respective pattern. This is necessary to enable a pattern integrator managing inconsistencies when integrating M-Patterns. If e.g. one M-Pattern relies on information passing a formal review and publication process, while another M-Pattern wants to subject this information to wiki-style evolution, it has to be thoroughly checked whether and how these M-Pattern can be used together. 1 Integrating the EAM patterns shipped with this catalog should be a minor problem, as the EAM patterns are developed relying on a common terminology in order to fit to each other. c TU München, sebis, 28. All rights reserved. 27

28 2. Using the EAM Pattern Catalog Integrating V-Patterns Integrating V-Pattern may appear as the easiest integration task, as viewpoints are, according to the IEEE 1471 [IEE], supposed to be relatively self-contained. They are demanded to be able to address one or more concerns on their own, without demanding information from other viewpoints. Adopting the idea of patterns to viewpoints offers the advantage to easily add layers to viewpoints. It is then possible to e.g. visualize applications on one layer and different key performance indicators on additional layers. This is the basis for the so called layering principle 2, which is borrowed from cartography (see Figure 2.2 for an example). Measures Interconnections Applications Base Map Figure 2.2: Layering principle 2.4. Integrating I-Patterns As described in [BEL + 7b], integrating I-Patterns strongly relies on the integrator s skills in conceptual modeling. It may e.g. be possible to identify identical classes within two I-Patterns to be integrated. However, identifying identical classes may not be as easy as it possibly seems at first sight, e.g. by identifying similar class names. Although EAM pattern designers should simplify pattern integration by naming different concepts clearly differently, also across different EAM patterns, this cannot basically be expected, especially, if patterns from various catalogs with distinct authors are to be integrated. Issues in this respect may originate from the simplifications inherent in the creation of models [Sta7], which may of course vary in different abstractions underlying different I-Patterns. A prominent example in this respect can be found in common abstractions of a business application. In some cases, a business application signifies a system installed in a specific environment, offering specific functionalities. In other cases, the term might specify the software itself, making no statements about specific installations. Usage of the term might also vary in respect to the versioning information used. While, as stated above, sensible naming schemes, e.g. BusinessApplication, DeployedBusinessApplication, BusinessApplicationVersion, are able to contribute to the prevention of such problems, one must not rely on this alone. Exact definitions of the used concepts have to be provided by the pattern designers, in order to enable the user to find possibly contradictory definitions of concepts. Furthermore, 2 See [ELSW] for more details on the layering principle. During the creation of this EAM Pattern Catalog version, the distinction between different concepts with different names has been taken into account. Nevertheless, there are some concepts, like e.g. Service and Business Service where this distinction may be improved in one of the next releases of the EAM Pattern Catalog. Another improvement may be the introduction of abstract concepts, like a service, which may than be further detailed in a kind of inheritance relationship. 28 c TU München, sebis, 28. All rights reserved.

29 2. Using the EAM Pattern Catalog these definitions have to be used by the pattern integrators, checking them carefully to avoid possible inconsistencies in the resulting information model. 2.5 How to Read the EAM Pattern Graph Two different kinds of EAM pattern graphs are included in this EAM Pattern Catalog. An overview of all included EAM patterns, together with the addressed concerns (see Figure 1.2), and a subgraph for each M-Pattern and V-Pattern, showing the relationships of one EAM pattern to related EAM patterns 4. The complete EAM pattern graph has been simplified to improve readability, it e.g. does not include differentiations between different types of edges, but solely the relationships between the different EAM patterns. Additionally, concerns and M-Patterns have been clustered according to the structure introduced in Section 1.2. Contrastingly, the subgraphs are more detailed, as the semantics of the different edges are emphasized. Figure 2. shows the different kinds of relationships used in the subgraphs. The following description explains the different relationship types: Relationship Type 1 The concerns C-19 and C-11 are addresses by M-Pattern M-4. Relationship Type 2 M-Pattern M-4 uses V-Patterns V-9 and V-7. Relationship Type V-Pattern V-27 visualizes information of I-Patterns I-2 and I-27. Relationship Type 4 V-Pattern V-7 is a layer and can alternatively be used on V-Patterns V-25 and V-28. Relationship Type 5 V-Pattern V-24 constitutes a base map for V-Patterns V-9 and V-41. Relationship Type M-Pattern M-4 uses results of M-Pattern M-2. Relationship Type 1 Relationship Type 2 C-19 C-11 M-4 Relationship Type V-27 M-4 V-9 V-7 I-2 I-27 Relationship Type 4 Relationship Type 5 Relationship Type V-7 V-25 V-28 V-9 V-41 V-24 M-4 M-2 Figure 2.: Types of relationships between EAM patterns 4 Future versions of this EAM Pattern Catalog may also include subgraphs for each I-Pattern, as the I- Pattern may obtain more references to other I-Patterns. c TU München, sebis, 28. All rights reserved. 29

30

31 CHAPTER Concerns This chapter contains a listing of all concerns, which are considered in the EAM Pattern Catalog. The concerns are ordered according to their identifier. For each concern a list of M-Pattern addressing the concern is given. For allowing easier access to the concerns listed below, Figure.1 shows the concerns grouped according to the EA management topics introduced in Figure 1.1. Complex Concern Technology Homogeneity C-2 C-4 C-5 C-8 C-9 C-4 C-5 C-1 C-11 C-19 Business Processes C-54 C-55 C-5 Application Landscape Planning C- C-4 C-5 C-8 C-87 C-88 C- C-44 C-89 C-9 Support of Business Processes C-78 C-8 C-95 Project Portfolio Management Infrastructure Management C-29 C-41 C-91 C-92 C-98 Interface, Business Object, and Service Management C-51 C-52 C-1 C-2 C-4 C-5 C- C-7 C-8 C-7 C-71 C-99 Figure.1: EA management Topics used for structuring the Concerns c TU München, sebis, 28. All rights reserved. 1

32 . Concerns.1 Concern C-2 C-2: Where are architectural blueprints or architectural standards used, and are there areas where those standards are breached? Addressed by: M-2 (see page 4), M-4 (see page 44).2 Concern C-4 C-4: Which technologies, e.g. programming languages, middleware, operating systems, database management systems, used in the application landscape should be replaced, which ones should be kept? Addressed by: M- (see page 48). Concern C-5 C-5: Which activities or projects have to be started, in order to increase conformance to standards? What has to be done in order to modify the current business applications to increase their conformance to standards and reduce heterogeneity? Addressed by: M- (see page 48), M-4 (see page 44).4 Concern C-8 C-8: The goal is to reduce the usage of individual software, by replacing such systems with standard software. The concern is aimed at outlining project proposals for replacing individual software, which can then be evaluated in respect to their feasibility and benefit. Addressed by: M- (see page 48).5 Concern C-9 C-9: Possibilities to reorganize the application landscape in respect to the used technologies should be outlined. Thereby, possible goals are: Reducing licensing costs, reducing maintenance costs, taking into account the support periods of the technology products, etc. Addressed by: M- (see page 48). Concern C-19 C-19: Do the business applications currently used correspond to the architectural blueprints and architectural solutions (architectural standards)? If not, are there documented reasons for this, as e.g. strategic decisions? Addressed by: M-4 (see page 44) 2 c TU München, sebis, 28. All rights reserved.

33 . Concerns.7 Concern C-29 C-29: At the beginning of a planning period the available IT budget has to be assigned to project proposals. Project proposals that will be approved have to be selected, others have to be rejected or delayed. Addressed by: M-2 (see page 82).8 Concern C- C-: Which applications are used by which organizational units? Addressed by: M-1 (see page 1).9 Concern C-4 C-4: How does the long-term vision, the target of the application landscape, look like? Addressed by: M-14 (see page 4).1 Concern C-5 C-5: How does the application landscape look like at a specific date? Addressed by: M-14 (see page 4).11 Concern C- C-: Which dependencies exist between business applications and are affected by current or planned projects? Which projects change the same business application? Are there changes on a business application that must be finalized before changes made by another project can be performed? Addressed by: M-15 (see page ).12 Concern C-41 C-41: Which infrastructure software is used by the business applications? Addressed by: M-4 (see page 87), M-1 (see page 4).1 Concern C-44 C-44: How can the operating expenses and maintenance costs be reduced, e.g. by identification of business applications providing the same functionality (redundancy)? c TU München, sebis, 28. All rights reserved.

34 . Concerns Addressed by: M-18 (see page 9).14 Concern C-4 C-4: Which knowledge about specific subjects, e.g. currently available in the organization? Addressed by: M-5 (see page 54) technologies, or programming languages, is.15 Concern C-5 C-5: How is an architectural blueprint / architectural solution made up? Addressed by: M-2 (see page 4).1 Concern C-51 C-51: Which business objects are used or exchanged by which business applications or services? Addressed by: M-19 (see page 89).17 Concern C-52 C-52: What are the dependencies between the used business objects? Addressed by: M-19 (see page 89).18 Concern C-54 C-54: Do the business processes adequately consider the environment of the organization, like incoming events, as e.g. customer requests? Addressed by: M- (see page 57).19 Concern C-55 C-55: Which business processes, if any, are suitable candidates for being outsourced? Addressed by: M- (see page 57).2 Concern C-5 C-5: What business processes contain core competencies of the organization? 4 c TU München, sebis, 28. All rights reserved.

35 . Concerns Addressed by: M- (see page 57).21 Concern C-1 C-1: Which business objects are exchanged over which interfaces? Addressed by: M-19 (see page 89).22 Concern C-2 C-2: What are the domains of the application landscape? Addressed by: M-2 (see page 91).2 Concern C-4 C-4: How to find services within the development process of the application landscape? Addressed by: M-2 (see page 91).24 Concern C-5 C-5: Which services are offered by which business application? Addressed by: M-2 (see page 91).25 Concern C- C-: Which business processes are supported by which services? Addressed by: M-2 (see page 91).2 Concern C-7 C-7: Which interfaces are offered/used by which business application? Addressed by: M-21 (see page 9).27 Concern C-8 C-8: What is the type, e.g. online, offline, batch, etc. of a specific interface? How is the interface implemented? What are its capabilities? Addressed by: M-21 (see page 9) c TU München, sebis, 28. All rights reserved. 5

36 . Concerns.28 Concern C-7 C-7: Which business applications are affected by the shut-down of an interface? Addressed by: M-21 (see page 9).29 Concern C-71 C-71: How does the lifecycle of a service look like? Addressed by: M-22 (see page 9). Concern C-78 C-78: To which extent are the business processes supported by business applications? Which business processes are supported manually? Can the automated support be extended? Addressed by: M-29 (see page 71), M- (see page 74).1 Concern C-8 C-8: To which extend does the IT support the flexibility of the business processes? Where is the flexibility put at risk? Addressed by: M-18 (see page 9), M-29 (see page 71), M- (see page 74).2 Concern C-8 C-8: Which business applications are hosted by which organizational unit? Addressed by: M-1 (see page 1). Concern C-87 C-87: Which business processes are supported by which business application? Addressed by: M-1 (see page 1).4 Concern C-88 C-88: How will the application landscape evolve over time in order to support the strategies defined? What are the differences to the current landscape? Addressed by: M-14 (see page 4) c TU München, sebis, 28. All rights reserved.

37 . Concerns.5 Concern C-89 C-89: Which business applications will be affected by projects in the near future? Addressed by: M-15 (see page ). Concern C-9 C-9: In which phase of its lifecycle is a business application at a certain point in time? Addressed by: M-15 (see page ).7 Concern C-91 C-91: The activities modifying the application landscape should be aligned to the needs, which have been specified by the defined strategies. Thereby, financial aspects and necessities dictated by the environment of the organization, e.g. via laws, regulations, etc. should be considered. Addressed by: M-24 (see page 7).8 Concern C-92 C-92: Increase the probability of success of challenging projects by selecting them for special project monitoring/consulting by the enterprise architecture management. Identify the projects, which can be expected to profit from such a monitoring. Addressed by: M-25 (see page 78).9 Concern C-95 C-95: How can a more continuous IT support concerning business processes be realized? Addressed by: M-29 (see page 71), M- (see page 74).4 Concern C-98 C-98: What is the impact of the shut-down of an infrastructure element? What other elements of the application landscape are affected? Addressed by: M-4 (see page 87).41 Concern C-99 C-99: Which offered interfaces are affected by the removal of a business application? c TU München, sebis, 28. All rights reserved. 7

38 . Concerns Addressed by: M-21 (see page 9).42 Concern C-1 C-1: Analyze, to what extent individual and standard software is used in the application landscape. Addressed by: M-1 (see page 52).4 Concern C-11 C-11: Which activities or projects have to be started in order to improve conformance to architectural standards? Which modifications to the currently used business applications are necessary to achieve conformity? Addressed by: M-4 (see page 44) 8 c TU München, sebis, 28. All rights reserved.

39 CHAPTER 4 Methodology Patterns (M-Patterns) This chapter includes all M-Patterns that have been evaluated in the Enterprise Architecture Management Viewpoint Survey. They are grouped according to their membership to a question complex. c TU München, sebis, 28. All rights reserved. 9

40 4. Methodology Patterns (M-Patterns) 4.1 Technology Homogeneity Analysis of Standard Conformity of the Application Landscape (M-2) M-Pattern Overview Id M-2 Name Alias Summary Version 1. Analysis of Standard Conformity of the Application Landscape Analysis of Architectural Standards This M-Pattern gives an overview, which business applications conform to architectural standards Problem Section The methodology addresses the following concerns: C-2: Where are architectural blueprints or architectural standards used, and are there areas where those standards are breached? C-5: How is an architectural blueprint / architectural solution made up? One of the fundamental problems to be addressed in this context is the growing complexity of the application landscape induced by the uncontrolled increase in used technologies, architectures, platforms, etc. Controlling this growth is thereby supposed to increase efficiency in IT operation and development, e.g. due the possibility to focus necessary knowledge on selected technologies, platforms, etc. Solution Section M-2 Architectural solutions and architectural blueprints consider homogeneity not only on the level of a specific kind of technology e.g. programming languages or middleware, but include architectural solutions and consider technologies at the level of standardized technology bundles. The methodology uses the following viewpoints: M-4 C-2 C-5 M-2 V-5: Standard Conformity Layerfor C-2 V-: Clustering by Standard, for C-2 V-2: Technologies by Architectural Standardspecifically for C-5 V- V-5 V-2 V- V-: Architectural Solution in detail (UML); This viewpoint also addresses C- 5. While it has not been selected via the online questionnaire (see A.2), we reference this 4 c TU München, sebis, 28. All rights reserved.

41 4. Methodology Patterns (M-Patterns) viewpoint nevertheless, as it illustrates the basic concepts behind architectural solutions and architectural blueprints as a way to create architectural standards. This methodology describes basic steps for creating an overview of which (deployed) business application uses which architectural solution, and gives hints for analyzing this overview. For collecting information, it has to be noted that the employees operating a (deployed) business application might not always be totally aware of the respective application s architecture. Thus, the respective developers might have to be included into the data collection process. Of course, up-to-date blueprint and solution definitions are a prerequisite for this task (see methodology M-4). Additionally, an understanding about the blueprints should exist with the developers. This could possible require a more detailed overview than provided by V-2. The collected information should be verified. Also here different possibilities apply, ranging from automated plausibility checks to manual reviews, which could be tied into visualization creation. If necessary, missing or possibly erroneous information has to be delivered in addition or corrected. Creation of the visualizations (e.g. according to V-5 and V-) A V-2 - diagram can provide first background information about the existing architectural blueprints and solutions. It can give a first overview of the technologies included in a standard. This allows a first stage of the analysis: The set of standards might be to small (too restrictive) or too big (too permissive). In analyzing diagrams according to viewpoints V-5 and V-, the focus is likely to be on the business applications not conforming to the respective architectural standard. On the one hand, such business applications might be looked at specifically, considering e.g.: Does it require not to conform with the standard? How much are costs thus induced? Who bears these costs? Has the wrong standard been prescribed for the application? On the other hand, analysis can also focus on the totality of the non-conforming business applications, e.g. looking at: What do they have in common? Are the standards inadequate for important parts of the application landscape? Are there organizational units for which there are no means of enforcing the standards? Especially a V- - diagram might be helpful in getting an impression of the importance of the different architectural solutions. A standard only existing to serve a small proportion of the business applications might need a special justification. c TU München, sebis, 28. All rights reserved. 41

42 4. Methodology Patterns (M-Patterns) Consequence Section The architectural blueprints and solutions need to live as boundary objects 1 in the communities of the software architects and the enterprise architects. Only if these two communities interpret the blueprints and solutions in a coherent way, they can be supposed to be an instrument towards a less uncontrolled growth of the technology zoo behind an application landscape. 1 A boundary object is an object which allows members of different communities to build a shared understanding in respect to certain things. Boundary objects are interpreted differently by the different communities, and realizing and discussing these differences can lead to a shared understanding. [SG89, Str99] 42 c TU München, sebis, 28. All rights reserved.

43 4. Methodology Patterns (M-Patterns) The data collection effort per year for information about business applications, architectural solutions, and assignment of architectural solutions to business applications has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth The data collection effort per year for information about the structure of architectural solutions and its components or technologies has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-2 see Section A.2.2. c TU München, sebis, 28. All rights reserved. 4

44 4. Methodology Patterns (M-Patterns) Management of Blueprint Conformity of the Application Landscape (M-4) M-Pattern Overview Id M-4 Name Alias Summary Version 1. Management of Blueprint Conformity of the Application Landscape Management of Architectural Standards The methodology helps to decide on problems regarding the use of architectural solutions or architectural blueprints. Thereby, the appliance of the methodology may lead to new guidelines, or roadmaps. It can be based on analyses from M-2. Problem Section The methodology addresses the following concerns: C-19: Do the business applications currently used correspond to the architectural blueprints and architectural solutions (architectural standards)? If not, are there documented reasons for this, as e.g. strategic decisions? C-11: Which activities or projects have to be started in order to improve conformance to architectural standards? Which modifications to the currently used business applications are necessary to achieve conformity? Solution Section M-4 This methodology is based on methodology M-2. It is supposed to address a high inhomogeneity regarding used software architectures and technologies in an application landscape (e.g. found via M-2), which can arise due to uncontrolled development or evolution of business applications. C-19 C-11 The methodology addresses such an uncontrolled evolution by setting architectural standards, i.e. developing a set of architectural blueprints and architectural solutions, and assigning them to the business applications. Architectural blueprints V-9 V-7 and solutions are thereby defined as introduced in M-2. After architectural standards have been set, activities and projects for improving conformance to the standards can be derived, which can then enter project portfolio management as proposals. Subsequently, three aspects of the methodology are described: Firstly, creating architectural standards, then, setting standards for specific business applications or subsets of the application landscape, and finally, enforcing them. M-4 M-2 44 c TU München, sebis, 28. All rights reserved.

45 4. Methodology Patterns (M-Patterns) The methodology uses the following viewpoints: V-9: Effects of a Project Proposal on the Application Landscape (detail) V-7: Standard Conformity Exceptions Setting Standards: Creating Architectural Blueprints and Architectural Solutions: Before setting specific standards, it is necessary to decide, what these standards should encompass. Possibilities here are e.g.: 1. Which components (deployed and running sub-systems) a business application may consists of, and how these may communicate (connectors) 2. The infrastructure software, on which the components rely on. The hardware running the components 4. Development environments used for developing the respective software The EAMVS online survey found that the first two items are most important to practitioners. 2 Thereby, the first and the second item can be addressed by architectural blueprints and solutions, as used in M-2. Understood this way, an architectural blueprint is an exemplary description of a software architecture in the component-and-connector viewtype according to [CBB + 2]. This leads to different possible notations for defining an architectural blueprint: We propose V-Pattern V-, which is based on the respective UML-notation in [CBB + 2]. While this V-Pattern has not been selected by the online survey (see A.2), we present it nonetheless, as it constitutes an important component of this M-Pattern, and no equivalent viewpoint has been selected. V-Pattern V-78 is an possible alternative to V-, and was also not been selected by the online survey. The architectural description language ACME [GMW97] is another possibility. However, the description of the exemplary architecture in an architectural blueprint is technologyneutral. The specific technologies are set when an architectural solution is created based on a specific architectural blueprint, which assigns a specific technology to each so called abstract technology in the architectural solution. Several aspects may influence, which and how many architectural standards are offered. In favour of an additional architectural standard: Projects may choose an architecture and technologies they see most fit for the respective tasks. Against an additional architectural standard Knowledge about an additional architecture has to be kept available (at least) as long as the respective business applications are operated. Available knowledge (from other business applications) might not be reused. 2 Ranked by practitioners regarding importance on a 1-5 scale (5 is most important), they received an average rating of 4 or more. c TU München, sebis, 28. All rights reserved. 45

46 4. Methodology Patterns (M-Patterns) The set of offered standards has to strike a balance between these effects. Setting standards: Selecting standards for business applications In term of the concerns addressed by the methodology, setting standards is focused on C-19. We propose addressing this concern using diagrams according to V-7. Such a diagram can indicate, where architectural standards are met, where this is not the case, and where breaching the standard is specifically allowed. Breaching standards can e.g. be allowed if significant business success is tied to the possibility to have projects outside the respective standards. However, this introduces the issue of who receives the benefits derived from breaching the standard, and who bears the costs induced thereby. This is further discussed in the Consequence Section. Enforcing Standards: Deriving Measures for increasing Homogeneity Once standards are set, measures for improving conformance have to be developed and discussed, as described in C-11. Certainly, such measures are described in a detailled, textual way. However, diagrams according to V-9 can give an overview of the changes in the application landscape due to a (specific) proposed measure. A variant of this would display the changes of a set of proposals on one software map. Deriving measures involves finding the non-conforming business applications (e.g. via analyses as described in M-2). Based on this, the reasons for the business applications non-conforming to the standards can be determined. This sets the ground for deciding, whether a specific business application currently not conforming to its standards has to be changed. Subsequent points might be important in such a discussion: Has the wrong standard been set for a business application? In this case, the standard should be changed. If there are excessive costs for getting conformant to the standard, an exception could be sensible. If the benefit of conforming to the standard cannot be realized in a specific situtaion, this might also be a reason for an exception. If it is decided that one or more business applications have to be changed, the respecitve proposal has to be created, and can then be entered into project portfolio management. Consequence Section It is helpful, if not necessary for the methodology, that architectural solutions are boundary objects between Enterprise Architects and Software Architects. These two domains need an aligned understanding of the architectural standards, enabling them to efficiently communicate in using them. If architectural standards are to be beneficial, there has to be an entity having both power and committment to enforce the standards. This entity is then likely to be also in charge of allowing exceptions from the standards. Thereby, it has to address the problem that the benefit and the costs of conforming to blueprints and solutions occur in different places: It is likely that the costs for conforming to an architectural standard occur directly with the development team or operators responsible for the respective application (in the short term). Costs can also occur at users, if an conforming business application is less suitable, e.g. due to decreased performance, which is not improvable without a highly specialized architecture. 4 c TU München, sebis, 28. All rights reserved.

47 4. Methodology Patterns (M-Patterns) The benefit of increased homogeneity are likely to be of a more long-term nature, and occur primarily with the IT departments responsible for operating and developing business applications. However, if more efficient development can lead to a more swift project execution, business might be able to benefit from a reduced time to market. If the decision process is not able to balance this on a cross-organizational level, it might happen that decisions are locally optimal for specific organizational units, but suboptimal for the organization as a whole. An example for an approach trying to balance the aspects is allowing deviations from the standard, but estimating the future effort of fixing issues created by this, and imposing an respective fee on the organizational unit that demands breaching the standard. The data collection effort per year for information about issues like business applications, project proposals and affected business applications, and kind of change has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth The data collection effort per year for information about the conformity of business applications to architectural solutions, reasons for non-conformity, etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-4 see Section A.2.4. c TU München, sebis, 28. All rights reserved. 47

48 4. Methodology Patterns (M-Patterns) 4.1. Management of Homogeneity (M-) M-Pattern Overview Id M- Name Alias Summary Version 1. Management of Homogeneity Analysis and Management of Homogeneity, Technical Homogeneity The heterogeneity of the application landscape should be reduced. Therefore, different proposals should be made, and their feasibility and benefit should be evaluated. Problem Section The methodology addresses the following concerns: C-4: Which technologies, e.g. programming languages, middleware, operating systems, database management systems, used in the application landscape should be replaced, which ones should be kept? C-5: Which activities or projects have to be started, in order to increase conformance to standards? What has to be done in order to modify the current business applications to increase their conformance to standards and reduce heterogeneity? C-8: The goal is to reduce the usage of individual software, by replacing such systems with standard software. The concern is aimed at outlining project proposals for replacing individual software, which can then be evaluated in respect to their feasibility and benefit. C-9: Possibilities to reorganize the application landscape in respect to the used technologies should be outlined. Thereby, possible goals are: Reducing licensing costs, reducing maintenance costs, taking into account the support periods of the technology products, etc. Solution Section M- Addressing above concerns involves analyzing the application landscape, in order to create project proposals for improving homogeneity. These proposals then have to be documented, and possibly analyzed, before they are entered into project portfolio management. Contrary to M-2 and M-4, this methodology focusses on the respective technologies alone, without considering their role in architectures. C-4 C-5 C-8 C-9 M- V-7 V-8 V-9 V-41 V-45 V-7 48 c TU München, sebis, 28. All rights reserved.

49 4. Methodology Patterns (M-Patterns) The methodology uses the following viewpoints: V-7: Effects of a Project Proposal on the Application Landscape V-8: Effects of a Project Proposal on Technologies V-9: Effects of a Project Proposal on the Application Landscape (detail) V-41: Cluster Map indicating standard vs. individual software V-45: Process Support Map, showing standard vs. individual software; This V-Pattern can be used as an alternative visualization to V-41, which has however not been confirmed by the online questionnaire (see A.2). V-7: Technology Usage Analysis: EAMVS found no specific best practices for visualizing and analyzing technological homogeneity in an application landscape (see Section A.2.1 ). Thus, such viewpoints are not directly included in the methodology here, but viewpoint V-1 may give valuable hints in designing respective visualizations. This viewpoint is not included in the pattern catalog itself, but is here presented in the document s appendix (see Section B.2.1). A major decision in creating such overview of technologies used in the application landscape is, for which kinds of technologies the data is collected and visualized. Possibilities here include: middleware, hardware, operating systems, used development platforms, and databases. Middleware has been found as most relevant by EAMVS. Creating and Documenting Proposals: Documenting proposals relies heavily on textual documents, in which the respective proposal can be described in detail. However, we suggest complementing such a description with a graphical overview of a the proposal, using the subsequently stated viewpoints. V-7: A V-7 diagram can be used to document, which business applications are affected by a proposal. This is e.g. relevant in the context of concerns C-5 and C-8. V-9: Allows a higher level of detail than V-7 diagrams. Relevant to concern C-8. V-8: A V-8 diagram can be used in documenting more high-level decisions in a proposal, the replacement of a complete technology, which then has to be removed from the application landscape at all. This is relevant to concern C-4. V-41: Relevant to concern C-8, distinguishes individual and standard software. V-7: Relevant to concern C-9, shows specifically, which business application uses which infrastructure instance. Evaluating Proposals: In discussing and evaluating a proposal documented as described above, subsequent points might be relevant to proposals aimed at specific business applications: To what extent is a business application dependent on a non-standard technology? If a proposal forces a standard on a business application in spite of excessive costs (also including missed business opportunities), it is possibly not of benefit. It might also be possible that the benefit of switching to standardized technologies for a specific business application is unlikely to be realized. Of 28 answering practitioners, 2 considered middleware as relevant. c TU München, sebis, 28. All rights reserved. 49

50 4. Methodology Patterns (M-Patterns) When discussing the replacement of technologies themselves, subsequent aspects might be relevant: Is it possible to replace the respective technology? It can be expected, that on average, the marginal utility of removing a technology decreases with the number of technologies (of the same kind) used in the organization: If there is a large number of basically exchangeable technologies, it is likely that one can be removed without excessive cost. However, if there are only two technologies of a kind, e.g. database management systems, left, replacing one might be exptected to be more difficult. Consequence Section Influencing the success of the methodology might be, whether the technologies to be standardized are determined on the right granularity level. If they are set too fine-grained, developers might perceive them as impeding, business as useless micro-management. If they are too coarse-grained, they might mean nothing to developers. Also, kinds of technologies have to be targeted, where the benefits of homogenization can be actually realized. If technology standards are to be beneficial, there has to be an entity having both power and committment to enforce the standards. This entity is then likely to be also in charge of allowing exceptions from the standards. Thereby, it has to address the problem that the benefit and the costs of conforming to standards occur in different places, similarly as with the architectural standards described in M-Pattern M-4. If the decision process is not able to balance this on a cross-organizational level, it might happen that decisions are locally optimal for specific organizational units, but suboptimal for the organization as a whole. 5 c TU München, sebis, 28. All rights reserved.

51 4. Methodology Patterns (M-Patterns) The data collection effort per year for information about for business applications, technologies, projects proposals and which business applications they affect, etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth The data collection effort per year for information about business applications, and whether they are standard- or individual software has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M- see Section A.2.. c TU München, sebis, 28. All rights reserved. 51

52 4. Methodology Patterns (M-Patterns) Analysis of standard vs. individual Software (M-1) M-Pattern Overview Id M-1 Name Alias Summary Version 1. Analysis of standard vs. individual Software Analysis of standardized vs. customized Software The M-Pattern analyzes the usage of standard and individual software in the application landscape. Problem Section The following concerns are addressed by this methodology: C-1: Analyze, to what extent individual and standard software is used in the application landscape. Such analyses can e.g. be conducted as a basis for decisions about replacing individual software with standard software. However, they might also be relevant to other decisions, e.g. about the extent of software development skills necessary in an organization. Solution Section M-1 For getting an overview of the role these two kinds of software play in an organization, we propose V-41: Cluster Map indicating standard vs. individual software V-45: Process Support Map, showing standard vs. individual software C-1 M-1 In analyses as mentioned above, the information whether a business application is standard or individual software might have to be put into a context, in order to be properly interpretable in the respective analyzes: V-41 V-45 Additional information about the specific business applications: The age (and possibly life cycle information) of the business application. Details about the kind of standard software. Different kinds of taxonomies might be used here, e.g. administrative software vs. management information systems, etc. 52 c TU München, sebis, 28. All rights reserved.

53 4. Methodology Patterns (M-Patterns) Information about the importance of the business applications in the application landscape: The number of users working on the business application. This information has been rated as rather important in the EAMVS online questionnaire. 4 Criticality to business. Information about the standard software and the standard software market in general: Extent to which standard software for the kind of support offered by a specific business application exists. Roadmap information, which is addressed specifically by M-15 Information about the software vendor of standard software, e.g. from market research companies. Technical Information: see M- Concerning information about the support offered to business by the business applications, V-45 is especially important. In considering this information, one might follow the approach that especially processes containing core competencies might be in need of individual software. This might be the case if standard software is not sufficient for creating competitive advantages regarding central capabilities. Consequence Section The data collection effort per year for information about which business applications are standard software and which are individual software, etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-1 see Section A Rated by practitioners on a scale from 1-5 (5 is most important), the number of users received an average rating of c TU München, sebis, 28. All rights reserved. 5

54 4. Methodology Patterns (M-Patterns) Analysis of the Enterprise Knowledge (M-5) M-Pattern Overview Id M-5 Name Alias Summary Version 1. Analysis of the Enterprise Knowledge Software Development Skills This M-Pattern is concerned with analyses for adjusting the required knowledge about technology, programming languages, etc. with the availiable knowledge within the enterprise. Problem Section The following concerns are addressed by this methodology: C-4: Which knowledge about specific subjects, e.g. technologies, or programming languages, is currently available in the organization? Solution Section The methodology uses the following viewpoints: M-5 V-8: Knowledge Needs C-4 Building a taxonomy for knowledge classification A basic requirement for creating diagrams as proposed by V-8 is a taxonomy for the knowledge items relevant to the organization. On the one hand, this taxonomy has to contain knowledge items relevant to the employees analyzing the respective diagrams. On the other hand, data collection has to be feasible, which could e.g. rule out overly detailed taxonomies, or esoteric knowledge items for which it is difficult to create a shared understanding in the organization. The knowledge taxonomy might be built using items from M-2, M- and M-4, e.g. the technologies or architectural blueprints. However, if a knowledge management using a similar taxonomy, e.g. for yellow pages, is in place, this taxonomy might be reused as well. Data Collection Data collection has to find a way of measuring knowledge, specifically the need and the availability of knowledge in a given organizational unit. Depending on process maturity in the respective organiza- M-5 V-8 54 c TU München, sebis, 28. All rights reserved.

55 4. Methodology Patterns (M-Patterns) tional units, different approaches are possible. The approaches mentioned here measure knowledge as working time of an employee having the respective knowledge. The estimations can be done ad hoc. Thereby, one has to pay attention that employees having knowledge in more than one item are not counted more than once. If such data is available from effort estimations, this data could possibly be used. However, it is advisable to check, whether there is a feasible way to assign the estimations to the knowledge items and employees having the knowledge. Consequence Section A taxonomy for knowledge classification has to be created and established in the organization. Regarding this taxonomy, there has to be a shared understanding in the organizational units supplying information to and using information from methodology M-5. If this shared understanding does not exist, M-2 might lead to adding up and comparing different kinds of knowledge, which only have received the same name in different organizational units, more or less by accident. The data collection effort per year for information about the available knowledge and knowledge need has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-5 see Section A.2.. c TU München, sebis, 28. All rights reserved. 55

56 4. Methodology Patterns (M-Patterns) 4.2 Business Processes Business applications are operated in organizations to support business processes. This leaves EA management in need of methodologies for analyzing and designing the interaction of business applications, business processes, and possibly related entities relevant to business, as e.g. strategies, products and markets. Subsequently, business processes are thereby considered on a value chain level (similar to the processes in Porter s value chain [Por85]). The relevance and existence of best practices regarding business processes has been examined by EAMV s online questionnaire. Thereby, best practices were found on the high level mentioned here, however only considering business processes and business applications, not products, markets, etc. Nevertheless, best practices regarding a more detailed view on the support business processes receive from the business applications exist, and are described in Section c TU München, sebis, 28. All rights reserved.

57 4. Methodology Patterns (M-Patterns) Process Analysis (M-) M-Pattern Overview Id M- Name Alias Summary Version 1. Process Analysis High Level Process Analysis This M-Pattern analyzes the business processes at a high level of abstraction (value chain level). Problem Section The methodology addresses the following concerns: C-54: Do the business processes adequately consider the environment of the organization, like incoming events, as e.g. customer requests? C-55: Which business processes, if any, are suitable candidates for being outsourced? C-5: What business processes contain core competencies of the organization? Solution Section M- The methodology addresses above concerns by analyzing the business processes of an organization, the process landscape, at a high level, which can include the first three levels of granularity. Thus, the approach is not at a detail level where specific process steps and control activities are specifically considered. C-54 C-55 C-5 M- The methodology is targeted at employees responsible for specific business processes at the above mentioned granularity level, or, to some extent for the process landscape as a whole, V-12 V-17 which need to conduct analyses for addressing above concerns. Therefore, the methodology uses subsequent viewpoints for analyzing collectivity of the business processes and their interactions: The methodology uses the following viewpoints: V-12 specifically for C-54 V-17 for C-55 and C-5 High level business process analysis is to be performed based on data (received) from business process management. We do not detail the business process modeling and information collection here, as we c TU München, sebis, 28. All rights reserved. 57

58 4. Methodology Patterns (M-Patterns) see such tasks more in the domain of business process management. However, the respective data has to be obtained in an up-to-date version from business process management. Achieving this involves two aspects: Checking, whether the information available from business process management is up to date. On the one hand, it can be assumed, that on the granularity level used here, businesss processes are relatively stable. But on the other hand, there are cases in which business processes have been documented in a singular project in the past, and have since been neither updated nor lived. In such cases, it has to be carefully validated, whether the data is sufficient for the intended analysis. Obtaining and Using the data from business process management. If the data is directly used in the repositories used by business process management, or if business process management and EA management share a repository, using the data is relatively straightforward. However, if the data has to be imported into an EA management repository, the situation may be more difficult. Aside from the technical realization of the import, it has be be verified, whether the definitions of the concepts in business process management and EA management fit together in way that allows the desired data exchange. If not, the data exchange has to find ways for considering the discrepancies. Based on the visualization, the business processes can be analyzed at a high level. The goal thereby is making these analyzes more holistic, by considering more diverse stakeholders in EA management than in business process management alone. In respect to analyzing a view according to viewpoint V-12, in order to address concern C-54 subsequent hints might be helpful: Are there important events not considered in the diagram? One might e.g. query, whether there are important entities in the environment, to which the processes cannot react. Guiding this question via a schema as e.g. Porters five forces (suppliers, substitute products, new market entrants, competitors, customers) [Por85] might aid this question. Are all important business functions (organizational units) given for each process step? Are unimportant business functions indicated? Why has the business process been modeled in such a way? Are business processes missing? For analyzing a view according to V-Pattern V-17, to address concerns as C-55 and C-5, the following hints might provide help Are there business processes which might be candidates for outsourcing? Which business processes are core competencies of the organization? Who is responsible for the business processes? Who has to carry them out? Can changing this lead to improvements? How sophistiacted is the IT support provided by the business applications to the business processes? Which business processes react to the events that are most frequent or most important, e.g. in terms of revenue, or most difficult to answer? 58 c TU München, sebis, 28. All rights reserved.

59 4. Methodology Patterns (M-Patterns) Consequence Section For this methodology, EA management should to some extent be able to offer a more holistic perspective, or additional information, compared to business process management alone. Otherwise, the visualizations are merely informing, which might also be important, but might be unlikely to yield valuable additional insights. The data collection effort per year for information about business processes, with predecessor-successor relationships, events triggering processes, organizational units responsible for processes, etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M- see Section A.2.7. c TU München, sebis, 28. All rights reserved. 59

60

61 4. Methodology Patterns (M-Patterns) 4. Application Landscape Planning 4..1 Analysis of the Application Landscape (M-1) M-Pattern Overview Id M-1 Name Alias Summary Version 1. Analysis of the current application landscapes Development of the current application landscape The M-Pattern examines the status quo of the application landscapes to give a holistic view about the current alignment of business and IT. Thereby, applying the methodology may lead to potential projects improving this alignment as well as guidelines and roadmaps for the future evolution of the application landscape. Problem Section The methodology addresses the following concerns: C-: Which applications are used by which organizational units? C-8: Which business applications are hosted by which organizational unit? C-87: Which business processes are supported by which business application? Solution Section M-1 The methodology addresses the concerns mentioned above by visualizing the current support provided by business applications. Thereby, the support relationship between business processes and business applications is of particular importance. The question which business application supports which business process, as well as the usage or hosting of the business applications by an organizational unit may be of relevance within the analysis of the status quo. C- C-8 C-87 M-1 V-17 V-18 V-24 V-25 In a service oriented architecture, the layer of the business applications would be hidden by a service layer. Therefore, the supporting service of a business process and its realization through a business application would be of vital importance. Contrary, the hosting of the business applications providing the service is of lower importance. c TU München, sebis, 28. All rights reserved. 1

62 4. Methodology Patterns (M-Patterns) Possible conclusions that can be drawn from the visualizations are: If there is a missing support of a business process at a certain organizational unit. If the business process is supported by a service or a business application. If there is a redundant support of a business process, visualized in the viewpoint if different business applications support one process step at different organizational units. If an business application is used multiple times in different organizational units. If an business application is hosted multiple times in different organizational units. The methodology uses the following viewpoints: V-17: Process Support Map V-18: Service-based Business Process Support Map V-24: Cluster Map for hosting Relationship V-25: Cluster Map for using Relationship The objectives of the methodology is to give an enterprise architect an overview about the status quo of the application landscape, to identify changes that are necessary to improve the alignment of business and IT. Besides, having a documentation that provides a holistic view about the current status of the application landscape allows the different stakeholders to have a common background for discussions. Thereby, the aspect of enhancing the transparency of the status quo of the application landscape plays an important role fostering communication in an enterprise. Consequence Section A holistic view on the current application landscape with up-to-date information is only possible if a tight integration with other management processes of the application landscape is realized to gain the required information. Thereby, especially the support by the business process and application owners is of vital importance. 2 c TU München, sebis, 28. All rights reserved.

63 4. Methodology Patterns (M-Patterns) The data collection effort per year for information about business applications, their lifecycle information, business processes, organizational units, and projects etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of M-Pattern M-1 see Section A c TU München, sebis, 28. All rights reserved.

64 4. Methodology Patterns (M-Patterns) 4..2 Development of Plan and Target Landscapes (M-14) M-Pattern Overview Id M-14 Name Alias Summary Version 1. Development of planned and target landscapes Evolution of the application landscape The M-Pattern considers the development of planned and target landscapes to support managing the evolution of the application landscape. The target landscape as a long term perspective shows the envisioned architecture of the application landscape derived from the strategies and goals of the enterprise. Planned landscapes illustrate intermediate steps, transforming the current landscape in the direction of the target landscape. Thereby, a planned landscape shows the application landscape as it develops through the changes performed by projects up to a specific date, thus, additionally providing support for project planning. Problem Section The methodology addresses the following concerns: C-4: How does the long-term vision, the target of the application landscape, look like? C-5: How does the application landscape look like at a specific date? C-88: How will the application landscape evolve over time in order to support the strategies defined? What are the differences to the current landscape? Solution Section M-14 The methodology addresses the concerns listed above by visualizing the effects of current and planned projects. Thereby, planned landscapes visualize the changes current and planned projects perform on the application landscape until a certain point in time. Thus, more than one planned landscape usually exist within an enterprise. C-4 C-5 C-88 M-14 The target landscape visualizes a vision of the application landscape as a long-term perspective. Therefore, there is no need for projects to be defined, which transform the current landscape into the target one. The target landscape should be V-17 V-24 V-2 V-4 derived from the IT strategy of the enterprise. It can be used to ensure that the evolution of the application landscape heads in the right direction. 4 c TU München, sebis, 28. All rights reserved.

65 4. Methodology Patterns (M-Patterns) The methodology uses the following viewpoints: V-17: Process Support Map V-24: Cluster Map for hosting Relationship V-2: Process Support Map visualizing Changes in Relations to their Time Horizon V-4: Migration of Functionality The objective of the methodology is to give the enterprise architect an overview of the changes that will be performed on the application landscape until a certain point in time. As the target landscape documents the strategies and goals of the enterprise and their impact on the application landscape, it can be used by the enterprise architect to review the planned landscapes to point in the direction of the target one. Besides, project portfolio management can use the documentation to evaluate the influence and alignment of potential projects with the planned evolution of the application landscape and their interaction with current and planned projects. This, helps project portfolio management to gain information, which projects should be carried out within the next planning period. Consequence Section A holistic view on the planned and target application landscape with up-to-date information is only possible if a tight integration in other management processes of the application landscape is possible. Thereby, especially the goal and objective management and the project portfolio management are of vital importance, as the target landscape is derived from the goals of the enterprise and the project portfolio management holds information about current and planned projects. The data collection effort per year for information about business applications, their lifecycle information, migration of functionality between different applications, and projects, which achieve such migrations and lifecycle changes etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-14 see Section A.2.1. c TU München, sebis, 28. All rights reserved. 5

66 4. Methodology Patterns (M-Patterns) 4.. Management of the Application Lifecycle (M-15) M-Pattern Overview Id M-15 Name Alias Summary Version 1. Management of the application lifecycle Application lifecycle management Concerning the evolution of the application landscape, this methodology deals with projects affecting one ore more business applications and their interrelations. Thereby, the dependencies between the affected business applications play a key role. The methodology provides an overview of the lifecycle phases of business applications to support the project management process. Problem Section The methodology addresses the following concerns: C-: Which dependencies exist between business applications and are affected by current or planned projects? Which projects change the same business application? Are there changes on a business application that must be finalized before changes made by another project can be performed? C-89: Which business applications will be affected by projects in the near future? C-9: In which phase of its lifecycle is a business application at a certain point in time? Solution Section M-15 The methodology addresses the concerns mentioned above by visualizing the different phases of business applications and their versions. Thereby, lifecycle phases as e.g. planned, in development, piloting, in production, and in retirement are of interest. The relation to the projects that perform the changes on the visualized business applications can be displayed additionally, to indicate the drivers of evolution. C- C-89 C-9 M-15 Supplementary to the relationship between applications, their lifecycle phase and the projects performing changes, and the functions provided by the business applications are of interest here. V-2 V-27 V-2 V- V- V-4 Thereby, the support of business processes plays an important role, as well as the migration of functionality between different business applications according to a given point in time. c TU München, sebis, 28. All rights reserved.

67 4. Methodology Patterns (M-Patterns) The following exemplary rules may, among others, help in interpreting the viewpoints: If a project changes a business application that will be in retirement shortly afterwards, the changes will be lost. If two projects perform changes on the same business application a concurrent implementation may be difficult. The methodology uses the following viewpoints: V-2: Time Interval Map visualizing Lifecycles of Applications V-27: Application Lifecycle Project Layer V-2: Process Support Map visualizing Changes in Relations to their Time Horizon V-: Time Interval Map visualizing Projects and the affected Business Application V-: Overview over Lifecycle of Business Applications V-4: Migration of Functionality The Viewpoints V-2 and V-27 are very similar, the viewpoint V-27 can be used to replace the viewpoint 2. The objective of the methodology is to allow the enterprise architect to get an overview about the evolution of business applications within a certain time span. This information may be used to ensure the practicability of projects, for example if a project should be conducted that performs changes on business applications that will be retired shortly afterwards. Furthermore, the project managers can use the documented evolution of the application landscape to identify conflicts, i.e. two projects are planned that change the same business application at the same time. The support relationship between business process steps and business applications as well as their lifecycle status is an important information especially for business critical processes. Consequence Section An overview about the current and prospective lifecycle phases of business applications is only possible if a tight integration to other management processes is realized. One example is the project management process that needs to deliver information about current and planned projects and their effects on business applications. c TU München, sebis, 28. All rights reserved. 7

68 4. Methodology Patterns (M-Patterns) The data collection effort per year for information about business applications, business processes, and support of business processes provided by the business applications at different organizational units etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-15 see Section A c TU München, sebis, 28. All rights reserved.

69 4. Methodology Patterns (M-Patterns) 4..4 Horizontal and vertical integration (M-18) M-Pattern Overview Id M-18 Name Alias Summary Version 1. Horizontal and vertical integration The M-Pattern helps to analyze the level of process support provided by the business applications. Thereby, vertical integration deals with the level of uniformity of process support for different e.g. organizational units, products or locations. Horizontal integration refers to the level continuity of process support provided, thus a business applications provides support for more than one process. Problem Section The methodology addresses the following concerns: C-44: How can the operating expenses and maintenance costs be reduced, e.g. by identification of business applications providing the same functionality (redundancy)? Solution Section M-18 The methodology relies on the usage of a process support map, which visualizes a process chain, as a linearly ordered sequence of process steps on the x-axis. The y-axis of the process support map can differ according to the enterprise s kind or the addressed concerns. Elements that can be visualized on the y-axis are for example locations or organizational units. C-44 M-18 The methodology analyzes the process support provided by different business applications. Thereby, horizontal integration means that several V-17 V-28 V-29 V- successive business processes are continually supported by one business application. Vertical integration describes the uniform process support provided by one business application for a dedicated number of organizational units or locations. Supporting the analysis of process support according to vertical an horizontal integration, viewpoints as e.g. V-28, V-29, and V- can be used. These visualize the integration by expanding the border of the business application in the y- or x-direction. The methodology uses the following viewpoints: V-17: Process Support Map V-28: Process Support Map visualizing horizontal Integration c TU München, sebis, 28. All rights reserved. 9

70 4. Methodology Patterns (M-Patterns) V-29: Process Support Map visualizing vertical Integration V-: Process Support Map visualizing vertical and horizontal Integration The objective of this methodology is to identify potential for cost reductions as well as potentials for optimization. Cost reduction may be achieved by e.g. changing the process support of organizational units, that use different business applications providing the same functionality to one standardized business application. Optimization possibilities may be achieved by e.g. using identified economies of scale. Consequence Section The methodology only deals with business processes on a high level of abstraction. Typically the view on a process chain as a linearly ordered sequence of processes is only possible for the levels to. Thus, the methodology cannot be downscaled to a more detailed level. However, the analysis as introduced above provides support to identify potential candidates of redundancy on a high abstraction level. Nevertheless, the identified potential redundancies need to be analyzed in more detail, as they can turn out to be no redundancies at all. They might, for example support other subprocesses of the process step as visualized on the aggregated view of the software map. Moreover, if there are redundancies, they might have been deliberately introduced, e.g. in order to achieve a higher flexibility. In such cases, it may be reasonable to retain the redundancy. In case that no such reasons can be found, the results from the analysis regarding redundancies can be used as input for activities defining visions or plans for the evolution of the application landscape. This can include definitions of project proposals that serve the elimination of the redundancies. Nevertheless, it must be noted, that an integration in both directions, horizontally and vertically is not always possible as the symbols might intersect or overlap. The data collection effort per year for information about detailed information about business processes, including the responsible organizational units, and supporting business applications etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-18 see Section A c TU München, sebis, 28. All rights reserved.

71 4. Methodology Patterns (M-Patterns) 4.4 Support of Business Processes High Level Process Support (M-29) M-Pattern Overview Id M-29 Name Alias Summary Version 1. High level process support The M-Pattern analyzes the support provided by business applications for the individual business processes on a high level of abstraction. In this context, the individual business processes are focussed on, in contrast to the business process landscape including all business processes of an enterprise. Problem Section The methodology addresses the following concerns: C-78: To which extent are the business processes supported by business applications? Which business processes are supported manually? Can the automated support be extended? C-8: To which extend does the IT support the flexibility of the business processes? Where is the flexibility put at risk? C-95: How can a more continuous IT support concerning business processes be realized? Solution Section M-29 The methodology refers to aspects of business process support on a high abstraction view (level to ), where a business process can be deemed to be a linearly ordered sequence of processes. Thereby, the support provided by a business application or manual support for a business process is of interest. Automation by business applications may have a negative influence on the flexibility of the process support, especially in cases with a high vertical or horizontal integration. Thus, the automation may be a threat in respect to the flexibility for the operative process conduction. C-78 C-8 C-95 M-29 V-28 c TU München, sebis, 28. All rights reserved. 71

72 4. Methodology Patterns (M-Patterns) Conclusions that can be made from the analysis results of this methodology in respect to business process support are: If a business process is not supported by a business application at one or more specific organizational units or locations this suggests that the process is poorly supported. If a business application supports a lot of (different) business processes, possible conclusions are that the support for the different business process steps fits together very well, and/or that low flexibility in respect to changing the business process or a specific task is required or supported. Concerning risk aspects, this situation may lead to the assumption that projects implementing business process changes in business applications might be in risk of conflicts with other projects. If a business process is supported by a high number of business applications in an organizational unit or location, this hints that different tasks are supported in a highly specific way and/or that the integration of the business applications may be suboptimal. Another possible conclusion could be that business applications with duplicate functionality exist, thereby, the redundancy might endanger the quality of process outputs. Regarding risk issues, the described setting hints to a high dependency on the software, the software vendor, and the existing knowledge about the software. The methodology uses the following viewpoints: V-28: Process Support Map visualizing horizontal Integration The objective of the methodology is to provide information to process managers who are concerned with the the conduction of the business processes. Based on the analysis results, the process managers can suggest improvements concerning the evolution of the IT support for business processes. Thereby, aspects as which functionality of a business application or service is used for the conduction of a business process may be of relevance. Resulting in an proposal concerning the evolution of the application landscape, the methodology may also influences the work of demand and project managers. Consequence Section In order to further analyze the above described results, three possibilities for extending the analysis should be considered: metrics, EPCs, and process specific data flows between business applications due to execution of the business process under consideration. Concerning the business process support metrics about the share of process steps supported by business applications and/or the share of fully automated process steps as well as the (estimated) costs for the process execution, average time for the process execution, share of process executions completed by target time, error rate as the share of business processes that are not executed error free. 72 c TU München, sebis, 28. All rights reserved.

73 4. Methodology Patterns (M-Patterns) The data collection effort per year for information about services, service level agreements, the fulfillment of service level agreements, dependencies between services, the components a service is build upon, processes, organizational units and locations etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-29 see Section A.2.1. c TU München, sebis, 28. All rights reserved. 7

74 4. Methodology Patterns (M-Patterns) Business Process Data Flow Analysis (M-) M-Pattern Overview Id M- Name Alias Summary Version 1. Business Process data flow analysis Analysis of the data flow within a business process support The M-Pattern analyzes the support provided by the application landscape for an individual business process. The focus of the methodology lies on a single business process and its support instead of the business process landscape in a holistic view. Thereby, the data flows between different business applications are analyzed. Problem Section The methodology addresses the following concerns: C-78: To which extent are the business processes supported by business applications? Which business processes are supported manually? Can the automated support be extended? Solution Section M- The methodology analyzes the existing support provided by different applications for the conduction of an individual business process. Thereby, the exchange of business objects as well as the different types of interfaces are of interest. Concerning the different types of interfaces a possible differentiation might be online, offline, and manual. C-78 M- In addition to the aspects of different interface types, the business objects being exchanged between different business applications play an important role. The question of an existing data governance (who is the primary owner of the data) may influence the outcome of the analysis as detailed in the following. The methodology uses the following viewpoints: V-48: Cluster Map visualizing Business Object Flows between Business Applications V c TU München, sebis, 28. All rights reserved.

75 4. Methodology Patterns (M-Patterns) The analysis of data flows between business applications could reveal if manual interfaces exist, which make up a format discontinuity/media disruption. detect that no clear governance of data is given. This can make process execution more difficult and endanger the quality of process outcomes as redundant data that are not consistent may exist. During the analysis of data flows the following conclusions can be drawn regarding risk aspects: If data is transported from source to the business application where it is needed via several hops. Risks as e.g. failure risks, risk propagation, risk of data being corrupted may grow. The danger emanating from the absence of a clear governance of data should be monitored to avoid decreasing quality of process outcomes. The following results can be achieved by applying the methodology: Analyses results concerning weaknesses, risks, etc. Proposals for improving the process support provided by the business applications Consequence Section The data collection effort per year for information about services, dependencies between services, and components a service consists of etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M- see Section A c TU München, sebis, 28. All rights reserved. 75

76 4. Methodology Patterns (M-Patterns) 4.5 Project Portfolio Management Strategic Conformance Analysis of the Project Portfolio (M-24) M-Pattern Overview Id M-24 Name Alias Summary Version 1. Strategic Conformance Analysis of the Project Portfolio This M-Pattern is used to analyze the project portfolio concerning the defined strategies. Problem Section The M-Pattern addresses the following concerns: C-91: The activities modifying the application landscape should be aligned to the needs, which have been specified by the defined strategies. Thereby, financial aspects and necessities dictated by the environment of the organization, e.g. via laws, regulations, etc. should be considered. Changes on the application landscape are effects of activities or projects. Thus these activities and projects have have to be aligned with the companies strategies. Financial aspects and external factors Should also be considered in this kind of analyzes. Solution Section M-24 In order to evaluate the strategy conformance of the projects, the following information is gathered about the project proposals: C-91 Strategic Impact Rating: The impact of the project in respect to each strategy is estimated on a scale from -1 to 1. The rating is the average of these values for all strategies. Environmental Impact Rating: Defined as the average of the ratings (from -1 to 1) of the project in respect to each environmental factor. Estimated return on investment of the projects: A possibility to minimize the effort for data collection is, to calculate the return on investment only for projects with high investments. M-24 V- 7 c TU München, sebis, 28. All rights reserved.

77 4. Methodology Patterns (M-Patterns) The M-Pattern uses the following viewpoints: V-: Strategic Project Portfolio Overview The V-Pattern V- can be used to support decisions about project proposal approvals, considering mainly which projects have to be conducted, if aspects of organizational strategies and environmental influence are considered. Additionally financial information, like e.g. the available budget for all projects, should be considered here as constraints. Consequence Section Despite all analyzes on project conformance to company strategies, urgent business demands have to be considered. In these circumstances, it may be possible that a project has to be conducted, even it does not conform to the companies strategies. In such cases the reasons for the decision should be well documented in order to make these decisions traceable for future analyzes. It would also be advantageous to save some budget in order to realign the changes that have been performed by the project with company strategies in the future. A more detailed model for strategic conformance analysis, than the one proposed in V-Pattern V-, can be found in I-Pattern I-8. (see page 2) The data collection effort for information about strategies, environmental factors, rating of projects, etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-24 see Section A c TU München, sebis, 28. All rights reserved. 77

78 4. Methodology Patterns (M-Patterns) Monitoring of the Project Portfolio (M-25) M-Pattern Overview Id M-25 Name Monitoring of the Project Portfolio Alias Summary This M-Pattern is concerned with the monitoring of the project portfolio. Version 1. Problem Section The M-Pattern addresses the following concerns: C-92: Increase the probability of success of challenging projects by selecting them for special project monitoring/consulting by the enterprise architecture management. Identify the projects, which can be expected to profit from such a monitoring. Typically, some projects within the project portfolio are especially challenging. These kind of projects should be considered as important and have to be under special observation in order to improve their success probability. This methodology guides enterprise architecture management in finding such projects, which can be expected to profit from such a monitoring. Solution Section M-25 According to [Kel7], certain projects should receive special attention from enterprise architecture management. Using viewpoints as described below, these projects can be identified, possibly directly at the time of project approval. Evidence for identifying those projects is given in the following paragraphs: According to [Kel7], project proposals looking rather complex should be further examined. In order to avoid unnecessary complexity, it should be verified whether there are possibilities to conduct such projects more easy. If it is not clear, whether such possibilities exist, project monitoring could be sensible. The methodology uses the following V-Pattern: M-2 C-92 M-25 V-57 V-59 V-1 V-57: Expected Proposal Effects V-59: Financial Project Portfolio Overview V-1: Technical Project Portfolio Overview 78 c TU München, sebis, 28. All rights reserved.

79 4. Methodology Patterns (M-Patterns) In order to find complex projects, V-Pattern V-1 can be used. High project cost, development time and number of affected business applications can be indicators for project complexity. Also high strategic impact could lead to project complexity as the successful completion of the project is of high importance. In addition, checking viewpoint V-57 could be advantageous, in order to determine possible sources of complexity in the application landscape. Projects, which affect many business applications or important processes can be easily identified using this viewpoint. Risky projects, e.g. concerning the probability to fail finishing within the defined project time, should also receive special project monitoring. On the one hand, complex projects can be seen as risky. On the other hand, viewpoint V-59 can reveal aspects of financial risk, e.g. projects with a high standard deviation of the ROI, maybe even together with a high investment, i.e. project cost. As described in [Kel7], revealing possibly avoidable efforts, e.g. building own frameworks instead of using standard ones, developing basic components multiple times, can only be achieved by studying the project (proposal) description. Thereby, it might be especially important to check projects with the following characteristics: high cost, high effort, etc. This information can be visualized using V-Pattern V-1. Consequence Section Figure also includes a reference to M-Pattern M-2, as this M-Pattern uses the results of M-25 as input for decisions about project approval. The data collection effort for business case calculations for the project proposals has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth c TU München, sebis, 28. All rights reserved. 79

80 4. Methodology Patterns (M-Patterns) The data collection effort for rating the conformity of project proposals to defined strategies has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth The data collection effort for rating the impact of environmental factors, like e.g. proposals has been stated by practitioners using such methodologies as: laws on project Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth 8 c TU München, sebis, 28. All rights reserved.

81 4. Methodology Patterns (M-Patterns) The data collection effort for estimating the development effort has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-25 see Section A c TU München, sebis, 28. All rights reserved. 81

82 4. Methodology Patterns (M-Patterns) 4.5. Decision for Project Approval (M-2) M-Pattern Overview Id M-2 Name Decision for Project Approval Alias Summary This M-Pattern provides guidance for project approval decisions. Version 1. Problem Section The M-Pattern addresses the following concerns: C-29: At the beginning of a planning period the available IT budget has to be assigned to project proposals. Project proposals that will be approved have to be selected, others have to be rejected or delayed. In a typical company, the needed budget for proposed projects exceeds the available budget. Therefore, some projects have to be approved and other have to be declined or delayed. On the one hand the selected projects have to fit the available budget and on the other hand, they have to be realizable concerning possible risks or dependencies to other projects via shared resources, like e.g. business applications or infrastructure elements. Additionally there may be some projects, which must be approved in any case e.g. because there are regulations or laws, which demand certain changes to the application landscape. Solution Section M-2 The methodology builds on a set of project proposals, for which it has to be decided whether they will be approved or not. Such decisions are usually influenced by a multitude of criteria. An exemplary subset is given below. Information about these criteria can be used to justify or reject a project. C-29 M-2 M-25 Projects may be necessary, due to laws, regulations, etc. This is considered in V- Pattern V-59 and V-1 via the Environmental Factor Rating. V-5 V-57 V-59 V- V-1 Projects may be tied to strategies, initiatives, etc. This is considered in V-Pattern V-59 and V-1 via the Strategic Impact Rating. 82 c TU München, sebis, 28. All rights reserved.

83 4. Methodology Patterns (M-Patterns) Projects may be initiated in order to achieve long term cost savings. This is considered in V-Pattern V- via the Expected Return On Investment. Projects may be initiated in order to gain new capabilities or are supposed to generate additional revenue. This is considered in V-Pattern V- via the Expected Return On Investment. Additionally project portfolio management has to get a full picture of the projects, including aspects as e.g. risks and costs associated with it. Therefore, the following criteria should also be taken into account: Estimated duration of the projects. This is considered in V-Pattern V-1 via the development time in person months. Estimated costs of the projects. This is considered in V-Pattern V-59, V- and V-1 via the project proposal costs. Risks connected to the projects. Financial risks are considered by V-Pattern V-59. V-57 and V-1 cover technical risks, as e.g. a high number of changed business applications. Undesired influences on the application landscape, e.g. on homogeneity, complexity, etc. This is considered in V-Pattern V-57 and V-5 via the dependency of project proposals to business applications offering the possibility to further analyze the affected business applications. This M-Pattern uses the following V-Pattern: V-5: Proposal Impact Table V-57: Expected Proposal Effects V-59: Financial Project Portfolio Overview V-: Strategic Project Portfolio Overview V-1: Technical Project Portfolio Overview Consequence Section Figure 4.5. also includes a reference to M-Pattern M-25, as this M-Pattern provides input for decisions about project approval for M-2. This means that M-25 is the basis for M-2 and is therefore used by M-2. Usually, depending on the number of the project proposals under consideration the approval is a task, done by the management of the enterprise architecture or by a special group of people within the company who are only concerned with the selection of project proposals. For a description of Environmental Factor Rating, Strategic Impact Rating, and Expected Return On Investment see I-Pattern I-59. c TU München, sebis, 28. All rights reserved. 8

84 4. Methodology Patterns (M-Patterns) The data collection effort for business applications, which are affected by project proposals has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth The data collection effort for business case calculations for the project proposals has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth 84 c TU München, sebis, 28. All rights reserved.

85 4. Methodology Patterns (M-Patterns) The data collection effort for rating the conformity of project proposals to defined strategies has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth The data collection effort for rating the impact of environmental factors, like e.g. proposals has been stated by practitioners using such methodologies as: laws on project Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth c TU München, sebis, 28. All rights reserved. 85

86 4. Methodology Patterns (M-Patterns) The data collection effort for estimating the development effort has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-2 see Section A c TU München, sebis, 28. All rights reserved.

87 4. Methodology Patterns (M-Patterns) 4. Infrastructure Management 4..1 Infrastructure Failure Impact Analysis (M-4) M-Pattern Overview Id M-4 Name Alias Summary Version 1. Infrastructure Failure Impact Analysis The M-Pattern considers the impact of failures of infrastructure elements concerning the application landscape. Problem Section The M-Pattern addresses the following concerns: C-41: Which infrastructure software is used by the business applications? C-98: What is the impact of the shut-down of an infrastructure element? What other elements of the application landscape are affected? Failures of infrastructure elements of the application landscape are not only of interest for employees responsible for these infrastructure elements, but also for persons responsible for e.g. business applications, business services or business processes as all these are dependent on infrastructure. Therefore, these dependencies have to be analyzed in order to be able to estimate consequences of infrastructure failures. 5 Solution Section M-4 In order to be able to analyze the impact of infrastructure failures, all dependencies to and between infrastructure elements are of interest. The V-Pattern listed below show these dependencies (V-5 and V-75). C-41 C-98 Analysis may be started directly focusing on the dependencies to business applications in order to do a kind of scenario analysis, e.g. what would happen if a database fails. M-4 Additionally the dependencies of business applications to business services or business processes can be used for further analyzes. V-5 V-75 5 Failures in this case may also include a system running out of support. c TU München, sebis, 28. All rights reserved. 87

88 4. Methodology Patterns (M-Patterns) If the analysis turns out a failure can cause large damages, a project should be proposed in order to address the potential problems (risk mitigation). The methodology uses the following V-Pattern: V-5: Infrastructure Usage V-75: Business Application Deployments The V-Pattern V-5 and V-75 are exchangeable as they contain equal information in different representation. Consequence Section The V-Pattern listed above do not consider failover or redundancy strategies of infrastructure elements. If these strategies should also be considered, more information has to be gather about those failover or redundancy strategies in order to perform a more detailed analysis. If further analyzes should be conducted, especially in respect to losses caused by a failure, additional information, as e.g. dependencies to business processes, has to be collected. The data collection effort for information about used infrastructure elements, dependencies to business applications, etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-4 see Section A c TU München, sebis, 28. All rights reserved.

89 4. Methodology Patterns (M-Patterns) 4.7 Interface, Business Object, and Service Management Management of Business Objects (M-19) M-Pattern Overview Id M-19 Name Alias Summary Version 1. Management of Business Objects The M-Pattern covers the management of business objects, their attributes and relationships. Problem Section The M-Pattern addresses the following concerns: C-51: Which business objects are used or exchanged by which business applications or services? C-52: What are the dependencies between the used business objects? C-1: Which business objects are exchanged over which interfaces? This M-Pattern addresses multiple concerns, which all refer to business objects, their dependencies and their usage. Business objects may be used and processed by different elements of the application landscape like e.g. business applications or business services. Management of business objects is an important task in the management of the application landscape as usually one business object is used by more than one application landscape element. Therefore, information about business objects is a subject relevant to EA management. Solution Section M-19 Attributes of business objects play an important role as they are part of the specification, what for example a customer really is. It is also advised to maintain an additional glossary, where the business objects are defined in a textual way. The methodology uses the following V-Pattern: C-51 C-52 C-1 M-19 V-4: Business Object ER Diagram V-47: Business Object Class Diagram V-48: Cluster Map visualizing Business Object Flows between Business Applications V-49: Communication Table V-4 V-47 V-48 V-49 V-51 V-52 V-82 c TU München, sebis, 28. All rights reserved. 89

90 4. Methodology Patterns (M-Patterns) V-51: Process Overview V-52: Business-level Communication Overview V-82: Business Object Flows V-Pattern V-4 and V-47 use different notation but are interchangeable as they both visualize business objects, their attributes and their relationships. The other V-Pattern (V-48, V-49, V-51, V-52 and V-82) are also exchangeable as they all show how business objects are exchanged, and the type of transmission used. They can be used to show dependencies between business applications or business service. This information is for example needed if a business application is exchanged by another. This exchange effects the depending business applications as e.g. used interfaces have to be adapted. Consequence Section Management of business objects may not be mixed up with company-wide data modeling [Sin91][Ort91]. This approach was too heavyweight as it tried to specify a complete company-wide data model, which led to a high complexity and high adjustment effort within the company. The goal in business object management is to specify the exchanged business objects between business processes, business services or business applications. Business objects may also be used as a starting point for the definition of domains and the definition of business services. E.g. based on the business object customer a customer domain can be found, which includes services that cope with processing customers. See M-2 (see page 91) for more information. The data collection effort for information about business objects, their attributes and relationships, services, interfaces and business applications, etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-19 see Section A c TU München, sebis, 28. All rights reserved.

91 4. Methodology Patterns (M-Patterns) Management of Business Services and Domains (M-2) M-Pattern Overview Id M-2 Name Alias Summary Version 1. Management of Business Services and Domains The M-Pattern considers the management of business services and their relationships. Problem Section The M-Pattern addresses the following concerns: C-2: What are the domains of the application landscape? C-4: How to find services within the development process of the application landscape? C-5: Which services are offered by which business application? C-: Which business processes are supported by which services? This methodology is concerned with the management of business services and the domains they belong to. When domains have been defined within the application landscape, those domains can than be used to reduce complexity of the application landscape through separation into smaller, easier manageable parts. Thereby, it is also of interest, which business objects are used by which business application or business service. Additionally, this methodology gives guidance on how to find business services. Solution Section M-2 In order to find business services within the application landscape, different approaches can be used. The first approach, also known as topdown approach, is to look at the business processes within the company. These processes have to be supported by services. Therefore, it would be possible to drill down the processes in order to find the right granularity for the services. The task to find the right granularity is one of the challenges with this approach. V-Pattern V-18 and V-8 can be used to support this approach. C-2 C-4 C-5 M-2 V-18 V-48 V-55 C- V-5 V-8 Another approach, also known as bottom-up approach starts with the business applications within the application landscape and tries to search for functionalities, which can be provided by c TU München, sebis, 28. All rights reserved. 91

92 4. Methodology Patterns (M-Patterns) a business service. The difficulty with this approach is the sheer amount of functionalities provided by applications as these have to be matched in order to avoid an unmanageable amount of services. V-Pattern V-5 shows a visualization, which can be used to find and manage infrastructure services. The third approach is a mixture of the bottom-up and the top-down approach. In this case business services are found by identifying business objects and their relationships. Services are only allowed to operate on the previously defined business objects. The danger of this approach is that the network of business objects and their relationships may become to unhandy to be managed in an appropriate way. Leveraging this approach V-Pattern V-47 can be used. The methodology uses the following viewpoints: V-18: Service-based Business Process Support Map V-48: Cluster Map visualizing Business Object Flows between Business Applications V-55: Component Cluster Map V-5: Infrastructure Usage V-8: Process Support Map with Services Consequence Section When using this methodology also the results of M-Pattern M-19 (see page 89) can be of interest, as this M-Pattern is concerned with business objects and their usage. The data collection effort for information about business objects, services, infrastructure elements, business applications, domain, etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-2 see Section A c TU München, sebis, 28. All rights reserved.

93 4. Methodology Patterns (M-Patterns) 4.7. Management of Interfaces (M-21) M-Pattern Overview Id M-21 Name Alias Summary Version 1. Management of Interfaces The M-Pattern is concerned with the management of connections between business applications and the thereby used interfaces. Problem Section The M-Pattern addresses the following concerns: C-1: Which business objects are exchanged over which interfaces? C-7: Which interfaces are offered/used by which business application? C-8: What is the type, e.g. online, offline, batch, etc. of a specific interface? How is the interface implemented? What are its capabilities? C-7: Which business applications are affected by the shut-down of an interface? C-99: Which offered interfaces are affected by the removal of a business application? One of the most important information about the application landscape is how business applications are connected to each other. Thereby, also information about the offered, used interfaces, as well as the type of interface and information about the exchanged business objects is of relevance. As interfaces evolve over time, planning aspects should also be considered in the management of interfaces. Solution Section M-21 Dependencies between business applications are of high importance as this information can be used to do different kind of analyzes. C-1 C-7 C-8 C-7 C-99 Impact analysis is one possible usage scenario. It could be of interest to show all business applications, which use the interfaces of an application under consideration. This knowledge can be used e.g. when the application will be shut-down in the future. In this case, all application owners of affected applications should be identified and informed that an interface their business application uses will not be available in the future. V-Pattern V-48, V-, and V-81 can be used for this purpose. V-48 V- V-4 M-21 V-79 V-8 V-81 c TU München, sebis, 28. All rights reserved. 9

94 4. Methodology Patterns (M-Patterns) A similar case would be the introduction of a new business application. Typically an application is not introduced in a green field approach, therefore it has to fit in the already existing application landscape. E.g. existing functionalities which are offered by interfaces should be reused. In this case, it would also be interesting to know, which business objects are used by which interface in order to create an appropriate adapter. Analyzes of this kind are supported by visualizations according to V-48, V-, V-4 and V-81. If not only static analyzes are of interest, V-Pattern V-79 may be a relevant visualization. This V- Pattern is based on the concepts of UML sequence diagrams and is therefore able to show execution sequences of interfaces. Concerning the planning and development of interface V-Pattern V-8 can be used. This viewpoint uses the notation of UML class diagrams in order to visualize the modification, e.g. a replacement, of interfaces as well as the offering of interfaces by business applications. The methodology uses the following viewpoints: V-48: Cluster Map visualizing Business Object Flows between Business Applications V-: Information Flows V-4: Applications and Interfaces V-79: Call Sequences V-8: Application and Interface Migrations V-81: Communicating Appplications Consequence Section The information employed by this methodology may be used as a basis for a bottom-up approach for identifying services within the application landscape. See M-Pattern M-2 (see page 91) for more information. The V-Pattern V-4, V-79, and V-8 use a notation based on UML concepts an may therefore be an interesting solution for stakeholders with a technical background. 94 c TU München, sebis, 28. All rights reserved.

95 4. Methodology Patterns (M-Patterns) The data collection effort for information about business processes, business application together with their interfaces, etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-21 see Section A c TU München, sebis, 28. All rights reserved. 95

96 4. Methodology Patterns (M-Patterns) Service Lifecycle Management (M-22) M-Pattern Overview Id M-22 Name Service Lifecycle Management Alias Summary This M-Pattern is concerned with the management of service lifecycles. Version 1. Problem Section The M-Pattern addresses the following concerns: C-71: How does the lifecycle of a service look like? Like business applications or infrastructure elements, business services also have a lifecycle as the requirements for a service changes over time. Therefore, these lifecylces have to be managed in order to keep track about changes or to avoid unexpected problems. Solution Section M-22 This M-Pattern suggests three different V- Pattern, which are exchangeable as they show simialr information. V-Pattern V-44 contains some additional information compared to the other two V-Pattern s as it also includes information, which projects only perform minor changes to a service and which ones result in a new version of a service. Therefore, all of the viewpoints can be used to visualize the different lifecylce phases of business services. Thereby, the granularity of the time line may vary from fiscal years up to months reflecting the demanded detail of planning. The visualized lifecylces offer the possibility to do long term planning of the future service development as well as analyzes of potential problems, like e.g. the phase out of a service. Such information may than be used to perform impact analyzes to other dependent elements of the application landscape. The methodology uses the following viewpoints: V-44: Service Lifecycles V-9: Service Lifecycles V-7: High-level Service Lifecylces V-44 C-71 M-22 V-9 V-7 9 c TU München, sebis, 28. All rights reserved.

97 4. Methodology Patterns (M-Patterns) Consequence Section This M-Pattern can only be one building block in a complete service management. As with business applications, a demand and a portfolio management has to be in place to really implement the concept of services and particularly the concept of a service oriented architecture. Therefore, the methodology introduced here should be further extended by additional M-Patterns satisfying these demands. The data collection effort for information about projects resulting in changes to services, lifecycle of services, etc. has been stated by practitioners using such methodologies as: Total Number of Answers < 1 person-day 1-5 persondays 5 person-days - 1 person-days 1 person-days - 1 personmonth > 1 personmonth For further information concerning the evaluation of methodology M-22 see Section A c TU München, sebis, 28. All rights reserved. 97

98 CHAPTER 5 Viewpoint Patterns (V-Patterns) This chapter contains all V-Patterns, which have been evaluated in the Enterprise Architecture Management Viewpoint Survey. The V-Pattern s are sorted according to their identifier. 98 c TU München, sebis, 28. All rights reserved.

99 5. Viewpoint Patterns (V-Patterns) 5.1 Viewpoint V-5 V-Pattern Overview Id V-5 Name Standard Conformity Layer Alias Summary This V-Pattern visualizes conformity aspects to company standards. Version Solution Section Munich Hamburg Garching London Online Shop (1) Human Resources System (7) POS System (Germany/Munich) (1) Product Shipment System (Germany) (4) POS System (Germany/ Hamburg) (12) Inventory Control System (2) Monetary Transactions System (Great Britain) (5) Customer Complaint System (19) Monetary Transactions System (Germany) () Business Traveling System (1) Worktime Management (Germany/Munich) (18) Fleet Management System (9) Price Tag Printing System (Germany/ Hamburg) (172) Data Warehouse (8) POS System (Great Britain) (15) Customer Satisfaction Analysis System (2) Accounting System (5) MIS (1) Price Tag Printing System (Germany/ Munich) (17) Document Management System (11) Worktime Management (Germany/ Hamburg) (182) Supplier Relationship Management System (12) Price Tag Printing System (Great Britain) (175) Costing System () Financial Planning System (14) Campaign Management System (15) Customer Relationship Management System (21) Worktime Management (Great Britain) (185) Legend Map Symbols A Organizational Unit B (1) Business Application (with id) Conforms to architecutal standard Yes No V-5 Visualization Rules A B (1) C (2) Organizational Unit (A) hosting Business Application (C) Figure 5.1: Viewpoint V-5 Conformity (interpreted in a dichotomous way as yes or no) can be visualized on a layer by overlaying each symbol representing a business application with a symbol of which the color depends on the conformity: green, if it has an associated architectural solution, red otherwise. Blueprint conformity information as maintained according to I-Pattern I- can easily be visualized via a layer on a software map. The figure above shows this on an exemplary cluster map. Variations: A third color can be used for business applications, for which the information of conformity is not known or not relevant. This would require an additional attribute in the information model. M-2 V-5 I- V-17 V-24 V-25 V-28 V-29 V- c TU München, sebis, 28. All rights reserved. 99

100 5. Viewpoint Patterns (V-Patterns) This V-Pattern constitutes a layer for a software map and can therefore not be used solely. Possible V-Pattern, which can be used as a base map for this layer are the following: V-17: Process Support Map V-24: Cluster Map for hosting Relationship V-25: Cluster Map for using Relationship V-28: Process Support Map visualizing horizontal Integration V-29: Process Support Map visualizing vertical Integration V-: Process Support Map visualizing vertical and horizontal Integration 1 c TU München, sebis, 28. All rights reserved.

101 5. Viewpoint Patterns (V-Patterns) 5.2 Viewpoint V- V-Pattern Overview Id V- Name Alias Summary Version 1. Clustering by Standard This V-Pattern visualizes homogeneity aspects, concerning architectural solutions Solution Section ArchSol1a ArchSol1b ArchSol2b ArchSol No Architectural Solution Conformance Fleet Management System (9) Supplier Relationship Management System (12) Human Resources System (7) Inventory Control System (2) Online Shop (1) Monetary Transactions System (Germany) () Monetary Transactions System (Great Britain) (5) Customer Relationship Management System (21) Product Shipment System (Germany) (4) Accounting System (5) Costing System () Document Management System (11) Data Warehouse (8) MIS (1) Financial Planning System (14) Campaign Management System (15) Business Traveling System (1) POS System (Great Britain) (15) Price Tag Printing System (Germany/ Munich) (17) Price Tag Printing System (Germany/ Hamburg) (172) POS System (Germany/Munich) (1) Price Tag Printing System (Great Britain) (175) Worktime Management (Germany/ Hamburg) (182) Customer Complaint System (19) POS System (Germany/ Hamburg) (12) Customer Satisfaction Analysis System (2) Worktime Management (Germany/Munich) (18) Worktime Management (Great Britain) (185) Legend Map Symbols Visualization Rules A Architectural Solution A B (1) B (1) Business Application (with id) C (2) Architectural Solution (A) used by Business Application (C) Figure 5.2: Viewpoint V- c TU München, sebis, 28. All rights reserved. 11

102 V- 5. Viewpoint Patterns (V-Patterns) This V-Pattern visualizes the usage of architectural solutions and architectural blueprints by visualizing each architectural solution as an rectangle, containing the business applications implementing them. Each business application is represented by one rectangle, which is then nested into the rectangle representing the architectural solution used by the business application under consideration (see Figure 5.2 for an example). The underlying I-Pattern is I-. Business applications not conforming to any architectural solution can be represented in a separate rectangle, named e.g. No Architectural Solution Conformance. M-2 V- I-2 12 c TU München, sebis, 28. All rights reserved.

103 Degree of Knowledge Coverage in % 5. Viewpoint Patterns (V-Patterns) 5. Viewpoint V-8 V-Pattern Overview Id V-8 Name Alias Summary Version 1. Knowledge Needs This V-Pattern visualizes the existing knowledge for different programming languages Solution Section V-8 Knowledge Set Figure 5.: Viewpoint V-8 Insights into knowledge aspects can be given by a bar chart showing the number of times a technology, programming language, etc. is required and available within the enterprise. This data can easily be visualized in bar charts as presented in Figure 5. with knowledge set on the x-axis and the respective coverage degrees on the y-axis. For calculating coverage degrees, see I-Pattern I-8 and M-Pattern M-5. We propose ordering the elements on x-axis by decreasing usage count. M-5 V-8 I-8 c TU München, sebis, 28. All rights reserved. 1

104 5. Viewpoint Patterns (V-Patterns) 5.4 Viewpoint V-12 V-Pattern Overview Id V-12 Name Alias Summary Version 1. Business Process and Business Function Relationship This V-Pattern gives an overview of the business events, the business processes they trigger, and the business functions, e.g. organizational units, responsible for the processes Solution Section Customer Relations Claim Handling Handle Claim Financial Handling Damage occurred Register Accept Valuate Pay Legend Map Symbols Visualization Rules A B C Business Function Business Event Business Process C C B Business Process (C) C reacts to Business Event (B) Business Process (C) B produces Business Event (B) Successor Relationship D between Business V-12Processes (C) and (D) D C A C Business Process (C) is a sub Business Process of (D) Business Function (A) is responsible for Business Process (C) Figure 5.4: Viewpoint V-12 This V-Pattern gives an overview of the business events, the business processes they trigger, and the business functions, e.g. organizational units, responsible for the processes. This V-Pattern is based on I-Pattern I-12. M- V-12 I c TU München, sebis, 28. All rights reserved.

105 5. Viewpoint Patterns (V-Patterns) 5.5 Viewpoint V-17 V-Pattern Overview Id V-17 Name Alias Summary Version 1. Process Support Map This V-Pattern visualizes, which business applications support which business processes at which organizational units Solution Section Acquisition Warehousing Distribution Headquarter Inventory Control System (2) Monetary Transaction System (Germany) () Inventory Control System (2) Inventory Control System (2) Campaign Management System (15) Customer Relationship Management System (21) Online Shop (1) Subsidiary Munich Inventory Control System (2) Monetary Transaction System (Germany) () Price Tag Printing System (Germany/ Munich) (17) Inventory Control System (2) Inventory Control System (2) Campaign Management System (15) POS System (Germany/Munich) (1) Customer Complaint System (19) Monetary Transaction System (Germany) () Subsidiary Hamburg Inventory Control System (2) Monetary Transaction System (Germany) () Price Tag Printing System (Germany/ Hamburg) (172) Inventory Control System (2) Inventory Control System (2) Campaign Management System (15) POS System (Germany/ Hamburg) (12) Customer Complaint System (19) Monetary Transaction System (Germany) () Subsidiary London Inventory Control System (2) Monetary Transaction System (Great Britain) (5) Price Tag Printing System (Great Britain) (175) Inventory Control System (2) Inventory Control System (2) Campaign Management System (15) POS System (Great Britain) (15) Customer Complaint System (19) Monetary Transaction System (Great Britain) (5) Warehouse Inventory Control System (2) Monetary Transaction System (Germany) () Inventory Control System (2) Inventory Control System (2) Product Shipment System (Germany) (4) Legend Map Symbols A Business Process A B (1) Business Application B with Id 1 C Organizational Unit C Visualization Rules C Vertical Alignment A Horizontal Alignment B (1) Business Process (A) is supported by Business Application (B) and used at Organizational Unit (C) A Ordering B Business Process (A) is a predecessor of (B) Figure 5.5: Viewpoint V-17 c TU München, sebis, 28. All rights reserved. 15

106 5. Viewpoint Patterns (V-Patterns) V-17 This V-Pattern, a process support map, visualizes, which business applications support which business processes at which organizational units. This V-Pattern is based on I-Pattern I-. V-7 V-9 V-5 M- M-1 M-14 M-18 V-41 V-45 V-17 V-57 V-7 V-7 I Consequence Section This V-Pattern can also be used to show the relationship between business applications and locations, instead of business applications and organizational units. In this case the corresponding I-Pattern has to be adapted to include an entity for location. 1 c TU München, sebis, 28. All rights reserved.

107 5. Viewpoint Patterns (V-Patterns) 5. Viewpoint V-18 V-Pattern Overview Id V-18 Name Alias Summary Version 1. Service-based Business Process Support Map This V-Pattern visualizes, how business processes are supported by services provided by business applications Solution Section Handle Claim Register Accept Valuate Pay Scanning service Customer administration service Claims administration service Printing service Payment service Document management system CRM application Home & Away Policy administration Home & Away Financial administration Legend Map Symbols B Business Process Visualization Rules D C Business Process (C) is a sub Business Process of (D) C Application Service B E Successor Relationship between Business Processes (B) and (E) D Business Application D C Business Application (D) exposes Application Service (C) C B Application Service (C) supports Business Process (B) Figure 5.: Viewpoint V-18 c TU München, sebis, 28. All rights reserved. 17

108 5. Viewpoint Patterns (V-Patterns) V-18 This V-Pattern visualizes, how business processes are supported by services provides by business applications. This V-Pattern is based on I-Pattern I-18. M-1 M-2 V-18 I c TU München, sebis, 28. All rights reserved.

109 5. Viewpoint Patterns (V-Patterns) 5.7 Viewpoint V-2 V-Pattern Overview Id V-2 Name Alias Summary Version 1. Technologies by Architectural Standard This V-Pattern consists of a table containing the technologies used in an architectural solution Solution Section Architectural Solution Name (english) Used Technologies ArchSol1a Oracle 9i, Tomcat 5.1, Apache 2..5, IE. ArchSol1b Oracle 9i, Bea Weblogic 8.1, Apache 2..5, IE. ArchSol2a DB2., Proprietary Fat-Client ArchSol2b Oracle 9i, V-2 Proprietary Fat-Client ArchSol Oracle 9i, Bea Weblogic 8.1, Proprietary Fat-Client Figure 5.7: Viewpoint V-2 This V-Pattern consists of a table containing the technologies used in an architectural solution. This V-Pattern is based on I-Pattern I-2. M-2 V-2 I-2 c TU München, sebis, 28. All rights reserved. 19

110 5. Viewpoint Patterns (V-Patterns) 5.8 Viewpoint V-24 V-Pattern Overview Id V-24 Name Cluster Map for hosting Relationship Alias Summary This V-Pattern visualizes organizational units hosting business applications. Version Solution Section Munich Hamburg Garching London Online Shop (1) Human Resources System (7) POS System (Germany/Munich) (1) Product Shipment System (Germany) (4) POS System (Germany/ Hamburg) (12) Inventory Control System (2) Monetary Transactions System (Great Britain) (5) Customer Complaint System (19) Monetary Transactions System (Germany) () Business Traveling System (1) Worktime Management (Germany/Munich) (18) Fleet Management System (9) Price Tag Printing System (Germany/ Hamburg) (172) Data Warehouse (8) POS System (Great Britain) (15) Customer Satisfaction Analysis System (2) Accounting System (5) MIS (1) Price Tag Printing System (Germany/ Munich) (17) Document Management System (11) Worktime Management (Germany/ Hamburg) (182) Supplier Relationship Management System (12) Price Tag Printing System (Great Britain) (175) Costing System () Financial Planning System (14) Campaign Management System (15) Customer Relationship Management System (21) Worktime Management (Great Britain) (185) Legend Map Symbols A Organizational Unit B (1) Business Application Visualization Rules A B (1) C (2) Organizational Unit (A) hosting Business Application (C) V-24 Figure 5.8: Viewpoint V-24 This V-Pattern is a cluster map grouping the business applications according to the hosting location or organizational unit. It is based on I- Pattern I-24. V-9 V-41 V-7 V-5 M-1 M-14 V-45 V-57 V-24 V- V-7 V-7 V-81 I c TU München, sebis, 28. All rights reserved.

111 5. Viewpoint Patterns (V-Patterns) 5.9 Viewpoint V-25 V-Pattern Overview Id V-25 Name Cluster Map for using Relationship Alias Summary This V-Pattern visualizes organizational units using business applications. Version Solution Section Munich Hamburg Garching London Online Shop (1) Human Resources System (7) POS System (Germany/Munich) (1) Product Shipment System (Germany) (4) POS System (Germany/ Hamburg) (12) Inventory Control System (2) Monetary Transactions System (Great Britain) (5) Customer Complaint System (19) Monetary Transactions System (Germany) () Business Traveling System (1) Worktime Management (Germany/Munich) (18) Fleet Management System (9) Price Tag Printing System (Germany/ Hamburg) (172) Data Warehouse (8) POS System (Great Britain) (15) Customer Satisfaction Analysis System (2) Accounting System (5) MIS (1) Price Tag Printing System (Germany/ Munich) (17) Document Management System (11) Worktime Management (Germany/ Hamburg) (182) Supplier Relationship Management System (12) Price Tag Printing System (Great Britain) (175) Costing System () Financial Planning System (14) Campaign Management System (15) Customer Relationship Management System (21) Worktime Management (Great Britain) (185) Legend Map Symbols A Organizational Unit B (1) Business Application Visualization Rules A B (1) C (2) Organizational Unit (A) using Business Application (C) V-25 Figure 5.9: Viewpoint V-25 This V-Pattern is a cluster map grouping the business applications by the using locations or organizational units. Thereby, business applications used at more than one organizational unit may appear more than once on the map. This V-Pattern is based on I-Pattern I-25. V-9 V-41 V-45 V-57 V-7 V-5 M-1 V-25 V- V-7 V-7 V-81 I-25 c TU München, sebis, 28. All rights reserved. 111