ArchiMate Extension for Modeling the TOGAF Implementation and Migration Phases

Transcription

1 ArchiMate Extension for Modeling the TOGAF Implementation and Migration Phases A White Paper by: Henk Jonkers, Harmen van den Berg, Maria-Eugenia Iacob, and Dick Quartel December 2010

2 Copyright 2010 The Open Group All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owners. This White Paper is an informational document and does not form part of the TOGAF documentation set. Readers should note that this document has not been approved through the formal Open Group Standards Process and does not represent the formal consensus of The Open Group Architecture Forum. Boundaryless Information Flow and TOGAF are trademarks and ArchiMate, Making Standards Work, The Open Group, UNIX, and the X device are registered trademarks of The Open Group in the United States and other countries. All other trademarks are the property of their respective owners. ArchiMate Extension for Modeling the TOGAF Implementation and Migration Phases Document No.: W111 Published by The Open Group, December Any comments relating to the material contained in this document may be submitted to: The Open Group 44 Montgomery St. #960 San Francisco, CA or by to: [email protected] A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 2

3 Table of Contents Introduction 5 Requirements for Implementation and Migration Modeling 7 Implementation and Migration Modeling Concepts 8 Viewpoints in the Implementation and Migration Phases 14 Conclusions 16 References 17 About the Authors 18 About The Open Group 18 A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 3

4 Boundaryless Information Flow achieved through global interoperability in a secure, reliable, and timely manner Executive Summary The Open Group standards for enterprise architecture, TOGAF TM and ArchiMate, have a firm common foundation in their shared concept of viewpoint-based access to a common underlying model. On the other hand, the two standards complement each other: TOGAF offers a well-defined architecture development process with supporting guidelines and techniques, while ArchiMate is a well-defined language to create enterprise architecture models, including an easy-to-understand graphical notation. The current version of ArchiMate (the ArchiMate core ) chiefly supports the creation of models of the Business, Application, Data, and Technology Architectures as defined in Phases B, C, and D of the TOGAF ADM. However, in the other ADM phases, models are also useful to create insight and support communication among stakeholders. It is important that the modeling concepts for these phases are wellaligned with TOGAF, as well as with the ArchiMate core concepts. In an earlier White Paper, modeling concepts were proposed to model business goals, architecture principles, and requirements in the early ADM phases and the Requirements Management process (which we refer to as the motivation extension of ArchiMate). In this White Paper, we propose an extension of ArchiMate that is aimed at the implementation and migration phases (Phases E, F, and G) of the ADM. This includes concepts such as implementation programs and projects, plateaus (e.g., to model Baseline, Target, and Transition Architectures as defined in TOGAF), and gaps. Also, we specify how these concepts may be related to the ArchiMate core and motivation extension concepts. With the proposed extensions, a new version of ArchiMate will support clear and consistent modeling throughout all phases of the TOGAF ADM. A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 4

5 Introduction In 2009, The Open Group adopted Version 1.0 of ArchiMate as a standard language for modeling enterprise architectures [11]. Around the same time, Version 9 of TOGAF, The Open Group framework and method for enterprise architecture, was published [10]. TOGAF and ArchiMate have a firm common foundation: they share the concept of an underlying common repository of architectural artifacts and models, and both advocate the use of viewpoints to present the appropriate subset of this information to various stakeholders. However, the two standards also complement each other: TOGAF offers a well-defined architecture development process with supporting guidelines and techniques, while ArchiMate is a well-defined language to create enterprise architecture models, including an easy-to-understand graphical notation [2]. ArchiMate 1.0 chiefly supports the creation of coherent models that are part of the Business, Application, Data, and Technology Architectures as defined in Phases B, C, and D of the TOGAF Architecture Development Method (ADM). However, in the other ADM phases, models are also useful to create insight and support communication among stakeholders. Therefore, we propose to define additional modeling domains as extensions to ArchiMate. These extensions provide a concrete way to model the concepts for these phases as identified in the Content Metamodel that is part of the TOGAF Architecture Content Framework. To improve the coherence and consistency of models, it is important that these modeling concepts are well-aligned with both TOGAF and the ArchiMate core concepts. Motivation extension Preliminary Phase H: Architecture Change Management Phase A: Architecture Vision ArchiMate core Phase B: Business Architecture Phase G: Implementation Governance Requirements Management Phase C: Information Systems Architecture Implementation & migration extension Phase F: Migration Planning Phase E: Opportunities. & Solutions Phase D: Technology Architecture Figure 1: ArchiMate Core and Extensions in Relation to the TOGAF ADM A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 5

6 We identify two main directions for extending ArchiMate (see Figure 1): In the early ADM phases (the Preliminary Phase and Phase A: Architecture Vision), business goals and architecture principles are established (for the organization as a whole, or made specific for a particular architecture development cycle), and a first set of architecture requirements is defined. The Requirements Management process is responsible for keeping track of the architecture requirements throughout the application of the ADM. In [8], modeling concepts to support these phases have been defined, as well as their relationship to the ArchiMate 1.0 language. We will refer to these concepts as the motivation extension of ArchiMate. Also, this White Paper outlines a way of working for requirements management. In the implementation-related ADM phases (Phase E: Opportunities and Solutions, Phase F: Migration Planning, and Phase G: Implementation Governance), possible projects and work packages to implement the developed architectures are identified, prioritized, and planned. Based on the consolidated gap analysis results from Phases B, C, and D, the Transition Architectures referenced in TOGAF are defined. The actual implementation projects are assessed on their compliance to the defined architectures. In this White Paper, we propose modeling concepts to support these implementation and migrationrelated phases. We will refer to these concepts as the implementation and migration extension of ArchiMate. A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 6

7 Requirements for Implementation and Migration Modeling In this section, we list a number of important requirements that the implementation and migration extension of ArchiMate should meet. Consistency with the TOGAF core specification The concepts and relationships of the extension should adhere to the structure and concept definitions of the TOGAF Content Metamodel. Consistency with the ArchiMate core and the motivation extension The concepts and relationships of the extension should, as much as possible, adhere to the language structure and design principles, as presented in Chapter 3 of the ArchiMate 1.0 Specification [11]. Also, relationships with the ArchiMate core concepts and the motivation concepts should be defined. Parsimony Following the ArchiMate philosophy, the set of additional concepts and relationships that is defined should be kept to a minimum. If possible, concepts or relationships from the ArchiMate core or the motivation extension should be re-used. Compliance with program and project management standards and best practices, such as MSP [5], PRINCE2 [6], and PMBoK [7] It should be possible to express the main concepts of these methods in a generic way. Concepts that are specific to one of these methods should not be part of the language, but may be defined as specializations of the generic concepts. A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 7

8 Implementation and Migration Modeling Concepts In this section, we briefly introduce the modeling concepts used in the implementation and migration phases of the ADM. These concepts are subdivided in two categories: concepts for modeling projects and programs (and related concepts), and concepts related to migration planning. Also, we show how these aspects can be related to the ArchiMate core and to the motivation extension of ArchiMate. Modeling Projects and Programs A project can be defined as: A series of actions designed to accomplish a unique goal within a specified time [6] or: A temporary endeavor undertaken to create a unique product or service [7] Although many different definitions exist, most of them share a number of characteristics of a project: It is temporary in nature, and has a clearly defined beginning and end. It has clearly defined goals and/or it delivers a clearly defined set of results. The change accomplished through a project is unique, or in any case unique enough not to be managed under a line management function but to be started as a project. This means that, in principle, no project is the same as another. These characteristics distinguish a project from business as usual. Conceptually, a project is similar to a business process, in that it consists of a set of causally related tasks, aimed at producing a well-defined result. However, as already indicated in the characteristics described above, a project is a unique, one-off process. This also implies that funding and personnel assignments for a project are not ongoing. Still, a project can be described in a way very similar to the description of a process. Therefore, for project, we consider the same three aspects that are used for each of the layers in the ArchiMate core language: behavior, (active) structure, and information (or passive structure). The concepts for each of these aspects, as well as their relationships, are shown in Figure 2. A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 8

9 Figure 2: Concepts for Project Modeling The central behavioral concept is a project. A project has special status: it has a clearly defined beginning and end date, and a well-defined set of goals or results. A method like PRINCE2 also requires each project to have a valid business case. A project may be subdivided into a hierarchy of project activities. In different project management methods, different terms may be used for this; for example, in PRINCE2, a project is divided into a number of sequential stages, which may consist of several work packages. The lowest level of decomposition of project behavior is often called a project task. Multiple projects which are managed together coherently, and which all contribute to a common outcome, can be grouped into a program. A program may also contain subprograms. The program concept can also be used to model a project portfolio ; i.e., all the programs and projects within a certain context e.g., the organization as a whole. To each program, project, or project activity, one or more project roles can be assigned. Methods like PRINCE2 define a number of standard roles for a project; e.g., project board member (subdivided in executive, senior user, and senior supplier ), project manager, work package leader, change authority, etc. These project roles may be fulfilled by specific project resources. A single resource may be assigned to multiple roles, although there may be some restrictions on the roles that may be combined. Projects and project activities produce project results (or deliverables). These may be results of any kind; e.g., reports, papers, services, software, physical products, etc. A project s results may also be (a part of) an architecture, or a solution that implements (a part of) an architecture. In PRINCE2, the results (products) of a project are leading. The overall result of a project is described in a project product description ; the hierarchical decomposition of this product in sub-products is shown in a Product Breakdown Structure, an example of which is shown in Figure 3. A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 9

10 Figure 3: Example of a Product Breakdown Structure Modeling Plateaus and Gaps An important premise in TOGAF is that the various architectures are described for different stages in time. In each of the Phases B, C, and D of the ADM, a Baseline Architecture and Target Architecture are created, describing the current situation and the desired future situation. In Phase E: Opportunities and Solutions, one or more Transition Architectures may be defined, showing the enterprise at incremental states reflecting periods of transition between the Baseline and Target Architectures. Transition Architectures are used to allow for individual work packages and projects to be grouped into managed portfolios and programs, illustrating the business value at each stage. In order to support this, we introduce the plateau concept (see Figure 4). A plateau is a time interval with a start and an end, which must bear certain significance, i.e.: The next plateau starts where the previous plateau ended. The transitions between these plateaus correspond to a specific change in the enterprise architecture. Examples of these specific changes are: the adjustment of the organizational structure (e.g., the introduction of business units, introduction of mid-office, etc.), change of the IT network from token-ring to IP, or making legacy systems available through the use of web services. Figure 4: Concepts for Period Modeling A gap is an important outcome of a gap analysis in Phases B, C, and D of the TOGAF ADM, and forms an important input for the subsequent implementation and migration planning. The gap concept is linked to two plateaus (e.g., baseline and target architecture, or two subsequent transition architectures), and represents the differences between these plateaus. A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 10

11 The order of the plateaus can be modeled using the ArchiMate triggering relationship. Junctions may be used to model alternatives for a certain plateau, as is illustrated in Figure 5. Figure 5: Ordering and Alternatives of Plateaus Also, relationships can be created between the enterprise architecture models created at different moments in time (expressed with the ArchiMate core concepts) and the migration models. Subsequently, these models can be used as a basis for emphasizing the differences between the different versions of models in different plateaus (e.g., gap analysis between baseline and target architectures as defined in TOGAF). Relationships with the ArchiMate Core Figure 6 shows how the implementation and migration concepts can be related to the ArchiMate core concepts. Figure 6: Relationships Projects, Plateaus, Gaps, and the ArchiMate Core Concepts A plateau is linked to an architecture that is valid for a certain time span. To indicate which parts of the architecture belong to a certain plateau, a plateau may aggregate any of the concepts of the ArchiMate core. A gap aggregates the core concepts that are unique to one of the plateaus linked by the gap; i.e., the core concepts that make up the difference between these plateaus. As an example, consider a simplified version of the Baseline and Target of the infrastructure of the ArchiSurance example, as shown in Figure 7. In the target situation, the separate application servers of the Car and Legal Aid back offices have been removed. However, in order to sustain the same level of availability of the servers, a new backup application server is introduced. A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 11

12 Figure 7: Baseline and Target Architecture of the Infrastructure Figure 8 models the gap between the Baseline and Target infrastructure, showing which of the elements of the infrastructure only occur in either the Baseline or the Target. Figure 8: Gap Between Baseline and Target Infrastructure A project result may be, among others, an architecture or a part of an architecture. Therefore, any of the concepts of the ArchiMate core may be considered as a specialization of a project result. Also, a complete architecture belonging to a certain plateau may be defined as a project result. In this case, the plateau (representing the corresponding architecture) may be considered as a specialization of a project result. A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 12

13 Weaker relationships may also be defined; for example, the association relationship may be used to show that parts of the architecture are affected in some way by certain programs, projects, or project activities. Relationships with the ArchiMate Motivation Extension Strictly speaking, the relationships between the implementation and migration concepts and the motivation concepts are indirect relationships; e.g., a project result realizes a requirement or goal through the realization of an ArchiMate core element (e.g., an application component, business process, or service). However, it is still useful to make these relationships explicit, to show directly that a project result is needed to realize certain requirements and goals. Also, goals and requirements can be associated with a certain plateau; e.g., certain requirements may only be applicable to the Target Architecture, while others may apply to a certain Transition Architecture. This can be modeled by means of the aggregation relationship. Figure 9 summarizes the relationships between the concepts of the implementation and migration extension and the concepts of the motivation extension. Figure 9: Relationships Projects, Plateaus, and the ArchiMate Motivation Extension A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 13

14 Viewpoints in the Implementation and Migration Phases TOGAF includes the Project Context diagram as a viewpoint, which describes the scope of a work package to be implemented as part of a broader transformation roadmap. The Project Context diagram links a work package to the organizations, functions, services, processes, applications, data, and technology that will be added, removed, or impacted by the project. Figure 10 shows an example of a Project Context diagram for the application rationalization projects carried out at the ArchiSurance insurance company (see [2] for an introduction to this example). Green indicates elements in the architecture that are new in the Target Architecture; blue indicates elements that need to be modified; and red indicates elements from the Baseline Architecture that will be phased out in the future situation. Figure 10: Example of a Project Context Diagram In Figure 5, we already showed how plateaus can be used to support migration planning, by modeling the sequencing, and possibly alternatives, for the Transition Architectures. Figure 11 sketches the Baseline, Target, and two alternative Transition Architectures for the ArchiSurance case. In the Baseline, there are separate back-office systems and CRM systems. In the Target, both the back-office systems and CRM systems have been integrated. The Transition Architectures represent the intermediate situations in which either the back-office systems or CRM systems have been integrated first (assuming that there are insufficient resources, or it is too risky, to perform both integration projects in parallel). A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 14

15 Transition 2, alternative A Transition 1 Target Transition 2, alternative B Figure 11: Alternative Transition Architectures for ArchiSurance In Phase F, a selection from the alternatives will be made, the result of which is part of the detailed Implementation and Migration Plan. A useful viewpoint to be included in this plan is a diagram that shows how the different architectures (Baseline, Target, and Transition Architectures) are linked through the various implementation projects. Figure 12 shows an example of such a diagram for the ArchiSurance case. First, a project is carried out to integrate the back-office systems, which results in the Transition Architecture with a single back-office system (but still separate CRM systems). Next, a project is carried out to also integrate the CRM systems, which leads to the Target Architecture. Figure 12: Plateaus Linked through Projects A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 15

16 Conclusions Version 1.0 of the ArchiMate standard for enterprise architecture modeling (the ArchiMate core ) chiefly supports the creation of coherent models that are part of the Business, Application, Data, and Technology Architectures as defined in Phases B, C, and D of the TOGAF Architecture Development Method (ADM). However, in the other ADM phases, models are also useful to create insight and support stakeholder communication. In a previous White Paper, a motivation extension for ArchiMate was proposed, which focuses on the early phases of the ADM (the Preliminary Phase and Phase A: Architecture Vision), as well as on the central Requirements Management process. In this extension, concepts such as (business) goals, requirements, and (architecture) principles have been defined. In this White Paper, we introduced an extension of ArchiMate to support the late ADM phases, related to the implementation and migration of architectures: Phase E (Opportunities and Solutions), Phase F (Migration Planning), and Phase G (Implementation Governance). This extension includes concepts for modeling implementation programs and projects (thus supporting program and portfolio management), and a plateau concept to support migration planning. We also showed how these concepts can be related to the ArchiMate core concepts and to the concepts of the motivation extension. With the proposed extensions, a new version of ArchiMate will support clear and consistent modeling throughout all phases of the TOGAF ADM. Also, with the resulting models, complete (forward and backward) traceability can be achieved between goals, principles, and requirements, elements of the architecture, and implementation projects. A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 16

17 References [1] Concepts for Modeling Enterprise Architectures, H. Jonkers, M.M. Lankhorst, R. van Buuren, S. Hoppenbrouwers, M. Bonsangue, L. van der Torre, International Journal of Cooperative Information Systems (IJCIS), Special Issue on Architecture in IT, 2004:13(3): [2] TOGAF 9 and ArchiMate 1.0, H. Jonkers, E. Proper, & M. Turner, White Paper, published by The Open Group, November [3] TOGAF and ArchiMate : A Future Together, H. Jonkers, E. Proper, & M. Turner, White Paper, published by The Open Group, November [4] Enterprise Architecture at Work, M.M. Lankhorst et al, Springer-Verlag, Berlin, [5] Managing Successful Programmes, Office of Government Commerce (OGC), Stationary Office Books, [6] Managing Successful Projects with PRINCE2 (2009 Edition), Office of Government Commerce (OGC), Stationary Office Books, [7] A Guide to the Project Management Body of Knowledge (PMBoK Guide) (Fourth Edition), Project Management Institute, [8] Supporting Requirements Management and Principles in TOGAF and ArchiMate, D. Quartel, W. Engelsman, H. Jonkers, White Paper, to be published by The Open Group, [9] Extending and Formalizing the Framework for Information Systems Architecture, J.F. Sowa, J.A. Zachman, IBM Systems Journal, 1992:31(3); [10] TOGAF Version 9, The Open Group, published by Van Haren Publishing, [11] ArchiMate 1.0 Specification, The Open Group, published by Van Haren Publishing, [12] A Framework for Information Systems Architecture, J.A. Zachman, IBM Systems Journal, Vol. 26, No. 3, 1987, pp A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 17

18 About the Authors Henk Jonkers is a Senior Research Consultant at BiZZdesign. In this capacity, he is involved in the company s new developments in the areas of business process engineering and enterprise architecture. He participates in multi-party research projects, as well as in consultancy for customers. Henk was one of the main developers of ArchiMate and an author of the ArchiMate 1.0 Specification. He is TOGAF 9 Certified. Harmen van den Berg is partner and co-founder of BiZZdesign. He developed methods and techniques for business process modeling and enterprise architecture, and applied these as a consultant at various organizations. He has authored several publications on business process modeling and enterprise architecture, and is chair of the Dutch ArchiMate Usage working group. He is TOGAF8 Certified, and a trainer of TOGAF and ArchiMate courses. Harmen is a speaker at many enterprise architecture conferences, such as LAC, EAM, and The Open Group. Maria-Eugenia Iacob is Assistant Professor at the Department of Information Systems and Change Management at the University of Twente. She holds a PhD degree in Mathematical Analysis from the University Babes-Bolyai of Cluj-Napoca, Romania. She has done research in several projects in the areas of service-oriented architectures, model-driven development, e-services architectures, design methods, business and e-business process (re)engineering, (enterprise) information systems architectures, and e-government. Dick Quartel is a Senior Researcher at Novay. In this capacity, he is involved in research, consultancy, project management, and project development. The mission of Novay is to facilitate innovation enabled by ICT in companies and public organizations. Before joining Novay, Dick worked as an assistant professor at the University of Twente. His expertise and interests include enterprise and service-oriented architecture, business process (re)design, model-driven development of services and software, service composition and interoperability, and requirements modeling. Dick has worked in several national and European projects. About The Open Group The Open Group is a vendor-neutral and technology-neutral consortium, whose vision of Boundaryless Information Flow will enable access to integrated information within and between enterprises based on open standards and global interoperability. The Open Group works with customers, suppliers, consortia, and other standards bodies. Its role is to capture, understand, and address current and emerging requirements, establish policies, and share best practices; to facilitate interoperability, develop consensus, and evolve and integrate specifications and Open Source technologies; to offer a comprehensive set of services to enhance the operational efficiency of consortia; and to operate the industry's premier certification service, including UNIX system certification. Further information on The Open Group can be found at A Wh i t e P ap e r P u b l i s h ed b y Th e O p e n Gr o u p 18