TOGAF 9 and ArchiMate 1

TOGAF™ 9 and ArchiMate® 1.0

A White Paper by:

Henk Jonkers, Erik Proper, and Mike Turner

November 2009


www.opengroup.org A W h i t e P a p e r P u b l i s h e d b y T h e O p e n G r o u p 2

Copyright © 2009 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.

Object Management Group™ and Unified Modeling Language™ are trademarks and UML® is a registered trademark of the Object Management Group.

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.


Document No.: W191

Published by The Open Group, November 2009

Any comments relating to the material contained in this document may be submitted to:

The Open Group 44 Montgomery St. #960 San Francisco, CA 94104

or by email to:

[email protected]

mailto:[email protected]



Table of Contents

Introduction 5 Ingredients of an Enterprise Architecture Approach ..........................................5

Overview of the TOGAF Specification 6

Overview of the ArchiMate Specification 8

Common Foundation 9 Views, Viewpoints, and Stakeholders ..............................................................10

TOGAF and ArchiMate 11 ArchiMate and the Architecture Content Framework ......................................11 ArchiMate, the Enterprise Continuum, and TOGAF Reference Models..........12 ArchiMate Models Throughout the ADM........................................................13 Summary ..........................................................................................................20

Conclusions 21

References 22

About the Authors 23

About The Open Group 23



Boundaryless Information Flow™ achieved through global interoperability in a secure, reliable, and timely manner

Executive Summary

This White Paper discusses the TOGAF 9 and ArchiMate 1.0 specifications, illustrating how these two open standards of The Open Group can be used together. The main observations are:

• TOGAF and ArchiMate overlap in their use of viewpoints, and the concept of an underlying common repository of architectural artifacts and models; i.e., they have a firm common foundation.

• TOGAF and ArchiMate complement each other with respect to the definition of an architecture development process and the definition of an enterprise architecture modeling language.

• ArchiMate 1.0 chiefly supports modeling of the architectures in Phases B, C, and D of the TOGAF Architecture Development Method (ADM). The resulting models are used as input for the subsequent ADM phases. However, modeling concepts specifically aimed at the other phases – e.g., concepts for modeling principles, goals and requirements, or concepts to support migration planning – are still missing in the language. This observation points in a direction for possible language extensions in future versions of ArchiMate.

This paper supports Boundaryless Information Flow by discussing how two Open Group specifications can be used in combination.



Introduction Whenever enterprise architecture is considered to be the “weakest link” in an organization, preventing it from achieving whatever business strategy it may have, the advocates of new architecture support tools claim that they have the silver bullet that will easily cure all major prevailing problems. It is subsequently assumed that having such a tool will give business professionals not only more control over the IT complexity, but will also help them develop organization-wide information systems that follow, serve, and implement the corporate business strategy and seamlessly integrate with business processes. Thus, enterprise architecture tools appear to hold the potential of allowing organizations to derive maximum business value from IT investments and to become flexible and coherent in the management of organizational changes, resources, and planning.

In this White Paper we argue that, besides tools, organizations need a complete approach to guide the development of enterprise architecture, from strategy and requirements to implementation and maintenance.

Our goal in this paper is to demonstrate that such an approach can result from the combination of two open standards for enterprise architecture currently promoted by The Open Group. The first one, The Open Group Architecture Framework (TOGAF 9) [7], has been for more than a decade the world’s leading (enterprise) architecture method. The second one, ArchiMate 1.0, has recently been adopted as an Open Group standard for modeling enterprise architectures [3, 8].

One of the strengths of the TOGAF method is its ability to stress the importance of stakeholder concerns for each enterprise architecture development phase: creation, change, and governance. This ability may suggest that TOGAF also describes how an architect should address these concerns. This, however, is not the case. What TOGAF actually offers is a sort of “open interface” for the declaration of such a “concern”. The actual specification of the concern is left to any suitable modeling language which is capable of capturing such concerns and is compliant with the ISO/IEC 42010:2007 standard [1].

ArchiMate is such a modeling standard: it follows the definitions and relationships of the concepts of concern, viewpoint, and view proposed by the ISO/IEC 42010:2007 standard for architecture description. The ArchiMate framework is therefore capable of defining stakeholder concerns in viewpoints, while the ArchiMate language is capable of addressing these with corresponding views showing the right aspects of the architecture conforming to defined viewpoints.

Ingredients of an Enterprise Architecture Approach

Enterprise architecture frameworks vary in the aspects they cover. They may have, among others, any combination of the following ingredients (see Figure 1):

• A process (“way of working”) for creating architectures; this may be accompanied by guidelines, techniques, and best practices

• A set or classification of viewpoints

• A language for describing architectures (defining concepts and relationships, but also a notation)

• The concept of a (virtual) architecture repository, possibly containing predefined architectural artifacts and (reference) models



View-pointsProcess Language

Repository, (Reference) ModelsRepository, (Reference) Models

Figure 1: Ingredients of an Enterprise Architecture Approach

The core of TOGAF is a process – the Architecture Development Method (ADM); it also describes viewpoints, techniques, and reference models, but not a complete language (the Architecture Content Framework identifies relevant architecture building blocks, but it does not constitute a formal modeling language, nor a notation).

ArchiMate describes viewpoints and provides a formal modeling language, including a (graphical) notation.

TOGAF and ArchiMate overlap in their use of viewpoints, and the concept of an underlying common repository of architectural artifacts and models; i.e., they have a firm common foundation.

TOGAF and ArchiMate complement each other with respect to the definition of an architecture development process and the definition of an enterprise architecture modeling language.

In this White Paper, we show an impression of how the current versions of TOGAF and ArchiMate might work together. Although there are still some gaps, there are no objections to starting with the combined use of TOGAF 9 and ArchiMate 1.0 now. Further versions of the standards may lead to an even better integration, whilst ensuring that current investments in terms of models describing baseline and/or target architectures are retained. For a vision on the future co-existence of TOGAF and ArchiMate, we refer to a separate White Paper on this topic [9].

Overview of the TOGAF Specification The Open Group Architecture Framework (TOGAF) is a framework – a detailed method and a set of supporting tools – for developing an enterprise architecture. It may be used freely by any organization wishing to develop an enterprise architecture for use within that organization.

There are seven main parts to the TOGAF document:

• PART I: Introduction This part provides a high-level introduction to the key concepts of enterprise architecture and in particular the TOGAF approach. It contains the definitions of terms used throughout TOGAF and release notes detailing the changes between this version and the previous version of TOGAF.

• PART II: Architecture Development Method This part is the core of TOGAF. It describes the TOGAF ADM – a step-by-step approach to developing an enterprise architecture (see Figure 2).

• PART III: ADM Guidelines and Techniques This part contains a collection of guidelines and techniques available for use in applying TOGAF and the TOGAF ADM.



Figure 2: The TOGAF Architecture Development Method (ADM)

• PART IV: Architecture Content Framework This part describes the TOGAF content framework, including a structured metamodel for architectural artifacts (see Figure 3), the use of re-usable architecture building blocks, and an overview of typical architecture deliverables.

Figure 3: The TOGAF Architecture Content Framework

• PART V: Enterprise Continuum & Tools This part discusses appropriate taxonomies and tools to categorize and store the outputs of architecture activity within an enterprise.



• PART VI: TOGAF Reference Models This part provides a selection of architectural reference models, which includes the TOGAF Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM).

• PART VII: Architecture Capability Framework This part discusses the organization, processes, skills, roles, and responsibilities required to establish and operate an architecture function within an enterprise.

Overview of the ArchiMate Specification The ArchiMate enterprise architecture modeling language has been developed to provide a uniform representation for architecture descriptions. It offers an integrated architectural approach that describes and visualizes the different architecture domains and their underlying relationships and dependencies.

In a short time, ArchiMate has become the open standard for architecture modeling in the Netherlands; it is now also becoming well known in the international enterprise architecture community, and recently it has been brought under the aegis of The Open Group.

The ArchiMate standard is structured as follows:

• Chapter 1: Introduction

• Chapter 2: Enterprise Architecture This chapter makes the case for enterprise architecture and for the necessity of a modeling standard for enterprise architecture.

• Chapter 3: Language Structure This chapter presents some general ideas, principles, and assumptions underlying the development of the ArchiMate metamodel (illustrated in Figure 4) and introduces the ArchiMate framework (see Figure 5).

Figure 4: Structure of the ArchiMate Language



Figure 5: The ArchiMate Framework

• Chapter 4: Business Layer This chapter covers the definition and usage of the business layer modeling concepts, together with examples.

• Chapter 5: Application Layer This chapter covers the definition and usage of the application layer modeling concept, together with examples.

• Chapter 6: Technology Layer This chapter covers the definition and usage of the technical infrastructure layer modeling concept, together with examples.

• Chapter 7: Cross-Layer Dependencies and Chapter 8: Relationships These chapters cover the definition of relationship concepts in a similar way.

• Chapter 9: Architecture Viewpoints This chapter presents and clarifies a set of architecture viewpoints, developed in ArchiMate based on practical experience. All ArchiMate viewpoints are described in detail. For each viewpoint, the comprised concepts and relationships, the guidelines for the viewpoint use, and the goal and target group of the viewpoint are specified. Furthermore, each viewpoint description contains example models.

• Chapter 10: Language Extension Mechanisms This chapter handles extending and/or specializing the ArchiMate core language for specialized or domain-specific purposes.

• Chapter 11: Future Directions This chapter identifies extensions and directions for developments in the next versions of the language.

Common Foundation Establishing and maintaining a coherent enterprise architecture is clearly a complex task, because it involves many different people with differing backgrounds using various notations. In order to get a handle on this complexity, researchers have initially focused on the definition of architectural frameworks for classifying and positioning the various architectural descriptions with respect to each other (e.g., the Zachman framework [6, 10]). A problem with looking at enterprise architecture through the lens of an architectural



framework is that it categorizes and divides architectural descriptions rather than providing insight into their coherence.

Views, Viewpoints, and Stakeholders

Views are an ideal mechanism to purposefully convey information about architecture areas. In general, a view is defined as a part of an architecture description that addresses a set of related concerns and is addressed to a set of stakeholders. A view is specified by means of a viewpoint, which prescribes the concepts, models, analysis techniques, and visualizations that are provided by the view. Simply put, a view is what you see, and a viewpoint is where you are looking from.

Figure 6: Metamodel from ISO/IEC 42010:2007 [1]

Viewpoints are a means to focus on particular aspects of the architecture. These aspects are determined by the concerns of a stakeholder with whom communication takes place. What should and should not be visible from a specific viewpoint is therefore entirely dependent on the argumentation with respect to a stakeholder’s concerns.

Viewpoints are designed for the purpose of communicating certain aspects of an architecture. The communication enabled by a viewpoint can be strictly informative, but in general will be bi-directional. The architect informs stakeholders, and stakeholders give their feedback (critique or consent) on the presented aspects. What is and what is not shown in a view depends on the scope of the viewpoint and on what is relevant to the concerns of the stakeholder. Ideally, these are the same; i.e., the viewpoint is designed with specific concerns of a stakeholder in mind. Relevance to a stakeholder’s concern, therefore, is the selection criterion that is used to determine which objects and relations are to appear in a view.

The following are examples of stakeholders and concerns as a basis for the specification of viewpoints:

• End user: For example, what are the consequences for his work and workplace?



• Architect: What is the consequence for the maintainability of a system, with respect to corrective, preventive, and adaptive maintenance?

• Upper-level management: How can we ensure our policies are followed in the development and operation of processes and systems? What is the impact of decisions (on personnel, finance, ICT, etc.)?

• Operational manager, responsible for exploitation or maintenance: For example, what new technologies are there to prepare for? Is there a need to adapt maintenance processes? What is the impact of changes to existing applications? How secure are my systems?

• Project manager, responsible for the development of new applications: What are the relevant domains and their relations? What is the dependence of business processes on the applications to be built? What is their expected performance?

• Developer: What are the modifications with respect to the current situation that need to be done?

Repository

P1 P2

A1 A2

S1

O1

D1 E1 F1

M1

A3

S2

Repository

P1 P2

A1 A2

S1

O1

D1 E1 F1

M1

A3

S2

A1 A2

S1

A3

S2

D1 E1 F1 √√P2√P1

A3A2A1

√√P2√P1

A3A2A1

P2

A2

F1

S2

Figure 7: Views on a Shared Model

TOGAF and ArchiMate

ArchiMate and the Architecture Content Framework

The Architecture Content Framework of TOGAF identifies the main types of architecture building blocks that are relevant for the different types of architecture. ArchiMate offers precisely defined concepts, including a graphical notation, to represent many of these building blocks.

Figure 8 sketches how the main ArchiMate concepts fit into the Architecture Content Framework. From this mapping, it is clear that ArchiMate primarily covers the building blocks associated with Phases B, C, and D of the TOGAF ADM: the concepts for the preparatory phases and the architecture realization phases are not yet covered.



Principle

RequirementGoal

Business rule

PrincipleStakeholder

ConcernAssessment

Value

BusinessService

BusinessProcess

BusinessFunction

BusinessActor

BusinessRole

ApplicationService

ApplicationComponent

DataObject

Artifact

Node

Device

InfrastructureService

DeliverableResultProjectProgram

Figure 8: Main ArchiMate Concepts Positioned in the Architecture Content Framework

Figure 9 roughly shows how the concepts and relationships from the core content metamodel of TOGAF can be represented with ArchiMate concepts and relationships.

ApplicationService

DataObject

ApplicationComponent Node

InfrastructureService

Node realizesInfra. service

Business Process aggregatesBusiness Function

Business Role is assignedto Business Process

BusinessRole Business

Process

BusinessFunctionBusiness Actor is assigned

to Business Role

Business Actor is composedof Business actor

BusinessActor

Application Serviceaccesses Data Object

Application Componentrealizes Application Service

Figure 9: ArchiMate and the TOGAF Core Content Metamodel

ArchiMate, the Enterprise Continuum, and TOGAF Reference Models

The Architecture Continuum, part of the TOGAF Enterprise Continuum, provides a way to classify architectures based on how generic/specific they are (ranging from very general foundation architectures, through common systems architectures and industry architectures, to organization-specific architectures).



TOGAF provides two reference models: the Technical Reference Model (TRM), part of the Foundation Architecture, and the Integrated Information Infrastructure Reference Model (III-RM), a common systems architecture, which can be used as an initial population of the Architecture Continuum. These reference models (or any other reference models that may exist, for that matter) may be expressed and stored using ArchiMate. An advantage of this is that it facilitates the re-use of elements from these reference models (e.g., services as defined by the TRM) in the architectures to be developed, especially if these architectures are also modeled with ArchiMate.

ArchiMate Models Throughout the ADM Introduction to the Example

As an example, we consider ArchiSurance, a fictitious insurance company. ArchiSurance is a merger of three previously independent insurance companies:

• The original ArchiSurance, the largest of the three, offered home and travel insurances.

• PRO-FIT was a company specializing in car insurances.

• LegallyYours was a small company specializing in legal aid insurances.

The new company will offer all the insurance products of the original companies. It has a common front-office for customer contacts, and for each class of insurance products, there is a separate back-office.

ArchiSurance intends to use a combination of TOGAF and ArchiMate as the basis for a rationalization of their application portfolio. Currently, back-office functionality (e.g., policy administration, financials, claims data management) is divided over four different applications, and there is a separate CRM system for the Legal Aid department (see the application landscape map in Figure 10).

MaintainingCustomer &

IntermediaryRelations

ClaimHandling

Contracting

DocumentProcessing

LiabilityInsurance

CarInsurance

TravelInsurance

HomeInsurance

Legal AidInsurance

Web portal

Call center application

Customer relationship management system

Home & AwayPolicy administration

Legal Aidbackofficesystem

Legal AidCRM

Document management system

Home & AwayFinancial application

BusinessFunctions

Products

FinancialHandling

Car insurance application



ClaimHandling

Contracting

DocumentProcessing

LiabilityInsurance

CarInsurance

TravelInsurance

HomeInsurance

Legal AidInsurance

Web portal

Call center application

Customer relationship management system

Home & AwayPolicy administration

Legal Aidbackofficesystem

Legal AidCRM



BusinessFunctions

Products

FinancialHandling


Figure 10: ArchiSurance Application Landscape Map: Baseline

In the target situation that is envisaged, there will be a single back-office system for all types of insurance, covering all back-office functionality, as well as a single CRM system for all departments (see the application landscape map in Figure 11).





ClaimHandling

Contracting

DocumentProcessing

LiabilityInsurance

CarInsurance

TravelInsurance

HomeInsurance

Legal AidInsuranceWeb portal

Call center applicationCustomer relationship management system

Home & AwayPolicy administration Legal Aid

backofficesystem

Legal AidCRM



BusinessFunctions

Products

FinancialHandling




ClaimHandling

Contracting

DocumentProcessing

LiabilityInsurance

CarInsurance

TravelInsurance

HomeInsurance

Legal AidInsuranceWeb portal

Call center applicationCustomer relationship management system

Home & AwayPolicy administration Legal Aid

backofficesystem

Legal AidCRM



BusinessFunctions

Products

FinancialHandling


ArchiSuranceback-office system

ArchiSurance CRM system

Figure 11: ArchiSurance Application Landscape Map: Target

Preliminary Phase

The preliminary phase prepares an organization to undertake successful enterprise architecture projects.

In a number of activities undertaken in the preliminary phase, ArchiMate may be involved:

• Scope the enterprise organizations impacted: A high-level ArchiMate model may be used to graphically show the core, soft, and extended enterprise units affected by the enterprise architecture work. However, this scope may also be visualized in a more informal way, or in a non-graphical way.

• Define and establish enterprise architecture team and organization: Again, ArchiMate models may be used to precisely define the roles involved and their relationships. Also here, more informal visualizations or non-graphical definitions may be chosen instead.

• Select and tailor architecture framework(s): This includes content tailoring and, if ArchiMate is chosen as the language for enterprise architecture modeling, tailoring of the language (e.g., defining enterprise-specific specializations or extensions of ArchiMate concepts and relationships).

Phase A: Architecture Vision

Phase A is about project establishment and initiates an iteration of the architecture development cycle, setting the scope, constraints, and expectations for the iteration. It is required in order to validate the business context and to create the approved Statement of Architecture Work.

Outputs of Phase A include Versions 0.1 (the “vision”) of the baseline and target business, information systems, and technology architectures. These can be represented as high-level ArchiMate models; e.g., using the Introductory viewpoint as defined in the ArchiMate 1.0 Specification [8]. Figure 12 shows an example of such a view.



Figure 12: ArchiMate Introductory Viewpoint for the Architecture Vision

Phases B, C, and D: Business, Information Systems, and Technology Architectures

The role of ArchiMate in the ADM is most prominent in Phases B, C, and D, in which the actual architectures are developed. The ArchiMate language is rich enough to model the baseline and target architectures for the different phases, at varying levels of detail. Also, precisely defined ArchiMate models facilitate the gap analysis between baseline and target.

For the business architecture (Phase B), ArchiMate can be used to model, e.g., the organization structure, products and business services, the business functions, the main business processes and their relationships (see Figure 13 for an example), business objects, etc. In our example, the business architecture of ArchiSurance does not change; i.e., baseline and target are the same. In this case, the business architecture is used only as context for the other architectures.

AcceptRegister PayValuate

Handle Claim

DamageOccured

CreateContract

FormaliseRequest

Check and Sign Contract

Close Contract

Request forInsurance

Insurancepolicy

Figure 13: Fragment of the Business Architecture

The main differences between baseline and target are in the application architecture (part of the information systems architecture, Phase C). These architectures are shown in Figure 14 and Figure 15, which show the main applications, their relationships, and the application functions offered by the back-office application(s).



Claimdata mgt.

Policydata mgt.

Riskassess-

ment

Home & Awaypolicy administration

Premiumcollection

Claimpayment

Home & Awayfinancial application

Claimdata mgt.

Policydata mgt.

Claimpayment

Premiumcollection

Car insuranceapplication

Claimdata mgt.

Policydata mgt.

Premiumcollection

Claimpayment

Legal aidback-office system


Customer Relations Management system

Call centerapplication

Legal Aid CRM system

Web portal

Figure 14: Baseline Application Architecture

Claimdata mgt.

Policydata mgt.

Riskassess-

mentPremiumcollection

Claimpayment

ArchiSurance back-office system


ArchiSuranceCustomer Relations Management system


Web portal

Figure 15: Target Application Architecture

Once the baseline and target application architectures have been modeled, a gap analysis can be performed, highlighting the differences between the two. The results can be presented in a gap matrix, as described in the TOGAF ADM Guidelines & Techniques; alternatively, they can be shown graphically; e.g., using colors, as shown in Figure 16.



Claimdata mgt.

Policydata mgt.

Riskassess-

ment

ArchiSuranceback-office system

Premiumcollection

Claimpayment

Home & Awayfin. application

Claimdata mgt.

Policydata mgt.

Claimpayment

Premiumcollection


Claimdata mgt.

Policydata mgt.

Premiumcollection

Claimpayment



ArchiSuranceCustomer Relations Management system


Legal Aid CRM system

Web portal

both in Baseline and Target application architectureonly in Baseline application architectureother parent

both in Baseline and Target application architectureonly in Baseline application architectureother parent

Figure 16: Application Architecture: Gap Analysis

ArchiMate is also perfectly suited to model the relationships between the different architectures. As an example, Figure 17 shows how the business architecture and the application architecture are aligned, by modeling which sub-processes make use of which application services.

DamageOccured AcceptRegister PayValuate

Handle Claim

ArchiSuranceback-office

system


Documentmanagement

system

Acceptcall

Storedocument

Registerclaim

Enterassessment

Calculateamount Pay

Figure 17: Business-Application Alignment

The data architecture (also part of the information systems architecture, Phase C) of ArchiSurance does not change; i.e., baseline and target are the same. Figure 18 shows a fragment of this architecture.

Customer File

Damage ClaimInsurance Policy

Customer

InsuranceRequest

Legal aid Insurance Policy

Liability Insurance Policy

Travel Insurance Policy

Car Insurance Policy HomeInsurance Policy

Figure 18: Data Architecture

For the baseline technology architecture (Phase D), we assume that there are separate application servers for the different back-office applications (see Figure 19).



Home & Awayapplication server

Carapplication server

Legal aidapplication server

Legal aidbackofficeapplication

Legal aidCRM

application

Home & Awaypolicy admin.

Home & Awayfinancial app.

Carinsuranceapplication

Web server

Webportal

Genericapplication server

DMSapplication

CRMapplication

Callcenter

application

ArchiSuranceLAN

Figure 19: Baseline Technology Architecture

In the target technology architecture, the back-office application will run on a single application server. However, in order to improve the reliability and availability of the application, a back-up application server for the back-office is introduced (see Figure 20).

ArchiSurancebackoffice

back-up server


server

ArchiSurancebackofficeapplication

Web server

Webportal


DMSapplication

CRMapplication

Callcenter

application

ArchiSuranceLAN

Figure 20: Target Technology Architecture

Again, we can show the results of the gap analysis between the baseline and target application architectures graphically, as illustrated in Figure 21.



Home & Awayapplication server


server

ArchiSurancebackofficeapplication

Legal aidCRM

application

Home & Awaypolicy admin.

Home & Awayfinancial app.

Carinsuranceapplication

Web server

Webportal


DMSapplication

CRMapplication

Callcenter

application

ArchiSuranceLAN

Carapplication server


back-up server

both in Baseline and Target application architectureonly in Baseline application architectureonly in Target application architecture

both in Baseline and Target application architectureonly in Baseline application architectureonly in Target application architecture

Figure 21: Technology Architecture: Gap Analysis

Phase E: Opportunities and Solutions and Phase F: Migration Planning

An important concept that TOGAF 9 introduces for Phases E and F is the transition architecture, representing a possible intermediary situation (“plateau”) between the baseline architecture and the target architecture. For example, in the ArchiSurance case, we can imagine a situation in which the two CRM applications have been replaced by a single application, but in which there are still separate back-office systems; an alternative transition architecture may represent a situation with a single back-office system, but still two separate CRM applications. Figure 22 illustrates this.

Claimdata mgt.

Policydata mgt.

Riskassess-

ment


systemPremiumcollection

Claimpayment


Claimdata mgt.

Policydata mgt.

Claimpayment

Premiumcollection


Claimdata mgt.

Policydata mgt.

Premiumcollection

Claimpayment


Documentmanagement

system

ArchiSuranceCRM

system


Webportal


Webportal

ArchiSuranceCRM

system

Documentmanagement

system

Claimdata mgt.

Policydata mgt.

Riskassess-


Claimpayment


system

Legal AidCRM system

Claimdata mgt.

Policydata mgt.

Riskassess-

ment


systemPremiumcollection

Claimpayment


Claimdata mgt.

Policydata mgt.

Claimpayment

Premiumcollection


Claimdata mgt.

Policydata mgt.

Premiumcollection

Claimpayment


Documentmanagement

system

ArchiSuranceCRM

system


Legal AidCRM system

Webportal

Claimdata mgt.

Policydata mgt.

Riskassess-


Claimpayment


system

Documentmanagement

system

ArchiSuranceCRM

system


Webportal

Figure 22: Transition Architectures

Based on these transition architectures, implementation projects can be planned. For example, we can define a project for the integration of the CRM applications, and a project for the integration of the back-office applications. The order in which these projects are carried out depends on which of the transition architectures is selected.

Phase G: Implementation Governance

In the Implementation Governance phase, the developed architectures (baseline, target, and transition) are used as a steering mechanism for the implementation projects. They form the basis for, among others, architecture compliance reviews.



Phase H: Architecture Change Management

Well-defined architecture models help to get a better grip on the architecture change management process in general. Conversely, changes in the ArchiMate models created throughout the ADM should also be governed by the architecture change management process.

Requirements Management

Requirements management has a central position in the ADM cycle, concerned with establishing and maintaining requirements for the architectures to be developed in general, which may be (partly) documented as ArchiMate models. The current version of ArchiMate does not have facilities to express the requirements themselves.

Summary

Figure 23 illustrates which phases of the ADM can be (completely or partly) supported by ArchiMate models. The use of ArchiMate is most prominent in Phases B, C, and D, in which the actual architectures are created. Preparations for the use of ArchiMate take place in the Preliminary Phase and Phase A. In the later phases (E through H), the created ArchiMate models are used to prepare and govern the implementation of the target architecture.

Prelim.

A

Reqs.Mgt.

E

G C

B

DF

H

Prelim.

A

Reqs.Mgt.

E

G C

B

DF

H

Figure 23: Summary of ArchiMate Coverage of the ADM



Conclusions TOGAF has been for more than a decade the world’s leading (enterprise) architecture method. ArchiMate has recently been adopted as an Open Group standard for modeling enterprise architectures. TOGAF and ArchiMate overlap in their use of viewpoints, and the concept of an underlying common repository of architectural artifacts and models; i.e., they have a firm common foundation. However, they complement each other with respect to the definition of an architecture development process and the definition of an enterprise architecture modeling language.

ArchiMate Version 1.0 chiefly supports modeling of the architectures in Phases B, C, and D of the TOGAF ADM. The resulting models are used as input for the subsequent ADM phases. However, modeling concepts specifically aimed at the other phases – e.g., concepts for modeling principles, goals and requirements, or concepts to support migration planning – are still missing in the language. This observation points in a direction for possible language extensions in future versions of ArchiMate.



References 1. ISO/IEC 42010:2007, Systems and Software Engineering – Recommended Practice for Architectural

Description of Software-Intensive Systems, Edition 1.

2. 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):257–288.

3. Enterprise Architecture at Work, M.M. Lankhorst et al, Springer-Verlag, Berlin; 2005.

4. Enterprise Architecture Development and Modeling, M.M. Lankhorst, H. van Drunen, Via Nova Architectura, March 21, 2007.

5. Unified Modeling Language (UML), Version 2.1.2: Superstructure, Object Management Group (OMG), formal/07-11-02, November 2007.

6. Extending and Formalizing the Framework for Information Systems Architecture, J.F. Sowa, J.A. Zachman, IBM Systems Journal, 1992:31(3);590-616.

7. TOGAF Version 9, The Open Group, published by Van Haren Publishing, 2009.

8. ArchiMate 1.0 Specification, The Open Group, published by Van Haren Publishing, 2009.

9. TOGAF and ArchiMate: A Future Together, H. Jonkers, E. Proper, M. Turner, White Paper (W192), published by The Open Group, September 2009.

10. A Framework for Information Systems Architecture, J.A. Zachman, IBM Systems Journal, Vol. 26, No. 3, 1987, pp. 267-292.



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 8 and 9 certified.

Erik Proper is Professor in Information Systems at the Radboud University Nijmegen and leader of the Architecture Service-Line at Capgemini in the Netherlands. Erik divides his time between doing research on architecture and modeling-related topics with his team at the University, and helping organizations in growing their enterprise architecture capabilities. Erik was one of the initiators of the ArchiMate project and co-author of the ArchiMate 1.0 Specification, and is currently vice-chair of The Open Group ArchiMate Forum. He is also TOGAF 8 and 9 certified.

Mike Turner is an Enterprise Architect at Capgemini and has been focusing exclusively on enterprise architecture for the past six years. Mike spends his time helping organizations to grow enterprise architecture capabilities and assisting organizations in the realization of strategic change through the use of enterprise architecture. Mike has a deep understanding of enterprise architecture frameworks, leading Capgemini’s development effort on TOGAF Version 9 and also working in the core team that developed the SAP Enterprise Architecture Framework (a joint initiative between Capgemini and SAP).

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 www.opengroup.org.

http://www.opengroup.org/

Documents

TOGAF 9 and ArchiMate 1