Open Group Standard ArchiMate

(1)

Open Group Standard

ArchiMate

^®

2.0 Specification

(2)

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 owner.

It is fair use of this specification for implementers to use the names, labels, etc. contained within the specification. The intent of publication of the specification is to encourage implementations of the specification.

Technical Standard

ArchiMate^® 2.0 Specification

ISBN: 1-937218-00-3 Document Number: C118

Published by The Open Group, January 2012.

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

The Open Group Apex Plaza Forbury Road Reading

Berkshire, RG1 1AX United Kingdom or by electronic mail to:

ogspecs@opengroup.org

(3)

Table of Figures

Figure 1: Metamodels at Different Levels of Specificity ... 3

Figure 2: Generic Metamodel: The Core Concepts of ArchiMate ... 5

Figure 3: Collaboration and Interaction ... 6

Figure 4: Architectural Framework ... 7

Figure 5: Relationship between Core and Motivational Elements in ArchiMate ... 9

Figure 6: Relationships between Motivational, Core, and Implementation and Migration Elements ... 11

Figure 7: Correspondence between ArchiMate and TOGAF ... 12

Figure 8: Correspondence between ArchiMate (including extensions) and TOGAF ... 13

Figure 9: Business Layer Metamodel ... 14

Figure 10: Business Actor Notation ... 16

Figure 11: Business Role Notation ... 17

Figure 12: Business Collaboration Notation ... 18

Figure 13: Business Interface Notation ... 19

Figure 14: Location Notation ... 19

Figure 15: Business Object Notation ... 20

Figure 16: Business Process Notation ... 22

Figure 17: Business Function Notation ... 24

Figure 18: Business Interaction Notation ... 25

Figure 19: Business Event Notation ... 26

Figure 20: Business Service Notation ... 27

Figure 21: Representation Notation ... 30

Figure 22: Meaning Notation ... 31

Figure 23: Value Notation ... 32

Figure 24: Product Notation ... 33

Figure 25: Contract Notation ... 34

Figure 26: Application Layer Metamodel ... 37

Figure 27: Application Component Notation ... 38

Figure 28: Application Collaboration Notation ... 39

Figure 29: Application Interface Notation ... 40

Figure 30: Data Object Notation ... 41

Figure 31: Application Function Notation ... 42

Figure 32: Application Interaction Notation ... 43

Figure 33: Application Service Notation ... 44

Figure 34: Technology Layer Metamodel ... 47

Figure 35: Node Notation ... 48

Figure 36: Device Notation ... 49

Figure 37: System Software Notation ... 50

Figure 38: Infrastructure Interface Notations ... 51

(8)

Figure 39: Network Notation, as Connection and as Box ... 52

Figure 40: Communication Path Notation, as Connection and as Box ... 52

Figure 41: Infrastructure Function Notation ... 53

Figure 42: Infrastructure Interface Notation ... 54

Figure 43: Artifact Notation ... 55

Figure 44: Relationships between Business Layer and Lower Layer Concepts ... 58

Figure 45: Relationships between Application Layer and Technology Layer Concepts 59 Figure 46: Composition Notation ... 60

Figure 47: Aggregation Notation ... 61

Figure 48: Assignment Notation ... 62

Figure 49: Realization Notation ... 62

Figure 50: Used By Notation ... 63

Figure 51: Access Notation ... 64

Figure 52: Association Notation ... 65

Figure 53: Triggering Notation ... 65

Figure 54: Flow Notation ... 66

Figure 55: Grouping Notation ... 67

Figure 56: Junction Notation ... 68

Figure 57: Specialization Notation ... 68

Figure 58: Conceptual Model of Architectural Description (from [1]) ... 75

Figure 59: Classification of Enterprise Architecture Viewpoints ... 77

Figure 60: More Examples of Specialized Concepts ... 117

Figure 61: Motivation Extension Metamodel ... 118

Figure 62: Stakeholder Notation ... 119

Figure 63: Driver Notation ... 120

Figure 64: Assessment Notation ... 121

Figure 65: Goal Notation ... 122

Figure 66: Requirement Notation ... 123

Figure 67: Constraint Notation ... 124

Figure 68: Principle Notation ... 126

Figure 69: Aggregation Notation ... 127

Figure 70: Realization Notation ... 128

Figure 71: Influence Notation ... 130

Figure 72: Relationships between Motivation Extension and the ArchiMate Core Concepts ... 131

Figure 73: Implementation and Migration Extension Metamodel ... 145

Figure 74: Work Package Notation ... 145

Figure 75: Deliverable Notation ... 146

Figure 76: Plateau Notation ... 147

Figure 77: Gap Notation ... 148

Figure 78: Relationships between Implementation & Migration Extension and the ArchiMate Core Concepts ... 149

Figure 79: Relationships between Plateau, Deliverable, and Motivation Concepts ... 150

(9)

Preface

The Open Group

The Open Group is a global consortium that enables the achievement of business objectives through IT standards. With more than 400 member organizations, The Open Group has a diverse membership that spans all sectors of the IT community – customers, systems and solutions suppliers, tool vendors, integrators, and consultants, as well as academics and researchers – to:

• Capture, understand, and address current and emerging requirements, and establish policies and share best practices

• Facilitate interoperability, develop consensus, and evolve and integrate specifications and open source technologies

• Offer a comprehensive set of services to enhance the operational efficiency of consortia

• Operate the industry’s premier certification service

Further information on The Open Group is available at www.opengroup.org.

The Open Group publishes a wide range of technical documentation, most of which is focused on development of Open Group Standards and Guides, but which also includes white papers, technical studies, certification and testing documentation, and business titles. Full details and a catalog are available at www.opengroup.org/bookstore.

Readers should note that updates – in the form of Corrigenda – may apply to any publication.

This information is published at www.opengroup.org/corrigenda.

This Document

This document is The Open Group Standard for the ArchiMate 2.0 Specification.

Issue 2.0 includes a number of corrections, clarifications, and improvements compared to the previous issue, as well as two optional language extensions: the Motivation extension and the Implementation and Migration extension.

Intended Audience

The intended audience of this Technical Standard is threefold:

• Enterprise architecture practitioners, such as architects (application, information, process, infrastructure, products/services, and, obviously, enterprise architects), senior and operational management, project leaders, and anyone committed to work within the reference framework defined by the enterprise architecture. It is assumed that the reader has a certain skill level and is effectively committed to enterprise architecture. Such a

(10)

person is most likely the architect – that is, someone who has affinity with modeling techniques, knows his way around the organization, and is familiar with information technology.

• Those who intend to implement ArchiMate in a software tool. They will find a complete and detailed description of the language in this document.

• The academic community, on which we rely for amending and improving the language based on state-of-the-art research results in the architecture field.

Structure

The structure of this Technical Standard is as follows:

• Chapter 1, Introduction, provides a brief introduction to the purpose of this standard.

• Chapter 2, Language Structure, presents some general ideas, principles, and assumptions underlying the development of the ArchiMate metamodel and introduces the ArchiMate framework.

• Chapter 3, Business Layer, covers the definition and usage of the business layer concept, together with examples.

• Chapter 4, Application Layer, covers the definition and usage of the application layer concept, together with examples.

• Chapter 5, Technology Layer, covers the definition and usage of the technical infrastructure layer concept, together with examples.

• Chapter 6, Cross-Layer Dependencies, and Chapter 7, Relationships, cover the definition of relationship concepts in a similar way.

• Chapter 8, Architecture Viewpoints, 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 and of the viewpoint are specified. Furthermore, each viewpoint description contains example models.

• Chapter 9, Language Extension Mechanisms, handles extending and/or specializing the ArchiMate language for specialized or domain-specific purposes.

• Chapter 10, Motivation Extension, describes an optional language extension with concepts, relationships, and viewpoints for expressing the motivation for an architecture (e.g., stakeholders, concerns, goals, principles, and requirements).

• Chapter 11, Implementation and Migration Extension, describes an optional language extension with concepts, relationships, and viewpoints for expressing the implementation and migration aspects of an architecture (e.g., project, programs, plateaus, and gaps).

• Chapter 12, Future Directions, is an informative chapter that identifies extensions and directions for developments in the next versions of the language.

(11)

Trademarks

Boundaryless Information Flow™ is a trademark and ArchiMate^®, Jericho Forum^®, Making Standards Work^®, Motif^®, OSF/1^®, The Open Group^®, TOGAF^®, UNIX^®, and the “X” device are registered trademarks of The Open Group in the United States and other countries.

Java^® is a registered trademark of Oracle and/or its affiliates.

MDA^®, Model Driven Architecture^®, OMG^®, and UML^® are registered trademarks and BPMN™, Business Process Modeling Notation™, MOF™, and Unified Modeling Language™

are trademarks of the Object Management Group..

All other brands, company, and product names are used for identification purposes only and may be trademarks that are the sole property of their respective owners.

(12)

Acknowledgements

The Open Group gratefully acknowledges the contribution of the following people in the development of this Open Group Standard:

• Maria-Eugenia Iacob, University of Twente

• Henk Jonkers, BiZZdesign BV

• Marc M. Lankhorst, Novay

• Erik (H.A.) Proper, Public Research Centre Henri Tudor & Radboud University Nijmegen

• Dick A.C. Quartel, BiZZdesign BV

The Open Group and ArchiMate project team would like to thank in particular the following individuals for their support and review of this Open Group Standard:

• Iver Band, Standard Insurance Company

• Mary Beijleveld, UWV

• Alexander Bielowski, Software AG

• Adrian Campbell, Ingenia Consulting

• John Coleshaw, QA Ltd.

• Jörgen Dahlberg, Biner Consulting

• Garry Doherty, The Open Group

• Wilco Engelsman, BiZZdesign BV

• Roland Ettema, Logica

• Henry M. Franken, BiZZdesign BV

• Kirk Hansen, Kirk Hansen Consulting

• Jos van Hillegersberg, University of Twente

• Andrew Josey, The Open Group

• Louw Labuschagne, Real IRM

• Veer Muchandi, Hewlett-Packard

• Bill Poole, JourneyOne

• Henk Volbeda, Sogeti

(13)

• Egon Willemsz, UWV

The results presented in this Open Group Standard have largely been produced during the ArchiMate project, and The Open Group gratefully acknowledges the contribution of the many people – former members of the project team – who have contributed to them.

The ArchiMate project comprised the following organizations:

• ABN AMRO

• Centrum voor Wiskunde en Informatica

• Dutch Tax and Customs Administration

• Leiden Institute of Advanced Computer Science

• Ordina

• Radboud Universiteit Nijmegen

• Stichting Pensioenfonds ABP

• Novay

(14)

Referenced Documents

The following documents are referenced in this Open Group Standard:

[1] ISO/IEC 42010:2007, Systems and Software Engineering – Recommended Practice for Architectural Description of Software-Intensive Systems, Edition 1.

[2] Enterprise Architecture at Work: Modeling, Communication, and Analysis, M.M. Lankhorst et al, Springer, 2005.

[3] Architecture Principles: The Cornerstones of Enterprise Architecture, D. Greefhorst, E. Proper, Springer, 2011.

[4] The Open Group Architecture Framework TOGAF, Version 9, 2009.

[5] A Framework for Information Systems Architecture, J.A. Zachman, IBM Systems Journal, Volume 26, No. 3, pp. 276–292, 1987.

[6] ITU Recommendation X.901 | ISO/IEC 10746-1:1998, Information Technology – Open Distributed Processing – Reference Model – Part 1: Overview, International Telecommunication Union, 1996.

[7] Unified Modeling Language: Infrastructure, Version 2.0 (formal/05-05-05), Object Management Group, March 2006.

[8] Extending and Formalizing the Framework for Information Systems Architecture, J.F. Sowa, J.A. Zachman,, IBM Systems Journal, Volume 31, No. 3, pp. 590-616, 1992.

[9] Enterprise Ontology: Theory and Methodology, J.L.G. Dietz, Springer, 2006.

[10] Unified Modeling Language: Superstructure, Version 2.0 (formal/05-07-04), Object Management Group, August 2005.

[11] A Business Process Design Language, H. Eertink, W. Janssen, P. Oude Luttighuis, W. Teeuw, C. Vissers, in Proceedings of the First World Congress on Formal Methods, Toulouse, France, September 1999.

[12] Enterprise Business Architecture: The Formal Link between Strategy and Results, R. Whittle, C.B. Myrick, CRC Press, 2004.

[13] Composition of Relations in Enterprise Architecture, R.v. Buuren, H. Jonkers, M.E. Iacob, P. Strating, in Proceedings of the Second International Conference on Graph Transformation, pp. 39–53, Edited by H. Ehrig et al, Rome, Italy, 2004.

[14] Viewpoints: A Framework for Integrating Multiple Perspectives in System

Development, A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein, M. Goedicke,

(15)

in International Journal on Software Engineering and Knowledge Engineering, Volume 2, No. 1, pp. 31–58, 1992.

[15] Viewpoints for Requirements Definition, G. Kotonya, I. Sommerville, IEE/BCS Software Engineering Journal, Volume 7, No. 6, pp. 375–387, November 1992.

[16] Paradigm Shift – The New Promise of Information Technology, D. Tapscott, A. Caston, New York: McGraw-Hill, 1993.

[17] The 4+1 View Model of Architecture, P.B. Kruchten, IEEE Software, Volume 12, No. 6, pp. 42–50, 1995.

[18] Model-Driven Architecture: Applying MDA to Enterprise Computing, D. Frankel, Wiley, 2003.

[19] Performance and Cost Analysis of Service-Oriented Enterprise Architectures, H. Jonkers, M. E. Iacob, in Global Implications of Modern Enterprise Information Systems: Technologies and Applications, Edited by A. Gunasekaran, IGI Global, 2009.

[20] Business Process Modeling Notation Specification (dtc/06-02-01), Object Management Group, February 2006.

[21] The Chaos Report, The Standish Group, 1994.

[22] No Silver Bullet: Essence and Accidents of Software Engineering, F.P. Brooks, IEEE Computer, 20(4):10–19, 1987.

[23] Managing Successful Programs, Office of Government Commerce (OGC), Stationery Office Books, 2007.

[24] Managing Successful Projects with PRINCE2 – 2009 Edition, Office of Government Commerce (OGC), Stationery Office Books, 2009.

[25] A Guide to the Project Management Body of Knowledge (PMBoK Guide), Fourth Edition, Project Management Institute, 2009.

(16)

(17)

1 Introduction

An architecture is typically developed because key people have concerns that need to be addressed by the business and IT systems within the organization. Such people are commonly referred to as the “stakeholders” in the system. The role of the architect is to address these concerns, by identifying and refining the requirements that the stakeholders have, developing views of the architecture that show how the concerns and the requirements are going to be addressed, and by showing the trade-offs that are going to be made in reconciling the potentially conflicting concerns of different stakeholders. Without the architecture, it is unlikely that all the concerns and requirements will be considered and met.

Architecture descriptions are formal descriptions of an information system, organized in a way that supports reasoning about the structural and behavioral properties of the system and its evolution. They define the components or building blocks that make up the overall information system, and provide a plan from which products can be procured, and subsystems developed, that will work together to implement the overall system. It thus enables you to manage your overall IT investment in a way that meets the needs of your business.

To provide a uniform representation for diagrams that describe enterprise architectures, the ArchiMate enterprise architecture modeling language has been developed. It offers an integrated architectural approach that describes and visualizes the different architecture domains and their underlying relations and dependencies.

ArchiMate is a lightweight and scalable language in several respects:

• Its architecture framework is simple but comprehensive enough to provide a good structuring mechanism for architecture domains, layers, and aspects.

• The language incorporates the concepts of the “service orientation” paradigm that

promotes a new organizing principle in terms of (business, application, and infrastructure) services for organizations, with far-reaching consequences for their enterprise

architecture.

The role of the ArchiMate standard is to provide a graphical language for the representation of enterprise architectures over time (i.e., including transformation and migration planning), as well as their motivation and rationale. The evolution of the standard is closely linked to the developments of the TOGAF standard and the emerging results from The Open Group forums and work groups active in this area. As a consequence, the ArchiMate standard does not provide its own set of defined terms, but rather follows those provided by the TOGAF standard.

This is Issue 2.0 of the Technical Standard, which contains a number of corrections, improvements, and clarifications in the description of the core language as described in Issue 1.0, as well as two optional extensions of the language: the Motivation extension and the Implementation and Migration extension.

(18)

This specification contains the formal definition of ArchiMate as a visual design language with adequate concepts for specifying inter-related architectures, and specific viewpoints for selected stakeholders. This is complemented by some considerations regarding language extension mechanisms, analysis, and methodological support. Furthermore, this document is accompanied by a separate document, in which certification and governance procedures surrounding the specification are specified.

(19)

2 Language Structure

The unambiguous specification and description of enterprise architecture’s components and especially of their relationships requires an architecture modeling language that addresses the issue of consistent alignment and facilitates a coherent modeling of enterprise architectures.

This chapter presents the construction of the ArchiMate architecture modeling language. The precise definition and illustration of its generic set of core concepts and relationships follow in Chapters 4, 5, 6, 7, and 8. The concepts and relationships of the two language extensions are described in more detail in Chapters 10 and 11. They provide a proper basis for visualization, analysis, tooling, and use of these concepts and relationships.

Sections 2.1 through 2.5 discuss some general ideas, principles, and assumptions underlying the development of the ArchiMate metamodel. Section 2.6 presents the ArchiMate framework, which is used in the remainder of this document as a reference taxonomy scheme for architecture concepts, models, viewpoints, and views. Sections 2.7 and 2.8 describe the basic structure of the two language extensions. Section 2.9 briefly describes the relationship between ArchiMate and TOGAF.

2.1 Design Approach

A key challenge in the development of a general metamodel for enterprise architecture is to strike a balance between the specificity of languages for individual architecture domains, and a very general set of architecture concepts, which reflects a view of systems as a mere set of inter- related entities. Figure 1 illustrates that concepts can be described at different levels of specialization.

Process Application

Domain- and company- specific concepts Enterprise architecture

concepts Generic concepts

more generic more specific ^Entity

Relation

Figure 1: Metamodels at Different Levels of Specificity

At the base of the triangle we find the metamodels of the architecture modeling concepts used by

(20)

is an example of a language in this category. At the top of the triangle we find the “most general” metamodel for system architectures, essentially a metamodel that merely comprises notions such as “entity” and “relation”.

The design of the ArchiMate language started from a set of relatively generic concepts (higher up in the pyramid). These have been specialized towards application at different architectural layers, as explained below in the following sections.

The most important design restriction on the language is that it has been explicitly designed to be as small as possible, but still usable for most enterprise architecture modeling tasks. Many other languages, such as UML 2.0, try to accommodate all needs of all possible users. In the interest of simplicity of learning and use, ArchiMate has been limited to the concepts that suffice for modeling the proverbial 80% of practical cases.

2.2 Core Concepts

The core language consists of three main types of elements (note, however, that the model elements often represent classes of entities in the real world): active structure elements, behavior elements, and passive structure elements (objects). The active structure elements are the business actors, application components, and devices that display actual behavior; i.e., the

‘subjects’ of activity (right side of the Figure 2).

An active structure element is defined as an entity that is capable of performing behavior.

Then there is the behavioral or dynamic aspect (center of Figure 2). The active structure concepts are assigned to behavioral concepts, to show who or what performs the behavior.

A behavior element is defined as a unit of activity performed by one or more active structure elements.

The passive structure elements are the objects on which behavior is performed.

A passive structure element is defined as an object on which behavior is performed.

In the domain of information-intensive organizations, which is the main focus of the language, passive structure elements are usually information or data objects, but they may also be used to represent physical objects. These three aspects – active structure, behavior, and passive structure – have been inspired by natural language, where a sentence has a subject (active structure), a verb (behavior), and an object (passive structure).

Second, we make a distinction between an external view and an internal view on systems. When looking at the behavioral aspect, these views reflect the principles of service orientation.

A service is defined as a unit of functionality that a system exposes to its environment, while hiding internal operations, which provides a certain value (monetary or otherwise).

(21)

Figure 2: Generic Metamodel: The Core Concepts of ArchiMate¹

Thus, the service is the externally visible behavior of the providing system, from the perspective of systems that use that service; the environment consists of everything outside this providing system. The value provides the motivation for the service’s existence. For the external users, only this exposed functionality and value, together with non-functional aspects such as the quality of service, costs, etc., are relevant. These can be specified in a contract or Service Level Agreement (SLA). Services are accessible through interfaces, which constitute the external view on the active structural aspect.

An interface is defined as a point of access where one or more services are made available to the environment.

An interface provides an external view on the service provider and hides its internal structure.

2.3 Collaboration and Interaction

Going one level deeper in the structure of the language, we distinguish between behavior that is performed by a single structure element (e.g., actor, role component, etc.), or collective behavior (interaction) that is performed by a collaboration of multiple structure elements.

A collaboration is defined as a (temporary) grouping (or aggregation) of two or more structure elements, working together to perform some collective behavior.

This collective behavior can be modeled as an interaction.

1In this figure, and all the other metamodel pictures in this document, a convention for role names of relationships is used that is similar to UML (but using verbs instead of nouns). For example, a Behavior Element realizes a Service, and a Service is realized by a Behavior Element. If no cardinality is shown for a relationship end, a default of 0..* (zero or more) is assumed; if the default does not

(22)

An interaction is defined as a unit of behavior performed by a collaboration of two or more structure elements.

Figure 3: Collaboration and Interaction

2.4 Relationships

Next to the core concepts outlined above, ArchiMate contains a core set of relationships. Several of these relationships have been adopted from corresponding relationship concepts that occur in existing standards; e.g., relationships such as composition, aggregation, association, and specialization are taken from UML 2.0, while triggering is used in many business process modeling languages.

Note: For the sake of readability, the metamodel figures in the next sections do not show all possible relationships in the language. Refer to Section 7.5 on additional derived relationships. Furthermore, aggregation, composition, and specialization relationships are always permitted between two elements that have the same type.

2.5 Layering

The ArchiMate language defines three main layers (depicted with different colors in the examples in the next chapters), based on specializations of the core concepts described in Sections 2.2 and 2.3:

1. The Business Layer offers products and services to external customers, which are realized in the organization by business processes performed by business actors.

2. The Application Layer supports the business layer with application services which are realized by (software) applications.

3. The Technology Layer offers infrastructure services (e.g., processing, storage, and communication services) needed to run applications, realized by computer and communication hardware and system software.

The general structure of models within the different layers is similar. The same types of concepts and relationships are used, although their exact nature and granularity differ. In Chapters 3, 4, and 5, we further develop these concepts to obtain concepts specific to a particular layer. Figure 2 shows the central structure that is found in each layer.

(23)

In line with service orientation, the most important relationship between layers is formed by

“used by” relationships, which show how the higher layers make use of the services of lower layers. (Note, however, that services need not only be used by elements in a higher layer, but also can be used by elements in the same layer.) A second type of link is formed by realization relationships: elements in lower layers may realize comparable elements in higher layers; e.g., a

“data object” (Application layer) may realize a “business object” (Business layer); or an

“artifact” (Technology layer) may realize either a “data object” or an “application component”

(Application layer).

2.6 The ArchiMate Framework

The aspects and layers identified in the previous sections can be organized as a framework of nine “cells”, as illustrated in Figure 4.

It is important to realize that the classification of concepts based on aspects and layers is only a global one. It is impossible to define a strict boundary between the aspects and layers, because concepts that link the different aspects and layers play a central role in a coherent architectural description. For example, running somewhat ahead of the later conceptual discussions, (business) functions and (business) roles serve as intermediary concepts between “purely behavioral” concepts and “purely structural” concepts.

Technology Application

Business Environment

Passive

structure Behavior Active

structure

Figure 4: Architectural Framework

Besides the core aspects shown in Figure 4 (passive structure, behavior, and active structure), which are mainly operational in nature, the work of an enterprise architect touches upon numerous other aspects, not explicitly covered by the ArchiMate framework, some of which may cross several (or all) conceptual domains; for example:

• Goals, principles, and requirements

• Risk and security

• Governance

• Policies and business rules

(24)

• Costs

• Performance

• Timing

• Planning and evolution

Not all of these aspects can be completely covered using the standard language extension mechanisms as described in Chapter 9. In order to facilitate tool vendors and methodology experts in providing support for these aspects within the overall ArchiMate language, specific extensions can be added. These modular extension add new concepts, relationships, or attributes, while complying to the design restriction that ArchiMate is explicitly designed to be as small as possible.

Also, it may be useful to add concepts or attributes related to the design process rather than to the system or organization that is to be described or designed. Examples of such concepts or attributes are requirements and design decisions.

This new issue of the specification addresses two such extensions: the Motivation extension and the Implementation and Migration extension. The Motivation extension is introduced in the next section and elaborated in more detail in Chapter 10. The Implementation and Migration extension is introduced in Section 2.8 and elaborated in more detail in Chapter 11. Other aspects may be addressed in future extensions of the language (see Chapter 12 for a more thorough discussion of this).

2.7 Motivation Extension

The core concepts of ArchiMate focus on describing the architecture of systems that support the enterprise. Not covered are the elements which, in different ways, motivate the design and operation of the enterprise. These motivational aspects correspond to the “Why” column of the Zachman framework [8], which was intentionally left out of scope in the design of ArchiMate 1.0.

The Motivation extension of ArchiMate adds the motivational concepts such as goal, principle, and requirement. It addresses the way the enterprise architecture is aligned to its context, as described by motivational elements.

A motivational element is defined as an element that provides the context or reason lying behind the architecture of an enterprise.

In addition, the Motivation extension recognizes the concepts of stakeholders, drivers, and assessments. Stakeholders represent (groups of) persons or organizations that influence, guide, or constrain the enterprise. Drivers represent internal or external factors which influence the plans and aims of an enterprise. An understanding of strengths, weaknesses, opportunities, and threats in relation to these drivers will help the formation of plans and aims to appropriately address these issues.

Figure 5 depicts that the core elements of an architectural description are related to motivational elements via requirements. Goals and principles have to be translated into requirements before

(25)

core elements, such as services, processes, and applications, can be assigned that realize them.

The possible relationships among motivational elements are explained in Chapter 10.

Another relationship between the core metamodel and the Motivation extension is that a business actor may be assigned to a stakeholder, which can be seen as a motivational role (as opposed to an operational business role) that an actor may fulfill.

The main reason to introduce motivational concepts in ArchiMate is to support requirements management and to support the Preliminary Phase and Phase A (Architecture Vision) of the TOGAF ADM, which establish the high-level business goals, architecture principles, and initial business requirements.

Requirements management is an important activity in the process of designing and managing enterprise architectures. Goals from various stakeholders form the basis for any change to an organization. These goals need to be translated into requirements on the organization’s architecture. This architecture should reflect how the requirements are realized by services, processes, and software applications in the day-to-day operations. Therefore, the quality of the architecture is largely determined by the ability to capture and analyze the relevant goals and requirements, the extent to which they can be realized by the architecture, and the ease with which goal and requirements can be changed.

Figure 5: Relationship between Core and Motivational Elements in ArchiMate

Principles and requirements are strongly related [3]. Principles are general rules and guidelines that help inform and support the way in which an organization sets about fulfilling its mission. In contrast, requirements constrain and shape a specific design of some enterprise architecture. This corresponds to the distinction between two commonly used interpretations of enterprise architecture: (i) as the structure of some organization in terms of its components and their

(26)

relationships, and (ii) as a set of principles that should be applied to any such structure.² The scope of the first interpretation concerns a single design of the organization, whereas the second concerns any possible design. Requirements are associated with the first interpretation. Instead, principles are independent of a specific design and have to be specialized into requirements in the process of designing the organization’s architecture. This makes the application of principles an important part of requirements management.

Inadequate requirements management is one of the main causes of impaired or failed IT projects [21], due to exceeding budgets or deadlines, or not delivering the expected results. This is well phrased by the following quote of Brooks [22]: “No other part of the work so cripples the resulting system if done wrong”. Therefore, the requirements management process and the architecture development process need to be well-aligned, and traceability should be maintained between requirements and the architectural elements that realize these requirements.

In the TOGAF Architecture Development Method (ADM) [4], requirements management is a central process that applies to all phases of the ADM cycle. While TOGAF presents

“requirements” on requirements management, it refrains from mandating or recommending existing languages, methods, and tools from the area of requirements engineering. ArchiMate supports the requirements management process by means of the motivational concepts.

2.8 Implementation and Migration Extension

The Implementation and Migration extension of ArchiMate adds concepts 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 to support program, portfolio, and project management, and a plateau concept to support migration planning. The proposed extension aims at covering the main concepts of program and project management standards and best practices, such as MSP [23], PRINCE2 [24], and PMBoK [25].

Concepts that are specific to one of these methods are not part of the extension, but may be defined as specialization of the generic concepts. In this way, the set of concepts and relationships that are defined in the extension is kept at a minimum.

Furthermore, concepts or relationships from the ArchiMate core or the Motivation extension are re-used where possible. Figure 6 depicts the relationship between concepts from the Implementation and Migration extension and concepts from the ArchiMate core and Motivation extension. A deliverable may realize core elements within an architecture. A gap may be associated with any number of core elements. A location may be assigned to work packages and deliverables. A work package realizes requirements indirectly through the realization of core elements (e.g., an application component, business process, or service). Also, core elements are linked to the other concepts of the Motivation extension by means of derived relationships. The possible relationships among implementation and migration, core, and motivational elements are explained in more detail in Chapters 10 and 11.

2 Both interpretations are combined in the second meaning of architecture as described in Section 2.2.

(27)

Figure 6: Relationships between Motivational, Core, and Implementation and Migration Elements

2.9 ArchiMate and TOGAF

The ArchiMate language, as described in this Technical Standard, complements TOGAF [4] in that it provides a vendor-independent set of concepts, including a graphical representation, that helps to create a consistent, integrated model “below the waterline”, which can be depicted in the form of TOGAF views.

The structure of the core ArchiMate language closely corresponds with the three main architectures as addressed in the TOGAF ADM. This is illustrated in Figure 7. This correspondence would suggest a fairly easy mapping between TOGAF views and the ArchiMate viewpoints.

(28)

TOGAF ADM ArchiMate Technology Application Business

Passive structure

Behavior Active structure

Figure 7: Correspondence between ArchiMate and TOGAF

Some TOGAF views are not matched in the ArchiMate core, however. Partially, this is because the scope of TOGAF is broader and in particular addresses more of the high-level strategic issues and the lower-level engineering aspects of system development, whereas the ArchiMate core is limited to the enterprise architecture level of abstraction. However, the two language extensions, described in Chapters 10 and 11, address these additional issues. They define concepts such as goal, principle, and requirement, as well as the planning and migration-oriented concepts. Figure 8 illustrates this.

(29)

Implementation & Migration Business layer

Application layer

Technology layer

Information Behavior Structure Motivation

Phase A:

Architecture Vision Preliminary

Requirements Management Phase H:

Architecture Change Management

Phase E:

Opportunities

& Solutions Phase F:

Migration Planning Phase G:

Implementation Governance

Phase B:

Business Architecture

Phase C:

Information Systems Architectures

Phase D:

Technology Architecture

Figure 8: Correspondence between ArchiMate (including extensions) and TOGAF

Although some of the viewpoints that are defined in TOGAF cannot easily be mapped onto ArchiMate viewpoints, the ArchiMate language and its analysis techniques do support the concepts addressed in these viewpoints. While there is no one-to-one mapping between them, there is still a fair amount of correspondence between the ArchiMate viewpoints and the viewpoints that are defined in TOGAF. Although corresponding viewpoints from ArchiMate and TOGAF do not necessarily have identical coverage, we can see that many viewpoints from both methods address largely the same issues.

TOGAF and ArchiMate can easily be used in conjunction and they appear to cover much of the same ground, although with some differences in scope and approach.

(30)

3 Business Layer

3.1 Business Layer Metamodel

Figure 9 shows the metamodel of business layer concepts. The metamodel follows the structure of the generic metamodel introduced in the previous chapter. However, this layer also includes a number of additional informational concepts which are relevant in the business domain: a product and associated contract, the meaning of business objects, and the value of products and business services.

Figure 9: Business Layer Metamodel³

Note: This figure does not show all permitted relationships: every concept in the language can have composition, aggregation, and specialization relationships with concepts of

3In the metamodel pictures, we use colors to distinguish concepts belonging to the different aspects of the ArchiMate framework:

green for passive structure, yellow for behavior, and blue for active structure. In ArchiMate models, there are no formal semantics assigned to colors. However, they can be used freely to stress certain aspects in models. For instance, in the example models presented in this standard, we often use colors to distinguish between the layers of the ArchiMate framework: yellow for the business layer, blue for the application layer, and green for the technology layer.

(31)

the same type; furthermore, there are indirect relationships that can be derived, as explained in Section 7.5.

3.2 Structural Concepts

The structure aspect at the business layer refers to the static structure of an organization, in terms of the entities that make up the organization and their relationships.

Two types of entities are distinguished:

• The active entities that are the subjects (e.g., business actors or business roles) that perform behavior such as business processes or functions (capabilities). Business actors may be individual persons (e.g., customers or employees), but also groups of people (organization units) and resources that have a permanent (or at least long-term) status within the organizations. Typical examples of the latter are a department and a business unit.

• The passive entities (business objects) that are manipulated by behavior such as business processes or functions. The passive entities represent the important concepts in which the business thinks about a domain.

Architectural descriptions focus on structure, which means that the inter-relationships of entities within an organization play an important role. To make this explicit, the concept of business collaboration has been introduced. Business collaborations have been inspired by collaborations as defined in the UML 2.0 standard [7], [10], although the UML collaborations apply to components in the application layer. Also, the ArchiMate business collaboration concept has a strong resemblance to the “community” concept as defined in the RM-ODP Enterprise Language [6], as well as to the “interaction point” concept, defined in Amber [11] as the place where interactions occur.

The concept of business interfaces is introduced to explicitly model the (logical or physical) locations or channels where the services that a role offers to the environment can be accessed.

The same service may be offered on a number of different interfaces; e.g., by mail, by telephone, or through the Internet. In contrast to application modeling, it is uncommon in current business layer modeling approaches to recognize the business interface concept.

3.2.1 Business Actor

A business actor is defined as an organizational entity that is capable of performing behavior.

A business actor performs the behavior assigned to (one or more) business roles. A business actor is an organizational entity as opposed to a technical entity; i.e., it belongs to the business layer. Actors may, however, include entities outside the actual enterprise; e.g., customers and partners. Examples of business actors are humans, departments, and business units. A business actor may be assigned to one or more business roles. The name of a business actor should preferably be a noun.

(32)

Figure 10: Business Actor Notation

Example

The model below illustrates the use of business actors. The company ArchiSurance is modeled as a business actor that is composed of two departments. The Travel insurance seller role is assigned to the travel department. In this role, the travel department performs the Take out insurance process, which offers a service that is accessible via the business interface assigned to this role.

Example 1: Business Actor

3.2.2 Business Role

A business role is defined as the responsibility for performing specific behavior, to which an actor can be assigned.

Business processes or business functions are assigned to a single business role with certain responsibilities or skills. A business actor that is assigned to a business role ultimately performs the corresponding behavior. In addition to the relation of a business role with behavior, a business role is also useful in a (structural) organizational sense; for instance, in the division of labor within an organization.

A business role may be assigned to one or more business processes or business functions, while a business actor may be assigned to a business role. A business interface or an application interface may be used by a business role, while a business interface may be part of a business

(33)

role (through a composition relationship, which is not shown explicitly in the interface notation).

The name of a business role should preferably be a noun.

Figure 11: Business Role Notation

Example

In the model below, the business role Insurance Seller is fulfilled by the Insurance Department actor and has telephone as a provided interface. The business role Insurance Buyer is fulfilled by the

Customer actor, and has telephone as a required interface.

Example 2: Business Role

3.2.3 Business Collaboration

Business collaboration is defined as an aggregate of two or more business roles that work together to perform collective behavior.

A business process or function may be interpreted as the internal behavior assigned to a single business role. In some cases behavior is the collective effort of more than one business role; in fact a collaboration of two or more business roles results in collective behavior which may be more than simply the sum of the behavior of the separate roles. Business collaborations represent this collective effort. Business interactions are used to describe the internal behavior that takes place within business collaboration. A collaboration is a (possibly temporary) collection of roles within an organization which perform collaborative behavior (interactions). Unlike a department, which may also group roles, a business collaboration does not have an official (permanent) status within the organization; it is specifically aimed at a specific interaction or set of interactions between roles. However, a business collaboration can be regarded as a kind of

“virtual role”, hence its designation as a specialization of role. It is especially useful in modeling B2B interactions between different organizations.

A business collaboration may be composed of a number of business roles, and may be assigned to one or more business interactions. A business interface or an application interface may be used by a business collaboration, while a business collaboration may have business interfaces (through composition). The name of a business collaboration should preferably be a noun. It is also rather common to leave a business collaboration unnamed.

(34)

Figure 12: Business Collaboration Notation

Example

The model below illustrates a possible use of the collaboration concept. In this example, selling an insurance product involves the Sales department, fulfilling a sales support role, and a department specialized in that particular type of insurance, fulfilling an insurance seller role. The example also shows that one role, in this case Sales support, can participate in more than one collaboration.

Example 3: Business Collaboration

3.2.4 Business Interface

A business interface is defined as a point of access where a business service is made available to the environment.

A business interface exposes the functionality of a business service to other business roles (provided interface), or expects functionality from other business services (required interface). It is often referred to as a channel (telephone, internet, local office, etc.). The same business service may be exposed through different interfaces.

A business interface may be part of a business role through a composition relationship, which is not shown in the standard notation, and a business interface may be used by a business role. A business interface may be assigned to one or more business services, which means that these services are exposed by the interface. The name of a business interface should preferably be a noun.

(35)

Figure 13: Business Interface Notation

Example

In the model below, the business services provided by the Luggage insurance seller and its collaboration with the Medical insurance seller are exposed by means of a web form and call center business interface, respectively.

Example 4: Business Interface

3.2.5 Location

A location is defined as a conceptual point or extent in space.

The location concept is used to model the distribution of structural elements such as business actors, application components, and devices. This is modeled by means of an assignment relationship from location to structural element. Indirectly, a location can also be assigned to a behavior element, to indicate where the behavior is performed.

Figure 14: Location Notation

(36)

Example

The model below shows that the departments of an insurance company are distributed over different locations. The Legal and Finance departments are centralized at the main office, and there are claims handling departments at various local offices throughout the country.

Example 5: Location

3.2.6 Business Object

A business object is defined as a passive element that has relevance from a business perspective.

Business objects represent the important “informational” or “conceptual” elements in which the business thinks about a domain. Generally, a business object is used to model an object type (cf.

a UML class), of which several instances may exist within the organization. A wide variety of types of business objects can be defined. Business objects are passive in the sense that they do not trigger or perform processes.

Business objects may be accessed (e.g., in the case of information objects, which are most common in the application domains in which ArchiMate is applied, they may be created, read, written) by a business process, function, a business interaction, a business event, or a business service. A business object may have association, specialization, aggregation, or composition relationships with other business objects. A business object may be realized by a representation or by a data object (or both). The name of a business object should preferably be a noun.

Figure 15: Business Object Notation

Example

The model below shows a business object Invoice, which aggregates (multiple) business objects

Invoice line. Two possible realizations of this business object exist: an Electronic invoice (data object) and a Paper invoice (representation). The business process Create invoice creates the invoice and the invoice lines, while the business process Send invoice accesses the business object Invoice.

(37)

Example 6: Business Object

3.3 Behavioral Concepts

Based on service orientation, a crucial design decision for the behavioral part of our metamodel is the distinction between “external” and “internal” behavior of an organization.

The externally visible behavior is modeled by the concept business service. A business service represents a coherent piece of functionality that offers added value to the environment, independent of the way this functionality is realized internally. A distinction can be made between “external” business services, offered to external customers, and “internal” business services, offering supporting functionality to processes or functions within the organization.

Several types of internal behavior elements that can realize a service are distinguished. Although the distinction between the two is not always sharp, it is often useful to distinguish a process view and a function view on behavior; two concepts associated with these views, business process and business function, are defined. Both concepts can be used to group more detailed business processes/functions, but based on different grouping criteria. A business process represents a workflow or value stream consisting of smaller processes/functions, with one or more clear starting points and leading to some result. It is sometimes described as “customer to customer”, where this customer may also be an internal customer, in the case of sub-processes within an organization. The goal of such a business process is to “satisfy or delight the customer” [12]. A business function offers functionality that may be useful for one or more business processes. It groups behavior based on, for example, required skills, resources, (application) support, etc. Typically, the business processes of an organization are defined based on the products and services that the organization offers, while the business functions are the basis for, for example, the assignment of resources to tasks and the application support.

A business interaction is a unit of behavior similar to a business process or function, but which is performed in a collaboration of two or more roles within the organization. Unlike the interaction concept in Amber [11], which is an atomic unit of collaborative behavior, our business interaction can be decomposed into smaller interactions. Although interactions are external behavior from the perspective of the roles participating in the collaboration, the

(38)

behavior is internal to the collaboration as a whole. Similar to processes or functions, the result of a business interaction can be made available to the environment through a business service.

A business event is something that happens (externally) and may influence business processes, functions, or interactions. The “business event” concept is similar to the “trigger” concept in Amber [11] and the “initial state” and “final state” concepts as used in, for example, UML activity diagrams. However, our business event is more generally applicable in the sense that it can also be used to model other types of events, in addition to triggers.

3.3.1 Business Process

A business process is defined as a behavior element that groups behavior based on an ordering of activities. It is intended to produce a defined set of products or business services.

A business process describes the internal behavior performed by a business role that is required to produce a set of products and services. For a consumer the products and services are relevant and the required behavior is merely a black box, hence the designation “internal”.

In comparison to a business interaction, in which a collaboration of two or more business roles are (interactively) involved, at a given level of granularity only one business role is involved with a business process. However, a complex business process may be an aggregation of other, finer-grained processes, each of which may be assigned to finer-grained roles that are aggregated by roles that are aggregated by the original role.

There is a potential many-to-many relationship between business processes and business functions. Informally speaking, processes describe some kind of “flow” of activities, whereas functions group activities according to required skills, knowledge, resources, etc.

A business process may be triggered by, or trigger, any other business behavior element (e.g., business event, business process, business function, or business interaction). A business process may access business objects. A business process may realize one or more business services and may use (internal) business services or application services. A business role or an application component may be assigned to a business process to perform this process manually or automated, respectively. The name of a business process should preferably be a verb in the simple present tense; e.g., “handle claim”.

In an ArchiMate model, the existence of business processes is depicted. It does not, however, list the flow of activities in detail. During business process modeling, a business process can be expanded using a business process design language; e.g., BPMN [20].

Figure 16: Business Process Notation

(39)

Example

The model below illustrates the use of business processes and its relation with other concepts.

The Take out insurance process is composed of three sub-processes. For clarity, the sub-processes are drawn in the overall process (structuring). Each sub-process triggers the next sub-process.

The event Request for Insurance triggers the first sub-process. A particular role, in this case an insurance seller, is assigned to perform the required work. The process itself realizes an Insurance selling service. The Receive request sub-process uses the business object Customer info.

Example 7: Business Process

3.3.2 Business Function

A business function is defined as a behavior element that groups behavior based on a chosen set of criteria (typically required business resources and/or competences).

Just like a business process, a business function also describes internal behavior performed by a business role. However, while a business process group’s behavior is based on a sequence or

“flow” of activities that is needed to realize a product or service, a business function typically groups behavior based on required business resources, skills, competences, knowledge, etc.

There is a potential many-to-many relation between business processes and business functions.

Complex processes in general involve activities that offer various functions. In this sense a business process forms a string of business functions. In general, a business function delivers added value from a business point of view. Organizational units or applications may coincide with business functions due to their specific grouping of business activities.

A business function may be triggered by, or trigger, any other business behavior element (business event, business process, business function, or business interaction). A business function may access business objects. A business function may realize one or more business services and may use (internal) business services or application services. A business role or an application component may be assigned to a business function. The name of a business function should preferably be a verb ending with “-ing”; e.g., “claims processing”, or a noun ending in “- ion” or “-ment”; e.g., “administration”.

(40)

Figure 17: Business Function Notation

Example

The model below illustrates the use of business functions, as well as the relationship between business functions and business processes. The three business functions group a number of business sub-processes. The business process, initiated by a business event, involves sub- processes from different business functions. The Insurer role is assigned to each of the business functions. Moreover, business functions may access business objects; in this case, the Customer handling function uses or manipulates the Customer information object. Also, the Financial handling

function makes use of a Billing application service and realizes a Premium collection business service.

Example 8: Business Function

3.3.3 Business Interaction

A business interaction is defined as a behavior element that describes the behavior of a business collaboration.

Open Group Standard ArchiMate