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 [email protected] 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

112 5. Viewpoint Patterns (V-Patterns) 5.1 Viewpoint V-2 V-Pattern Overview Id V-2 Name Alias Summary Version 1. Time Interval Map visualizing Lifecycles of Applications This V-Pattern visualizes the lifecycles of business applications, including the respective versions Solution Section Accounting v Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec v 1.5 v v 2. v 2.5 Business Traveling System v 1. v1. v1.5 v 1.5 Management Information System v 1. v1. v2. v 2. Legend Map Symbols A Business Application Application status planned Application Version status planned Visualization Rules A Jan Feb B Business Application Version Application status in development Application status in production Application status in retirement Application Version status in development Application Version status in production Application Version status in retirement V-2 B Version (B) belongs to Business Application (A) A B Business Application (A) is in production in Jan and Feb Figure 5.1: Viewpoint V-2 This V-Pattern is an interval map showing the lifecycles of business applications in an aggregating view, which is additionally detailed by the respective versions. The V-Pattern depends on I-Pattern I-2. M-15 V-2 I c TU München, sebis, 28. All rights reserved.

113 5. Viewpoint Patterns (V-Patterns) Consequence Section The status of the business application in this V-Pattern has to be derived by the status of the corresponding business application versions. Thereby, an ordering of the business application version status can be used for the deduction, e.g. if there is a business application version, which is in state in production, this state overrules the other status and the Business Application is assigned the status in production. The needed information can be gathered form the I-Pattern I-2. c TU München, sebis, 28. All rights reserved. 11

114 5. Viewpoint Patterns (V-Patterns) 5.11 Viewpoint V-27 V-Pattern Overview Id V-27 Name Alias Summary Version 1. Application Lifecycle Project Layer This V-Pattern visualizes project proposals in addition to the lifecycles of the business applications Solution Section Accounting v Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec v 1.5 v v 2. v 2.5 Business Traveling System v 1. v1. v1.5 v 1.5 Management Information System v 1. v1. v2. v 2. Project 1 Legend Map Symbols A Business Application Application status planned Application Version status planned Visualization Rules A Jan Feb Jan Feb B C Business Application Version Project Application status in development Application status in production Application status in retirement Application Version status in development Application Version status in production Application Version status in retirement V-27 B Version (B) belongs to Business Application (A) A B Business Application (A) is in production in Jan and Feb C Project (C) is running in Jan and Feb Figure 5.11: Viewpoint V-27 This V-Pattern is an interval map, which shows project proposals in addition to the lifecycles of the business applications. The V-Pattern depends on I-Pattern I-. M-15 V-27 I- 114 c TU München, sebis, 28. All rights reserved.

115 5. Viewpoint Patterns (V-Patterns) 5.12 Viewpoint V-28 V-Pattern Overview Id V-28 Name Alias Summary Version 1. Process Support Map visualizing horizontal Integration This V-Pattern visualizes which business applications support which business processes at which organizational units, focusing on the degree of horizontal integration Solution Section Acquisition Warehousing Distribution Headquarter Inventory Control System (2) Monetary Transaction System (Germany) () 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) 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) 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) 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) 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 Business Process (A) is A supported by Business Application (B) and used at Horizontal Alignment Organizational Unit (C) B (1) A B Business Process (A) is a predecessor of (B) Ordering A D Horizontal Alignment Horizontal Alignment Business Processes (A) and (D) are supported by Business Application (B) (Horizontal Integration) B (1) Figure 5.12: Viewpoint V-28 c TU München, sebis, 28. All rights reserved. 115

116 5. Viewpoint Patterns (V-Patterns) V-28 This V-Pattern is a process support map. It visualizes which business applications support which business processes at which organizational units, focusing on the degree of horizontal integration. The visualization displays the support of two or more neighboring processes by the same business application in the same location as a horizontally extended rectangle. The focus of this V-Pattern is on the degree of horizontal integration. This V-Pattern is based on I-Pattern I-. V-7 V-9 V-41 V-45 V-57 V-5 M-18 V-28 M-29 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. 11 c TU München, sebis, 28. All rights reserved.

117 5. Viewpoint Patterns (V-Patterns) 5.1 Viewpoint V-29 V-Pattern Overview Id V-29 Name Alias Summary Version 1. Process Support Map visualizing vertical Integration This V-Pattern visualizes which business applications support which business processes at which organizational units or locations, focusing on the degree of vertical integration Solution Section Acquisition Warehousing Distribution Headquarter Customer Relationship Management System (21) Online Shop (1) Subsidiary Munich Subsidiary Hamburg Inventory Control System (2) Monetary Transaction System (Germany) () Price Tag Printing System (Germany/ Munich) (17) Price Tag Printing System (Germany/ Hamburg) (172) Inventory Control System (2) Inventory Control System (2) Campaign Management System (15) POS System (Germany/Munich) (1) POS System (Germany/ Hamburg) (12) Customer Complaint System (19) Monetary Transaction System (Germany) () Subsidiary London Monetary Transaction System (Great Britain) (5) Price Tag Printing System (Great Britain) (175) POS System (Great Britain) (15) Monetary Transaction System (Great Britain) (5) Warehouse Monetary Transaction System (Germany) () 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 Business Process (A) is A supported by Business Application (B) and used at Horizontal Alignment Organizational Unit (C) B (1) A B Business Process (A) is a predecessor of (B) Ordering C E Vertical Alignment B (1) Business Application (B) is used at Organizational Unit (C) and Organizational Unit (E) (Vertical Integration) Figure 5.1: Viewpoint V-29 c TU München, sebis, 28. All rights reserved. 117

118 5. Viewpoint Patterns (V-Patterns) V-29 This V-Pattern is of type process support map, thus visualizing which business applications support which business processes at which organizational units or locations. Here, business applications supporting a specific process step in more than one neighboring (graphically, on the diagram) organizational units are shown as a vertically extended rectangle. The focus of this V- Pattern is on the degree of vertical integration. This V-Pattern is based on I-Pattern I-. V-7 V-5 V-9 V-41 V-45 V-57 V-7 V-7 M-18 V-29 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. 118 c TU München, sebis, 28. All rights reserved.

119 5. Viewpoint Patterns (V-Patterns) 5.14 Viewpoint V- V-Pattern Overview Id V- Name Alias Summary Version 1. Process Support Map visualizing vertical and horizontal Integration This V-Pattern visualizes which business applications support which business processes at which organizational units or locations, focusing on the degree of vertical and horizontal integration Solution Section Acquisition Warehousing Distribution Headquarter Customer Relationship Management System (21) Online Shop (1) Subsidiary Munich Subsidiary Hamburg Inventory Control System (2) Monetary Transaction System (Germany) () Price Tag Printing System (Germany/ Munich) (17) Price Tag Printing System (Germany/ Hamburg) (172) Inventory Control System (2) Campaign Management System (15) POS System (Germany/Munich) (1) POS System (Germany/ Hamburg) (12) Customer Complaint System (19) Monetary Transaction System (Germany) () Subsidiary London Monetary Transaction System (Great Britain) (5) Price Tag Printing System (Great Britain) (175) POS System (Great Britain) (15) Monetary Transaction System (Great Britain) (5) Warehouse Monetary Transaction System (Germany) () Product Shipment System (Germany) (4) Legend Map Symbols Visualization Rules A B (1) C Business Process A Business Application B with Id 1 Organizational Unit C 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) A D Horizontal Alignment Horizontal Alignment Business Processes (A) and (D) are supported by Business Application (B) (Horizontal Integration) C E Vertical Alignment B (1) Business Application (B) is used at Organizational Unit (C) and Organizational Unit (E) (Vertical Integration) B (1) Figure 5.14: Viewpoint V- c TU München, sebis, 28. All rights reserved. 119

120 5. Viewpoint Patterns (V-Patterns) V- This V-Pattern is of type process support map, thus visualizing which business applications support which business processes at which organizational units or locations. Thereby, graphically neighboring business application rectangles representing the same business application are composed to horizontally and/or vertically extended rectangles. The focus of this V-Pattern is on the degree of horizontal and vertical integration. This V-Pattern is based on I-Pattern I-. V-7 V-5 V-9 V-41 V-45 V-57 V-7 V-7 M-18 V- 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. 12 c TU München, sebis, 28. All rights reserved.

121 5. Viewpoint Patterns (V-Patterns) 5.15 Viewpoint V-2 V-Pattern Overview Id V-2 Name Alias Summary Version 1. Process Support Map visualizing Changes in Relations to their Time Horizon This V-Pattern visualizes how business processes are currently supported by business applications, and how these applications are going to be changed in the next years Solution Section Customer Acqusition Basic Services Transaction Processing&Clearing Additional Services 27 CRM System Giro Clearing Settlement A BoSha System A 28 CRM System Giro Clearing Settlement A BoSha System A BoSha System B 29 CRM System Giro Clearing Settlement A BoSha System B > 29 CRM System Giro Clearing Settlement A BoSha System B Legend Map Symbols E Business Process A Business Application Business Application Status A B C D new removed unchanged changed Visualization Rules C A Horizontal Alignment Vertical Alignment B (1) A Horizontal Alignment B (1) D Horizontal Alignment Business Process (A) is supported by Business Application (B) in Year (C) Business Processes (A) and (D) are supported by Business Application (B) (Horizontal Integration) Figure 5.15: Viewpoint V-2 c TU München, sebis, 28. All rights reserved. 121

122 5. Viewpoint Patterns (V-Patterns) V-2 This V-Pattern shows, how business processes are currently supported by business applications, and how these supports are going to be changed in the next years. The V-Pattern depends on I-Pattern I-2 and I-Pattern I-. M-14 V-2 I-2 I Consequence Section The I-Patterns I-2 and I- can be easily integrated by the concept BusinessApplication. 122 c TU München, sebis, 28. All rights reserved.

123 5. Viewpoint Patterns (V-Patterns) 5.1 Viewpoint V- V-Pattern Overview Id V- Name Alias Summary Version 1. Time Interval Map visualizing Projects and the affected Business Application This V-Pattern visualizes how business applications are (potentially) affected by project for the next years Solution Section Roadmap Sample Application Category FY 7 FY 8 FY 9 Application 1 V1. Sample Project Application 1 V2. FY 7 FY 8 FY 9 Application 2 V5.5 Sample Project 2 FY 7 FY 8 FY 9 Sample Project Application V1. Legend Map Symbols A B Business Application Version Project Visualization Rules A B C Business Application Version (C) replaces Business Application Version (A) as a result of Project (B) C Fiscal Year A B Business Application Version (A) is changed by Project (B) Project Status A Planned/Active Business Application Version Status Planned B A Business Application Version (A) is created by Project (B) B Idea In development In Production C A Business Application Version (A) is active in Fiscal Year To be Retired Figure 5.1: Viewpoint V- c TU München, sebis, 28. All rights reserved. 12

124 5. Viewpoint Patterns (V-Patterns) V- This V-Pattern shows how business applications are (potentially) affected by projects in the next fiscal years. Thereby, the diagram distinguishes, whether a project proposal plans to replace, or introduce a business application. This V-Pattern depends on I-Pattern I-. M-15 V- I- 124 c TU München, sebis, 28. All rights reserved.

125 5. Viewpoint Patterns (V-Patterns) 5.17 Viewpoint V-5 V-Pattern Overview Id V-5 Name Alias Summary Version 1. Proposal Impact Table This V-Pattern visualizes proposals affecting business applications in a tabular way Solution Section Business Application / Affected by Project P1 P2 P P4 P5 P P7 P8 P9 P1 Online Shop x x Inventory Control System Monetary Transactions System (Germany) Monetary Transactions System (Great Britain) x Product Shipment System (Germany) x Accounting System x Costing System Human Resources System Data Warehouse Fleet Management System Business Traveling System x x Document Management System Supplier Relationship Management System MIS (Management Information System) Financial Planning System Campaign Management (Marketing Automation System) POS System (Germany/Munich) x POS System (Germany/Hamburg) x POS System (Great Britain) Price Tag Printing System (Germany/Munich) Price Tag Printing System (Germany/Hamburg) Price Tag Printing System (Great Britain) Worktime Management System (Germany/Munich) x Worktime Management System (Germany/Hamburg) Worktime Management System (Great Britain) Customer Complaint System x Customer Satisfaction Analysis System V-5 Customer Relationship Management System Figure 5.17: Viewpoint V-5 This V-Pattern is a table showing how projects are planned to affect business applications. It depends on I-Pattern I-5. M-2 V-5 I-5 c TU München, sebis, 28. All rights reserved. 125

126 5. Viewpoint Patterns (V-Patterns) 5.18 Viewpoint V- V-Pattern Overview Id V- Name Overview over Lifecycle of Business Applications Alias Summary This V-Pattern visualizes projects changing business applications. Version Solution Section This Year Next Year + /5 Years To Be Retired In Production In Development Planned Application 4 Application 5 Application 7 Application 1 Application Application 8 Application 12 Application 2 Application Application 9 Application 1 Application 11 Legend Map Symbols Visualization Rules Application Business Application Year Lifecycle Phases To Be Retired In Production In Development Phase Vertical Alignment Horizontal Alignment Business Application (B) is in Lifecycle Phase Phase in time horizon Year B Planned Figure 5.18: Viewpoint V- 12 c TU München, sebis, 28. All rights reserved.

127 V- 5. Viewpoint Patterns (V-Patterns) This V-Pattern gives an overview of the lifecycles of business applications for a specific space in time. It depends on I-Pattern I-. M-15 V- I- c TU München, sebis, 28. All rights reserved. 127

128 5. Viewpoint Patterns (V-Patterns) 5.19 Viewpoint V-7 V-Pattern Overview Id V-7 Name Alias Summary Version 1. Effects of a Project Proposal on the Application Landscape This V-Pattern visualizes which business applications are affected by a specific project proposal 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 B (1) B (1) Organizational Unit Business Application Business Application affected by Project Proposal Visualization Rules A B (1) C (2) Organizational Unit (A) hosting Business Application (C) Figure 5.19: Viewpoint V c TU München, sebis, 28. All rights reserved.

129 V-7 5. Viewpoint Patterns (V-Patterns) This V-Pattern describes a layer showing, which business applications are affected by a specific project proposal, by highlighting these business applications. The figure above shows this on an exemplary cluster map. Thereby, the diagram complements a textual project proposal description. The V-Pattern depends on I-Pattern I-5. M- V-17 V-24 V-25 V-7 V-28 V-29 I-5 V Consequence Section 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 c TU München, sebis, 28. All rights reserved. 129

130 5. Viewpoint Patterns (V-Patterns) 5.2 Viewpoint V-8 V-Pattern Overview Id V-8 Name Alias Summary Version 1. Effects of a Project Proposal on Technologies This V-Pattern visualizes technologies, their number of usages and highlights selected ones, which will be replaced by another technology Solution Section Basic Te echnologies.net 1.1 Java 1.4 Java 1. Ocaml Perl Cobol LISP FORTRAN Ada C++ Eiffel.NET 2..NET 1. Java Number of Applications using a programming language Basic Technologies affected by Project Proposal Figure 5.2: Viewpoint V-8 1 c TU München, sebis, 28. All rights reserved.

131 V-8 5. Viewpoint Patterns (V-Patterns) This V-Pattern indicates on a bar chart, which basic technologies (infrastructure technologies, programming languages, etc.) are affected by a project proposal, e.g. the replacement of a specific programming language. The bar chart itself shows the number of usages of the respective basic technology. The V-Pattern relies on I-Pattern I-8. M- V-8 I-8 c TU München, sebis, 28. All rights reserved. 11

132 5. Viewpoint Patterns (V-Patterns) 5.21 Viewpoint V-9 V-Pattern Overview Id V-9 Name Effects of a Project Proposal on the Application Landscape (detail) Alias Summary This V-Pattern visualizes changes in the application landscape. 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 Visualization Rules A Organizational Unit Status of Business Application B (1) Business Application B (1) New Business Application B (1) B (1) Business Application is modified Replaced by another Business Application A B (1) C (2) Organizational Unit (A) hosting Business Application (C) Figure 5.21: Viewpoint V-9 12 c TU München, sebis, 28. All rights reserved.

133 V-9 5. Viewpoint Patterns (V-Patterns) This V-Pattern is a layer showing, which business applications are affected by a specific (project) proposal, by highlighting these business applications. Thereby, a color code indicates the nature of the change. The figure above shows this on an exemplary cluster map. Thereby, the diagram complements a textual project proposal description. The V-Pattern depends on I-Pattern I-9. M- V-9 M-4 V-17 V-24 V-25 V-28 V-29 I-9 V Consequence Section 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 c TU München, sebis, 28. All rights reserved. 1

134 5. Viewpoint Patterns (V-Patterns) 5.22 Viewpoint V-4 V-Pattern Overview Id V-4 Name Alias Summary Version 1. Migration of Functionality This V-Pattern visualizes migration of functionality from one business application to another Solution Section Business Application 1 Business Application 2 Start Migration Start Migration Shut Down Business Application Business Application 4 Shut Down Replacement Migration Client- Master-Data Migration Product Booking Field Test Stage I Stage II Migration Migration One leading System Business Application 5 Business Application Business Application 7 Q4 2 Start Migration Start Migration Migration Start Migration Shut Down Migration Field Test Q1 Q2 Q Q4 Q Legend Map Symbols Visualization Rules A B Milestone with Description Goal of Project with description A D E Migration of Functionality (D) from one Business Application to another at Milestone (A) resulting in Milestone (E) Business Application is Introduced Business Application is in Phase Out B Goal (B) has been achieved on Business Application C Business Application is in Production Timespan C Business Application is active in Timespan (C) D Migration of Functionality with description Figure 5.22: Viewpoint V-4 14 c TU München, sebis, 28. All rights reserved.

135 V-4 5. Viewpoint Patterns (V-Patterns) This V-Pattern visualizes dependencies between business applications and how functionality is migrated between these business applications. Thereby, the diagram covers changes within a specific space in time. This V-Pattern relies on I-Pattern I-4. M-14 V-4 M-15 I-4 c TU München, sebis, 28. All rights reserved. 15

136 5. Viewpoint Patterns (V-Patterns) 5.2 Viewpoint V-41 V-Pattern Overview Id V-41 Name Cluster Map indicating standard vs. individual software Alias Summary This V-Pattern visualizes standard and individual software on a cluster map. 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 Visualization Rules A Organizational Unit Type of Business Application Standard Software V-41 B (1) Business Application Individual Software A B (1) C (2) Organizational Unit (A) hosting Business Application (C) Figure 5.2: Viewpoint V-41 This V-Pattern shows, whether a business application is standard or individual software via color coding on a layer. The figure above shows this on an exemplary cluster map. This V-Pattern depends on I-Pattern I-41. M- M-1 V-17 V-24 V-41 V-25 V-28 V-29 I-41 V- 1 c TU München, sebis, 28. All rights reserved.

137 5. Viewpoint Patterns (V-Patterns) Consequence Section 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 c TU München, sebis, 28. All rights reserved. 17

138 5. Viewpoint Patterns (V-Patterns) 5.24 Viewpoint V-44 V-Pattern Overview Id V-44 Name Service Lifecycles Alias Summary This V-Pattern shows how project proposals intend to change services. Version Solution Section Roadmap for Services FY 7 FY 8 FY 9 Service 1 V1. Sample Project Service 1 V2. FY 7 FY 8 FY 9 Service 2 V5.5 Sample Project 2 FY 7 FY 8 FY 9 Sample Project Service V1. Legend Map Symbols A Service Version B Project Visualization Rules A B C Service Version (C) replaces Service Version (A) as a result of Project (B) C Fiscal Year A B Service Version (A) is changed by Project (B) Project Status A Planned/Active Service Version Status Planned B A Service Version (A) is created by Project (B) B Idea In development In Production C A Service Version (A) is active in Fiscal Year To be Retired Figure 5.24: Viewpoint V c TU München, sebis, 28. All rights reserved.

139 V Viewpoint Patterns (V-Patterns) This V-Pattern shows, how project proposals intend to change services. Thereby, the diagram distinguishes a replacement of a service by another service from changes to an existing service or introduction. This V-Pattern depends on I- Pattern I-44. M-22 V-44 I-44 c TU München, sebis, 28. All rights reserved. 19

140 5. Viewpoint Patterns (V-Patterns) 5.25 Viewpoint V-45 V-Pattern Overview Id V-45 Name Alias Summary Version 1. Process Support Map, showing standard vs. individual software This V-Pattern visualizes whether a business application is standard or individual software, together with the information, which business process they support and which organizational units are using them Solution Section Acquisition Warehousing Distribution Headquarter Customer Relationship Management System (21) Online Shop (1) Subsidiary Munich Subsidiary Hamburg Inventory Control System (2) Monetary Transaction System (Germany) () Price Tag Printing System (Germany/ Munich) (17) Price Tag Printing System (Germany/ Hamburg) (172) Inventory Control System (2) Campaign Management System (15) POS System (Germany/Munich) (1) POS System (Germany/ Hamburg) (12) Customer Complaint System (19) Monetary Transaction System (Germany) () Subsidiary London Monetary Transaction System (Great Britain) (5) Price Tag Printing System (Great Britain) (175) POS System (Great Britain) (15) Monetary Transaction System (Great Britain) (5) Warehouse Monetary Transaction System (Germany) () Product Shipment System (Germany) (4) Legend Map Symbols A Business Process A B (1) Business Application B with Id 1 (Individual Software) D (1) Business Application D with Id 1 (Standard Software) C Organizational Unit C Visualization Rules C A Vertical Alignment A Business Process (A) is supported by Business Application (B) and used at Horizontal Alignment Organizational Unit (C) B (1) Horizontal Alignment Horizontal Alignment B (1) D Business Processes (A) and (D) are supported by Business Application (B) (Horizontal Integration) C E A B Business Process (A) is a predecessor of (B) Ordering Vertical Alignment B (1) Business Application (B) is used at Organizational Unit (C) and (E) (Vertical Integration) Figure 5.25: Viewpoint V c TU München, sebis, 28. All rights reserved.

141 V Viewpoint Patterns (V-Patterns) This V-Pattern shows, whether a business application is standard or individual software as a layer for a software map. The figure above shows this on an exemplary process support map. The underlying I-Pattern is I-41. M- M-1 V-17 V-24 V-45 V-25 V-28 V-29 I-41 V Consequence Section 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 c TU München, sebis, 28. All rights reserved. 141

142 5. Viewpoint Patterns (V-Patterns) 5.2 Viewpoint V-4 V-Pattern Overview Id V-4 Name Alias Summary Version 1. Business Object ER Diagram This V-Pattern is used for modeling business objects using an entity relationship diagram Solution Section Surename Person Forename Name City n Age ZipCode 1 has n Address n belongs to Street HouseNumber Legend Map Symbols A Attribute B Primary Key C Business Object D Relationship Visualization Rules C A C B n C D C Business Object (C) has Attribute (A) Business Object (C) has Primary Key (B) Business Object (C) has a Relationship End with Multiplicity n Relationship (D) of Business Object (C) Figure 5.2: Viewpoint V c TU München, sebis, 28. All rights reserved.

143 V-4 5. Viewpoint Patterns (V-Patterns) This V-Pattern shows a diagram, which allows the modeling of business objects based on the notation of entity relationship diagrams (ER diagram) [Che7]. The underlying I-Pattern is I-4. M-19 V-4 I-4 c TU München, sebis, 28. All rights reserved. 14

144 5. Viewpoint Patterns (V-Patterns) 5.27 Viewpoint V-47 V-Pattern Overview Id V-47 Name Business Object Class Diagram Alias Summary This V-Pattern uses the notation of UML 2. class diagrams. Version Solution Section Person +Surname : String +Forname : String +Age : Integer +belongsto * +has * Address +Street : String +HouseNumber : String +belongsto * +has..1 City +Name : String +ZipCode : String Legend Map Symbols Visualization Rules Class Business Object A +B : CA Business Object (A) with Attribute (B) and Datatype of Attribute (CA) +End1 * +End2 * Association with A Association Ends and Cardinalities V-47 +End1 +End2 * * D Relationship between Business Object (A) and (D) with Cardinality * to * Figure 5.27: Viewpoint V-47 This V-Pattern shows a diagram which allows the modeling of business objects based on the notation of UML 2. class diagrams. The underlying I-Pattern is I-47. M-19 V-47 I c TU München, sebis, 28. All rights reserved.

145 5. Viewpoint Patterns (V-Patterns) 5.28 Viewpoint V-48 V-Pattern Overview Id V-48 Name Alias Summary Version 1. Cluster Map visualizing Business Object Flows between Business Applications This V-Pattern visualizes the flow of business objects of a selected business process Solution Section Business Process: Distribution Warehouse Subsidiary Munich Invoice POS System (Germany/Munich) Stock Item Inventory Control System Monetary Transactions System (Germany) Monetary Transaction Product Shipment System (Germany) Stock Item Stock Item Campaign Management System Customer Complaint System Customer Complaint Legend Map Symbols Visualization Rules A Business Application Type of Interface Online A B (1) Organizational Unit (A) hosting Business Application (C) B Organizational Unit Offline C (2) Interface Manual D Business Object (D) is transfered in Information Flow B Business Object A A Business Application (A) has Interface Outgoing Information Flow from Business Application (A) Information Flow A Incoming Information Flow to Business Application (A) Figure 5.28: Viewpoint V-48 c TU München, sebis, 28. All rights reserved. 145

146 5. Viewpoint Patterns (V-Patterns) V-48 This V-Pattern shows, how business objects are exchanged between business applications, thereby considering the interfaces offered by the business applications of a selected business process. This V-Pattern is based on I-Patterns I-, I-48, and I-. M-19 M-2 M-21 M- V-48 I- I-48 I Consequence Section The I-Patterns I- and I- can easily be integrated by the concept Business Application, which can be found in both I-Patterns. The resulting information model from the integration of I- and I- can be integrated with I-48 by the concept SupportRelationship. The information required for this V-Pattern is quite similar but more extensive to the information required for V-Pattern V-82. Therefore, V-82 may also be considered when modeling business objects that are transfered over interfaces. 14 c TU München, sebis, 28. All rights reserved.

147 5. Viewpoint Patterns (V-Patterns) 5.29 Viewpoint V-49 V-Pattern Overview Id V-49 Name Communication Table Alias Summary This V-Pattern visualizes the data flow of business objects. Version Solution Section Business Process Distribution in Subsidiary Munich Server Business Applications Campaign Management System Inventory Control System Monetary Transactions System (Germany) Client Business Applications Interface Complaint Interface Invoice Interface Stock Interface Stock Interface Transaction Interface Campaign Management System Stock Item Stock Item Customer Complaint System Customer Complaint POS System (Germany/Munich) Invoice Monetary Transaction Legend Map Symbols Visualization Rules A B C Business Application Information Flow Business Object Interface Type of Interface Online Offline Manual A A D B D B Business Object (B) is transfered from Business Application (A) to Business Application (D) Business Object (B) is transfered from Business Application (D) to Business Application (A) A C C A Business Application (A) has Interface (C) D Business Application (A) has Interfaces (C) and (D) Figure 5.29: Viewpoint V-49 c TU München, sebis, 28. All rights reserved. 147

148 5. Viewpoint Patterns (V-Patterns) V-49 This V-Pattern shows in a table, how business objects are exchanged between business applications, thereby considering the interfaces offered by the business applications. This V-Pattern is based on I-Patterns I-, I-48, and I-. M-19 V-49 I- I-48 I Consequence Section The I-Patterns I- and I- can easily be integrated by the concept Business Application, which can be found in both I-Patterns. The resulting information model from the integration of I- and I- can be integrated with I-48 by the concept SupportRelationship. The information required for this V-Pattern is quite similar but more extensive to the information required for V-Pattern V-82. Therefore, V-82 may also be considered when modeling business objects that are transfered over interfaces. 148 c TU München, sebis, 28. All rights reserved.

149 5. Viewpoint Patterns (V-Patterns) 5. Viewpoint V-51 V-Pattern Overview Id V-51 Name Alias Summary Version 1. Process Overview This V-Pattern shows how business objects are used by business processes in business interactions Solution Section Policy creation service Policy information service Home & Away Policy administration Policy Creation Home & Away Financial administration Calculate risk Calculate premium Create policy Store policy Premium collection Insurance request data Insurance policy data Customer file data Legend Map Symbols Visualization Rules A Business Process E B Business Function (B) reads Data Object (E) B C Business Function Business Service B E Business Function (B) writes Data Object (E) D Application Component B F Business Function (B) is predecessor of Business Function (F) E Business Object B Business Interaction is the successor to Business Function (B) Business Interaction B Business Interaction proceeds Business Function (B) C Business Interaction realized by Application Service (C) A C Business Service (C) realized by Business Process (A) D A Application Component (D) executes Business Process (A) A B Business Function (B) is part of Business Process (A) Figure 5.: Viewpoint V-51 c TU München, sebis, 28. All rights reserved. 149

150 5. Viewpoint Patterns (V-Patterns) V-51 This V-Pattern shows, how business objects are used by business processes in business interactions. Thereby, business interactions are interactions of business functions in a process flow. The underlying I-Pattern is I-51. M-19 V-51 I c TU München, sebis, 28. All rights reserved.

151 5. Viewpoint Patterns (V-Patterns) 5.1 Viewpoint V-52 V-Pattern Overview Id V-52 Name Alias Summary Version 1. Business-level Communication Overview This V-Pattern shows how business roles, including external ones, and business functions, exchange business objects Solution Section Customer information Product information Customer information Product information Maintaining Intermediary Relations Maintaining Customer Relations Insurance information Claims Customer Intermediary Customer information Claims Contracts Contracting Insurance policies Claim Handling Claim information Insurance policies Claims Asset Management Money Money Financial Handling Claim payments Insurance premiums Customer s Bank Legend Map Symbols Visualization Rules A B C Business Role Business Function Information Flow A B A C D Business Role (A) has Business Function (B) Information Flow (C) from Business Role (A) to Business Role (D) A C B Information Flow (C) from Business Role (A) to Business Function (B) B B C C A E Information Flow (C) from Business Function (B) to Business Role (A) Information Flow (C) from Business Function (B) to Business Function (E) Figure 5.1: Viewpoint V-52 c TU München, sebis, 28. All rights reserved. 151

152 5. Viewpoint Patterns (V-Patterns) V-52 This V-Pattern shows, how business roles, including external ones, and business functions, exchange business objects. The underlying I- Pattern is I-52. M-19 V-52 I c TU München, sebis, 28. All rights reserved.

153 5. Viewpoint Patterns (V-Patterns) 5.2 Viewpoint V-55 V-Pattern Overview Id V-55 Name Alias Component Cluster Map Summary This V-Pattern groups components of a certain kind, e.g. services, by the domain they belong to. Version Solution Section Products Customers Relationships Component 1 Component 5 Component 9 Component 12 Component 1 Component 2 Component 22 Component 2 Component Component 1 Component 1 Component 17 Component 21 Component Component 7 Component 11 Component 14 Component 18 Component 4 Component 8 Component 15 Component 19 Legend Map Symbols A B Domain with name A Component B Visualization Rules A B C Component (C) is part of Domain (A) Figure 5.2: Viewpoint V-55 c TU München, sebis, 28. All rights reserved. 15

154 5. Viewpoint Patterns (V-Patterns) V-55 This V-Pattern groups components of a certain kind (e.g. services) by the domain they belong to. The exemplary Figure 5.2 uses Products, Customers, and Relationships as domains, while of course other domains are possible. This V-Pattern is based on I-Pattern I-55. M-2 V-55 I c TU München, sebis, 28. All rights reserved.

155 5. Viewpoint Patterns (V-Patterns) 5. Viewpoint V-5 V-Pattern Overview Id V-5 Name Alias Summary Version 1. Infrastructure Usage This V-Pattern shows the infrastructure services offered by infrastructure software, which are used by business applications Solution Section Home Insurance Application Home & Away Financial Application Car Insurance Application Legal Aid Backoffice System Messaging service Data access service Mainframe Message Queuing DBMS (DB2) Legend Map Symbols Visualization Rules B A Application Component Device C B E System Software (E) is deployed on Device (B) C System Software C D System Software (C) realizes Infrastructure Service (D) D Infrastructure Service D A Application Component (A) uses Infrastructure Service (D) Figure 5.: Viewpoint V-5 c TU München, sebis, 28. All rights reserved. 155

156 5. Viewpoint Patterns (V-Patterns) V-5 This V-Pattern shows the infrastructure services offered by infrastructure software and used by business applications. This V-Pattern is based on I-Pattern I-5. M-2 M-4 V-5 I-5 15 c TU München, sebis, 28. All rights reserved.

157 5. Viewpoint Patterns (V-Patterns) 5.4 Viewpoint V-57 V-Pattern Overview Id V-57 Name Alias Summary Version 1. Expected Proposal Effects This V-Pattern shows projects changing business applications, together with costs of the projects on a process support map Solution Section Acquisition Warehousing Distribution Headquarter Customer Relationship Management System (21) Online Shop (1) Subsidiary Munich Subsidiary Hamburg Inventory Control System (2) Monetary Transaction System (Germany) () P17 P Price Tag Printing System (Germany/ Munich) (17) Price Tag Printing System (Germany/ Hamburg) (172) Inventory Control System (2) Campaign Management System (15) POS System (Germany/Munich) (1) POS System (Germany/ Hamburg) (12) Customer Complaint System (19) Monetary Transaction System (Germany) () P17 P Subsidiary London Monetary Transaction System (Great Britain) (5) Price Tag Printing System (Great Britain) (175) P5 POS System (Great Britain) (15) P5 P15 Monetary Transaction System (Great Britain) (5) Warehouse P14 Monetary Transaction System (Germany) () P14 Product Shipment System (Germany) (4) Legend Map Symbols Visualization Rules A B (1) C D 5. Business Process A Business Application B with Id 1 Organizational Unit C Project Costs for Project Proposal (D) C A Vertical Alignment A Horizontal Alignment B (1) Horizontal Alignment Horizontal Alignment D Business Process (A) is supported by Business Application (B) and used at Organizational Unit (C) Business Processes (A) and (D) are supported by Business Application (B) (Horizontal Integration) C E A B Ordering B (1) Vertical Alignment Business Process (A) is a predecessor of (B) Business Application (B) is used at Organizational Unit (C) and (E) (Vertical Integration) B (1) A (1) C D Business Application (A) is affected by Project Proposal (D) Figure 5.4: Viewpoint V-57 c TU München, sebis, 28. All rights reserved. 157

158 5. Viewpoint Patterns (V-Patterns) V-57 This V-Pattern shows project proposals changing business applications as a layer for a software map. Thereby, this layer also indicates the (estimated) costs of the respective project proposals. The figure above shows this on an exemplary process support map. The underlying I-Pattern is I-57. M-25 V-57 M-2 V-17 V-24 V-25 V-28 V-29 I-57 V Consequence Section 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 158 c TU München, sebis, 28. All rights reserved.

159 Expected Return of Project (ROI) 5. Viewpoint Patterns (V-Patterns) 5.5 Viewpoint V-59 V-Pattern Overview Id V-59 Name Alias Summary Version 1. Financial Project Portfolio Overview This V-Pattern visualizes the relation between the standard deviation of the return of investment (ROI) and expected ROI of a project proposal Solution Section Project Proposals: Financial Overview Matrix 4% % 2% 1% Reliability Improvement of the Online Shop Consolidation of Monetary Transaction Systems VAT change in Accounting System Introduction of RFID in the Warehouse VAT change in Price Tag Printing System % -1% -2%,5,1,15 Connection of,2,25, VAT change in Online Shop Costing and Accounting System Standard Deviation of ROI VAT change in POS System VAT change in Costing System Legend Map Symbols Project Proposal with Name A Project Proposal Costs Strategic Impact Rating + Environmental Factor Rating -2 2 Visualization Rules B C A Project Proposal (A) has Expected Return of Project (ROI) and Standard Deviation of ROI Figure 5.5: Viewpoint V-59 c TU München, sebis, 28. All rights reserved. 159

160 5. Viewpoint Patterns (V-Patterns) V-59 This V-Pattern shows a set of project proposals in a portfolio matrix. The axes of the portfolio matrix are expected project return of investment (ROI), and the standard deviation of this ROI. The proposals are visualized as circles in the portfolio matrix, with the circle size indicating (estimated) project costs and the circle color the (expected) strategic impact of the project. This V-Pattern is based on I-Pattern I-59. M-25 V-59 M-2 I Consequence Section I-Pattern I-59 only shows a simplified information model fragment, which is sufficient to create the viewpoint described above. A more detailed information model fragment can be found in I-Pattern I-8. 1 c TU München, sebis, 28. All rights reserved.

161 Environmental Factor Rating 5. Viewpoint Patterns (V-Patterns) 5. Viewpoint V- V-Pattern Overview Id V- Name Alias Summary Version 1. Strategic Project Portfolio Overview This V-Pattern visualizes the relation between strategic impact, expected ROI, and an environmental factor rating of a project proposal Solution Section Project Proposals: Strategic Overview Matrix 1,8, Database Consolidation VAT change in Accounting System VAT change in Online Shop,4,2 -,4 -, -,8-1 Connection of Costing and Accounting System VAT change in POS System VAT change in Costing System -1 -,5,5 1 -,2 Strategic Impact Rating Integration of an auctioning platform into the online shop Consolidation of Monetary Transaction Systems Legend Map Symbols Project Proposal with Name A Project Proposal Costs Expected Return of Investment (ROI) of Project Proposal -2% 4% Visualization Rules B C A Project Proposal (A) has Environmental Factor Rating (B) and Strategic Impact Rating (C) Figure 5.: Viewpoint V- c TU München, sebis, 28. All rights reserved. 11

162 5. Viewpoint Patterns (V-Patterns) V- This V-Pattern shows a set of project proposals in a portfolio matrix. The axes of the portfolio matrix are the (expected) strategic impact and the extent to which it reacts to environmental influences, as e.g. laws, regulations or standards. The proposals are visualized as circles in the portfolio matrix, with the circle size indicating (estimated) project costs, and the circle color indicating the expected project return of investment (ROI). The V-Pattern is based on I-Pattern I-59. M-24 V- I-59 M Consequence Section I-Pattern I-59 only shows a simplified information model fragment, which is sufficient to create the viewpoint described above. A more detailed information model fragment can be found in I-Pattern I c TU München, sebis, 28. All rights reserved.

163 Number of Affected Business Applications 5. Viewpoint Patterns (V-Patterns) 5.7 Viewpoint V-1 V-Pattern Overview Id V-1 Name Alias Summary Version 1. Technical Project Portfolio Overview This V-Pattern visualizes the relation between development time in person month and number of affected business applications of a project proposal Solution Section Project Proposals: Technical Overview Matrix Integration of an auctioning platform into the online shop 4 VAT change in Online Shop VAT change in Costing System Consolidation of Monetary Transaction Systems Database Consolidation VAT Change in POS System VAT change in Accounting System Development Time in Person Months Legend Map Symbols A Project Proposal Costs Strategic Impact Rating + Environmental Factor Rating -2 2 Project Proposal with Name Visualization Rules B C A Project Proposal (A) has Number of Affected Business Applications (B) and Development Time in Person Months (C) Figure 5.7: Viewpoint V-1 c TU München, sebis, 28. All rights reserved. 1

164 5. Viewpoint Patterns (V-Patterns) V-1 This V-Pattern shows a set of project proposals in a portfolio matrix. The axes of the portfolio matrix are the (expected) development time and the number of affected business applications. The proposals are visualized as circles in the portfolio matrix, with the circle size indicating (estimated) project costs, and the circle color indicating the sum of the strategic impact rating and environmental factor rating. These two ratings indicate the strategic impact of a project and the extent to which it reacts to environmental influences. This V-Pattern is based on I-Pattern I-59. M-25 V-1 I-59 M Consequence Section I-Pattern I-59 only shows a simplified information model fragment, which is sufficient to create the viewpoint described above. A more detailed information model fragment can be found in I-Pattern I c TU München, sebis, 28. All rights reserved.

165 5. Viewpoint Patterns (V-Patterns) 5.8 Viewpoint V- V-Pattern Overview Id V- Name Alias Summary Version 1. Information Flows This V-Pattern visualizes the interconnections between business applications and the type of the used interfaces Solution Section Munich Garching Online Shop (1) Human Resources System (7) POS System (Germany/Munich) (1) Inventory Control System (2) Monetary Transactions System (Germany) () Business Traveling System (1) Worktime Management (Germany/Munich) (18) Data Warehouse (8) Accounting System (5) MIS (1) Price Tag Printing System (Germany/ Munich) (17) Supplier Relationship Management System (12) Costing System () Financial Planning System (14) Legend Map Symbols Visualization Rules A B (1) Organizational Unit Business Application Interface Type of Interface Online Offline Manual A B (1) C (2) Organizational Unit (A) hosting Business Application (C) Information Flow B (1) Business Application (B) has Interface B (1) B (1) Outgoing Information Flow from Business Application (B) Incoming Information Flow to Business Application (B) Figure 5.8: Viewpoint V- c TU München, sebis, 28. All rights reserved. 15

166 5. Viewpoint Patterns (V-Patterns) V- This V-Pattern shows information flows between the business applications on a layer. Thereby, different kinds of interfaces, as e.g. manual, synchronous/asynchronous etc. are distinguished. The figure above shows this on an exemplary cluster map. This V-Pattern is based on I- Pattern I-. M-21 V-24 V- I- V Consequence Section 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-24: Cluster Map for hosting Relationship V-25: Cluster Map for using Relationship 1 c TU München, sebis, 28. All rights reserved.

167 5. Viewpoint Patterns (V-Patterns) 5.9 Viewpoint V-4 V-Pattern Overview Id V-4 Name Alias Summary Version 1. Applications and Interfaces This V-Pattern relies on the notation of UML class diagrams for visualizing interfaces used and offered by business applications Solution Section «Application» 1 Online Shop «Interface»12 OnlineShop Interface +Order() «Application» Monetary Transaction System Legend Map Symbols «Application»A Business Application «Interface»B Interface with Operation +Operation() Visualization Rules «Application»A «Interface»B +Operation() «Application»A V-4 «Interface»B +Operation() Business Application (A) implements Interface (B) Business Application (A) uses Interface (B) Figure 5.9: Viewpoint V-4 This V-Pattern relies on the notation of UML class diagrams for visualizing interfaces used and offered by business applications. Thereby, business applications and interfaces are distinguished by stereotypes. This V-Pattern is based on I- Pattern I-4. M-21 V-4 I-4 c TU München, sebis, 28. All rights reserved. 17

168 5. Viewpoint Patterns (V-Patterns) 5.4 Viewpoint V- V-Pattern Overview Id V- Name Alias Summary Version 1. Architectural Solution in detail (UML) This V-Pattern uses the notation of an UML 2. object diagram to visualize an architectural solution Solution Section Architectural Solution: -Tier-Web-Architecture Client http Server Client jdbc Server IE. : Web Client Apache 2. : Webserver Oracle 8i : Relational DBMS Legend Map Symbols Visualization Rules A : B A : B D C E Technology (A) of Type (B) F : G D C E Connector (C) with Roles (D) and (E) V- Connector (C) between two Technologies (A) and (F) Figure 5.4: Viewpoint V- This V-Pattern uses the notation of an UML 2. object diagram to visualize an architectural solution, i.e. a specific concretization of an architectural blueprint. This V-Pattern is based on I-PatternI-. M-2 V- I- 18 c TU München, sebis, 28. All rights reserved.

169 5. Viewpoint Patterns (V-Patterns) 5.41 Viewpoint V-7 V-Pattern Overview Id V-7 Name Alias Summary Version 1. Standard Conformity Exceptions This V-Pattern shows on a layer, which business applications conform to architectural standards, and where exceptions from these standards have been allowed 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 Visualization Rules A B (1) Organizational Unit Business Application Conforms to architecutal standards Yes A B (1) No C (2) B (2) Organizational Unit (A) hosting Business Application (C) Business Application (B) is does not need to conform to the respective architectural standard Figure 5.41: Viewpoint V-7 c TU München, sebis, 28. All rights reserved. 19

170 5. Viewpoint Patterns (V-Patterns) V-7 This V-Pattern shows on a layer, which business applications conform to architectural standards, and where exceptions from these standards have been allowed. The figure above shows this on an exemplary cluster map. This V-Pattern is based on I-Pattern I-7. M-4 V-7 I-7 V-17 V-24 V-25 V-28 V-29 V Consequence Section 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 17 c TU München, sebis, 28. All rights reserved.

171 5. Viewpoint Patterns (V-Patterns) 5.42 Viewpoint V-8 V-Pattern Overview Id V-8 Name Alias Summary Version 1. Process Support Map with Services This V-Pattern visualizes which services support which business process in which organizational units Solution Section Acquisition Warehousing Distribution Headquarter Service (1) Service (2) Service (1) Service (1) Service (5) Service (7) Service (9) Subsidiary Munich Service (1) Service (2) Service (4) Service (1) Service (1) Service (5) Service (8) Service (1) Service (2) Subsidiary Hamburg Service (1) Service (2) Service (4) Service (1) Service (1) Service (5) Service (8) Service (1) Service (2) Subsidiary London Service (1) Service () Service (4) Service (1) Service (1) Service (5) Service (8) Service (1) Service () Warehouse Service (1) Service (2) Service (1) Service (1) Service () Legend Map Symbols A Business Process A B (1) Service B with Id 1 C Organizational Unit C Visualization Rules C A Business Process (A) is supported by Service (B) and used at Organizational Unit (C) V-8 Horizontal Alignment B (1) Vertical Alignment A B Business Process (A) is a predecessor of Business process (B) Ordering Figure 5.42: Viewpoint V-8 This V-Pattern visualizes which services support which business process in which organizational units. This V-Pattern is based on I-Pattern I-8. M-2 V-8 I-8 c TU München, sebis, 28. All rights reserved. 171

172 5. Viewpoint Patterns (V-Patterns) 5.4 Viewpoint V-9 V-Pattern Overview Id V-9 Name Service Lifecycles Alias Summary This V-Pattern visualizes the lifecycles of services in a gantt-like notation. Version Solution Section Service 1 v Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec v 1.5 v v 2. v 2.5 Service 2 v 2. v 2. v. v. v 4. Legend Map Symbols A Service Service status planned Service Version status planned Visualization Rules A Jan Feb B Service Version Service status in development Service status in production Service status in retirement Service Version status in development Service Version status in production Service Version status in retirement V-9 B Version (B) belongs to Service (A) A B Service (A) is in production in Jan und Feb Figure 5.4: Viewpoint V-9 This V-Pattern visualizes the lifecycles of services in a gantt-like notation. This V-Pattern is based on I-Pattern I-9. M-22 V-9 I c TU München, sebis, 28. All rights reserved.

173 5. Viewpoint Patterns (V-Patterns) Consequence Section The status of the service in this V-Pattern has to be derived by the status of the corresponding service versions. Thereby, an ordering of the service version statuses can be used for the deduction, e.g. if there is a service version which is in state in production, this state overrules the other statuses and the service is assigned the status in production. The needed information can be gathered from the I-Pattern I-9. c TU München, sebis, 28. All rights reserved. 17

174 5. Viewpoint Patterns (V-Patterns) 5.44 Viewpoint V-7 V-Pattern Overview Id V-7 Name High-level Service Lifecylces Alias Summary This V-Pattern visualizes current and future lifecycle phases of services. Version Solution Section This Year Next Year + /5 Years To Be Retired Service 1 Service 2 Service In Production Service 4 Service 5 Service In Development Planned Service 7 Service 8 Service 9 Service 12 Service 1 Service 11 Legend Map Symbols Visualization Rules A Lifecycle Phases Service To Be Retired In Production In Development Phase Vertical Alignment Year Horizontal Alignment A Service (A) is in Lifecycle Phase (Phase) in time horizon (Year) Planned Figure 5.44: Viewpoint V c TU München, sebis, 28. All rights reserved.

175 V-7 5. Viewpoint Patterns (V-Patterns) This V-Pattern visualizes current and future lifecycle phases of services. This V-Pattern is based on I-Pattern I-7. M-22 V-7 I-7 c TU München, sebis, 28. All rights reserved. 175

176 5. Viewpoint Patterns (V-Patterns) 5.45 Viewpoint V-75 V-Pattern Overview Id V-75 Name Alias Summary Version 1. Business Application Deployments This V-Pattern uses the notation of an UML 2. deployment diagram and shows, how infrastructure components are used by business applications Solution Section Legend Visualization Rules Hardware System Infrastructure Software Deployable Artifact Business Application Visualization Rules A connection between Hardware System (server1) and Hardware System (dbserver) exists Deployable Artifact (Home and Away Financial Application) is deployed on Infrastructure Software (Weblogic) Deployable Artifact (Car Insurance Application) is the manifestation (bytecode, executable, etc.) of Business Application (Car Insurance Application) Infrastructure Software runs on a Hardware System (server1) Figure 5.45: Viewpoint V c TU München, sebis, 28. All rights reserved.

177 V Viewpoint Patterns (V-Patterns) This V-Pattern uses the notation of an UML 2. deployment diagram and shows, how infrastructure components are used by business applications. This V-Pattern is based on I-Pattern I-75. M-4 V-75 I-75 c TU München, sebis, 28. All rights reserved. 177

178 5. Viewpoint Patterns (V-Patterns) 5.4 Viewpoint V-7 V-Pattern Overview Id V-7 Name Alias Summary Version 1. Technology Usage This V-Pattern visualizes which business applications use which infrastructure components together with the information, which of these infrastructure components run out of support Solution Section Headquarter Subsidiary Subsidiary Hamburg Warehouse Subsidiary London Munich 1 Online Shop (1) Human Resources System (7) 2 POS System (Germany/ Munich) (1) 2 Product Shipment System (Germany) (4) POS System (Germany/ Hamburg) (12) Inventory Control System (2) 2 Monetary 5 Transactions System (Great Britain) (5) Customer Complaint System (19) Monetary 2 Transactions System (Germany) () Business Traveling System (1) 2 Worktime Management (Germany/ Munich) (18) 2 Fleet Management System (9) Price Tag Printing System (Germany/ Hamburg) (172) Data Warehouse (8) 2 5 POS System (Great Britain) (15) Customer Satisfaction Analysis System (2) 5 Accounting System (5) MIS (1) 2 2 Price Tag Printing System (Germany/ Munich) (17) Document Management System (11) Worktime Management (Germany/ Hamburg) (182) Supplier Relationship Management System (12) 5 Price Tag Printing System (Great Britain) (175) 2 Costing System () 1 Financial Planning System (14) Campaign Management System (15) Customer Relationship Management System (21) 5 Worktime Management (Great Britain) (185) Legend Map Symbols Visualization Rules A B (1) Organizational Unit Business Application Database System 1 MySQL Munich (1) 2 Oracle Munich (2) A B (1) C (2) Organizational Unit (A) hosting Business Application (C) Database running out of support before x No 4 5 Oracle Hamburg () Oracle Garching (4) DB2 London (5) B(1) x Business Application (B) uses Database (x) x Yes PostgreSQL London () Figure 5.4: Viewpoint V c TU München, sebis, 28. All rights reserved.

179 V-7 5. Viewpoint Patterns (V-Patterns) This V-Pattern shows on a layer, which infrastructure components, e.g. database management systems, the different business applications use. Additionally, coloring indicates which infrastructure components have run out of support. The figure above shows this on an exemplary cluster map. This V-Pattern is based on I-Pattern I-7. M- V-7 I-7 V-17 V-24 V-25 V-28 V-29 V Consequence Section 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 c TU München, sebis, 28. All rights reserved. 179

180 5. Viewpoint Patterns (V-Patterns) 5.47 Viewpoint V-79 V-Pattern Overview Id V-79 Name Alias Summary Version 1. Call Sequences This V-Pattern visualizes the ordering of how interfaces of business applications are called, using the notation inspired by UML 2. sequence diagrams Solution Section Handle Complaint at Headquarter Customer Complaint System Campaign Management System Inventory Control System acquirecomplaint changestockamount complaintacquired Legend Map Symbols A Business Application Duration of Activity Message Synchronous Message Message Asynchronous Message Message Response Visualization Rules A Message Business Application (A) with Life Line and duration of Activity Synchronous call from one Business Application to another Message Message Asynchronous call from one Business Application to another Response of Business Application call Figure 5.47: Viewpoint V c TU München, sebis, 28. All rights reserved.

181 V Viewpoint Patterns (V-Patterns) This V-Pattern visualizes the ordering of how interfaces of business applications are called, using the notation inspired by UML 2. sequence diagrams. This V-Pattern is based on I-Pattern I-79. M-21 V-79 I-79 c TU München, sebis, 28. All rights reserved. 181

182 5. Viewpoint Patterns (V-Patterns) 5.48 Viewpoint V-8 V-Pattern Overview Id V-8 Name Alias Summary Version 1. Application and Interface Migrations This V-Pattern shows the effects of replacing a business application on its offered interfaces Solution Section «Modified Application» OnlineShop (11) «Modified Interface»OnlineShop Interface (121) «Application» OnlineShop (1) «Interface»OnlineShop Interface (12) Legend Map Symbols «Application» A Business Application Visualization Rules «Application» A «Interface» C Business Application (A) offers Interface (C) «Modified Application» B Modified Business Application «Modified Application» B «Modified Interface» D Modified Business Application (B) offers Modified Interface (D) «Interface» C Interface «Modified Application» B «Application» A Modified Business Application (B) replaces Business Application (A) «Modified Interface» D Modified Interface «Modified Interface» D «Interface» C Modified Interface Application (D) replaces Interface (C) Interface Offering Replacement Figure 5.48: Viewpoint V c TU München, sebis, 28. All rights reserved.

183 V-8 5. Viewpoint Patterns (V-Patterns) This V-Pattern shows the effects of replacing a business application on its offered interfaces. This V-Pattern is based on I-Pattern I-8. M-21 V-8 I-8 c TU München, sebis, 28. All rights reserved. 18

184 5. Viewpoint Patterns (V-Patterns) 5.49 Viewpoint V-81 V-Pattern Overview Id V-81 Name Alias Summary Version 1. Communicating Appplications This V-Pattern visualizes how business applications communicate using interfaces, including further information about the kind of communication Solution Section Munich Garching Online Shop (1) Human Resources System (7) POS System (Germany/Munich) (1) Inventory Control System (2) Monetary Transactions System (Germany) () Business Traveling System (1) Worktime Management (Germany/Munich) (18) Data Warehouse (8) Accounting System (5) MIS (1) Price Tag Printing System (Germany/ Munich) (17) Supplier Relationship Management System (12) Costing System () Financial Planning System (14) Legend Map Symbols A B (1) Organizational Unit Business Application Read Information Write Information Visualization Rules B (1) B (1) B (1) A B (1) Organizational Unit (A) hosting Business Application (B) C (2) C (2) C (2) Business Application (C) reads from Business Application (B) Business Application (C) writes to Business Application (B) Business Application (C) reads and writes to Business Application (B) Figure 5.49: Viewpoint V c TU München, sebis, 28. All rights reserved.

185 V Viewpoint Patterns (V-Patterns) This V-Pattern is based on a cluster map showing organizational units and the business applications they host (V-24). Based on this cluster map, it is indicated, how the business applications communicate via interfaces, also showing the kind of communication taking place (the data flow direction). This V-Pattern is based on I- Patterns I-24 and I-81. M-21 V-24 V-81 I-81 V Consequence Section The I-Pattern I-24 and I-81 can easily be integrated as they both include the concept Business Application. This V-Pattern can be seen as a layer for V-Pattern V-24. Alternatively this V-Pattern can also be used as a layer for V-Pattern V-25 when utilizing I-Pattern I-25. c TU München, sebis, 28. All rights reserved. 185

186 5. Viewpoint Patterns (V-Patterns) 5.5 Viewpoint V-82 V-Pattern Overview Id V-82 Name Alias Summary Version 1. Business Object Flows This V-Pattern visualizes how business objects are exchanged between business applications Solution Section «business object» Customer «business application» Application 1 Interface 1 «business application» Application 2 Legend Map Symbols Visualization Rules «business application» A Business Application with identifier «business object» D Business Object (D) is used by Interface (B) B «business object» D Offered Interface with name of Interface Required Interface with name of Interface Business Object with name B «business application» A B Business Application (A) offers Interface (B) «business application» E Business Application (E) uses Interface Figure 5.5: Viewpoint V c TU München, sebis, 28. All rights reserved.

187 V Viewpoint Patterns (V-Patterns) This V-Pattern shows, how business objects are exchanged between business applications, thereby relying on the notation of UML 2. component diagrams. This V-Pattern is based on I-Patterns I- and I-82. M-19 V-82 I Consequence Section The I-Pattern I- and I-82 can easily be integrated as they both include the concept Information- Flow. The information required for this V-Pattern is quite similar to the information required for V-Pattern, except that V-48 is a more detailed visualization. Therefore, V-48 may also be considered when modeling business objects that are transfered over interfaces. c TU München, sebis, 28. All rights reserved. 187

188 CHAPTER Information Model Patterns (I-Patterns) This chapter contains all I-Patternneeded by the V-Pattern, listed in the previous section (see Section 5). The I-Pattern are sorted according to their identifier. 188 c TU München, sebis, 28. All rights reserved.

189 . Information Model Patterns (I-Patterns).1 I-Pattern I- I-Pattern Overview Id I- Name Usage of Architectural Solutions Alias Summary Version Solution Section Figure.1: Information Model I- BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. ArchitecturalSolution: A concretization of an ArchitecturalBlueprint, created by selecting a specific Technology for each AbstractTechnology of the respective ArchitecturalBlueprint. An architectural solution thus describes a basic architecture for a business application, indicating of which components (technologies) it is made up, and how these interact. For definition of ArchitecturalBlueprint, AbstractTechnology, and AbstractTechnologyUsage, see I-Pattern I-. c TU München, sebis, 28. All rights reserved. 189

190 . Information Model Patterns (I-Patterns).2 I-Pattern I-8 I-Pattern Overview Id I-8 Name Skill Coverage Alias Summary Version Solution Section Figure.2: Information Model I-8 OrganizationalUnit: An organizational unit represents a subdivision of the organization according to its internal structure. A possible example are the entities showing up in an organigram. KnowledgeSet: Identifies a specific kind of knowledge. Examples could be Java (Knowledge), C++ (Knowledge), Oracle (Knowledge), etc. KnowledgeType: Further classifies a KnowledgeSet. Other or different types as shown in the class diagram are possible. SkillCoverage: Indicates, to what extent the need for knowledge characterized by a specific KnowledgeSet is covered in a specific OrganizationalUnit. Thereby, both needed and available knowledge are indicated by the number person months of a respective knowledge bearer needed or available in a specific space in time (e.g. a month). 19 c TU München, sebis, 28. All rights reserved.

191 . Information Model Patterns (I-Patterns). I-Pattern I-12 I-Pattern Overview Id I-12 Name Process Landscape Alias Summary Version Solution Section Figure.: Information Model I-12 BusinessProcess: According to [Krc5], defined as a sequence of logical individual functions with connections between them. [DFH] states input and output factors and a defined process objective as important characteristics of a business process. The business process should not be identified with single process steps or individual functions, but with high-level processes at a level similar to the one used in value chains. BusinessFunction: Offers (related) functionality that may be useful for one or more business processes (definition from [JGBvB5]). BusinessEvent: According to [JGBvB5], something that happens and may influence a BusinessProcess. Thereby, a process can produce a BusinessEvent or can be an reaction to a BusinessEvent. c TU München, sebis, 28. All rights reserved. 191

192 . Information Model Patterns (I-Patterns)..2 Consequence Section BusinessProcesses have to modeled at a granularity level, whhere each BusinessProcess has at most one predecessor and at most one successor. 192 c TU München, sebis, 28. All rights reserved.

193 . Information Model Patterns (I-Patterns).4 I-Pattern I-18 I-Pattern Overview Id I-18 Name Services and Service Usage Alias Summary Version Solution Section Figure.4: Information Model I-18 BusinessProcess: According to [Krc5], defined as a sequence of logical individual functions with connections between them. [DFH] states input and output factors and a defined process objective as important characteristics of a business process. The business process should not be identified with single process steps or individual functions, but with high-level processes at a level similar to the one used in value chains. BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. ApplicationService: A unit of functionality offered by a BusinessApplication, and used in executing a process (e.g. to support or automate process execution). c TU München, sebis, 28. All rights reserved. 19

194 . Information Model Patterns (I-Patterns).4.2 Consequence Section BusinessProcesses have to modeled at a granularity level, whhere each BusinessProcess has at most one predecessor and at most one successor. 194 c TU München, sebis, 28. All rights reserved.

195 . Information Model Patterns (I-Patterns).5 I-Pattern I-2 I-Pattern Overview Id I-2 Name Technology Usage Alias Summary Version Solution Section Figure.5: Information Model I-2 ArchitecturalSolution: A concretization of an ArchitecturalBlueprint, created by selecting a specific Technology for each AbstractTechnology of the respective ArchitecturalBlueprint. An architectural solution thus describes a basic architecture for a business application, indicating of which components (technologies) it is made up, and how these interact. Technology: A specific technology implementing an AbstractTechnology (e.g. Apache 2..5, being a Webserver, or Oracle 9.2i being a Database Management System). For definition of ArchitecturalBlueprint, AbstractTechnology, and AbstractTechnologyUsage, see I-Pattern I-. c TU München, sebis, 28. All rights reserved. 195

196 . Information Model Patterns (I-Patterns). I-Pattern I-24 I-Pattern Overview Id I-24 Name Hosting Business Applications Alias Summary Version Solution Section BusinessApplication id : String name : String hosts * 1 OrganizationalUnit name : String Figure.: Information Model I-24 OrganizationalUnit: An organizational unit represents a subdivision of the organization according to its internal structure. A possible example are the entities showing up in an organigram. BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. OrganizationalUnit hosts BusinessApplication: A specific OrganizationalUnit is responsible for hosting a BusinessApplication...2 Consequence Section If this I-Pattern is integrated into an information model storing BusinessApplicationVersions for a BusinessApplication, one should consider to change the BusinessApplication in this pattern to the BusinessApplicationVersion. 19 c TU München, sebis, 28. All rights reserved.

197 . Information Model Patterns (I-Patterns).7 I-Pattern I-25 I-Pattern Overview Id I-25 Name Using Business Applications Alias Summary Version Solution Section Figure.7: Information Model I-25 OrganizationalUnit: An organizational unit represents a subdivision of the organization according to its internal structure. A possible example are the entities showing up in an organigram. BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. OrganizationalUnit uses BusinessApplication: The organizational unit uses the business application to support its activities (e.g. the processes it executes). c TU München, sebis, 28. All rights reserved. 197

198 . Information Model Patterns (I-Patterns).8 I-Pattern I-2 I-Pattern Overview Id I-2 Name Business Application Versions Alias Summary Version Solution Section Figure.8: Information Model I-2 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. BusinessApplicationVersion: A specific version of a BusinessApplication, here meaning a specific release of this application. For versions, start and end dates of different lifecycle phases are recorded. 198 c TU München, sebis, 28. All rights reserved.

199 . Information Model Patterns (I-Patterns).9 I-Pattern I- I-Pattern Overview Id I- Name Process Support Alias Summary Version Solution Section Figure.9: Information Model I- BusinessProcess: According to [Krc5], defined as a sequence of logical individual functions with connections between them. [DFH] states input and output factors and a defined process objective as important characteristics of a business process. The business process should not be identified with single process steps or individual functions, but with high-level processes at a level similar to the one used in value chains. OrganizationalUnit: An organizational unit represents a subdivision of the organization according to its internal structure. A possible example are the entities showing up in an organigram. c TU München, sebis, 28. All rights reserved. 199

200 . Information Model Patterns (I-Patterns) BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. SupportRelationship: Represents the support of a process by a business application at a specific organizational unit. Basically, it constitutes, together with its three associations, a ternary relationship between BusinessProcess, OrganizationalUnit, and BusinessApplication. This is necessary in order to be able to tell exactly which organizational unit uses which business application to support a given process. 2 c TU München, sebis, 28. All rights reserved.

201 . Information Model Patterns (I-Patterns).1 I-Pattern I-2 I-Pattern Overview Id I-2 Name Timed Process Support Alias Summary Version Solution Section Figure.1: Information Model I-2 BusinessProcess: According to [Krc5], defined as a sequence of logical individual functions with connections between them. [DFH] states input and output factors and a defined process objective as important characteristics of a business process. The business process should not be identified with single process steps or individual functions, but with high-level processes at a level similar to the one used in value chains. SupportRelationship: Indicates, which BusinessApplication supports which BusinessProcess during which space in time. BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. c TU München, sebis, 28. All rights reserved. 21

202 . Information Model Patterns (I-Patterns).11 I-Pattern I- I-Pattern Overview Id I- Name Project Effects Business Application Version Alias Summary Version Solution Section Figure.11: Information Model I- BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. BusinessApplicationVersion: A specific version of a BusinessApplication, here meaning a specific release of this application. For versions, start and end dates of different lifecycle phases are recorded. Project: A planned activity concerned with modifying one or more elements from the application landscape, mostly focused on BusinessApplications. Projects transform the application landscape. ProjectStatus: An enumeration of different states a project can be in. ProjectEffect: Indicates, which effect a project has on a specific BusinessApplication. EffectType: Different kinds of effects a project can have on a BusinessApplication. Examples may include but are not limited to change, replace, remove. 22 c TU München, sebis, 28. All rights reserved.

203 . Information Model Patterns (I-Patterns).12 I-Pattern I-5 I-Pattern Overview Id I-5 Project Proposal Targets Alias Summary Version Solution Section Figure.12: Information Model I-5 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. ProjectProposal: A proposal for a project, with a description detailing the project proposal to a specific extent. Project: A planned activity concerned with modifying one or more elements from the application landscape, mostly focused on BusinessApplications. Projects transform the application landscape. c TU München, sebis, 28. All rights reserved. 2

204 . Information Model Patterns (I-Patterns).1 I-Pattern I- I-Pattern Overview Id I- Name Project Effects Alias Summary Version Solution Section BusinessApplication id : String name : String * ProjectEffect type : EffectType * EffectType replace change introduce Project name : String start : Date end : Date Figure.1: Information Model I- BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. EffectType: Different kinds of effects a project can have on a BusinessApplication. Examples may include but are not limited to change, replace, remove. Project: A planned activity concerned with modifying one or more elements from the application landscape, mostly focused on BusinessApplications. Projects transform the application landscape. ProjectEffect: Indicates, which effect a project has on a specific BusinessApplication. 24 c TU München, sebis, 28. All rights reserved.

205 . Information Model Patterns (I-Patterns).14 I-Pattern I-8 I-Pattern Overview Id I-8 Name Changing Basic Technologies Alias Summary Version Solution Section Figure.14: Information Model I-8 ProjectProposal: A proposal for a project, with a description detailing the project proposal to a specific extent. BasicTechnology: A basic technology used in operating or developing business applications. Basic technologies relevant to operating business applications might include middleware, database management systems, or operating systems. Basic technologies used in development could encompass programming languages, frameworks, etc. This I-Pattern targets a different aspect of a ProjectProposal than I-Patterns I-5 and I-9. While these focus on, which BusinessApplications a ProjectProposal intends to target, this I-Pattern is focused on changing the usage of basic technologies, which is likely to describe the proposals at a less detailed level of granularity Consequence Section How to specifically count the number of BusinessApplications relying on a specific BasicTechnology depends on, how this I-Pattern is integrated in the whole information model. If the necessary BasicTechnologies are stored for each BusinessApplication, possibly also via ArchitecturalSolutions (see e.g. I-Pattern I-), numberofrelyingapplications can be defined as a derived attribute. If this is not the case, the values have to be collected in the organization, and updated if necessary. c TU München, sebis, 28. All rights reserved. 25

206 . Information Model Patterns (I-Patterns).15 I-Pattern I-9 I-Pattern Overview Id I-9 Name Planned Proposal Effects Alias Summary Version Solution Section Figure.15: Information Model I-9 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. ProjectProposal: A proposal for a project, with a description detailing the project proposal to a specific extent. ProjectProposalEffect: The planned/assumed effects a project, if conducted according to the respective proposal, is going to have. EffectType: Different kinds of effects a project can have on a BusinessApplication. Examples may include but are not limited to change, replace, remove. 2 c TU München, sebis, 28. All rights reserved.

207 . Information Model Patterns (I-Patterns).1 I-Pattern I-4 I-Pattern Overview Id I-4 Name Functionality Migration Alias Summary Version Solution Section BusinessApplication id : String name : String type : BusinessApplicationType 1 1 target * source * MigrationActivity sourcedate targetdate name : String 1 affects * «aufzählung» EffectType replace change introduce Milestone name : String date : Date isprojectgoal : Boolean effecttype : EffectType * has 1 Project name : String start : Date end : Date Figure.1: Information Model I-4 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. MigrationActivity: A migration activity describes the movement of functionality from one BusinessApplication to another. Project: A planned activity concerned with modifying one or more elements from the application landscape, mostly focused on BusinessApplications. Projects transform the application landscape. Milestone: A milestone marks defined points during the execution of a project, where certain project activities should be completed. Thus, the progress of the project can be measured. At a milestone a certain effect on a BusinessApplication may occur. c TU München, sebis, 28. All rights reserved. 27

208 . Information Model Patterns (I-Patterns).17 I-Pattern I-41 I-Pattern Overview Id I-41 Name Standard vs. Individual Software Alias Summary Version Solution Section BusinessApplication name : String id : String type : BusinessApplicationType BusinessApplicationType individual standard Figure.17: Information Model I-41 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. BusinessApplicationType: The BusinessApplicationType defines whether an business application system is individual or standard software. 28 c TU München, sebis, 28. All rights reserved.

209 . Information Model Patterns (I-Patterns).18 I-Pattern I-44 I-Pattern Overview Id I-44 Name Service Lifecycles Alias Summary Version Solution Section Project name : String start : Date end : Date status : ProjectStatus ProjectStatus planned active idea ProjectEffectService type : EffectType * * Service 1 versions * id : String name : String * EffectType - replacedservice replace change introduce replaceby ServiceVersion version : String startplanned endplanned startdevelopment enddevelopment startproduction endprocduction startretirement endretirement * - newservice Figure.18: Information Model I-44 Project: A planned activity concerned with modifying one or more elements from the application landscape, mostly focused on BusinessApplications. Projects transform the application landscape. ServiceVersion: A specific version of a Service, here meaning a specific release of this service. For versions, start and end dates of different lifecycle phases are recorded. ProjectEffectService: Indicates, which effect a project has on a specific Service. ProjectStatus: An enumeration of different states a project can be in. EffectType: Different kinds of effects a project can have on a BusinessApplication. Examples may include but are not limited to change, replace, remove. c TU München, sebis, 28. All rights reserved. 29

210 . Information Model Patterns (I-Patterns).19 I-Pattern I-4 I-Pattern Overview Id I-4 Name Business Objects and Business Object Types Alias Summary Version Solution Section Relationship name : String..1 owns * Attribute name : String isprimarykey : Boolean 1 has 2..* RelationshipEnd multiplicity : Multiplicity rolename : String * has 1 1..* owns..1 BusinessObject name : String Multiplicity 1 n * * Figure.19: Information Model I-4 Attribute: An attribute describes a property (e.g. name, description) of an element. BusinessObject: An BusinessObject represents a business entity (e.g. an invoice) that is used during the execution of a business process, which performs operations (CRUD) on the Business- Object. Multiplicity: A multiplicity specifies the number of possible occurrences of an element. Relationship: A relationship describes a connection between elements RelationshipEnd: A relationshipend specifies the multiplicity of elements that can be connected to it and defines the role name of the connected elements. 21 c TU München, sebis, 28. All rights reserved.

211 . Information Model Patterns (I-Patterns).2 I-Pattern I-47 I-Pattern Overview Id I-47 Name Name of I-Pattern Alias Summary Version Solution Section BusinessObject name : String 1 has owns 1 * Attribute name : String type : DataType * RelationshipEnd multiplicity : Multiplicity rolename : String 2..* has 1 Relationship name : String Multiplicity 1 n * * Figure.2: Information Model I-47 BusinessObject: An BusinessObject represents a business entity (e.g. an invoice) that is used during the execution of a business process, which performs operations (CRUD) on the Business- Object. DataType: A DataType specifies the type of data that can be represented in the value of a data element (e.g. String for characters). DetailedAttribute: A DetailedAttribute describes properties of an element. Contrary to a simple Attribute, a DetailedAttribute specifies not only the name of a property (e.g. description) but also the type of the property (e.g. String). Multiplicity: A multiplicity specifies the number of possible occurrences of an element. Relationship: A relationship describes a connection between elements RelationshipEnd: A relationshipend specifies the multiplicity of elements that can be connected to it and defines the role name of the connected elements. c TU München, sebis, 28. All rights reserved. 211

212 . Information Model Patterns (I-Patterns).21 I-Pattern I-48 I-Pattern Overview Id I-48 Name Business Object Flow Alias Summary Version Solution Section BusinessObject name : String BusinessProcess name : String 1 transfers * InformationFlow type : InformationFlowType supportsvia 1 * 1 supports * SupportRelationship Figure.21: Information Model I-48 BusinessObject: An BusinessObject represents a business entity (e.g. an invoice) that is used during the execution of a business process, which performs operations (CRUD) on the Business- Object. InformationFlow: Transfer of information between a BusinessApplication acting as a server, exposing functionality via an interface, and a client BusinessApplication, using this functionality. The type indicates the direction of the information transfer. BusinessProcess: According to [Krc5], defined as a sequence of logical individual functions with connections between them. [DFH] states input and output factors and a defined process objective as important characteristics of a business process. The business process should not be identified with single process steps or individual functions, but with high-level processes at a level similar to the one used in value chains. SupportRelationship: Represents the support of a process by a business application at a specific organizational unit. Basically, it constitutes, together with its three associations, a ternary relationship between BusinessProcess, OrganizationalUnit, and BusinessApplication. This is necessary in order to be able to tell exactly which organizational unit uses which business application to support a given process. 212 c TU München, sebis, 28. All rights reserved.

213 . Information Model Patterns (I-Patterns).22 I-Pattern I-51 I-Pattern Overview Id I-51 Name Process Overview Alias Summary Version Solution Section Figure.22: Information Model I-51 ApplicationComponent: Self-contained part of a system that encapsulates its content and exposes its functionality through a set of interfaces (definition from [JGBvB5]). BusinessFunction: Offers (related) functionality that may be useful for one or more business processes (definition from [JGBvB5]). BusinessProcess: According to [Krc5], defined as a sequence of logical individual functions with connections between them. [DFH] states input and output factors and a defined process objective as important characteristics of a business process. The business process should not c TU München, sebis, 28. All rights reserved. 21

214 . Information Model Patterns (I-Patterns) be identified with single process steps or individual functions, but with high-level processes at a level similar to the one used in value chains. BusinessActivity: An activity relevant to business, i.e. a BusinessProcess or a BusinessFunction. BusinessObject: An BusinessObject represents a business entity (e.g. an invoice) that is used during the execution of a business process, which performs operations (CRUD) on the Business- Object. BOUsage: Describes, how a BusinessActivity accesses certain kinds of BusinessObjects BOUsageType: Specifies the kind of interaction that is performed on an BusinessObject. Typical interaction types contain but are not limited to read or write. BusinessService: A coherent set of functionality that offers added value to the environment, independent of the way this functionality is realized internally (definition from [JGBvB5]). BusinessInteraction: Behaviour performed in a collaboration of two or more business roles (definition from [JGBvB5]). 214 c TU München, sebis, 28. All rights reserved.

215 . Information Model Patterns (I-Patterns).2 I-Pattern I-52 I-Pattern Overview Id I-52 Name High Level Information Flows Alias Summary Version Solution Section source 1 * InformationFlowProvider 1 destination * InformationFlow BusinessRole name : String 1 * BusinessFunction name : String responsible for Figure.2: Information Model I-52 BusinessFunction: Offers (related) functionality that may be useful for one or more business processes (definition from [JGBvB5]). BusinessRole: States which business behaviour is performed by a business actor that fulfils this role (definition from [JGBvB5]). InformationFlow: Transfer of information between a BusinessApplication acting as a server, exposing functionality via an interface, and a client BusinessApplication, using this functionality. The type indicates the direction of the information transfer. InformationFlowProvider: Abstract superclass that generalizes BusinessRole and BusinessFuntion and determines the information flow source and destination. c TU München, sebis, 28. All rights reserved. 215

216 . Information Model Patterns (I-Patterns).24 I-Pattern I-55 I-Pattern Overview Id I-55 Name Domains and Components Alias Summary Version Solution Section Domain name : String 1 partof * Component name : String Figure.24: Information Model I-55 Component: A component describes a part of a larger system (e.g. services). Domain: Describes a logical grouping into areas relevant to business, e.g. customer, products. 21 c TU München, sebis, 28. All rights reserved.

217 . Information Model Patterns (I-Patterns).25 I-Pattern I-5 I-Pattern Overview Id I-5 Name Infrastructure Usage Alias Summary Version Solution Section SystemSoftware name : String * * Device name : String relies 1 SystemSoftwareDeployment name : String * InfrastructureService name : String * uses * ApplicationComponent name : String Figure.25: Information Model I-5 ApplicationComponent: Self-contained part of a system that encapsulates its content and exposes its functionality through a set of interfaces (definition from [JGBvB5]). Device: A physical computational resource, upon which artifacts may be deployed for execution (definition from [JGBvB5]). InfrastructureService: Externally visible unit of functionality, provided by one or more nodes, exposed through well-defined interfaces, and meaningful to the environment (definition from [JGBvB5]). SystemSoftware: The software environment for specific types of components and data objects that are deployed on it in the form of artifacts (definition from [JGBvB5]). SystemSoftwareDeployment: Describes the actual deployment of a SystemSoftware. c TU München, sebis, 28. All rights reserved. 217

218 . Information Model Patterns (I-Patterns).2 I-Pattern I-57 I-Pattern Overview Id I-57 Name Proposed Changes Alias Summary Version Solution Section BusinessApplication id : String name : String influences * * name : String ProjectProposal estimatedprojectcosts : Money Figure.2: Information Model I-57 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. Project: A planned activity concerned with modifying one or more elements from the application landscape, mostly focused on BusinessApplications. Projects transform the application landscape. 218 c TU München, sebis, 28. All rights reserved.

219 . Information Model Patterns (I-Patterns).27 I-Pattern I-59 I-Pattern Overview Id I-59 Name Project Proposal Alias Summary Version Solution Section Figure.27: Information Model I-59 ProjectProposal: A proposal for a project, with a description detailing the project proposal to a specific extent. In order to support project portfolio management in selecting and budgeting projects, the project proposal is here augmented with various details: strategicimpactrating: The impact of the project in respect to the strategies of the organization, on a scale from -1 (adverse to all strategies) to +1 (fits to all strategies) environmentalimpactrating: Extent, to which the project is a suitable response to environmental influences (laws, regulations, standars, etc.) on the organization, on a scale from -1 (inappropriate reaction) to +1 (appropriate reaction) developmenteffort: Project effort in person months estimatedprojectcosts: The expected cost of the proposed project. expectedroi: The estimated return on investment for the proposed project. stddeviationofroi: The standard deviation of the above mentioned return of investment, as a measure of (financial) risk associated with the project. numberofaffectedbusinessapplications: The number of business applications the respective project is planned to affect in its execution. c TU München, sebis, 28. All rights reserved. 219

220 . Information Model Patterns (I-Patterns).27.2 Consequence Section While the details described above can be estimated ad-hoc, a more detailed I-Pattern for describing project proposals, can be found in I-Pattern I-8 (see Figure.41). 22 c TU München, sebis, 28. All rights reserved.

221 . Information Model Patterns (I-Patterns).28 I-Pattern I- I-Pattern Overview Id I- Name Interfaces and Information Flows Alias Summary Version Solution Section Figure.28: Information Model I- BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. InformationFlow: Transfer of information between a BusinessApplication acting as a server, exposing functionality via an interface, and a client BusinessApplication, using this functionality. The type indicates the direction of the information transfer. InformationFlowType: Direction of a data flow between client and server: read means, that data is read from the server, write that data is transferred to the server, and read/write encompasses both. Interface: An interface, via which a BusinessApplication can expose functionality for external usage. InterfaceType: Classifies different kinds of interfaces (e.g. online, offline, manual). c TU München, sebis, 28. All rights reserved. 221

222 . Information Model Patterns (I-Patterns).29 I-Pattern I-4 I-Pattern Overview Id I-4 Name Interfaces and Operations Alias Summary Version Solution Section Figure.29: Information Model I-4 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. Interface: An interface, via which a BusinessApplication can expose functionality for external usage. Operation: An operation offered for execution by an Interface, encapsulating a subset of the functionality offered by the Interface. 222 c TU München, sebis, 28. All rights reserved.

223 . Information Model Patterns (I-Patterns). I-Pattern I- I-Pattern Overview Id I- Name Name of I-Pattern Alias Summary Version Solution Section Figure.: Information Model I- ArchitecturalBlueprint: A description of a software architecture (e.g. a client-server architecture), using so-called AbstractTechnologies as components. AbstractTechnology: A class of technologies offering similar, or even standardized functionalities. Examples are Webserver (with specific technologies then being Apache 2..5 or IIS.) or Database Management System (DBMS) (with specific technologies then being DB2. or Oracle 9i). AbstractUsage: The usage of an AbstractTechnology in an ArchitecturalBlueprint. c TU München, sebis, 28. All rights reserved. 22

224 . Information Model Patterns (I-Patterns) Connector and ConnectorRole: A Connector is a runtime pathway of interaction between two or more AbstractTechnologies. A ConnectorRole identifies the role taken by the respective AbstractUsage in the interaction. ArchitecturalSolution: A concretization of an ArchitecturalBlueprint, created by selecting a specific Technology for each AbstractTechnology of the respective ArchitecturalBlueprint. An architectural solution thus describes a basic architecture for a business application, indicating of which components (technologies) it is made up, and how these interact. Technology: A specific technology implementing an AbstractTechnology (e.g. Apache 2..5, being a Webserver, or Oracle 9.2i being a Database Management System). Usage: Selection of an actual Technology for an AbstractUsage, in the context of a specific ArchitecturalSolution. For the subset of Usages belonging to one ArchitecturalSolution, each AbstractUsage of the corresponding ArchitecturalBlueprint has to be assigned exactly one Usage. AbstractUsages not belonging to this ArchitecturalBlueprint may not be referenced. Basically, a this is a structure as proposed by [CBB + 2] for the Component&Connector Viewtype. However, [CBB + 2] does not use distinguish between abstract and specific elements, as done here to support architectural standardization. 224 c TU München, sebis, 28. All rights reserved.

225 . Information Model Patterns (I-Patterns).1 I-Pattern I-7 I-Pattern Overview Id I-7 Name Demanded Architectural Solutions Alias Summary Version Solution Section Figure.1: Information Model I-7 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. ArchitecturalSolution: A concretization of an ArchitecturalBlueprint, created by selecting a specific Technology for each AbstractTechnology of the respective ArchitecturalBlueprint. An architectural solution thus describes a basic architecture for a business application, indicating of which components (technologies) it is made up, and how these interact. DemandedSolution: Assigns a prescribed ArchitecturalSolution to a BusinessApplication, and indicates, whether the BusinessApplication meets this demand. Besides, violating the demand, with appropriate reasons, can be allowed. For definition of ArchitecturalBlueprint, AbstractTechnology, and AbstractTechnologyUsage, see I-Pattern I-. c TU München, sebis, 28. All rights reserved. 225

226 . Information Model Patterns (I-Patterns).2 I-Pattern I-8 I-Pattern Overview Id I-8 Name Process Support by Service Alias Summary Version Solution Section Figure.2: Information Model I-8 BusinessProcess: According to [Krc5], defined as a sequence of logical individual functions with connections between them. [DFH] states input and output factors and a defined process objective as important characteristics of a business process. The business process should not be identified with single process steps or individual functions, but with high-level processes at a level similar to the one used in value chains. OrganizationalUnit: An organizational unit represents a subdivision of the organization according to its internal structure. A possible example are the entities showing up in an organigram. Service: A defined set of functionality used in executing a process (e.g. to support or automate process execution). SupportRelationship: Represents the support of a process by a Service at a specific organizational unit. Basically, it constitutes, together with its three associations, a ternary relationship between BusinessProcess, OrganizationalUnit, and Service. This is necessary in order to be able to tell exactly which organizational unit uses which Service to support a given process. 22 c TU München, sebis, 28. All rights reserved.

227 . Information Model Patterns (I-Patterns). I-Pattern I-9 I-Pattern Overview Id I-9 Name Service Versions Alias Summary Version Solution Section ServiceVersion version : String Service name : String 1 versions * startplaned : Date endplaned : Date startdevelopment : Date enddevelopment : Date startproduction : Date endprocduction : Date startretirement : Date endretirement : Date Figure.: Information Model I-9 Service: A defined set of functionality used in executing a process (e.g. to support or automate process execution). ServiceVersion: A specific version of a Service, here meaning a specific release of this service. For versions, start and end dates of different lifecycle phases are recorded. c TU München, sebis, 28. All rights reserved. 227

228 . Information Model Patterns (I-Patterns).4 I-Pattern I-7 I-Pattern Overview Id I-7 Name Changing Services Alias Summary Version Solution Section Service id : String name : String EffectType * replaceapplication changeapplication newapplication ProjectEffectService type : EffectType * Project name : String start : Date end : Date status : ProjectStatus Figure.4: Information Model I-7 EffectType: Different kinds of effects a project can have on a BusinessApplication. Examples may include but are not limited to change, replace, remove. Project: A planned activity concerned with modifying one or more elements from the application landscape, mostly focused on BusinessApplications. Projects transform the application landscape. ProjectEffectService: Indicates, which effect a project has on a specific Service. Service: A defined set of functionality used in executing a process (e.g. to support or automate process execution). 228 c TU München, sebis, 28. All rights reserved.

229 . Information Model Patterns (I-Patterns).5 I-Pattern I-75 I-Pattern Overview Id I-75 Name Deployment Details Alias Summary Version Solution Section InfrastructureSoftware name : String BusinessApplication name : String manifest 1 * DeployableArtifact name : String deployon * 1 * deployment 1 InfrastructureSoftwareDeployment * isconnectedto * 1 runson HardwareSystemType Mainframe * HardwareSystem name : String type : HardwareSystemType Figure.5: Information Model I-75 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. DeployableArtifact: Describes an artifact that can be deployed on an InfrastructureSoftware, in which a kind of BusinessApplication manifests. HardwareSystem: Describes a physical entity (e.g. server). HardwareSystemType: mainframe server). Specifies the different types a HardwareSystem may belong to (e.g. InfrastructureSoftware: Describes a type of software that provides infrastructure functionalities (e.g. applicationservers). InfrastructureSoftwareDeployment: Describes the deployment of an infrastructure software. c TU München, sebis, 28. All rights reserved. 229

230 . Information Model Patterns (I-Patterns). I-Pattern I-7 I-Pattern Overview Id I-7 Name Infrastructure Usage Alias Summary Version Solution Section InfrastructureComponent name : String BusinessApplication name : String id : String type : BusinessApplicationType * uses * id : String startintoduction endintroduction startproduction endproduction startphaseout endphaseout endofsupport Figure.: Information Model I-7 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. InfrastructureComponent: Infrastructure components are deployed middleware or hardware systems e.g. a database management system. 2 c TU München, sebis, 28. All rights reserved.

231 . Information Model Patterns (I-Patterns).7 I-Pattern I-79 I-Pattern Overview Id I-79 Name Call Sequences Alias Summary Version Solution Section BusinessProcess 1 supports * 1 employs * BusinessApplication 1 * SupportRelationship Activity subsets supportswith * startswith 1 1 supportsat 1 OrganizationalUnit issender isreceiver - {ordered} - {ordered} * * Message name : String AsynchronousMessage SynchronousMessage SynchronousResponse 1 1 isresponseof Figure.7: Information Model I-79 Activity: Describes the behavior of an element as a coordinated sequence of actions. AsynchronousMessage: Describes a message, which is exchanged asynchronously. Thereby, asynchronous means that no answer about the acceptance of messages are created. BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. BusinessProcess: According to [Krc5], defined as a sequence of logical individual functions with connections between them. [DFH] states input and output factors and a defined process objective as important characteristics of a business process. The business process should not c TU München, sebis, 28. All rights reserved. 21

232 . Information Model Patterns (I-Patterns) be identified with single process steps or individual functions, but with high-level processes at a level similar to the one used in value chains. Message: A message can be exchanged between different elements using synchronous or asynchronous communications. OrganizationalUnit: An organizational unit represents a subdivision of the organization according to its internal structure. A possible example are the entities showing up in an organigram. SupportRelationship: Represents the support of a process by a business application at a specific organizational unit. Basically, it constitutes, together with its three associations, a ternary relationship between BusinessProcess, OrganizationalUnit, and BusinessApplication. This is necessary in order to be able to tell exactly which organizational unit uses which business application to support a given process. SynchronousMessage: Describes a message, which is exchanged synchronously. Thereby, synchronous means that an answer about the acceptance of the message is created (see Synchronous- Response. SynchronousResponse: Describes the response to a message, which is exchanged synchronously. Thereby, synchronous means that an answer about the acceptance of the message is created (see SynchronousMessage. 22 c TU München, sebis, 28. All rights reserved.

233 . Information Model Patterns (I-Patterns).8 I-Pattern I-8 I-Pattern Overview Id I-8 Name Changing Business Applications and Interfaces Alias Summary Version Solution Section Figure.8: Information Model I-8 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. Interface: An interface, via which a BusinessApplication can expose functionality for external usage. c TU München, sebis, 28. All rights reserved. 2

234 . Information Model Patterns (I-Patterns).9 I-Pattern I-81 I-Pattern Overview Id I-81 Name Communicating Business Applications Alias Summary Version Solution Section BusinessApplication id : String name : String type : BusinessApplicationType 1 1 source destination InformationFlowType read write read/write * * InformationFlow type : InformationFlowType Figure.9: Information Model I-81 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. InformationFlow: Transfer of information between a BusinessApplication acting as a server, exposing functionality via an interface, and a client BusinessApplication, using this functionality. The type indicates the direction of the information transfer. InformationFlowType: Direction of a data flow between client and server: read means, that data is read from the server, write that data is transferred to the server, and read/write encompasses both. 24 c TU München, sebis, 28. All rights reserved.

235 . Information Model Patterns (I-Patterns).4 I-Pattern I-82 I-Pattern Overview Id I-82 Name Name of I-Pattern Alias Summary Version Solution Section BusinessApplication id : String name : String 1 1 uses offers * * Interface name : String uses * 1..* BusinessObject name : String Figure.4: Information Model I-82 BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. BusinessObject: An BusinessObject represents a business entity (e.g. an invoice) that is used during the execution of a business process, which performs operations (CRUD) on the Business- Object. Interface: An interface, via which a BusinessApplication can expose functionality for external usage. c TU München, sebis, 28. All rights reserved. 25

236 . Information Model Patterns (I-Patterns).41 I-Pattern I-8 I-Pattern Overview Id I-8 Name Project Proposal Details Alias Summary Version Solution Section Figure.41: Information Model I-8 ProjectProposal: A proposal for a project, with a description detailing the project proposal to a specific extent. The derived attributes of ProjectProposal (the attributes starting with a / ) are detailed below: 2 c TU München, sebis, 28. All rights reserved.

237 . Information Model Patterns (I-Patterns) strategicimpactrating: To derive this rating, the project is rated on a scale from -1 to +1 in respect to each Strategy, which here denotes a strategic goal relevant in the context of the application landscape. This is done via an ImpactOnStrategy. The overall strategicimpactrating for a ProjectPropsal is then derived by averaging these ratings. Descriptions should be attached to the ratings, to explicated their rationale. environmentalimpactrating: To derive this rating, the project is rated on a scale from -1 to +1 in respect to each EnvironmentalInfluence by a ResponseToInfluence. EnvironmentalInfluences are thereby regulations, laws, standards or other influences the organization has to react to, and which are also relevant in the context of the application landscape. The overall strategicimpactrating for a ProjectPropsal is then derived by averaging these ratings. Descriptions should be attached to the ratings, to explicated their rationale. estimatedprojectcosts, expectedroi, stddeviationofroi: These can be derived from a finance plan attached to the project, which details, when Payments are received or made due to the project (cash flows). FinancePlanScenario allows capturing insecurity, by providing different finance plans for different scenarios. numberofaffectedbusinessapplications: Can be derived via the affects-association. BusinessApplication: A business application is a software system, which is part of an information system of an organization. An information system is according to [Krc5] understood as a sociotechnical system, which is, besides the software system, made up of the infrastructure the software system is based on, and a social component, namely the employees or stakeholders concerned with it. Thereby, infrastructure and social component are not considered as belonging to the business application, while the characterization business restricts the term to applications that support at least one process of the respective organization. Thus, business application denotes here an acutal deployement of a software. Strategy: Defines a long term plan how, the an organization seeks to achieve its vision and mission. Thereby, a strategy does not define immediate actions or concrete resources required Consequence Section A simplified version of this information model fragment can be found in I-Pattern I-59 (see Section.27). c TU München, sebis, 28. All rights reserved. 27

238

239 APPENDIX A Evaluation of the Questionnaire A.1 Approach of the Evaluation M-Pattern and V-Pattern presented in Sections 4 and 5 have been selected into the catalog according to the results of an online questionnaire, which asked practitioners about their opinion concerning the M-Pattern and V-Pattern. This section explains the procedures and methods, which guided these selection, while Section A.2 presents the actual evaluation results, which guided the compilation of the pattern catalog. A.1.1 Selecting Methodologies For determining, whether an M-Pattern can be considered relevant enough to be included in the catalog, two tests were applied to each M-Pattern: Test 1 The share of practitioners considering the methodology relevant in the population has to be %. For testing this, we used an exact binomial test [FKPT99]. The null hypothesis H was The share of practitioners considering the M-Pattern relevant = %. Consequently, H 1 was The share of practitioners considering the M-Pattern relevant > %. The significance level α was set to α =.1. Test 2 The share of practitioners actually using the methodology should be bigger than 15%. Also this was tested via exact binomial tests, with H being The share of practitioners using the methodology = 15%, and H 1 being The share of practitioners using the methodology > 15%. The significance level was again α =.1. If for both tests, H was rejected, and thus H 1 accepted, the respective M-Pattern has been included in the pattern catalog. c TU München, sebis, 28. All rights reserved. 29

240 A. Evaluation of the Questionnaire If one or both tests resulted in H being accepted, we tested a special condition, to check whether to include an M-Pattern in spite of failing the above described procedure: Test To be able to override Test 1 and Test 2, an M-Pattern has to be the only one, which addresses a specific concern, which in turn has to demonstrate a rather high importance in the population. Concerns were rated by the practitioners in the online questionnaire on a scale from 1 (least important) to 5 (most important). Due to the rather small sample size, a t-test is not used to assess concern importance, instead, we used a sign test [FKPT99] 1 : H : The median importance rating of the concern in the population is H 1 : The median importance rating of the concern in the population is > α =.5 Thus, an M-Pattern being the only one addressing a concern, for which Test rejects H,is included in the catalog. Evaluation Results Table for M-Pattern For each M-Pattern presented to practitioners in the online survey, a table presenting a summary of the results according to the test procedure as introduced above is shown: (1) Test1: (4) Relevant: (2) Irrelevant: Test2: (4) Currently Potentially () Test: (4) Self (5) () (7) Include/Exclude Colleagues (8) (9) (1) Methodology (11) (12) Cell 1 Number of Responses Cell 2 How many percent of respondents opined that this method is relevant. Cell How many percent of respondents opined that this method is irrelevant. Cell 4 Whether the respective test was passed (H 1 accepted, or not). Cell 5 How many percent of respondents are currently using this method. Cell How many percent of respondents could imagine using this method. Cell 7 How many percent of respondents are currently using this method, or could imagine using it. Cell 8 How many percent of respondents opined that colleagues are using this method currently. Cell 9 How many percent of respondents imagine that their colleagues could use this method. Cell 1 How many percent of respondents opined that colleagues are currently using this method, or could imagine that their colleagues are using this method. Cell 11 How many percent of respondents are currently using this method, or opined that colleagues are currently using it. Cell 12 How many percent of respondents could imagine using this method or could imagine that their colleagues could use this method. 1 The sign test is referred to as Vorzeichentest in German. 24 c TU München, sebis, 28. All rights reserved.

241 A. Evaluation of the Questionnaire A.1.2 Viewpoints and Related Aspects In order to decide whether to include a viewpoint into the pattern catalog, it is examined, whether it helps in addressing a relevant concern. Thereby, two aspects are taken into consideration: Aspect 1: Viewpoint Portfolio Whether a viewpoint helps addressing a relevant concern can be characterized along two properties: Suitability of Viewpoint in addressing the concern Relevance of the concern Using this characterization, the evaluation results of can be visualized as Viewpoint Portfolio. Thereby, the four quadrants can be used to classify Viewpoints as Best Practice, Academic, Retains Potential for Improvement, and Rubbish, as shown in Figure A.1. Figure A.2 shows an exemplary bubble chart for a V-Pattern. Suitability of Viewpoint in Addressing Concern suitability Academic Rubbish Best Practice Retains Potential for Improvement Relevance of Concern Figure A.1: Classification of Viewpoints relevance Figure A.2: Exemplary bubble chart The size of each bubble indicates how many users have checked the respective combination of viewpoint suitability and concern relevance. c TU München, sebis, 28. All rights reserved. 241

242 suitability A. Evaluation of the Questionnaire Aspect 2: Competence of Statements In respect to the experience the respective user has in related matters, his or her statement may count more or less. This can be taken into account by distinguishing users by their answer to the question whether they conduct analyses addressing the concern under consideration. 2 Thus, the bubble chart is extended as shown in Figure A.: relevance Figure A.: Exemplary bubble chart showing highlighting the statements of experienced users The violet bubbles indicate, how many of the practitioners belonging to the subset actually addressing the concern have checked the respective cases (suitability from 1 (least suitable) to 5 (most suitable), relevance from 1 (least relevant) to 5 (most relevant)). Thereby, practitoner has been considered addressing the concern, if indicating one of the following statements: Yes, if necessary (Ja bei Bedarf), Yes, daily (Ja, täglich), Yes, weekly (Ja, wöchentlich), Yes, monthly (Ja, monatlich), Yes, each quarter (Ja, quartalsweise), Yes, yearly (Ja, jährlich). Thus, it can be revealed whether a viewpoint only appears helpful to an unexperienced user, or whether it is actually helpful. Statistical Testing on Viewpoint Bubble Charts A possible test procedure for determining whether a viewpoint actually belongs into the best practice category could determine, whether it is rated average relevance 4, average suitability 4 in the population. However, this would require normal distributed variables in the population. This should not be assumed here. A binomial test could show, where the number of users with (relevance a, suitability b) is significantly x% in the population. Such tests were conducted as follows: H : Share of practitioners in the population holding the opinion (relevance, suitability ) is 5%. H 1 : Share of practitioners in the population holding the opinion (relevance, suitability ) 5%. α =.1 Thereby, 5% is considerably more than the proportion, which could be expected if all users were equally distributed over the utility/relevance grid (,, =.). 2 Führen Sie entsprechende Analysen durch? in the German-language online questionnaire. 242 c TU München, sebis, 28. All rights reserved.

243 suitability suitability A. Evaluation of the Questionnaire A.2 Results of the Evaluation A.2.1 Analysis of Homogeneity of the Application Landscape (M-1) Number of Responses: 1 Test1: H1 accepted Relevant: 1% Irrelevant: Test2: H1 rejected Currently Potentially % Test: H1 rejected Self 1,1% 54,84% 7,97% Exclude Colleagues 29,% 22,58% 48,9% Methodology 45,1% 7,97% A.2.2 Analysis of Standard Conformity of the Application Landscape (M- 2) Number of Responses: Test1: H1 accepted Relevant: 9,% Irrelevant: Test2: H1 accepted Currently Potentially,7% Test: H1 - Self,%,%,% Include Colleagues 4,7% 1,% 5,7% Methodology,%,7% Concern C-2, Viewpoint V-5 Concern C-2, Viewpoint V- relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint c TU München, sebis, 28. All rights reserved. 24

244 suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-2, Viewpoint V-7 Concern C-5, Viewpoint V-2 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint Concern C-5, Viewpoint V- Concern C-5, Viewpoint V-7 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 rejected Exclude Viewpoint 244 c TU München, sebis, 28. All rights reserved.

245 suitability suitability suitability suitability A. Evaluation of the Questionnaire A.2. Management of Homogeneity (M-) Number of Responses: 28 Test1: H1 accepted Relevant: 9,4% Irrelevant: Test2: H1 rejected Currently Potentially,57% Test: H1 accepted Self 17,8% 57,14% 71,4% Include Colleagues 25,% 28,57% 4,4% Methodology 9,29% 7,8% Concern C-4, Viewpoint V-8 Concern C-5, Viewpoint V-5 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint Concern C-5, Viewpoint V-7 Concern C-5, Viewpoint V-9 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint c TU München, sebis, 28. All rights reserved. 245

246 suitability suitability suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-8, Viewpoint V-5 Concern C-8, Viewpoint V-7 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint Concern C-8, Viewpoint V-9 Concern C-8, Viewpoint V-41 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-9, Viewpoint V-8 Concern C-9, Viewpoint V-5 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 rejected Exclude Viewpoint 24 c TU München, sebis, 28. All rights reserved.

247 suitability suitability suitability A. Evaluation of the Questionnaire Concern C-9, Viewpoint V-7 relevance Test4: H1 accepted Include Viewpoint A.2.4 Management of Blueprint Conformity of the Application Landscape (M-4) Number of Responses: 27 Test1: H1 accepted Relevant: 92,59% Irrelevant: Test2: H1 accepted Currently Potentially 7,41% Test: H1 - Self 4,74%,% 7,7% Include Colleagues 4,74% 11,11% 48,15% Methodology 2,9% 7,4% Concern C-19, Viewpoint V-7 Concern C-11, Viewpoint V-7 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint c TU München, sebis, 28. All rights reserved. 247

248 suitability suitability suitability A. Evaluation of the Questionnaire Concern C-11, Viewpoint V-9 relevance Test4: H1 accepted Include Viewpoint A.2.5 Analysis of standard vs. individual software (M-1) Number of Responses: 27 Test1: H1 accepted Relevant: 92,59% Irrelevant: Test2: H1 rejected Currently Potentially 7,41% Test: H1 accepted Self 22,22% 44,44%,7% Include Colleagues 29,% 18,52% 48,15% Methodology 48,15% 51,85% Concern C-1, Viewpoint V-41 Concern C-1, Viewpoint V-42 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint 248 c TU München, sebis, 28. All rights reserved.

249 suitability suitability suitability A. Evaluation of the Questionnaire Concern C-1, Viewpoint V-45 relevance Test4: H1 accepted Include Viewpoint A.2. Analysis of the enterprise knowledge (M-5) Number of Responses: 27 Test1: H1 accepted Relevant: 81,48% Irrelevant: Test2: H1 rejected Currently Potentially 18,52% Test: H1 accepted Self 11,11% 4,74% 48,15% Include Colleagues 18,52%,% 51,85% Methodology 25,9% 59,2% Concern C-4, Viewpoint V-8 Concern C-4, Viewpoint V-22 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint c TU München, sebis, 28. All rights reserved. 249

250 suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-47, Viewpoint V-8 Concern C-47, Viewpoint V-22 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 rejected Exclude Viewpoint Concern C-48, Viewpoint V-8 Concern C-48, Viewpoint V-22 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 rejected Exclude Viewpoint 25 c TU München, sebis, 28. All rights reserved.

251 suitability suitability suitability suitability A. Evaluation of the Questionnaire A.2.7 Process Analysis (M-) Number of Responses: 2 Test1: H1 accepted Relevant: 9,15% Irrelevant: Test2: H1 rejected Currently Potentially,85% Test: H1 accepted Self 19,2% 19,2% 8,4% Include Colleagues 57,9% 4,2% 8,77% Methodology 5,8% 42,1% Concern C-54, Viewpoint V-11 Concern C-54, Viewpoint V-12 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint Concern C-55, Viewpoint V-11 Concern C-55, Viewpoint V-12 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 rejected Exclude Viewpoint c TU München, sebis, 28. All rights reserved. 251

252 suitability suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-55, Viewpoint V-17 Concern C-5, Viewpoint V-11 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint Concern C-5, Viewpoint V-12 Concern C-5, Viewpoint V-17 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint Concern C-57, Viewpoint V-12 relevance Test4: H1 rejected Exclude Viewpoint 252 c TU München, sebis, 28. All rights reserved.

253 A. Evaluation of the Questionnaire A.2.8 Analysis of the business processes in respect to customer needs (M-7) Number of Responses: 25 Test1: H1 rejected Relevant: 72,% Irrelevant: Test2: H1 rejected Currently Potentially 28,% Test: H1 - Self,% 2,% 2,% Exclude Colleagues 52,% 2,% 4,% Methodology 52,% 2,% A.2.9 Alignment to Product Strategies (M-8) Number of Responses: 25 Test1: H1 accepted Relevant: 7,% Irrelevant: Test2: H1 rejected Currently Potentially 24,% Test: H1 rejected Self,% 24,% 24,% Exclude Colleagues 4,%,% 8,% Methodology 4,% 48,% A.2.1 Process KPIs (M-9) Number of Responses: 25 Test1: H1 accepted Relevant: 8,% Irrelevant: Test2: H1 rejected Currently Potentially 2,% Test: H1 accepted Self 4,% 1,% 2,% Exclude Colleagues 5,% 24,% 72,% Methodology,% 2,% c TU München, sebis, 28. All rights reserved. 25

254 suitability suitability A. Evaluation of the Questionnaire A.2.11 Process Landscape Planning (M-12) Number of Responses: 25 Test1: H1 accepted Relevant: 84,% Irrelevant: Test2: H1 rejected Currently Potentially 1,% Test: H1 rejected Self 12,% 2,% 44,% Exclude Colleagues,%,% 4,% Methodology 48,% 48,% A.2.12 Analysis of the Application Landscape (M-1) Number of Responses: 2 Test1: H1 accepted Relevant: 1,% Irrelevant: Test2: H1 accepted Currently Potentially,% Test: H1 - Self 9,2% 2,92% 92,1% Include Colleagues 4,15% 15,8% 5,85% Methodology 88,4% 4,2% Concern C-, Viewpoint V-25 Concern C-, Viewpoint V-17 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint 254 c TU München, sebis, 28. All rights reserved.

255 suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-8, Viewpoint V-24 Concern C-8, Viewpoint V-17 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-87, Viewpoint V-17 Concern C-87, Viewpoint V-18 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint c TU München, sebis, 28. All rights reserved. 255

256 suitability suitability suitability suitability A. Evaluation of the Questionnaire A.2.1 Development of Plan and Target Landscapes (M-14) Number of Responses: 2 Test1: H1 accepted Relevant: 1,% Irrelevant: Test2: H1 accepted Currently Potentially,% Test: H1 - Self 5,% 8,4% 88,4% Include Colleagues 8,4% 2,8% 57,9% Methodology 7,8% 4,15% Concern C-4, Viewpoint V-24 Concern C-4, Viewpoint V-25 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 rejected Exclude Viewpoint Concern C-4, Viewpoint V-17 Concern C-4, Viewpoint V-2 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint 25 c TU München, sebis, 28. All rights reserved.

257 suitability suitability suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-4, Viewpoint V-4 Concern C-88, Viewpoint V-2 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-88, Viewpoint V-4 Concern C-5, Viewpoint V-24 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-5, Viewpoint V-25 Concern C-5, Viewpoint V-17 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 rejected Exclude Viewpoint c TU München, sebis, 28. All rights reserved. 257

258 suitability suitability A. Evaluation of the Questionnaire Concern C-5, Viewpoint V-2 Concern C-5, Viewpoint V-4 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint 258 c TU München, sebis, 28. All rights reserved.

259 suitability suitability suitability suitability A. Evaluation of the Questionnaire A.2.14 Management of the Application Lifecycle (M-15) Number of Responses: 2 Test1: H1 accepted Relevant: 95,15% Irrelevant: Test2: H1 accepted Currently Potentially,85% Test: H1 - Self 4,2% 5,% 84,2% Include Colleagues 4,15% 19,2% 5,85% Methodology 1,54% 5,85% Concern C-, Viewpoint V-2 Concern C-, Viewpoint V-27 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-, Viewpoint V-2 Concern C-, Viewpoint V- relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint c TU München, sebis, 28. All rights reserved. 259

260 suitability suitability suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-, Viewpoint V- Concern C-, Viewpoint V-4 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-89, Viewpoint V-27 Concern C-89, Viewpoint V- relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-89, Viewpoint V-4 Concern C-9, Viewpoint V-2 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint 2 c TU München, sebis, 28. All rights reserved.

261 suitability suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-9, Viewpoint V-27 Concern C-9, Viewpoint V-2 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint Concern C-9, Viewpoint V- Concern C-9, Viewpoint V- relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-9, Viewpoint V-4 relevance Test4: H1 rejected Exclude Viewpoint c TU München, sebis, 28. All rights reserved. 21

262 suitability suitability suitability suitability A. Evaluation of the Questionnaire A.2.15 Horizontal and vertical integration (M-18) Number of Responses: 2 Test1: H1 accepted Relevant: 84,2% Irrelevant: Test2: H1 accepted Currently Potentially 15,8% Test: H1 - Self 8,4% 2,92% 5,8% Include Colleagues 2,92% 2,92% 5,85% Methodology 5,% 8,4% Concern C-44, Viewpoint V-17 Concern C-44, Viewpoint V-28 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-44, Viewpoint V-29 Concern C-44, Viewpoint V- relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint 22 c TU München, sebis, 28. All rights reserved.

263 suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-8, Viewpoint V-17 Concern C-8, Viewpoint V-28 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 rejected Exclude Viewpoint Concern C-8, Viewpoint V-29 Concern C-8, Viewpoint V- relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 rejected Exclude Viewpoint c TU München, sebis, 28. All rights reserved. 2

264 suitability suitability suitability suitability A. Evaluation of the Questionnaire A.2.1 High Level Process Support (M-29) Number of Responses: 27 Test1: H1 accepted Relevant: 92,59% Irrelevant: Test2: H1 accepted Currently Potentially 7,41% Test: H1 - Self 25,9% 4,74% 2,9% Include Colleagues 44,44% 29,%,7% Methodology 55,5% 51,85% Concern C-78, Viewpoint V-28 Concern C-8, Viewpoint V-28 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-94, Viewpoint V-28 Concern C-95, Viewpoint V-28 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint 24 c TU München, sebis, 28. All rights reserved.

265 suitability suitability suitability suitability A. Evaluation of the Questionnaire A.2.17 Business Process Data Flow Analysis (M-) Number of Responses: 2 Test1: H1 accepted Relevant: 88,4% Irrelevant: Test2: H1 accepted Currently Potentially 11,54% Test: H1 - Self 2,92% 5,85% 7,92% Include Colleagues 2,92% 4,2% 57,9% Methodology 42,1% 57,9% Concern C-78, Viewpoint V-48 Concern C-8, Viewpoint V-48 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint Concern C-94, Viewpoint V-48 Concern C-95, Viewpoint V-48 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 rejected Exclude Viewpoint c TU München, sebis, 28. All rights reserved. 25

266 suitability suitability A. Evaluation of the Questionnaire Concern C-94, Viewpoint V-48 Concern C-95, Viewpoint V-48 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 rejected Exclude Viewpoint A.2.18 Process Data Flow Analysis (M-2) Number of Responses: 2 Test1: H1 accepted Relevant: 88,4% Irrelevant: Test2: H1 rejected Currently Potentially 11,54% Test: H1 - Self 2,8% 5,% 7,8% Exclude Colleagues 8,4% 4,2% 5,8% Methodology 5,% 57,9% 2 c TU München, sebis, 28. All rights reserved.

267 suitability A. Evaluation of the Questionnaire A.2.19 Strategic Conformance Analysis of the Project Portfolio (M-24) Number of Responses: 25 Test1: H1 accepted Relevant: 84,% Irrelevant: Test2: H1 accepted Currently Potentially 1,% Test: H1 - Self 2,% 4,% 8,% Include Colleagues 4,% 28,%,% Methodology 52,% 44,% Concern C-91, Viewpoint V- relevance Test4: H1 accepted Include Viewpoint c TU München, sebis, 28. All rights reserved. 27

268 suitability suitability suitability suitability A. Evaluation of the Questionnaire A.2.2 Decision for Project Approval (M-2) Number of Responses: 25 Test1: H1 accepted Relevant: 7,% Irrelevant: Test2: H1 rejected Currently Potentially 24,% Test: H1 accepted Self 2,% 24,% 4,% Include Colleagues 44,% 24,% 4,% Methodology 5,% 2,% Concern C-29, Viewpoint V-5 Concern C-29, Viewpoint V-57 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-29, Viewpoint V-59 Concern C-29, Viewpoint V- relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint 28 c TU München, sebis, 28. All rights reserved.

269 suitability suitability suitability A. Evaluation of the Questionnaire Concern C-29, Viewpoint V-1 relevance Test4: H1 accepted Include Viewpoint A.2.21 Monitoring of the Project Portfolio (M-25) Number of Responses: 25 Test1: H1 rejected Relevant: 72,% Irrelevant: Test2: H1 rejected Currently Potentially 28,% Test: H1 accepted Self 24,% 24,% 48,% Include Colleagues 4,% 1,% 52,% Methodology 5,% 28,% Concern C-92, Viewpoint V-1 Concern C-92, Viewpoint V-57 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint c TU München, sebis, 28. All rights reserved. 29

270 suitability A. Evaluation of the Questionnaire Concern C-92, Viewpoint V-59 relevance Test4: H1 accepted Include Viewpoint A.2.22 Alignment of Project Portfolio to Organizational Skills (M-28) Number of Responses: 25 Test1: H1 rejected Relevant: 72,% Irrelevant: Test2: H1 rejected Currently Potentially 28,% Test: H1 rejected Self 4,% 2,%,% Exclude Colleagues 12,% 5,% 8,% Methodology 12,%,% A.2.2 Infrastructure Lifecycle Analysis (M-) Number of Responses: 2 Test1: H1 accepted Relevant: 9,15% Irrelevant: Test2: H1 rejected Currently Potentially,85% Test: H1 rejected Self 2,8% 2,8% 4,15% Exclude Colleagues 42,1% 8,4% 7,8% Methodology 57,9% 5,% 27 c TU München, sebis, 28. All rights reserved.

271 suitability suitability suitability suitability A. Evaluation of the Questionnaire A.2.24 Infrastructure Failure Impact Analysis (M-4) Number of Responses: 2 Test1: H1 accepted Relevant: 88,4% Irrelevant: Test2: H1 rejected Currently Potentially 11,54% Test: H1 accepted Self 15,8% 2,92% 8,4% Include Colleagues 42,1% 8,4% 7,92% Methodology 5,% 4,15% Concern C-41, Viewpoint V-5 Concern C-41, Viewpoint V-75 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint Concern C-41, Viewpoint V-7 Concern C-98, Viewpoint V-5 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint c TU München, sebis, 28. All rights reserved. 271

272 suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-98, Viewpoint V-75 Concern C-98, Viewpoint V-7 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint A.2.25 Management of Business Objects (M-19) Number of Responses: 25 Test1: H1 accepted Relevant: 9,% Irrelevant: Test2: H1 accepted Currently Potentially 4,% Test: H1 - Self 2,% 44,% 7,% Include Colleagues 4,% 2,% 8,% Methodology,% 48,% Concern C-51, Viewpoint V-48 Concern C-51, Viewpoint V-49 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint 272 c TU München, sebis, 28. All rights reserved.

273 suitability suitability suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-51, Viewpoint V-51 Concern C-51, Viewpoint V-52 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-51, Viewpoint V-82 Concern C-52, Viewpoint V-4 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-52, Viewpoint V-47 Concern C-1, Viewpoint V-48 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint c TU München, sebis, 28. All rights reserved. 27

274 suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-1, Viewpoint V-49 Concern C-1, Viewpoint V-51 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint Concern C-1, Viewpoint V-52 Concern C-1, Viewpoint V-82 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint 274 c TU München, sebis, 28. All rights reserved.

275 suitability suitability suitability suitability A. Evaluation of the Questionnaire A.2.2 Management of Business Services and Domains (M-2) Number of Responses: 25 Test1: H1 accepted Relevant: 1,% Irrelevant: Test2: H1 accepted Currently Potentially,% Test: H1 - Self 2,%,% 8,% Include Colleagues 4,%,% 7,% Methodology 5,% 52,% Concern C-2, Viewpoint V-55 Concern C-4, Viewpoint V-47 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint Concern C-4, Viewpoint V-55 Concern C-4, Viewpoint V-48 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint c TU München, sebis, 28. All rights reserved. 275

276 suitability suitability suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-4, Viewpoint V-18 Concern C-5, Viewpoint V-48 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint Concern C-5, Viewpoint V-18 Concern C-5, Viewpoint V-5 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-, Viewpoint V-8 Concern C-, Viewpoint V-18 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint 27 c TU München, sebis, 28. All rights reserved.

277 suitability suitability suitability suitability A. Evaluation of the Questionnaire A.2.27 Management of Interfaces (M-21) Number of Responses: 2 Test1: H1 accepted Relevant: 9,15% Irrelevant: Test2: H1 accepted Currently Potentially,85% Test: H1 - Self 42,1% 2,92% 9,2% Include Colleagues 4,15% 2,92% 7,8% Methodology 9,2% 8,4% Concern C-7, Viewpoint V- Concern C-7, Viewpoint V-4 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-7, Viewpoint V-48 Concern C-7, Viewpoint V-79 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint c TU München, sebis, 28. All rights reserved. 277

278 suitability suitability suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-7, Viewpoint V-81 Concern C-8, Viewpoint V-48 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-8, Viewpoint V- Concern C-8, Viewpoint V-79 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint Concern C-1, Viewpoint V-48 Concern C-1, Viewpoint V-52 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint 278 c TU München, sebis, 28. All rights reserved.

279 suitability suitability suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-1, Viewpoint V-79 Concern C-7, Viewpoint V- relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint Concern C-7, Viewpoint V-4 Concern C-7, Viewpoint V-48 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint Concern C-7, Viewpoint V-79 Concern C-7, Viewpoint V-81 relevance relevance Test4: H1 rejected Exclude Viewpoint Test4: H1 accepted Include Viewpoint c TU München, sebis, 28. All rights reserved. 279

280 suitability suitability suitability suitability A. Evaluation of the Questionnaire Concern C-99, Viewpoint V-8 Concern C-99, Viewpoint V-81 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint A.2.28 Service Lifecycle Management (M-22) Number of Responses: 2 Test1: H1 accepted Relevant: 8,77% Irrelevant: Test2: H1 rejected Currently Potentially 19,2% Test: H1 accepted Self 11,54% 8,4% 5,% Include Colleagues 2,8% 8,4% 1,54% Methodology 2,92% 57,9% Concern C-71, Viewpoint V-9 Concern C-71, Viewpoint V-44 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 accepted Include Viewpoint 28 c TU München, sebis, 28. All rights reserved.

281 suitability suitability suitability A. Evaluation of the Questionnaire Concern C-71, Viewpoint V-7 Concern C-72, Viewpoint V-9 relevance relevance Test4: H1 accepted Include Viewpoint Test4: H1 rejected Exclude Viewpoint Concern C-72, Viewpoint V-44 relevance Test4: H1 rejected Exclude Viewpoint c TU München, sebis, 28. All rights reserved. 281

282 A. Evaluation of the Questionnaire A.2.29 Management of Service Levels Agreements (SLA) (M-2) Number of Responses: 25 Test1: H1 accepted Relevant: 88,% Irrelevant: Test2: H1 rejected Currently Potentially 12,% Test: H1 rejected Self 12,% 2,% 28,% Exclude Colleagues 5,%,% 88,% Methodology 5,% 4,% A.2. Service Dependency Analysis (M-1) Number of Responses: 25 Test1: H1 accepted Relevant: 92,% Irrelevant: Test2: H1 rejected Currently Potentially 8,% Test: H1 rejected Self 12,% 4,% 52,% Exclude Colleagues 2,% 4,% 72,% Methodology,%,% 282 c TU München, sebis, 28. All rights reserved.

283 APPENDIX B Excluded EAM Patterns This section includes all EAM patterns, sorted by EAM pattern type, that have been categorized as not relevant for inclusion into the EAM Pattern Catalog by the online questionnaire. B.1 Excluded M-Patterns B.1.1 Analysis of the business processes in respect to customer needs (M-7) M-Pattern Overview Id M-8 Name Analysis of the business processes in respect to customer needs This M-Pattern enables high level analysis on how far the business processes are aligned to the customers and the services they use and need. It is targeted at employees who are responsible for the relationship between the organization and its customers. The M-Pattern allows analyzing, to what extent the processes are designed to achieve effective and efficient customer relationships. B.1.2 Alignment of the business processes to product policy (M-8) M-Pattern Overview Id M-8 Name Alignment of the business processes to product policy This M-Pattern enables high level analysis on how far the business processes are aligned to the products offered by the organisation. The M-Pattern is targeted at employees responsible for the product policy of the organization. c TU München, sebis, 28. All rights reserved. 28

284 B. Excluded EAM Patterns B.1. Process KPIs (M-9) M-Pattern Overview Id M-9 Name Process KPIs The M-Pattern helps to operationalize strategies via goals and metrics. Thereby, it focuses on the process-related aspects of executing a strategy. The M-Pattern defines measurable goals (key performance indicators and target values) for the business processes, for use in the context of process management. The achievement of the goals should be controlled by checking whether the target values have been reached at the milestones they are supposed to. B.1.4 Planning the Process Landscape (M-12) M-Pattern Overview Id M-12 Name Planning the Process Landscape This M-Pattern is based on existing analyses of the process landscape, on which it builds plans for the future development of the process landscape, like visions or change proposals. It is meant to support the evolution of the process landscape. B.1.5 Management of Service Levels Agreements (SLA) (M-2) M-Pattern Overview Id M-2 Name Management of Service Levels Agreements (SLA) This M-Pattern is concerned with the management of service level agreements (SLAs), i.e. the contract based arrangements about the provision of services. Thereby, offered and used services, including both enterprise-internal and enterprise-external services should be taken into account. B.1. Alignment of the Project Portfolio to Organizational Skills (M-28) M-Pattern Overview Id M-28 Name Alignment of the Project Portfolio to Organizational Skills This M-Pattern analyzes the knowledge needs arising from projects. 284 c TU München, sebis, 28. All rights reserved.

285 B. Excluded EAM Patterns B.1.7 Service Dependency Analysis (M-1) M-Pattern Overview Id M-1 Name Service Dependency Analysis This M-Pattern is concerned with the connections and dependencies between services which arise from mutual use. B.1.8 Detailled Analysis of Process Support (M-2) M-Pattern Overview Id M-2 Name Detailled Analysis of Process Support This M-Pattern helps to analyze the support of specific processes by the application landscape. Instead of analyising the complete application landscape with all its processes, this methodology focuses explicit on a specific process. Also the risks which arise from this support are evaluated. To do so, the methodology examines the process definition in detail. B.1.9 Infrastructure Lifecycle Analysis (M-) M-Pattern Overview Id M- Name Infrastructure Lifecycle Analysis This M-Pattern helps to analyze the support of specific processes by the application landscape. Instead of analyising the complete application landscape with all its processes, this methodology focuses explicit on a specific process. Also the risks which arise from this support are evaluated. To do so, the methodology examines the process definition in detail. c TU München, sebis, 28. All rights reserved. 285

286 B. Excluded EAM Patterns B.2 Excluded V-Patterns B.2.1 Viewpoint V-1 V-Pattern Overview Id V-1 Name Alias Summary Version 1. Used Programming Languages for Business Applications This V-Pattern visualizes the used programming languages for the shown business applications. Solution Section Visualization of homogeneity aspects, e.g. the used infrastructure, technologies, or programming languages on a layer on software maps. Figure B.1 shows an example for an homogeneity layer on a cluster map. Homogeneity information can easily be visualized via a layer on a software map, e.g. a process support or a cluster map. The homogeneity layer may be applied on e.g. the following software maps: 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 The information on which technologies, infrastructure, or programming language a business application relies on can be visualized in different ways, which are listed below: Color: The representation (or representations) of a business application can be overlayed with a symbol exhibiting exactly the same shape, but using its color to indicate a technology, infrastructure, or programming language. However, this possibility is of limited use, as only a limited number of colors can be easily distinguished by the user, and the visualization is limited to indicating one element at a time (or layer). Symbols: Each programming language, technology, or infrastructure is visualized by a distinct symbol. For each business application the respective symbols the business application relies on, are displayed on the symbol representing the business application (see Figure B.1 for an example). Text: The names of the programming languages, technologies, and infrastructures on which a business application relies can be displayed in the symbol representing the respective business application, possibly in compartments. 28 c TU München, sebis, 28. All rights reserved.

287 B. Excluded EAM Patterns 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) 1.1 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 Supplier Management Relationship (Germany/ Management Hamburg) (182) System (12) Price Tag Printing System (Great Britain) (175) Costing System () Financial Planning System (14) Campaign Management System (15) 1.1 Customer Relationship Management System (21) Worktime Management (Great Britain) (185) Legend Map Symbols A Organizational Unit Visualization Rules A B (1) Business Application (with id) Programming Languages 1.4 Java 1.4 LISP Perl B (1) C (2) Organizational Unit (A) hosting Business Application (C) 1. Java 1. C++ Ocaml 1.1 Cobol.NET 1.1 Ada FORTRAN D () Business Application (D) based on Programming Language Figure B.1: Viewpoint V-1 c TU München, sebis, 28. All rights reserved. 287

288 B. Excluded EAM Patterns B.2.2 Viewpoint V-2 V-Pattern Overview Id V-2 Name Alias Summary Version 1. Number of used Programming Languages - Bar Chart This V-Pattern visualizes the number of usages of programming languages, which have been used to implement the business applications of the application landscape. Solution Section g Language Programming.NET 1.1 Java 1.4 Java 1. Ocaml Perl Cobol LISP FORTRAN Ada C++ Eiffel.NET 2..NET 1. Java 1.5 Number of Business Applications using Programming Language Number of Business Applications using Programming Language Figure B.2: Viewpoint V-2 Insights into homogeneity aspects can be given by a bar chart visualization of the number of times a technology, infrastructure, or programming language is used. Therefore, for each technology, infrastructure, and programming language, it is counted how many business applications actually rely on the respective element. This data can easily be visualized in bar charts as shown in Figure B.2 with the number of usages on the x-axis and the respective counts on the y-axis. Thereby, we propose ordering the elements on x-axis by decreasing usage count. 288 c TU München, sebis, 28. All rights reserved.

289 B. Excluded EAM Patterns Variations: Basically many variations of the visualization as described above are possible, with the possibilities demonstrated by spreadsheet applications as Microsoft Excel, and the needs motivated by the exact goals of the employees using the transparency provided by the V-Pattern. Some variations are: Pie charts could be employed, to give an improved overview of the relations of the usages of the different elements All elements (technology, infrastructure, programming language) can be represented in one diagram c TU München, sebis, 28. All rights reserved. 289

290 B. Excluded EAM Patterns B.2. Viewpoint V-7 V-Pattern Overview Id V-7 Name Alias Summary Version 1. Distribution of Architectural Solutions This V-Pattern visualizes the business applications conforming to architectural solutions. Solution Section Distribution of Architectural Solutions ArchSol1a % ArchSol1b 4% ArchSol2a % ArchSol2b 7% No Conformance 57% ArchSol 29% ArchSol1a ArchSol1b ArchSol2a ArchSol2b ArchSol No Conformance Figure B.: Viewpoint V-7 For each ArchitecturalSolution s or ArchitecturalBlueprint b, it can be counted how many business applications instances reference s (subsequently called b(s)), or an ArchitecturalSolution that in turn is realized by b (subsequently called b(b)): Such information can be visualized in a pie chart giving an overview of the proportion of the AbstractBusinessApplication instances relying on certain blueprints/solutions (see Figure B.). Variations: Usage of other diagram types is possible, and can be advisable depending on the usage context. Bar charts can be used, showing the ArchitecturalSolutions or Blueprints on the x-axis, and b(s) or b(b) as the height of the bars. 29 c TU München, sebis, 28. All rights reserved.

291 B. Excluded EAM Patterns B.2.4 Viewpoint V-11 V-Pattern Overview Id V-11 Name Alias Summary Version 1. Triggered Business Processes by Business Events This V-Pattern gives an overview of the business events and the business processes they trigger. Solution Section Request for information Request for information Inform intermediary Inform Customer Request for insurance Close Contract Collect Premium Damage occured Handle Claim Opportunity needed Develop Product Manage Assets Legend Map Symbols Visualization Rules B Business Event B C Business Process (C) reacts to Business Event (B) C Business Process C B Business Process (C) produces Business Event (B) C C Successor Relationship between Business Processes (C) and (D) Figure B.4: Viewpoint V-11 This V-Pattern gives an overview of the business events and the business processes they trigger. c TU München, sebis, 28. All rights reserved. 291

292 B. Excluded EAM Patterns B.2.5 Viewpoint V-1 V-Pattern Overview Id V-1 Name Alias Summary Version 1. Business Services, Business Processes, and Roles This V-Pattern shows the relationships between business processes, the services they offer, and the roles using the services. Access channels can also be shown. Solution Section Customer Store Indirect Sales Call Center Insurance application service Individual Contact Call Center Claim registration service Claims payment service Store Internet Individual Contact Customer information service Internet Premium payment service Call Center Close Contract Handle Claim Inform Customer Collect Premium Legend Map Symbols Visualization Rules A Business Role B A Business Service (B) is used by Business Rols (A) B Business Service C B Business Service (B) is generated by Business Process (C) C Business Process D E Incoming Unidirectional Communication Outgoing Unidirectional Communication D B Business Service (B) uses Unidirectional Communication (D) F Bidirectional Communication Figure B.5: Viewpoint V-1 This V-Pattern shows the relationships between business processes, the services they offer, and the roles using the services. Access channels can also be shown. 292 c TU München, sebis, 28. All rights reserved.

293 B. Excluded EAM Patterns B.2. Viewpoint V-14 V-Pattern Overview Id V-14 Name Alias Summary Version 1. Business Processes and their Access Channels This V-Pattern shows business processes and the access channels (marketing channels) via which these processes can be accessed from outside the organization. Solution Section Store Individual Contact Call Center Indirect Sales Store Internet Call Center Internet Close Contract Handle Claim Inform Customer Collect Premium Individual Contact Call Center Legend Map Symbols Visualization Rules A Business Process E C Incoming Distribution Channel (E) for Business Process (C) E Incoming Distributive Channel F G Outgoing Distributive Channel Bidrectional Distributive Channel F C Outgoing Distribution Channel (F) for Business Process (C) G B Bidirectional Communication Channel (G) for Business Process (B) Figure B.: Viewpoint V-14 This V-Pattern shows business processes and the access channels (marketing channels) via which these processes can be accessed from outside the organization. c TU München, sebis, 28. All rights reserved. 29

294 B. Excluded EAM Patterns B.2.7 Viewpoint V-15 V-Pattern Overview Id V-15 Name Alias Summary Version 1. Product and Business Value Overview This V-Pattern shows the relationships of a business role (e.g. customer) and the value it obtains by using a product offered by the organization under consideration. The product is thereby represented as a set of services and contracts. Solution Section Customer "be insured" (security) Travel Insurance Insurance application service Premium payment service Customer data mutation service Insurance policy Claim registration service Customer information service Claims payment service Legend Map Symbols Visualization Rules A Business Role C E Product (C) is governed by Contract (E) B Business Value C C Product D Product (C) consists of Business Service (D) D Business Service B C Product (C) Delivers Business Value (B) E Contract A B Business Role (A) obtains Business Value (B) Figure B.7: Viewpoint V-15 This V-Pattern shows the relationships of a business role (e.g. customer) and the value it obtains by using a product offered by the organization under consideration. The product is thereby represented as a set of services and contracts. 294 c TU München, sebis, 28. All rights reserved.

295 B. Excluded EAM Patterns B.2.8 Viewpoint V-1 V-Pattern Overview Id V-1 Name Performance Metrics for Business Processes Alias Summary This V-Pattern visualizes a performance metric for business processes. Version 1. Solution Section Acquisition Warehousing Distribution Headquarter Customer Relationship Management System (21) Online Shop (1) Subsidiary Munich Subsidiary Hamburg Inventory Control System (2) Monetary Transaction System (Germany) () Price Tag Printing System (Germany/ Munich) (17) Price Tag Printing System (Germany/ Hamburg) (172) Inventory Control System (2) Campaign Management System (15) POS System (Germany/Munich) (1) POS System (Germany/ Hamburg) (12) Customer Complaint System (19) Monetary Transaction System (Germany) () Subsidiary London Monetary Transaction System (Great Britain) (5) Price Tag Printing System (Great Britain) (175) POS System (Great Britain) (15) Monetary Transaction System (Great Britain) (5) Warehouse Monetary Transaction System (Germany) () Product Shipment System (Germany) (4) Legend Map Symbols Visualization Rules A B (1) C 1% % Business Process A Business Application B with Id 1 Organizational Unit C Average Cycle Time in Q1 25 C A Vertical Alignment A Horizontal Alignment B (1) Horizontal Alignment Horizontal Alignment D Business Process (A) is supported by Business Application (B) and used at Organizational Unit (C) Business Processes (A) and (D) are supported by Business Application (B) (Horizontal Integration) C E A B Ordering B (1) Vertical Alignment Business Process (A) is a predecessor of (B) Business Application (B) is used at Organizational Unit (C) (Vertical Integration) B (1) Figure B.8: Viewpoint V-1 This V-Pattern visualizes a performance metric for business processes on a process support map by coloring the respective processes. As a basis for this V-Pattern, V-28, V-29, or V- can be used. c TU München, sebis, 28. All rights reserved. 295

296 B. Excluded EAM Patterns B.2.9 Viewpoint V-19 V-Pattern Overview Id V-19 Name Alias Summary Version 1. Business Services provided by Applications and used by Processes This V-Pattern shows, aspects of the relationships between business processes, business roles (e.g. customers), and business applications. Solution Section This V-Pattern shows, aspects of the relationships between business processes, business roles (e.g. customers), and business applications. The diagram visualizes the services offered by the processes, how different roles use this services, and what business applications support the processes in providing the services. 29 c TU München, sebis, 28. All rights reserved.

297 B. Excluded EAM Patterns Client ArchiSurance Claim registration Customer information Claims payment Handle Claim Register Accept Valuate Pay CRM application Policy administration Financial application Legend Map Symbols Visualization Rules A Business Role D C Business Process (C) is a sub Business Process of (D) B C Business Service Business Process A C B D Business Process (A) exposes Business Service (B) Successor Relationship between Business Processes (C) and (D) E Business Application E F Business Application (E) has Interconnection to Business Application (F) E C Business Application (E) supports Business Process (C) A D Business Role (A) has Business Process (D) A B Business Role (A) uses Business Service (B) Figure B.9: Viewpoint V-19 c TU München, sebis, 28. All rights reserved. 297

298 B. Excluded EAM Patterns B.2.1 Viewpoint V-2 V-Pattern Overview Id V-2 Name Usage of Services and Business Roles Alias Summary This V-Pattern shows, how services are used by business roles (e.g. customer). Version 1. Solution Section This V-Pattern shows, how services are used by business roles (e.g. customer). It shows, how these services are provides by business processes, which in turn rely on the support by business applications. In addition, the diagram shows planned changes, e.g. a replacement of a business application. 298 c TU München, sebis, 28. All rights reserved.

299 B. Excluded EAM Patterns Client ArchiSurance Claim registration Customer information Claims payment Handle Claim Register Accept Valuate Pay CRM application Policy administration Accounting Legend Map Symbols Visualization Rules A Business Role D C Business Process (C) is a sub Business Process of (D) B C Business Service Business Process A C B D Business Process (A) exposes Business Service (B) Successor Relationship between Business Processes (C) and (D) E Business Application Status of Business Application New Business F Application E E C F Business Application (E) has Interconnection to Business Application (F) Business Application (E) supports Business Process (C) F Business Application is modified A D Business Role (A) has Business Process (D) F Business Application is replaced by another Business Application A B Business Role (A) uses Business Service (B) Figure B.1: Viewpoint V-2 c TU München, sebis, 28. All rights reserved. 299

300 B. Excluded EAM Patterns B.2.11 Viewpoint V-21 V-Pattern Overview Id V-21 Name Alias Summary Version 1. Strategies and Goals Fulfillment This V-Pattern shows the relationships between strategies and goals, and the extent to which they are met. Solution Section Utilizing economies of scale Gaining market leadership Strategy Increase negotiating power Be a quality supplier Goal #Suppliers 15 1 Acquisition AvItems Warehouse 8 95 AvResTime 15 1 Distribution Process Legend Legend Visualization Rules A B Business Process Information Object A C 15 1 Metric (C) is assigned to Business Process (A) C 15 1 Target & Current Value for a Metric Current value Target value B B D Information Object (B) belongs to Swimlane (D) E Information Object (B) is connected with Information Object (D) B C 15 1 Information Object (B) is connected with Metric (C) Figure B.11: Viewpoint V-21 This V-Pattern shows the relationships between strategies and goals, and the extent to which they are met. This is shown using the affected processes as a base map. c TU München, sebis, 28. All rights reserved.

301 B. Excluded EAM Patterns B.2.12 Viewpoint V-22 V-Pattern Overview Id V-22 Name Alias Summary Version 1. Knowledge Distributions This V-Pattern visualizes the organizational distribution of different knowledge, concerning technologies, programming languages, etc. Solution Section Java 1.4 Java 1.4 Java 1.4 Java 1. Java 1. Java 1. Garching.NET 1.1 Cobol.NET 1.1 Hamburg Perl Munich.NET 1.1 Ada LISP Perl Java 1.4 FORTRAN LISP Cobol London C++.NET 1.1 Ocaml Ocaml Legend Map Symbols Visualization Rules A Organizational Unit Degree of Coverage 1% A B Available Knowledge (B) in Orgnizational Unit (A) B Programming Language 75% 5% B Coverage of Knowledge (B) 25% Figure B.12: Viewpoint V-22 This V-Pattern visualizes the organizational distribution of different knowledge, concerning technologies, programming languages, etc. Figure B.12 shows an example of a knowledge map visualizing OrganizationalUnits as double bordered ellipses, the programming languages as thought bubbles and a graphical representation of the degree of coverage. c TU München, sebis, 28. All rights reserved. 1

302 B. Excluded EAM Patterns B.2.1 Viewpoint V-42 V-Pattern Overview Id V-42 Name Alias Summary Version 1. Distributions of Standard vs. Individual Software Overview This V-Pattern visualizes business applications clustered according to their type (standard vs. individual software). Solution Section Individual Software Standard Software Online Shop (1) Inventory Control System (2) Monetary Transactions System (Great Britain) (5) Product Shipment System (Germany) (4) Costing System () Monetary Transactions System (Germany) () Accounting System (5) Data Warehouse (8) Human Resources System (7) Fleet Management System (9) Business Traveling System (1) Supplier Relationship Management System (12) MIS (1) Document Management System (11) Financial Planning System (14) Campaign Management System (15) POS System (Germany/Munich) (1) POS System (Germany/ Hamburg) (12) POS System (Great Britain) (15) Price Tag Printing System (Germany/ Hamburg) (172) Price Tag Printing System (Great Britain) (175) Price Tag Printing System (Germany/ Munich) (17) Worktime Management (Germany/Munich) (18) Worktime Management (Germany/ Hamburg) (182) Customer Complaint System (19) Customer Satisfaction Analysis System (2) Customer Relationship Management System (21) Worktime Management (Great Britain) (185) Legend Map Symbols Visualization Rules A System Type A B (1) B (1) Business Application C (2) Business Application (C) is of System Type (A) Figure B.1: Viewpoint V-42 This V-Pattern groups the business applications depending on whether they are standard or individual software. 2 c TU München, sebis, 28. All rights reserved.

303 B. Excluded EAM Patterns B.2.14 Viewpoint V-4 V-Pattern Overview Id V-4 Name Percentage of Standard vs. Individual Software Alias Summary This V-Pattern shows the percentage of standard or individual software. Version 1. Solution Section Individual Software 4% Standard Software % Standard Software Individual Software Figure B.14: Viewpoint V-4 This V-Pattern is a pie chart showing the ratio of standard vs. application landscape. individual software used in the c TU München, sebis, 28. All rights reserved.

304 B. Excluded EAM Patterns B.2.15 Viewpoint V-5 V-Pattern Overview Id V-5 Name Alias Summary Version 1. Business Service Usage This V-Pattern visualizes, which business process offers which services, and which business roles, e.g. a customer, use these services. Solution Section Customer Insurance application service Claim registration service Claims payment service Customer information service Premium payment service Close Contract Handle Claim Inform Customer Collect Premium Legend Map Symbols A Business Role Visualization Rules C B Business Process (C) offers Business Service (B) B Business Service B A Business Role (A) uses Business Service (B) C Business Process Figure B.15: Viewpoint V-5 This V-Pattern visualizes, which business process offers which services, and which business roles, e.g. a customer, use these services. 4 c TU München, sebis, 28. All rights reserved.

305 B. Excluded EAM Patterns B.2.1 Viewpoint V-5 V-Pattern Overview Id V-5 Name Alias Summary Version 1. EA Overview This V-Pattern visualizes, how business applications support business processes, and how these business processes offer services. Solution Section Client ArchiSurance Claim registration Customer information Claims payment Handle Claim Register Accept Valuate Pay CRM application Policy administration Financial application Legend Map Symbols Visualization Rules A Business Role D C Business Process (C) is a sub Business Process of (D) B C Business Service Business Process A C B D Business Process (A) exposes Business Service (B) Successor Relationship between Business Processes (C) and (D) E F G H Business Application Business Service affected by Proposal Business Process affected by Proposal Business Application affected by Proposal A A E E F C D B Business Application (E) has Interconnection to Business Application (F) Business Application (E) supports Business Process (C) Business Role (A) owns Business Process (D) Business Role (A) uses Business Service (B) Figure B.1: Viewpoint V-5 This V-Pattern shows, how business applications support business processes, and how these business processes offer services. In this diagram, elements affected by a project proposal are highlighted by their color. c TU München, sebis, 28. All rights reserved. 5

306 B. Excluded EAM Patterns B.2.17 Viewpoint V-54 V-Pattern Overview Id V-54 Name Alias Summary Version 1. Offering Services This V-Pattern shows, how different components, e.g. hardware, software, etc. are used in offering a specific service. Solution Section Service A-S 2nd Level Support Service B-S Service hours 7*24 hrs Service C-S Component A Service D-S Component X Service J Service K Service E-G Legend Map Symbols Visualization Rules A Components B Services Software A B (1) B (2) Service (A) is based on Component (B) B B Hardware Service Level A A Service (A) is using Service (C) B Deliverable Type of Dependency Qualitative Dependency Technical Dependency Figure B.17: Viewpoint V-54 This V-Pattern shows, how different components, e.g. hardware, software, etc. are used in offering a specific service. In addition to this, qualitative and technical dependencies of the service under consideration to other services are shown. c TU München, sebis, 28. All rights reserved.

307 B. Excluded EAM Patterns B.2.18 Viewpoint V-2 V-Pattern Overview Id V-2 Name Alias Summary Version 1. Knowledge Requirements of Projects This V-Pattern visualizes what knowledge, e.g. programming languages, technologies, etc. is needed for a project. Solution Section Connection of Costing and Accounting System Reliability Improvement of the Online Shop Programming Languages Technolgies Programming Languages Technolgies Cobol DB2. Java 1.4 Oracle 9i Ocaml Java 1..NET 1.1 Legend Map Symbols Visualization Rules A Project with short Description A Project (A) needs Knowledge about Programming Languages and Technologies Technolgies Details about needed knowledge FORTRAN Required Knowledge Programming Languages Technolgies Oracle 9i Figure B.18: Viewpoint V-2 This V-Pattern shows for a set of project proposals, which kinds of knowledge about programming languages, technologies, etc. the respective projects would require. c TU München, sebis, 28. All rights reserved. 7

308 B. Excluded EAM Patterns B.2.19 Viewpoint V-5 V-Pattern Overview Id V-5 Name Alias Summary Version 1. Event Driven Process Chain This V-Pattern visualizes a business process as an event driven process chain (EPC). Solution Section Invoice has been received Goods receipt Legend Map Symbols V Assign invoice to goods receipt Inventory Control System E F A Events describe under what circumstances a Function or a Process is executed or in which state a Function execution results Functions model the tasks or activities within the company Organizational Unit (executes all Functions in a Process if it is not connected to a specific Function) Invoice assigned to goods receipt B Business Application Accounting System Check for difference between goods receipt and invoice Visualization Rules F1 XOR If Function (F1) completes, either Events (E1) or (E2) occur Possible differences have been corrected E1 E2 Check whether postprocessing is nessecery E1 V If Event (E1) occurrs, both Functions (F1) and (F2) are executed F1 F2 Accounting Possible postprocessing finished F1 O Organizational Unit (O) executes Function (F1) F1 A Business Application (A) supports Function (F1) Figure B.19: Viewpoint V-5 This V-Pattern visualizes a business process as an event driven process chain (EPC). In addition to the process definition itself, the diagram shows the organizational units responsible for the different activities in the process, and the business applications supporting these activities. 8 c TU München, sebis, 28. All rights reserved.

309 B. Excluded EAM Patterns B.2.2 Viewpoint V-71 V-Pattern Overview Id V-71 Name Alias Summary Version 1. Service Level Fulfilments This V-Pattern shows, to what extent services fulfill their service level agreements. Solution Section Munich Garching Service (1) Service (5) Service (9) Service (12) Service (2) Service () Service (1) Service (1) Service () Service (7) Service (11) Service (14) Service (4) Service (8) Legend Map Symbols A Organizational Unit Visualization Rules A B (1) Service Level Fulfilment Service with Id Degree of Service Level Fulfilment > 95 % Degree of Service Level Fulfilment between 9 % and 95 % Degree of Service Level Fulfilment < 9 % B (1) C (2) B (1) Organizational Unit (A) hosting Service (C) Service (B) has Service Level Fulfilment Figure B.2: Viewpoint V-71 This V-Pattern is based on a cluster map displaying services, for which it shows, to what extent they fulfill their service level agreements. The services can thereby e.g. be clustered according to the operating organizational unit or location. This V-Pattern is based on I-Patterns I-71 and I-72. c TU München, sebis, 28. All rights reserved. 9

310 B. Excluded EAM Patterns Consequence Section The I-Pattern I-71 and I-72 can easily be integrated as they both include the concept Service. 1 c TU München, sebis, 28. All rights reserved.

311 B. Excluded EAM Patterns B.2.21 Viewpoint V-72 V-Pattern Overview Id V-72 Name Alias Summary Version 1. Service Level Fulfillment History This V-Pattern visualizes the degree of service level agreement fulfillment for a specific service, during different periods in time. Solution Section Service Level Overview over Login Service Login Service 1/27 2/27 /27 4/27 5/27 Availability Response Time Legend Map Symbols Visualization Rules A Quality Goal of Service 1/27 Service Level Fulfilment Degree of Quality Goal Fulfilment > 95 % Degree of Quality Goal Fulfilment between 9 % and 95 % A Vertical Alignment Horizontal Alignment Fulfilment of Service Level of Quality Goal (A) in Time Interval (1/27) Degree of Quality Goal Fulfilment < 9 % Figure B.21: Viewpoint V-72 This V-Pattern visualizes the degree of service level agreement fulfillment for a specific service, during different periods in time. This V-Pattern is based on I-Pattern I-72. c TU München, sebis, 28. All rights reserved. 11

312 B. Excluded EAM Patterns B.2.22 Viewpoint V-7 V-Pattern Overview Id V-7 Name Alias Summary Version 1. Service Topology This V-Pattern shows the elements a service is built on, as well as their distribution over different locations. Solution Section Internet DMZ Intranet -Client external Internet-Access- Service -OWA Server -SMTP-Gateway Server Client System MS Internet Explorer MS Internet Information Server MS Windows Server MS Exchange 2 MS Windows Server Client System -Mailbox Server -Global Catalog Server MS Outlook MS Exchange 2 MS Windows Server MS Windows Server Managed PKI Service- Service Active Directory Service Virus Protection Service for Mailserver-Service Legend Map Symbols Visualization Rules A B C Location Service System A B C Service (B) is part of Location (A) A B C System (C) is part of Location (A) F B System (F) has dependency to Service (B) F C D Component Dependency Relationship C System (F) has dependency to System (C) Type of Component Component HW/OS Component Software D D System (C) contains Component (D) Type of System System is base for Service System is not base for Service Figure B.22: Viewpoint V-7 This V-Pattern shows the topology of a service. Thereby both the usage of other services, and the 12 c TU München, sebis, 28. All rights reserved.

313 B. Excluded EAM Patterns distribution of its components over different locations is shown. Additionally it is shown which systems contain which components. This V-Pattern is based on I-Pattern I-7. c TU München, sebis, 28. All rights reserved. 1

314 B. Excluded EAM Patterns B.2.2 Viewpoint V-77 V-Pattern Overview Id V-77 Name Alias Summary Version 1. Name of V-Pattern This V-Pattern uses a gantt-like notation to visualize the lifecycles of infrastructure components. Solution Section Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan MySQL 2. (1) Oracle 9i (2) DB2. (5) PostgreSQl. () Legend Map Symbols Visualization Rules A (1) Infrastructure Component Status of Infrastructure Component Jan Feb Introduction A Productive Phase Out End of Support Period Infrastructure Component (A) is in production in Jan und Feb Figure B.2: Viewpoint V-77 This V-Pattern is an interval map displaying the lifecycles of infrastructure components in a gantt-like notation. This V-Pattern is based on I-Pattern I c TU München, sebis, 28. All rights reserved.

315 B. Excluded EAM Patterns B.2.24 Viewpoint V-78 V-Pattern Overview Id V-78 Name Alias Summary Version 1. Architectural Blueprint This V-Pattern visualizes an architectural blueprint with detailed information for every tier. Solution Section This V-Pattern shows the different architectural tiers of a business application (similar to the information contained in a Component & Connector Viewtype in Documenting Software Architectures Views and Beyond), and indicates the components located on the different tiers and their communication links. c TU München, sebis, 28. All rights reserved. 15

316 B. Excluded EAM Patterns Client Presentation Business Integration Resource <<Subsystem>> Web - Client (Browser) I <<Subsystem>> Web Server I <<Subsystem>> Application Server A <<Component>> Static Content A <<Component>> PresentationLogic <<Subsystem>> Web - Client (Browser) A <<Component>> Business Logic A <<Component>> Presentation Logic I <<Component>> System Interface <<Ext. System>> Other System <<Subsystem>> Rich-Client (Application) A <<Component>> Presentation Logic I <<Component>> Database Connector <<Component>> Business Logic I <<Component>> Authentification I <<Component>> Authorisation I <<Component>> Systems Management Database I <<Component>> Errorhandling <<Component>> Logging Legend Map Symbols Visualization Rules <<Subsystem>> A <<Component>> B <<Ext. System>> C D Subsystem Component External System Tier D <<Subsystem>> A D <<Component>> B D Subsystem (C) is part of Tier (D) Component (B) is part of Tier (D) Interface Usage with Type <<Ext. System>> C External System (C) is part of Tier (D) <<Subsystem>> Type of Interface Usage Interface Offering with Type Interface Usage (read/write) A <<Component>> Presentation B Subsystem (A) consists of Component (B) Interface Usage (read) D Type of Interface Offering Interface Usage (write) E Database (E) is part of Tier (D) Interface Offering (read/write) Interface Offering (read) <<Component>> B Component (B) offers Interface Interface Offering (write) <<Ext. System>> C External System (C) offers Interface Interface <<Component>> B Component (B) uses Interface E Database <<Subsystem>> A Subsystem (A) uses Interface <<Component>> B E Component (B) uses Database (E) Figure B.24: Viewpoint V-78 1 c TU München, sebis, 28. All rights reserved.

317 B. Excluded EAM Patterns B. Excluded I-Patterns B..1 I-Pattern I-71 I-Pattern Overview Id I-71 Name Offered Services Alias Summary Version 1. Solution Section OrganizationalUnit name : String hosts 1 * Service id : String name : String Figure B.25: Information Model I-71 OrganizationalUnit: An organizational unit represents a subdivision of the organization according to its internal structure. A possible example are the entities showing up in an organigram. Service: A defined set of functionality used in executing a process (e.g. to support or automate process execution). c TU München, sebis, 28. All rights reserved. 17

318 B. Excluded EAM Patterns B..2 I-Pattern I-72 I-Pattern Overview Id I-72 Name Service Level Fulfillments Alias Summary Version 1. Solution Section Figure B.2: Information Model I-72 QualityGoal: A QualityGoal describes the desired value, that should be achieved by a service to fulfill the SLA. QualityMeasurement: The QualityMeasurement contains the achieved value of a QualityGoal of a service within a specified time frame. Service: A defined set of functionality used in executing a process (e.g. to support or automate process execution). SLA: The service level agreement (SLA) specifies a contract between the service provider and the service receiver concerning the measurable level the fulfillment of the service should conform to. 18 c TU München, sebis, 28. All rights reserved.

319 B. Excluded EAM Patterns B.. I-Pattern I-7 I-Pattern Overview Id I-7 Name Service Topology Alias Summary Version 1. Solution Section Figure B.27: Information Model I-7 Component: A component describes a part of a larger system (e.g. services). ComponentType: Specifies the different types of components (e.g. software, hardware). Location: Describes a physical (e.g. Munich, London, New York) or virtual (e.g. Internet, Intranet) location. Service: A defined set of functionality used in executing a process (e.g. to support or automate process execution). System: Describes a piece of software in general. SystemType: Specifies the different types a system can belong to (e.g. subsystem, extending system). c TU München, sebis, 28. All rights reserved. 19

320 B. Excluded EAM Patterns B..4 I-Pattern I-77 I-Pattern Overview Id I-77 Name Infrastructure Lifecycle Alias Summary Version 1. Solution Section InfrastructureComponent name : String id : String startintoduction endintroduction startproduction endproduction startphaseout endphaseout endofsupport Figure B.28: Information Model I-77 InfrastructureComponent: Infrastructure components are deployed middleware or hardware systems e.g. a database management system. 2 c TU München, sebis, 28. All rights reserved.

321 Bibliography [BEL + 7a] S. Buckl, A.M. Ernst, J. Lankes, F. Matthes, C.M. Schweda, and A. Wittenburg. Generating Visualizations of Enterprise Architectures using Model Transformation (extended version). Enterprise Modelling and Information Systems Architectures - An International Journal, Vol. 2(2), 27. [BEL + 7b] S. Buckl, A.M. Ernst, J. Lankes, K. Schneider, and C.M. Schweda. A Pattern based Approach for constructing Enterprise Architecture Management Information Models. In A. Oberweis, C. Weinhardt, H. Gimpel, A. Koschmider, V. Pankratius, and Schnizler, editors, Wirtschaftsinformatik 27, pages , Karlsruhe, Germany, 27. Universitätsverlag Karlsruhe. [CBB + 2] [Che7] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord, and J. Stafford. Documenting Software Architectures: Views and Beyond. Addison Wesley, Boston, 22. P. Chen. The Entity-Relationship Model towards a unified View of Data. ACM Transactions on Database Systems, Vol. 1(1), 197. [DDLB98] T.H. Davenport, D.W. De Long, and M.C. Beers. Successful Knowledge Management Projects. Sloan Management Review, Vol. 9(2), [Der] G. Dern. Management von IT-Architekturen (Edition CIO). Vieweg, Wiesbaden, 2. [DFH] G. Disterer, F. Fels, and A. Hausotter. Taschenbuch der Wirtschaftsinformatik. Carl Hanser Verlag, München, 2. [ELSW] A.M. Ernst, J. Lankes, C.M. Schweda, and A. Wittenburg. Using Model Transformation for Generating Visualizations from Repository Contents - An application to Software Cartography. Technical report, Technische Universität München, Chair for Informatics 19 (sebis), Munich, 2. [FKPT99] [GMW97] [Gro] L. Fahrmeir, R. Künstler, I. Pigeot, and G. Tutz. Statistik. Der Weg zur Datenanalyse. Springer, Berlin, D. Garlan, R. Monroe, and D. Wile. ACME: An Architecture Description Interchange Language. In CASCON 97, Toronto, Ontario, Canada, IBM Press. The Open Group. TOGAF (The Open Group Architecture Framework). Version 8.1 Enterprise Edition. The Open Group, 2. c TU München, sebis, 28. All rights reserved. 21

322 BIBLIOGRAPHY [IEE] IEEE. IEEE Std Recommended Practice for Architectural Description of software-intensive Systems, 2. [JGBvB5] H. Jonkers, L. Groenewegen, M. Bonsangue, and R. van Buuren. A language for Enterprise Modelling. In Lankhorst Marc., editor, Enterprise Architecture at Work. Springer, Berlin, Heidelberg, New York, 25. [Kel7] W. Keller. IT-Unternehmensarchitektur. dpunkt.verlag, 27. [Krc5] H. Krcmar. Informationsmanagement. Springer, Berlin et al., 4 edition, 25. [Kro9] [Lei7] [LMW5] K. Kronlöf (Editor). Method integration: Concepts and Case Studies. John Wiley & Sons Ltd., Chichester, 199. J. Leitel. Entwicklung und Anwendung von Beurteilungskriterien für Enterprise Architecture Frameworks. Master s Thesis, Technische Universität München, Fakultät für Informatik, 27. J. Lankes, F. Matthes, and A. Wittenburg. Softwarekartographie: Systematische Darstellung von Anwendungslandschaften. In 7. Internationale Tagung Wirtschaftsinformatik, Bamberg, 25. [Ort91] E. Ortner. Unternehmensweite Datenmodellierung als Basis für intergrierte Informationsverarbeitung in Wirtschaft und Verwaltung. Wirtschaftsinformatik, Vol. (4), [Por85] M.E. Porter. Competitive Advantage. The Free Press, New York, [SBK7] M. Schermann, T. Böhmann, and H. Krcmar. Fostering the Evaluation of Reference Models: Application and Extension of the Concept of IS design theories. In 8. Internationale Tagung Wirtschaftsinformatik (to be published), Karlsruhe, 27. Karlsruher Universitätsverlag. [Sch] J. Schekkerman. How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework. Trafford Publishing, 2. [seb5] sebis. Enterprise Architecture Management Tool Survey 25. Technische Universität München, Chair for Informatics 19 (sebis), 25. [SG89] S. L. Star and J. R. Griesemer. Institutional Ecology: Translations and Coherence: Amateurs and Professionals in Berkeley s Museum of vertebrate Zoology. Social Studies of Science, Vol. 19():87 42, [Sin91] E. J. Sinz. Unternehmensweite Datenmodellierung: Probleme und Lösungsansätze. Wirtschaftsinformatik, Vol. (4), [Som4] I. Sommerville. Software Engineering. Pearson Education Ltd., Edinburgh, 7 edition, 24. [Sta7] H. Stachowiak. Allgemeine Modelltheorie. Springer-Verlag, Wien, 197. [Str99] [Wit7] [Zac92] Jörg Strübing. Soziale Welten Arenen Grenzobjekte. In 29. Kongress der Deutschen Gesellschaft für Soziologie (Sektion Wissenschafts- und Technikforschung), Freiburg, A. Wittenburg. Softwarekartographie: Modelle und Methoden zur systematischen Visualisierung von Anwendungslandschaften. PhD thesis, Fakultät für Informatik, Technische Universität München, 27. J. Zachman. Extending and Formalising the Framework for Information Systems architecture. IBM Systems Journal, Vol. 1(), c TU München, sebis, 28. All rights reserved.