ArchiMate Modeling Language

The Open Group Guide
How to Use the ArchiMate® Modeling Language to

Support the TOGAF® Standard
Prepared by The Open Group Architecture Forum and The Open Group ArchiMate Forum
Copyright © 2022, The Open Group
The Open Group hereby authorizes you to use this document for any purpose, PROVIDED THAT any copy of this
document, or any part thereof, which you make shall retain all copyright and other proprietary notices contained herein.
This document may contain other proprietary notices and copyright information.
Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any license or right
under any patent or trademark of The Open Group or any third party. Except as expressly provided above, nothing
contained herein shall be construed as conferring any license or right under any copyright of The Open Group.
Note that any product, process, or technology in this document may be the subject of other intellectual property rights
reserved by The Open Group, and may not be licensed hereunder.
This document is provided “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR
A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Some jurisdictions do not allow the exclusion of implied
warranties, so the above exclusion may not apply to you.
Any publication of The Open Group may include technical inaccuracies or typographical errors. Changes may be
periodically made to these publications; these changes will be incorporated in new editions of these publications. The
Open Group may make improvements and/or changes in the products and/or the programs described in these
publications at any time without notice.
Should any viewer of this document respond with information including feedback data, such as questions, comments,
suggestions, or the like regarding the content of this document, such information shall be deemed to be non-confidential
and The Open Group shall have no obligation of any kind with respect to such information and shall be free to
reproduce, use, disclose, and distribute the information to others without limitation. Further, The Open Group shall be
free to use any ideas, concepts, know-how, or techniques contained in such information for any purpose whatsoever
including but not limited to developing, manufacturing, and marketing products incorporating such information.
If you did not obtain this copy through The Open Group, it may not be the latest version. For your convenience, the
latest version of this publication may be downloaded at www.opengroup.org/library.
The Open Group Guide

How to Use the ArchiMate® Modeling Language to Support the TOGAF® Standard
ISBN: 1-947754-84-3
Document Number: G21E
Published by The Open Group, April 2022.

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
ii The Open Group Guide (2022)

Contents
1 Introduction ............................................................................................................... 1
1.1 Objective ......................................................................................................... 1
1.2 Guidance for the Reader ................................................................................. 1
1.3 Overview......................................................................................................... 1
1.4 Future Directions ............................................................................................ 2
2 Modeling Foundational TOGAF Concepts with ArchiMate Concepts ..................... 3

2.1 Scope and Level of Detail ............................................................................... 3
2.2 Mapping TOGAF Domains to ArchiMate Layers and Aspects ...................... 3
2.3 TOGAF Enterprise Continuum and Building Blocks ..................................... 6
2.4 TOGAF Logical and Physical Components ................................................... 8
2.5 TOGAF Architecture Level and Architecture Partitions ................................ 9
2.6 Mapping Approach ....................................................................................... 10
2.7 Modeling using ArchiMate Concepts for TOGAF Artifacts ........................ 12
3 Additional Benefits of the ArchiMate Structure and Concepts ............................... 13

3.1 Using Different Relationship Types ............................................................. 13
3.2 Generic Language Structure ......................................................................... 13
3.3 Relationships................................................................................................. 16
3.4 Additional Elements ..................................................................................... 16
3.5 Concepts Beyond IT ..................................................................................... 18
3.6 Viewpoint Mechanism .................................................................................. 18
4 ArchiMate Viewpoints to Model the TOGAF ADM Graphical Artifacts .............. 20

4.1 Phase A Graphical Artifacts ......................................................................... 20
4.2 Phase B Graphical Artifacts .......................................................................... 21
4.3 Phase C: Data Architecture Graphical Artifacts ........................................... 22
4.4 Phase C: Application Architecture Graphical Artifacts ................................ 23
4.5 Phase D Graphical Artifacts ......................................................................... 23
4.6 Phase E Graphical Artifacts .......................................................................... 24
5 Metamodel Based on the ArchiMate Specification................................................. 25
A ArchiMate Viewpoints to Model the TOGAF ADM Graphical Artifacts .............. 27

A.1 Phase A Graphical Artifacts ......................................................................... 28
A.2 Phase B Graphical Artifacts .......................................................................... 41
A.3 Phase C: Data Architecture Graphical Artifacts ........................................... 61
A.4 Phase C: Application Architecture Graphical Artifacts ................................ 72
A.5 Phase D Graphical Artifacts ......................................................................... 86
A.6 Phase E Graphical Artifacts .......................................................................... 98
B ArchiMate Constructs to Model TOGAF Matrices............................................... 104

B.1 Phase B Matrices ........................................................................................ 104
How to Use the ArchiMate® Modeling Language to Support the TOGAF® Standard iii
B.2 Phase C: Data Architecture Matrices .......................................................... 108
B.3 Phase C: Application Architecture Matrices............................................... 110
B.4 Phase D Matrices ........................................................................................ 114
C ArchiMate Constructs to Model TOGAF Catalogs............................................... 116

C.1 Preliminary Phase Catalogs ........................................................................ 116
C.2 Phase A Catalogs ........................................................................................ 117
C.3 Phase B Catalogs ........................................................................................ 119
C.4 Phase C: Data Architecture Catalogs .......................................................... 130
C.5 Phase C: Application Architecture Catalogs............................................... 131
C.6 Phase D Catalogs ........................................................................................ 135
C.7 Phase E and Phase F Catalogs (Migration Planning Tables) ...................... 137
C.8 Requirements Management Catalogs ......................................................... 140
D Extended Use of ArchiMate Viewpoints .............................................................. 142

D.1 Phase A Motivation Viewpoints ................................................................. 142
D.2 Phase E (F) Implementation and Migration Viewpoints ............................ 146
D.3 Physical Viewpoints ................................................................................... 147
E Mapping of Metamodel Entities............................................................................ 149
F Mapping of Metamodel Relationships .................................................................. 155
G Metamodel Based on the ArchiMate Modeling Language ................................... 172
H Minimal Metamodel based on the ArchiMate Modeling Language Structured

as the TOGAF Metamodel .................................................................................... 177
I Pure TOGAF Metamodel Using the ArchiMate Modeling Language .................. 180
iv The Open Group Guide (2022)

Preface
The Open Group
The Open Group is a global consortium that enables the achievement of business objectives
through technology standards. With more than 870 member organizations, we have a diverse
membership that spans all sectors of the technology community – customers, systems and
solutions suppliers, tool vendors, integrators and consultants, as well as academics and
researchers.
The mission of The Open Group is to drive the creation of Boundaryless Information Flow™
achieved by:
 Working with customers to capture, understand, and address current and emerging
requirements, establish policies, and share best practices
 Working with suppliers, consortia, and standards bodies to develop consensus and
facilitate interoperability, to evolve and integrate specifications and open source
technologies
 Offering a comprehensive set of services to enhance the operational efficiency of
consortia
 Developing and operating the industry’s premier certification service and encouraging
procurement of certified products
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 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/library.
This Document
This document is The Open Group Guide: How to Use the ArchiMate® Modeling Language to
Support the TOGAF® Standard. It has been developed and approved by The Open Group.
How to Use the ArchiMate® Modeling Language to Support the TOGAF® Standard v
Trademarks
ArchiMate, DirecNet, Making Standards Work, Open O logo, Open O and Check Certification
logo, Platform 3.0, The Open Group, TOGAF, UNIX, UNIXWARE, and the Open Brand X logo
are registered trademarks and Boundaryless Information Flow, Build with Integrity Buy with
Confidence, Commercial Aviation Reference Architecture, Dependability Through Assuredness,
Digital Practitioner Body of Knowledge, DPBoK, EMMM, FACE, the FACE logo, FHIM
Profile Builder, the FHIM logo, FPB, Future Airborne Capability Environment, IT4IT, the IT4IT
logo, O-AA, O-DEF, O-HERA, O-PAS, Open Agile Architecture, Open FAIR, Open Footprint,
Open Process Automation, Open Subsurface Data Universe, Open Trusted Technology Provider,
OSDU, Sensor Integration Simplified, SOSA, and the SOSA logo are trademarks of The Open
Group.
ITIL is a registered trademark of AXELOS Limited.
Microsoft is a registered trademark of Microsoft Corporation.
Object Management Group, OMG, and UML are registered trademarks and Unified Modeling
Language is a trademark of the Object Management Group, Inc.
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.
vi The Open Group Guide (2022)

About the Authors
(Please note affiliations were current at the time of approval.)
Mats Gejnevall, Minnovate & Biner Consulting
Mats Gejnevall is a long-time member of The Open Group and has been involved in many
different standards and guides of The Open Group on architecture. He has been a Co-Chair of
The Open Group SOA Work Group since 2006. Mats works at Minnovate as a mentor and
architect helping organizations to set up their Enterprise Architecture capabilities, creating
architectures and roadmaps to transform their enterprises to adaptive future states. His work has
been in a variety of industries, from Government to Industry, and Telco to Defense.
Bernd Ihnen, BiZZdesign
Bernd is a Senior Consultant and Trainer with Enterprise Architecture engagements in Germany,
Switzerland, Netherlands, Norway, Saudi Arabia, and Malaysia in manufacturing, finance,
public, and others sectors. His main focus is on Strategy-Business-IT-Alignment consultancy
with tool-supported standard methods. These methods include business capability-based analysis
for investments and technology risks, Enterprise Architecture modeling with the ArchiMate
language, application rationalization, story-telling, and management dashboard design
principles.
Rolf Knoll, Novatec Consulting GmbH
Rolf has been working as an Enterprise Architecture Consultant/Coach/Trainer for the last 16 of
his 28 years in the IT industry. He currently leads the Practice Area at Novatec Consulting
GmbH. He is a TOGAF and ArchiMate Trainer. In his consulting practice, he focuses on the
establishment and optimization of the Enterprise Architecture capability at customer
organizations of different sizes in different branches. In most customer situations he uses the
approach of a preconfigured TOGAF framework in conjunction with the ArchiMate language
(the “Novatec Reference Model”).
Marc Lankhorst, BiZZdesign
Marc Lankhorst is responsible for BiZZdesign’s vision, market development, consulting, and
coaching on digital business design and Enterprise Architecture, and for spreading the word on
the ArchiMate language for Enterprise Architecture modeling, for which he managed the
development of The Open Group Standard. Based on this experience, he advises clients on the
professional development of their architecture practice, helps them with implementing and using
the ArchiMate language in practice, and on the use of BiZZdesign’s software suite in doing so.
How to Use the ArchiMate® Modeling Language to Support the TOGAF® Standard vii
Acknowledgements
(Please note affiliations were current at the time of approval.)
The Open Group gratefully acknowledges the authors of this document:

 Mats Gejnevall, Minnovate & Biner Consulting
 Bernd Ihnen, BiZZdesign
 Rolf Knoll, Novatec Consulting GmbH
 Marc Lankhorst, BiZZdesign
The Open Group also gratefully acknowledges the contribution of the following people in the
development of this document:
 Chris Forde, The Open Group
 Sonia Gonzalez, The Open Group
 Jean-Baptiste Sarrodie, Accenture
viii The Open Group Guide (2022)

Referenced Documents
The following documents are referenced in this Guide:
(Please note that the links below are good at the time of writing but cannot be guaranteed for the
future.)
 ArchiMate® 2.1 Specification, a Standard of The Open Group (C13L), published by The
Open Group, December 2013; refer to: www.opengroup.org/library/c13l
 ArchiMate® 3.1 Specification, a Standard of The Open Group (C197), published by The
Open Group, November 2019; refer to: www.opengroup.org/library/c197
 ArchiMetal Case Study, Version 3.1 (Y195), published by The Open Group, November
2019; refer to: www.opengroup.org/library/y195
 ArchiSurance Case Study, Version 3.1 (Y194), published by The Open Group, November
2019; refer to: www.opengroup.org/library/y194
 How to Model Enterprise Risk Management and Security with the ArchiMate® Language
(W172), White Paper, published by The Open Group, November 2019; refer to:
www.opengroup.org/library/w172
 How to Use the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 3.0.1
Modeling Language, White Paper (W173), published by The Open Group, November
2017; refer to: www.opengroup.org/library/w173
 Modeling the Business Model Canvas with the ArchiMate® Specification (W195), White
Paper, published by The Open Group, February 2020; refer to:
www.opengroup.org/library/w195
 The TOGAF® Standard, 10th Edition, a Standard of The Open Group (C220), published by
The Open Group, April 2022; refer to: www.opengroup.org/library/c220
 TOGAF® 9 Template Deliverables, Set 1 (I092), published by The Open Group, October
2009; refer to: www.opengroup.org/library/i092
 TOGAF® 9 Template Artifacts and Deliverables, Set 2 (I093), published by The Open
Group, April 2010; refer to: www.opengroup.org/library/i093
 TOGAF® 9.1 Framework and ArchiMate® 2.1 Modeling Language Harmonization:
Glossaries Comparison, White Paper (W14A), published by The Open Group, August
2014; refer to: www.opengroup.org/library/w14a
Viewpoints Mapping, White Paper (W14B), published by The Open Group, August 2014;
refer to: www.opengroup.org/library/w14b
 TOGAF® 9.1 Framework and ArchiMate® 2.1 Modeling Language Harmonization – A
Practitioner’s Guide to Using the TOGAF® Framework and the ArchiMate® Language,
How to Use the ArchiMate® Modeling Language to Support the TOGAF® Standard ix
White Paper (W14C), published by The Open Group, December 2014; refer to:
www.opengroup.org/library/w14c
Content Metamodel Harmonization: Entities and Relationships, White Paper (W14D),
published by The Open Group, December 2014; refer to:
www.opengroup.org/library/w14d
 TOGAF® Series Guide: Business Capabilities, Version 2 (G211), published by The Open
Group, April 2022; refer to: www.opengroup.org/library/g211
 TOGAF® Series Guide: Business Models (G18A), published by The Open Group, April
2022; refer to: www.opengroup.org/library/g18a
 TOGAF® Series Guide: Information Mapping (G190), published by The Open Group,
April 2022; refer to: www.opengroup.org/library/g190
 TOGAF® Series Guide: Organization Mapping (G206), published by The Open Group,
April 2022; refer to: www.opengroup.org/library/g206
 TOGAF® Series Guide: The TOGAF® Technical Reference Model (TRM) (G175),
published by The Open Group, September 2017; refer to:
www.opengroup.org/library/g175
 TOGAF® Series Guide: Value Streams (G178), published by The Open Group, April
2022; refer to: www.opengroup.org/library/g178
 Using the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 2.0
Modeling Language, White Paper (W129), published by The Open Group, July 2012;
refer to: www.opengroup.org/library/w129
x The Open Group Guide (2022)

1 Introduction
1.1 Objective
The objective of this document is to describe how the ArchiMate® Specification can be used
with the TOGAF® Standard to support business transformations using enterprise, solution, or
other architecture activities. This can help specifically when tailoring the Architecture Content
Framework by using the ArchiMate modeling language in the Preliminary Phase of the TOGAF
Architecture Development Method (ADM).
1.2 Guidance for the Reader

Different readers of this document may be interested in different parts of it. Its primary audience
is architects who want to use the TOGAF Standard and ArchiMate Specification together. This
document provides them with a general understanding of how ArchiMate models can support the
different phases and activities of the TOGAF ADM, Enterprise Continuum, and Enterprise
Metamodel. These readers may be most interested in Chapter 2, which explains how the
foundational concepts of the TOGAF Standard can be modeled using the ArchiMate
Specification. In addition, Chapter 3 provides additional benefits of using the ArchiMate
Specification in the context of the TOGAF Standard.
Secondly, there may be readers who are particularly interested in expressing one or more of the
specific views mentioned in the TOGAF Standard by using the ArchiMate Specification. These
readers are served by Chapter 4, which maps the graphical artifacts (diagrams) from the TOGAF
ADM phases to the corresponding ArchiMate viewpoints, and also by Appendix A, Appendix B,
and Appendix C, which provide examples of the diagrams, matrices, and catalogs from the
various TOGAF ADM phases. Additionally, Appendix D provides examples of ArchiMate
viewpoints that do not directly match existing artifacts mentioned in the TOGAF Standard but
which we deem useful additions.
A third group of readers may be most interested in the conceptual background of the
correspondence and mapping between the ArchiMate and TOGAF notions; for instance, because
they want to implement these in software tools. They may be especially interested in Chapter 5,
which provides a metamodel for TOGAF artifacts based on the ArchiMate modeling language,
and Appendix E, Appendix F, Appendix G, Appendix H, and Appendix I, which provide
detailed mappings between entities and relationships of the two, and several depictions of this
metamodel at different levels of detail.
1.3 Overview
The TOGAF Standard for Enterprise Architecture has been developed and published by The
Open Group since 1995. The initial development of the ArchiMate Specification was funded by
the Dutch government and business partners, and lasted from July 2002 to December 2004. In
2008, the ownership and stewardship of the ArchiMate Specification was transferred to The
How to Use the ArchiMate® Modeling Language to Support the TOGAF® Standard 1
Open Group. It is now managed by the ArchiMate Forum within The Open Group. In February
2009, The Open Group published the ArchiMate 1.0 Specification. The TOGAF Standard is
broad and comprehensive, covering all areas of Enterprise Architecture. The ArchiMate
Specification, similarly broad and comprehensive, provides a complementary modeling language
for Enterprise Architecture. These standards can be used together, in combination, or separately.
The ADM is the method component of the TOGAF Standard and describes several phases of
activity. The focus of the Preliminary Phase of the ADM is to understand the specific needs of
an enterprise when setting up the Enterprise Architecture capability, and to tailor the TOGAF
framework to meet these needs.
Users of the standards generally need help when tailoring the artifacts to be created or used in
the different ADM phases, and the metamodel to be used to provide the information needed for
these artifacts. The artifact descriptions and the sample views being made available with the
TOGAF Standard by the TOGAF template library are designed to provide general guidance, and
therefore could be interpreted in different ways. A similar situation happens with the metamodel
entities and their relationships that are designed to provide general guidance; therefore,
additional guidance is needed on how the TOGAF metamodel and TOGAF artifacts can be
applied to model different situations.
In these cases, the ArchiMate modeling notation could be applied to support the TOGAF
Standard in the viewpoints and view definition process.
In other cases, users of the standards have already decided to use the ArchiMate Specification as
their Enterprise Architecture modeling language and the TOGAF Standard as the basis for their
overarching Enterprise Architecture approach. In these cases, users need assistance on how to
combine the ArchiMate and TOGAF Standards to define their joint Enterprise Architecture
approach.
All these cases are addressed by the general guidance provided in this document.
The approach is to reference the TOGAF Standard and the ArchiMate Specification, and also the
ArchiSurance Case Study (see Referenced Documents) as often as possible.
1.4 Future Directions

As the approach of this project is based on the concepts of the most recent versions of the two
standards being available, we plan to review this document and deliver an update whenever a
version of one of the standards is released with major changes to the concepts used in this
document.
In future with a more flexible partitioned TOGAF Standard, the approach of this project could be
documented as one standard configuration on how to use the ArchiMate language in conjunction
with the TOGAF Standard.
2 The Open Group Guide (2022)

2 Modeling Foundational TOGAF Concepts with
ArchiMate Concepts
In this chapter, we explain the generic approach to using ArchiMate concepts with TOGAF
projects. The concepts of the ArchiMate Specification provide a number of benefits when used
in the context of the TOGAF Standard; most importantly, a notation for its concepts. This offers
a nominal way of expressing TOGAF architecture artifacts in modeling concepts based on the
ArchiMate language.
To facilitate this combined usage, this chapter provides a mapping between the concepts used by
the two standards and explains the correspondences and differences. We first discuss the general
ideas behind the structure of the ArchiMate language metamodel and how it aligns with and
sometimes differs from the TOGAF Enterprise Metamodel. Next, we describe how the TOGAF
architecture domains and concepts can be mapped onto the corresponding ArchiMate layers,
aspects, and concepts.
2.1 Scope and Level of Detail

To be able to use ArchiMate concepts to express models in a TOGAF context, the scope of the
ArchiMate Specification needs to cover at least the whole TOGAF Enterprise Metamodel.
The scope of the ArchiMate language provides significant details for modeling Enterprise
Architecture domains. For example, in its core layers, it allows internal behavior (processes and
functions) to be modeled at all layers, and there are more additions, as explained in Section 2.7.
2.2 Mapping TOGAF Domains to ArchiMate Layers and Aspects

The TOGAF Standard identifies four architecture domains which together constitute an
Enterprise Architecture:
 Business Architecture is a representation of holistic, multi-dimensional business views of
capabilities, end-to-end value delivery, information, and organizational structure; and the
relationships among these business views and strategies, products, policies, processes,
initiatives, and stakeholders
 Information Systems Architecture consists of two parts:
— Data Architecture is a description of the structure of the enterprise’s major types
and sources of data, logical data assets, physical data assets, and data management
resources
— Application Architecture provides a blueprint for the individual applications to be
deployed, their interactions, and their relationships to the core business processes of
the organization
 Technology Architecture is a description of the structure and interaction of the
technology services and technology
In addition, the TOGAF Standard contains a set of general entities that are also applied to deliver
architecture artifacts, therefore they are covered in this document as part of the mapping, as long
as they are used in existing TOGAF artifacts.
The ArchiMate Specification in its Core Framework (see Figure 1) covers the same scope but
organizes this somewhat differently, in layers and aspects:
 Layers: the three levels at which an enterprise can be modeled: Business, Application,
and Technology
 Aspects:
— The Active Structure aspect, which represents the structural elements (the business
actors, application components, and devices that display actual behavior; i.e., the
“subjects” of activity)
— The Behavior aspect, which represents the behavior (processes, functions, events, and
services) performed by the actors; structural elements are assigned to behavioral
elements, to show who or what displays the behavior
— The Passive Structure aspect, which represents the objects on which behavior is
performed; these are usually information objects in the Business Layer and data
objects in the Application Layer, but they may also be used to represent physical
objects
The ArchiMate layers are very similar to the TOGAF domains. Business equals Business,
Technology is Technology, and the Application Layer corresponds with the TOGAF Information
Systems Architecture. The only difference is that there is no Data Architecture layer in the
ArchiMate Specification. Rather, the passive structure aspect covers Data and Information in all
core layers, with business objects in the Business Layer (most often used to represent conceptual
information elements), data objects in the Application Layer, and artifacts in the Technology
Layer.
The Term “Physical”
In the TOGAF Standard, the term “physical” is used to denote solution-specific building blocks.
This has its roots in data modeling, where the abstraction levels of conceptual, logical, and
physical are used to describe different levels of data model. In the ArchiMate Specification, the
term “physical” is used to denote material, tangible things; i.e., the realm where physics applies.
The physical elements in the Technology Layer in the ArchiMate language allow for modeling
such tangible objects and technology. To avoid confusion, we will use the term “physical” in the
TOGAF sense of the word throughout this document and explicitly mark cases where we mean
to indicate truly physical, tangible elements of technology.

Figure 1: ArchiMate Core Framework
Next to these core layers and aspects, the ArchiMate language also comprises additional layers
and aspects, to describe:
 The Motivation behind the architecture, with concepts such as stakeholder, goal, and
requirements
 The Strategy of the enterprise as expressed in its value streams, capabilities, resources,
and courses of action
 Physical elements to describe operational (non-IT) technology, such as physical
equipment, material, and facilities
 Implementation and Migration elements to model the evolution of the architecture and the
activities to implement it, supporting project and program management and migration
planning
Together, this gives us the ArchiMate Full Framework, as shown in Figure 2.
Figure 2: ArchiMate Full Framework
These additional concepts cover areas of the TOGAF ADM besides the architecture layers
described above, and are developed in Phases B, C, and D of the ADM:
 Motivation elements are used in:
— The Preliminary Phase and Phase A to express, for example, stakeholders and their
concerns, business drivers, Architecture Vision, and Architecture Principles, etc.
— Phases B, C, and D to express requirements and constraints on the architecture itself
— The Requirements Management phase
 Strategy elements are used in Phase A and B to express the business and IT strategy and
high-level Business Architecture
 Implementation and Migration elements are used in Phase E (Opportunities and

Solutions) and Phase F (Migration Planning) to express the Architecture Roadmap, work
packages, and deliverables to realize the architecture
This yields an approximate correspondence between the ADM phases and ArchiMate concepts,
as shown in Figure 3. Note that this is not an exact match since, for example, the Business,
Application, and Technology Layer concepts will also be used throughout Phases E, F, and G.
Nevertheless, this clearly shows that the ArchiMate language covers all the steps of the TOGAF
ADM.
Figure 3: Correspondence Between the ArchiMate Language and TOGAF ADM
2.3 TOGAF Enterprise Continuum and Building Blocks

The TOGAF Enterprise Continuum is a framework to categorize architecture descriptions. It
helps to highlight on which level of abstraction an architect is acting, and outlines different
levels to be used for different purposes: “The Enterprise Continuum provides methods for

classifying architecture and solution artifacts …” (TOGAF Standard – Architecture Content,
Section 6.1; see Referenced Documents). Figure 4 shows the general idea of classification.
The central concept for describing these architecture and solution artifacts is the “building
block”, which is used throughout the TOGAF Standard. Building blocks have a number of
general characteristics, which are described in the TOGAF Standard – Architecture Content,
Chapter 5; see Referenced Documents. Often, building blocks are related to TOGAF metamodel
entity types (e.g., capability, process, actor, different types of services, or components).
The TOGAF Standard makes a foundational distinction between Architecture Building Blocks
(ABBs) and Solution Building Blocks (SBBs). ABBs are considered to be the conceptual and
logical building blocks defined in Phases A to D of the TOGAF ADM. SBBs represent the
physical building blocks (i.e., descriptions of the solution that may be procured or developed)
defined in Phase E. An SBB does not need to be a physical IT component; it can also be the
physical instantiation of an organization, actor, or a process. This distinction between
architecture and solution is also central to the TOGAF Enterprise Continuum, as shown in
Figure 4.
Figure 4: The TOGAF Enterprise Continuum1
Deployed solutions describe what is actually implemented – real-world assets. They reflect
which solutions are selected and instantiated with a deployment. These deployed solutions may
be the production installations, such as an Enterprise Resource Planning (ERP) system, and are
often managed by some IT operations department. Since deployed solutions are instances of
solutions, the Solutions Continuum contains types or blueprints of solutions which are rolled out:
“SBBs … may be either procured or developed” (TOGAF Standard – Architecture Content,
Section 5.2.4; see Referenced Documents). They are product or vendor-aware as a type of a
product which can be procured or developed.
1
Adapted from the TOGAF Standard – Architecture Content, Figure 6.1; see Referenced Documents.
The upper orange rectangle of the Enterprise Continuum reflects the Architecture Continuum,
comprising the ABBs. “ABBs capture the architectural requirements and direct and guide the
development of SBBs. They consist of, or they describe, the fundamental functionality” (TOGAF
Standard – Architecture Content, Section 5.2.3; see Referenced Documents). They can also be
called logical components; e.g., ERP or operating system.
Figure 52 summarizes our mapping approach. As can be seen, foundation architectures are
mainly modeled within the Technology Layer, while other more specific architectures are
usually modeled with the Application and Business Layers. This makes sense since the
Application Architecture is mainly built on a technology foundation that is not developed within
the enterprise, but rather bought in and configured (e.g., servers, operating systems, databases,
communication equipment, etc.). In the following sections, we will further explain this approach.
Figure 5: TOGAF Enterprise Continuum Mapped to ArchiMate Elements
2.4 TOGAF Logical and Physical Components

Next to ABBs and SBBs, the TOGAF Standard also distinguishes between logical and physical
application, data, and technology components, in particular in the TOGAF Enterprise
Metamodel (TOGAF Standard – Architecture Content, Chapter 2; see Referenced Documents)
and associated artifacts (TOGAF Standard – Architecture Content; Chapter 3; see Referenced
Documents). The definitions are as follows:
 Logical application component: an encapsulation of application functionality that is
independent of a particular implementation; for example, the classification of all purchase
request processing applications implemented in an enterprise
 Physical application component: a realization of logical application functionality using
components of functionality in applications that may be hired, procured, or built; for
2
Please note that “TBQ” is a fictional vendor of packed applications.

example, a configured and deployed instance of a Commercial Off-The-Shelf (COTS)
ERP supply chain management application
Although the TOGAF Standard does not explicitly state it, these definitions clearly show that
logical components should be considered ABBs (“independent of a particular implementation”)
and physical components are SBBs (“deployable component of functionality”). In the remainder
of this document, we will therefore assume these concepts correspond in this way. This mapping
is obvious for application components and technology components based on their definition.
2.5 TOGAF Architecture Level and Architecture Partitions

In the TOGAF Standard, levels provide a framework for dividing the Architecture Landscape
into levels of granularity (TOGAF Standard – Applying the ADM, Chapter 3; see Referenced
Documents).
There are three levels:

1. Strategic Architecture provides an organizing framework for operational and
change activity and allows for direction-setting at an executive level.
2. Segment Architecture provides an organizing framework for operational and change
activity and allows for direction-setting and the development of effective
Architecture Roadmaps at a program or portfolio level.
3. Capability Architecture provides an organizing framework for change activity and
the development of effective Architecture Roadmaps realizing capability increments.
Architecture on each level can be modeled using the identical ArchiMate constructs. There is no
need to define a specific mapping.
In the TOGAF Standard, partitions are used to simplify the development and management of the
Enterprise Architecture (TOGAF Standard – Applying the ADM, Chapter 4; see Referenced
Documents).
Architectures are partitioned because:

 Organizational unit architectures conflict with one another
 Different teams need to work on different elements of the architecture at the same time,
and partitions allow for specific groups of architects to own and develop specific elements
of the architecture
 Effective architecture re-use requires modular architecture segments that can be taken and
incorporated into broader architectures and solutions
Different partitions of architecture can be modeled using the identical ArchiMate concepts. If
there is a need to model the partitioning of the architecture, we recommend use of the ArchiMate
grouping element for this.
2.6 Mapping Approach
The ArchiMate 3.1 Specification provides three approaches to distinguish and map these
concepts. In this document, we use the first and preferred mapping approach, as mentioned in
Section 3.6 of the ArchiMate 3.1 Specification; see Referenced Documents.
We can explain this mapping at the Application Layer. In Figure 6, on the right-hand side, we
see a physical application component, or SBB, modeled as an application component. This is
assigned to the logical application component, or ABB, modeled as an application function. This
denotes that the physical application component performs this application function or,
equivalently, it implements the logical application component.
Figure 6: Mapping TOGAF Logical and Physical Application Components to ArchiMate Elements
It is not advisable to map TOGAF logical components to application components in the

ArchiMate Specification. The fact that both have “component” in their name should not be
confused. While the component notion of the TOGAF Standard has the generic meaning of an
encapsulation of something (logical, implementation-independent or physical, implementation-
specific), the more specific application component concept in the ArchiMate Specification
comes from the world of component-based software development and specifically means an
encapsulation of something aligned to implementation. The definition of application component
in the ArchiMate Specification speaks of being “… aligned to implementation structure …”
whereas the TOGAF Standard defines a logical application component as “… independent of a
particular implementation”.
We use this mapping pattern throughout this document; logical components are mapped to
ArchiMate behavior elements (typically functions), whereas physical components are mapped to
active structure concepts; e.g., business actors and roles in the Business Layer and nodes,
devices, and system software in the Technology Layer.
The domain of data and information is somewhat different. In fact, the entire distinction between
conceptual, logical, and physical levels of abstraction has its roots in information architecture:
 Conceptual elements represent the information concepts that the business finds relevant
 Logical elements provide structure to this information for manipulation by information
systems
 Physical elements describe the storage and encoding of this information; for example, in
the form of a file on a local hard drive, an XML message in JSON, or a table in an
application’s SQL database

In the ArchiMate language, these three levels of abstraction correspond with the Business,
Application, and Technology Layers respectively, and hence with business objects, data objects,
and artifacts.
The concept of business information added in the latest version of the TOGAF Standard as an
element of the Business Architecture domain is defined as an abstraction above the data entity
(see the TOGAF Standard – Architecture Content, Chapter 2; see Referenced Documents for
details). As there are no artifacts which reference the business information entity, we do not use
it in the mapping approach of the TOGAF artifacts. Depending on each artifact, we decide
whether to map the data entity to the business object or to the data object in the ArchiMate
language (see Chapter 4 for details).
We see the TOGAF data entity as being “conceptual” but residing in the Information Systems
Architecture, which we map to the ArchiMate Application Architecture. According to its
definition and the defined relationship to the data entity, the logical data component can be seen
as a mapping to the data object, too. It is then an aggregation of elementary data entities.
Table 1: Concepts Mapping Between the TOGAF and ArchiMate Standards
TOGAF Standard ArchiMate Specification ArchiMate Layer
Conceptual Business Information Business Object Business

Data Entity Data Object Application
Logical Logical Data Component Data Object Application
Physical Physical Data Component Artifact Technology
We combine this with the approach to mapping TOGAF logical and physical components as
described above. In addition, we map the conceptual level to the services. Moreover, in both the
Business and Technology Layers, a more fine-grained distinction can be made. For instance, a
business role is more “logical” than a business actor, but more “physical” (i.e., closer to
implementation in reality) than a business process or function.
This yields the picture shown in Figure 7.
Conceptual
Logical
Physical
Figure 7: Conceptual, Logical, and Physical Abstraction Levels Mapped to ArchiMate Elements
Typically, the design of some new system will progress from conceptual to logical to physical,
perhaps starting with the definition of the services it needs to provide and ending with its
implementation in concrete building blocks of organization, software, and other technology.
2.7 Modeling using ArchiMate Concepts for TOGAF Artifacts

How can we now use the mapping approach defined in the previous sections in concrete
architecture engagements? Let us first look at the use of contracts in the TOGAF and ArchiMate
Standards. The TOGAF Standard defines a contract as “an agreement between a consumer and
a provider that establishes functional and non-functional parameters for interaction”. This
applies to all types of interactions within the metamodel. The definition in the ArchiMate
Specification is quite similar: “A formal or informal specification of an agreement between a
provider and a consumer that specifies the rights and obligations associated with a product and
establishes functional and non-functional parameters for interaction”.
As defined in the TOGAF Standard – Architecture Content, Section 2.4 (see Referenced
Documents), a contract applies to all types of services in the metamodel; i.e., business,
application, and technology services. The same goes for service quality. Similarly, in the
ArchiMate Specification the contract element is used as part of a product, which in turn
aggregates business, application, and/or technology services.
The contract concept could also be used creatively by associating it with a serving relationship
from a service to the user of that service, or by associating it with a flow relationship to express a
Service-Level Agreement (SLA) on that specific transfer of information.

3 Additional Benefits of the ArchiMate Structure and
Concepts
In the previous chapter, we outlined how the foundational concepts of the TOGAF Standard can
be modeled using the ArchiMate Specification. Next to these basic modeling needs, there are
more advantages to the use of the ArchiMate language in the context of the TOGAF Standard.
3.1 Using Different Relationship Types

The ArchiMate metamodel uses different relationship types to express different kinds of
relationships between the different entities. In contrast to this, the TOGAF Standard uses named
associations.
We found these different ArchiMate relationships very helpful and recommend this concept
when using the ArchiMate language to represent the graphical artifacts of the TOGAF Standard.
This difference is most apparent in the generic structure of the ArchiMate language and how it
treats relationships.
3.2 Generic Language Structure

The structure of the ArchiMate core language was inspired by the structure of human languages.
All languages contain Subjects (S), Verbs (V), and Objects (O). Only the order of these differs
and is determined by the grammar of the language. For instance, English has an SVO order and
Japanese has SOV. In the ArchiMate Specification, this language structure corresponds with the
three aspects of active structure (subjects), behavior (verbs), and passive structure (objects).
Repeating from Section 2.2, the ArchiMate Specification contains:
 The Active Structure aspect, which represents the structural elements (the business actors,
application components, and devices that display actual behavior; i.e., the “subjects” of
activity)
 The Behavior aspect, which represents the behavior (processes, functions, events, and
services) performed by the actors; structural elements are assigned to behavioral elements,
to show who or what displays the behavior
 The Passive Structure aspect, which represents the objects on which behavior is
performed; these include information and data
This alignment with natural language makes it easier for people not used to formal modeling to
express themselves in or read an ArchiMate model. The sentence “John reads a book” would
look like Figure 8 in the ArchiMate language.
Active Structure: Behavior: Passive Structure:
Subject Verb Object
Business Actor Business Process Business Object
Figure 8: Sentence Structure in the ArchiMate Language
Next to these naturally-inspired language aspects, the ArchiMate metamodel also offers an
underlying, deeper structure of generic concepts. The TOGAF Enterprise Metamodel is a more
general structure with concepts related to each other without a superstructure of more generic
elements. The ArchiMate metamodel exhibits a generic set of abstract concepts to provide
structure to the language. For example, the business service, application service, and technology
service concepts are all subtypes of a generic service concept. Likewise, the business actor,
application component, and node concepts are all subtypes of the internal active structure
element. These abstract concepts are not used directly by users of the language in concrete
models. Rather, this generic structure “behind” the elements of the language improves its
consistency, and helps users to understand and learn the language.
The top levels of this structure are shown in Figure 9.
Figure 9: Top-Level Hierarchy of ArchiMate Concepts3
3
Figure 1 in the ArchiMate 3.1 Specification; see Referenced Documents.

Figure 10: Hierarchy of Behavior and Structure Elements4
For example, there is a generic concept “internal active structure element”, of which business
actor, application component, device, and others are subtypes. Specifically, the core of the
language is built around a set of six generic concepts that are specialized at each of the Business,
Application, and Technology Layers, as depicted in Figure 11.
Figure 11: Behavior and Structure Elements Metamodel 5
4
5
Because of its internal consistency, the use of such a generic structure enhances the
understandability and learnability of the language. It also offers advantages to tool implementers.
Moreover, it allows for easy extensibility of the language if the need arises, as witnessed, for
example, by the strategy and physical elements added in the ArchiMate Specification, Version
3.0.
Also, in Figure 11, we see the subdivision in aspects as mentioned before. It also shows another
distinction, between internal and external elements. For instance, a customer only sees the
business services of an enterprise; the external behavior elements. To provide these services, the
enterprise internally performs various business processes; the internal behavior elements.
This distinction provides architects with a way to express a black-box (i.e., external) view of
some architecture element, and a white-box (internal) view. This is common good practice in
design: first focus on the context and what the environment needs or expects, and only then be
concerned with the inner workings of a solution.
3.3 Relationships
Another important consideration for the two standards to be used together is in the definition of
relationships. These relationships are themselves language concepts in the ArchiMate
Specification that can leverage the TOGAF Enterprise Metamodel, where they denote
associations between metamodel elements. When expressing an architecture, these relationships
are as equally important as the model elements. Some would even argue that the lines between
the boxes are more significant than the boxes themselves since architecture is all about
coherence and connections. Having such a well-defined set of meaningful relationships is
therefore an important benefit of using the ArchiMate language to express architectures.
Next to this set of relationships, the ArchiMate Specification also provides derivation rules for
drawing conclusions about chains of relationships. For example, if A contains B and B contains
C, we may conclude that A contains C. These derivation rules are used in two ways in the
ArchiMate language:
1. To specify the language itself. The ArchiMate Specification consists of a minimal
metamodel plus all derivable relations.
2. To analyze architecture models and draw conclusions about them; for example, to
create simplified views or to find long-distance dependencies between architecture
elements.
Think of questions like: “What happens if this server fails?” This notion of relationship
derivation is unique among modeling languages and gives the ArchiMate language great
analytical power. This power can be used fruitfully in projects driven by the TOGAF Standard.
3.4 Additional Elements

The ArchiMate Specification offers a few other useful concepts that are not part of the TOGAF
Enterprise Metamodel. A very generic one is the grouping concept, which can be used to
aggregate elements that belong together for some reason. One example is the concept of
“business domain”, which may comprise all kinds of elements from different layers and aspects

of an architecture. Having such a generic element allows architects to structure their models
along different dimensions.
In the Business Layer, the ArchiMate modeling language has the business object element for
modeling information from a business or conceptual perspective; it is defined as “a concept used
within a particular business domain” (ArchiMate 3.1 Specification; see Referenced Documents)
and can therefore be used to capture any concept that is relevant from a business perspective.
Such a business object can be realized by one or more data objects in the Application Layer,
representing the logical, application-oriented view on data that corresponds with the logical data
components in the TOGAF Standard. This business perspective on information is introduced
with the TOGAF Business Information entity, and we map the new Business Information entity
to the Business Object of the ArchiMate language. We decide on a case-by-case basis whether
we map the TOGAF Data Entity to the ArchiMate Business Object or to the ArchiMate Data
Object.
In both the Application and Technology Layers, the ArchiMate Specification offers concepts for
expressing the internal behavior of the various components, with function and process concepts
at each layer. These can be used in various ways, from a high-level functional classification of
the applications to a detailed specification of the transformation steps that need to be performed
in some data-processing chain.
In the Technology Layer, the ArchiMate Specification makes a more fine-grained distinction
between hardware, software, and networking. Its generic internal active structure node element
can be used for the logical abstraction level in technology models, whereas its specialist device
and system software can be used for the physical abstraction level, in order to model hardware
and software. Similarly, the communication network element is used to model physical IT
networks (e.g., a Wi-Fi or Ethernet network), whereas the path element is used to model the
logical abstraction on top of that; e.g., a Virtual Private Network (VPN). These elements are
particularly useful for infrastructure architects, who often need more concrete and precise
concepts than the generic technology component of the TOGAF Standard.
To express the evolution of the architecture (and its implementation), the plateau concept is
useful. This captures a stable state of the architecture that exists in (or is planned for) a particular
timeframe. This allows architects to express the stages in which an architecture moves, from the
Baseline to Target Architectures, to capture which alternative implementation paths are possible,
and to analyze the pros and cons of each alternative. This is especially useful in Phase E:
Opportunities and Solutions and Phase F: Migration Planning to model Transition Architectures.
In its Motivation Layer, the ArchiMate language has a few additional concepts beyond the
TOGAF Enterprise Metamodel. Perhaps the most relevant is the outcome concept, which is used
to model a result. In addition to the goal concept, which models what the enterprise wants, an
outcome models what it gets, plans to get, expects to get, or wants to avoid getting. Thus, the
distinction between goals and outcomes lets architects model things like gaps between plans and
results, mitigation measures, etc.
A second useful motivation element is the value concept. This is used to express the importance
or value (not necessarily monetary) attached to some architecture element by some stakeholder.
As such, this helps to express what the desired and planned outcomes are “worth” to these
stakeholders, which is useful in all kinds of scenarios, starting with the prioritization of the
architecture work itself. A related but less frequently used motivation element is “meaning”.
This is used to express the interpretation of, or knowledge captured, in some architecture
element, and can be useful to model different interpretations of something by different
stakeholders. It is also used to express semantics of, for example, business objects.
3.5 Concepts Beyond IT

Enterprise Architecture goes beyond enterprise-wide IT architecture and the implementation of
business processes in software systems. One important addition in the ArchiMate 3.0
Specification was the inclusion of concepts for modeling physical technology. This is relevant
for any enterprise rooted in the physical world; e.g., retail, healthcare, defense, logistics, utilities,
etc. These concepts are tightly integrated with the rest of the Technology Layer concepts,
allowing combinations of both to be modeled; for example, an MRI scanner consisting of
physical equipment that scans the patient, and IT that performs the image processing and
analysis. Similarly, computer-controlled manufacturing, Internet of Things (IoT) devices,
physical aspects of data centers, virtual reality equipment for gaming and simulation, and all
kinds of other technologies can be expressed with these concepts. One of the most physical
examples is the steel manufacturing process explained in the ArchiMetal Case Study (see
Referenced Documents). Capturing the non-IT-based information flows is quite important for
any enterprise since we do not (and probably will not ever) live in a fully digitized world. To
that end, the ArchiMate language includes the representation element in the Business Layer for
modeling things like a paper document, a printed boarding pass, an insurance claim form, etc.
Another area where the ArchiMate language offers added value is in the Strategy Layer. Next to
the course of action, capability, and value stream concepts, the ArchiMate language also
contains the resource concept. This is especially relevant to capture business strategy approaches
such as the resource-based view:6 “A managerial framework used to determine the strategic
resources a firm can exploit to achieve sustainable competitive advantage”. This resource
concept can be used to capture any asset that an enterprise possesses, ranging from physical
equipment to employee skills and from knowledge to capital. These resources are in turn
realized by structure elements in the core layers of the language. For instance, a resource
“Employees with Social Media Skills” could be realized by a business actor “Customer Service
Team”.
3.6 Viewpoint Mechanism

A useful but sometimes overlooked part of the ArchiMate Specification is the viewpoint
mechanism it specifies. As stated in the ArchiMate 3.1 Specification (see Referenced
Documents): “Architecture viewpoints define abstractions on the set of models representing the
Enterprise Architecture, each aimed at a particular type of stakeholder and addressing a
particular set of concerns. Viewpoints can be used to view certain aspects in isolation, and to
relate two or more aspects”. The standard explains how to create such viewpoints in two steps:
1. Selecting a subset of relevant concepts (elements and relationships) from the
ArchiMate metamodel based on the information that is needed to address stakeholder
concerns. Patterns can be used to create viewpoints:
— Using all relations types, but a subset of element types
— Using a subset of relation types, but all element types
6
See also https://en.wikipedia.org/wiki/Resource-based_view.

— Using a subset of relation and element types
2. Defining a representation to depict these concepts in a way that is understood by the
stakeholders. This can be a diagram that uses standard or customized ArchiMate
notation, a catalog of elements, a matrix showing the relationships between two
groups of elements, or an entirely different visualization.
Applying a viewpoint to an architecture model means that those parts of the architecture are
selected that match the chosen set of concepts from Step 1, and are depicted in the manner
prescribed by Step 2. The usage of viewpoints reduces complexity for the designer and for the
consumer of the architecture artifacts/views (e.g., a diagram). It improves the analysis, design,
and communication.
This mechanism can be used to construct viewpoints for all architectural artifacts mentioned by
the TOGAF Standard – Architecture Content, Chapter 3; see Referenced Documents. This is the
basis for Chapter 4.
4 ArchiMate Viewpoints to Model the TOGAF ADM
Graphical Artifacts
The ArchiMate Specification specifies a viewpoint mechanism that can be used to define
specific viewpoints for the use-cases at hand. Thus, an architect can define viewpoints that
capture specific concerns of stakeholders in specific ways, possibly using an alternative notation
or visualization. Using this mechanism, applicable views can then be created by applying a
viewpoint to a model. This results in:
1. A selection of the relevant parts of the model to address the concerns at hand.
2. A visualization of that content that is understood by the stakeholders involved. This
can be a graphical diagram, but also a list (catalog), cross-reference table (matrix),
chart, or other depiction.
In this chapter, we use this viewpoint mechanism to define relevant viewpoints for the different
phases of the TOGAF ADM. As the ArchiMate Specification is a graphical modeling language,
we focus on how to deliver existing graphical artifacts of the TOGAF template library (TOGAF
9 Template Artifacts and Deliverables, Set 2; see Referenced Documents) with the ArchiMate
language.
This chapter covers all graphical artifacts of the TOGAF ADM phase by phase. In this chapter
we map the original TOGAF artifact to the ArchiMate viewpoint.
More details about this mapping and sample viewpoints can be found in Appendix A.
4.1 Phase A Graphical Artifacts

The objectives of Phase A are to:
 Develop a high-level aspirational vision of the capabilities and business value to be
delivered as a result of the proposed Enterprise Architecture
 Obtain approval for a Statement of Architecture Work that defines a program of works to
develop and deploy the architecture outlined in the Architecture Vision
The proposed Enterprise Architecture is expressed in some detail by a number of artifacts.

Table 2: Phase A TOGAF Graphical Artifact – ArchiMate Viewpoint Mapping
TOGAF Standard – Architecture Content ArchiMate 3.1 Specification
Business Model Diagram Business Model Canvas7
7
Business Model Canvas is not a standard ArchiMate viewpoint, but there is a mapping of ArchiMate metamodel entities to the
different areas and tools to support even the display of the canvas. Two samples can be found in Section A.1. More information can
be found in Modeling the Business Model Canvas with the ArchiMate® Specification (see Referenced Documents).

Business Capability Map Capability Map Viewpoint

We propose a series of ArchiMate viewpoints to
express a Solution Concept diagram:
 Strategy Viewpoint
 Resource Map Viewpoint
 Resource Realization Viewpoint8
Value Chain Diagram Process Cooperation Viewpoint
Value Stream Map Value Stream Viewpoint
4.2 Phase B Graphical Artifacts

The objectives of Phase B are to:
 Develop the Target Business Architecture that describes how the enterprise needs to
operate to achieve the business goals, and respond to the strategic drivers set out in the
Architecture Vision in a way that addresses the Statement of Architecture Work and
stakeholder concerns
 Identify candidate Architecture Roadmap components based upon gaps between the
Baseline and Target Business Architectures
Table 3: Phase B TOGAF Graphical Artifact – ArchiMate Viewpoint Mapping
ArchiMate 3.1 Specification

TOGAF Standard – Architecture Content (those in bold from ArchiMate 2.1 Specification)
Business Footprint Diagram Layered Viewpoint
Business Model Diagram Business Model Canvas
Business Service/Information Diagram Business Process Viewpoint
Functional Decomposition Diagram Business Function Viewpoint
Organization Map Actor Cooperation Viewpoint

(No viewpoint mapping available from different
sources.)
Product Lifecycle Diagram Product Lifecycle Viewpoint

sources.)
8
Modeling the Business Model Canvas with the ArchiMate Specification (W159); see Referenced Documents.
Business Event Diagram Business Process Cooperation Viewpoint
Process Flow Diagram Business Process Viewpoint
Goal/Objective/Service Diagram Goal Realization Viewpoint
Business Use-Case Diagram Business Process Cooperation Viewpoint
Organization Decomposition Diagram Organization Viewpoint
4.3 Phase C: Data Architecture Graphical Artifacts

The objectives of Phase C: Data Architecture are to:
 Develop the Target Data Architecture that enables the Business Architecture and the
Architecture Vision in a way that addresses the Statement of Architecture Work and
Baseline and Target Data Architectures
Table 4: Phase C: Data Architecture TOGAF Graphical Artifact – ArchiMate Viewpoint Mapping
Conceptual Data Diagram Information Structure Viewpoint
Logical Data Diagram Information Structure Viewpoint
Data Dissemination Diagram Information Structure Viewpoint
Data Security Diagram Information Structure Viewpoint
Data Lifecycle Diagram No viewpoint mapping available from different

sources. The Work Group created an explicit
viewpoint based on the ArchiMate viewpoint
mechanism.
Data Migration Diagram No viewpoint mapping available from different

sources. The Work Group created an explicit
viewpoint based on the ArchiMate viewpoint
mechanism.

4.4 Phase C: Application Architecture Graphical Artifacts
The objectives of Phase C: Application Architecture are to:
 Develop the Target Application Architecture that enables the Business Architecture and
the Architecture Vision, in a way that addresses the Statement of Architecture Work and
Baseline and Target Application Architectures
Table 5: Phase C: Application Architecture TOGAF Graphical Artifact – ArchiMate Viewpoint
Mapping
Application Communication Diagram Application Cooperation Viewpoint
Application and User Location Diagram No viewpoint mapping available from different
sources. The Work Group recommends a specific
diagram based on the ArchiMate viewpoint
mechanism.
Application Use-Case Diagram No viewpoint mapping available from different

mechanism.
Software Distribution Diagram Application Structure Viewpoint
Enterprise Manageability Diagram Proposal: move to Phase D Technology Usage

diagram
Application Migration Diagram No viewpoint mapping available from different

mechanism.
Process/Application Realization Diagram Application Usage Viewpoint
Software Engineering Diagram Application Structure Viewpoint
4.5 Phase D Graphical Artifacts

The objectives of Phase D are to:
 Develop the Target Technology Architecture to enable the Architecture Vision, target
business, data, and application building blocks to be delivered through technology
components and technology services in a way that addresses the Statement of Architecture
Work and stakeholder concerns
Baseline and Target Technology Architectures
Table 6: Phase D TOGAF Graphical Artifact – ArchiMate Viewpoint Mapping
Environments and Locations Diagram Technology Viewpoint
Platform Decomposition Diagram Technology Usage Viewpoint
Network and Communications Diagram No viewpoint mapping available from different

mechanism.
Networked Computing/Hardware Diagram No viewpoint mapping available from different

mechanism.
Processing Diagram Technology Viewpoint
4.6 Phase E Graphical Artifacts

The objectives of Phase E are to:
 Generate the initial complete version of the Architecture Roadmap, based upon the gap
analysis and candidate Architecture Roadmap components from Phases B, C, and D
 Determine whether an incremental approach is required, and if so, identify Transition
Architectures that will deliver continuous business value
 Define the overall SBBs to finalize the Target Architecture based on the ABBs
Table 7: Phase E TOGAF Graphical Artifact – ArchiMate Viewpoint Mapping
Benefits Diagram No viewpoint mapping available from different

sources. The Work Group proposes a sub-view of
the Goal Realization Viewpoint.
Project Context Diagram Implementation and Migration Viewpoint

5 Metamodel Based on the ArchiMate Specification
In this chapter we provide a minimal metamodel covering all the metamodel entities and
relationships necessary for all TOGAF ADM phases:
 ArchiMate viewpoints to represent all TOGAF graphical artifacts (see Chapter 4 and for
details see Appendix A)
 TOGAF matrices (see Appendix B)
 TOGAF catalogs (see Appendix C)
This was constructed by generating a domain-specific metamodel by adding all of the

metamodel entities and relationships being used for the ArchiMate viewpoints in Appendix A
and the metamodel entities and relationships being used in Appendix B and Appendix C. These
domain-specific metamodels can be found in Appendix G. In a final step, these domain-specific
metamodels have been consolidated to the one covering all phases.
Figure 12: Metamodel Based on the ArchiMate Specification to Cover the Complete TOGAF ADM

A ArchiMate Viewpoints to Model the TOGAF ADM
Graphical Artifacts
This appendix covers all graphical artifacts of the TOGAF ADM phase by phase with a detailed
description of the viewpoint definition and the metamodel entities and relationships used.
A.1 Phase A Graphical Artifacts
Table 8: TOGAF Solution Concept Diagram – ArchiMate Viewpoint Mapping

Solution Concept Diagram Introductory Viewpoint9

Name
A Solution Concept diagram provides a high-level The introductory viewpoint uses a simplified notation
orientation of the solution that is envisaged in order to to explain the essence of an architecture model to non-
meet the objectives of the architecture engagement. In architects that require a simpler, more intuitive
contrast to the more formal and detailed architecture notation.
diagrams developed in the following phases, the In contrast to the above we express a Solution Concept
solution concept represents a “pencil sketch” of the diagram by a series of ArchiMate viewpoints based on
expected solution at the outset of the engagement. the ArchiSurance Case Study; see Referenced
This diagram may embody key objectives, Documents.
requirements, and constraints for the engagement and Strategy Viewpoint:
may also highlight work areas to be investigated in
more detail with formal architecture modeling. The strategy viewpoint allows the Business Architect
to model a high-level, strategic overview of the
Its purpose is to quickly onboard and align
Description
strategies (courses of action) of the enterprise, the

stakeholders for a particular change initiative, so that capabilities, value streams, and resources supporting
all participants understand what the architecture those, and the envisaged outcomes.
engagement is seeking to achieve and how it is
expected that a particular solution approach will meet Resource Map Viewpoint:
the needs of the enterprise. The resource map viewpoint allows the Business
Architect to create a structured overview of the
resources of the enterprise. A resource map typically
shows two or three levels of resources across the entire
enterprise. It can, for example, be used as a heat map
to identify areas of investment. In some cases, a
resource map may also show relationships between
resources and the capabilities to which they are
assigned.
10
Resource Realization Viewpoint:
No explanation in documentation.
9
TOGAF Framework and ArchiMate Modeling Language Harmonization: Glossaries Comparison; see Referenced Documents.
10
ArchiSurance Case Study, Version 3.1; see Referenced Documents.

 Objectives  Goal
 Requirement  Requirement
 Constraint  Constraint
 Goal Solution concept viewpoint – top level
 Driver strategy viewpoint:
Note that all Metamodel Entities could potentially be  Driver
used.  Goal
 Assessment (no TOGAF element)
 Outcome (no TOGAF element)
 Course of Action
Metamodel Entities
 Capability
Solution concept viewpoint – bottom level
resource map viewpoint:
 Capability
 Resource (no TOGAF entity)
Solution concept viewpoint – extended level –
showing mapping to existing SBBs resource
realization viewpoint:
 Business Actor
 Application Component
 Equipment (no TOGAF element)
 Resource (no TOGAF element)
Solution concept viewpoint – summary:
 Outcome (no TOGAF entity)
 Resource (no TOGAF entity)
 Requirement
 A Goal is created by a Driver Solution Concept Viewpoint – top level:
 A Course of Action realizes a Goal Strategy Viewpoint:
 A Business Capability is influenced by a Course  A Capability is realizing a Goal or a Course of
of Action Action which is realizing an Outcome which is
 A Process operationalizes a Business Capability realizing a Goal
Metamodel Relationships
 A Function delivers a Business Capability  A Goal is influencing another goal, or a driver

 An Actor performs a Function being associated with an assessment
Solution Concept Viewpoint – bottom level
Resource Map Viewpoint:
 A Resource is assigned to a Capability
Solution Concept Viewpoint – extended level
Resource Realization Viewpoint:
 Business Actor/Application
Component/Equipment realizing a Resource
Solution Concept Viewpoint – summary:
 A Resource is realizing an Outcome or a
Requirement
Today’s Use of Channels Tomorrow’s Use of Channels
High-Value
Tasks
RM
From
RM RM to ST
Service Team
From From RM
Service Team Service to CC
Team to CC
Call Center
Call Center From Call From Service From RM
Center to Team to to Online
Online Online
Self-Service Internet Portal Self-Service Internet Portal
Low-Value
Tasks
Figure 13: Sample TOGAF Solution Concept Diagram
Figure 14: Sample ArchiMate Strategy View – Solution Concept View Top Level

Figure 15: Sample ArchiMate Resource Map View – Solution Concept View Bottom Level
Figure 16: Sample ArchiMate Resource Realization View – Solution Concept View Extended Level
Figure 17: Sample ArchiMate Solution Concept View 11
Table 9: TOGAF Value Chain Diagram – ArchiMate Viewpoint Mapping
Value Chain Diagram Actor Cooperation Viewpoint:12

In contrast to the initial mapping initiative, we propose
a direct mapping to a Process Cooperation Viewpoint.
Name
In general, the introduction of the Value Stream

Viewpoint in the most recent releases of both
standards could make obsolete the Value Chain
diagram.
Business Process Cooperation Viewpoint
11
12

A Value Chain diagram provides a high-level The business process cooperation viewpoint is used to
orientation view of an enterprise and how it interacts show the relationships of one or more business
with the outside world. In contrast to the more formal processes with each other and/or with their
Functional Decomposition diagram developed within environment. It can be used both to create a high-level
Phase B (Business Architecture), the Value Chain design of business processes within their context and
diagram focuses on presentational impact. to provide an operational manager responsible for one
The purpose of this diagram is to quickly onboard and or more such processes with insight into their
Description
align stakeholders for a particular change initiative, so dependencies. Important aspects of business process
that all participants understand the high-level cooperation are:
functional and organizational context of the  Causal relationships between the main business
architecture engagement. processes of the enterprise
 Mapping of business processes onto business
functions
 Realization of services by business processes
 Use of shared data
Each of these can be regarded as a “sub-viewpoint” of
the business process cooperation viewpoint.
 Process  Business Actor

 Role  Business Role
 Event  Business Collaboration
 Product  Location
 Business Interface
Metamodel Entities
 Business Process/Function/Interaction
 Business Event
 Business Service
 Business Object
 Representation
 Application Component/Collaboration
 Application Interface
 Application Process/Function/Interaction
 Application Event
 Application Service
 Data Object
 A Role performs a Process  Business Actor/Business Object being assigned to

 An Event generates a Process a location
 A Process follows a Process  Business Actor being assigned to a Business Role
 A Process decomposes a Process  Business Collaboration specializes a Business
 A Product is produced by a Process Role
 Business Collaboration aggregates Business
Role(s)
 Business Role being assigned to a Business
Process/Business Function
 Business Service/Business Process/Business

Function/Business Interaction accesses a Business
Object
 Business Process/Business Function realizes a
Business Service
 Business Service serves a Business
 Business Event triggers/being triggered by a
Business Process/Business Function/Business
Interaction
 Business Process/Business Function/Business
Interaction triggers a Business Process/Business
Function/Business Interaction
 Several more relationships connecting Business
Process/Business Function and Business
Interaction
 Application Service serves a Business Interaction
Firm Infrastructure
Activities
Human Resource Management

Support
Technology
Procurement
Inbound Outbound Marketing &

Operations Service
Logistics Logistics Sales
Primary Activities
Figure 18: Sample TOGAF Value Chain Diagram

Figure 19: Sample ArchiMate Business Process Cooperation View13
Table 10: TOGAF Business Model Diagram – ArchiMate Viewpoint Mapping

14
Business Model Diagram Business Model Canvas
Name
A model describing the rationale for how an enterprise With the actual release of the ArchiMate Specification
creates, delivers, and captures value. there is no standard viewpoint, but it is available with
Description
A detailed description and samples can be found in the different vendor-specific extensions. How to Model
TOGAF® Series Guide: Business Models (see Enterprise Risk Management and Security with the
Referenced Documents). ArchiMate® Language (see Referenced Documents)
explains in detail how to use the ArchiMate language
to model a Business Model Canvas.
Explicit mapping from business model content to  Business Actor, Stakeholder, Business Role:
metamodel entities cannot be found in the TOGAF® Partners
 Business Process, Capability: Activities
Metamodel Entities
Series Guide: Business Models.

 Business Service, Product, Value: Value
 Resource: Resources
 Business Collaboration, Capability: Relations
 Business Actor, Stakeholder, Role: Customers
 Business Interface, Resource: Channels
 Outcome (negative), Value (negative): Costs
 Outcome, Value: Revenues
(Preferred items in bold)
13
14
Source: BizzDesign Enterprise Studio.
Explicit mapping from business model content to

Relationships
Metamodel
metamodel relationships cannot be found in the

TOGAF® Series Guide: Business Models.
Product Customer Low Personal Mass

Manufacturers Analysis Prices Assistance Market
National Supplier Warranty Regional

Personal Touch
Suppliers Management Service Specialization
Regional Availability for

Suppliers Brand Common and Retail
Reputation Regional Needs Shopfronts
Real Web-Based
Estate Inventory Info
Facilities and Transport Profit on Sales
Employees and Supply Warranty Service
Scale Across Nation Manufacture Rebates
Figure 20: Sample TOGAF Business Model Diagram15
15
Taken from the TOGAF® Series Guide: Business Models; see Referenced Documents.

Figure 21: Sample ArchiMate Business Model View16
Table 11: TOGAF Business Capability Map – ArchiMate Viewpoint Mapping

Name
A family of diagrams representing a definitive listing The capability map viewpoint allows the Business
of a particular ability that a business may possess or Architect to create a structured overview of the
exchange to achieve a specific purpose. capabilities of the enterprise. A capability map
typically shows two or three levels of capabilities
Description
From Phase A:
across the entire enterprise. It can, for example, be
Identifies, categorizes, and decomposes the business used as a heat map to identify areas of investment. In
capabilities required for the business to have the ability some cases, a capability map may also show specific
to deliver value to one or more. outcomes delivered by these capabilities.
A detailed description and samples can be found in the
TOGAF® Series Guide: Business Capabilities (see
Referenced Documents).
 Business Capability  Capability

Metamodel
Entities
Optional:
 Outcome
 Resource
16
Sample View from BizzDesign Enterprise Studio.
 A Business Capability is a composition of other  A Capability is a composition of other

Relationships
Metamodel
Business Capabilities Capabilities
Business Planning Market Planning Partner Management

Strategic
Government Relations
Capital Management Policy Management
Management
Account Management Product Managment Distribution Management

Core
Customer Management Channel Management Agent Management
Procurement
Financial Management HR Management
Management
Supporting
Information Management Training Management Operations Management
Figure 22: Sample TOGAF Business Capability Map (as “Heat Map”)17
17
Taken from the TOGAF® Series Guide: Business Capabilities; see Referenced Documents.

Figure 23: Sample ArchiMate Capability Map View18
Table 12: TOGAF Value Stream Map – ArchiMate Viewpoint Mapping

Name
18
A diagram representing an end-to-end collection of The value stream viewpoint allows the Business
value-adding activities that create an overall result for Architect to create a structured overview of a value
a customer, stakeholder, or end user. stream, the capabilities supporting the stages in that
From Phase A: value stream, the value created, and the stakeholders
involved.
Value stream maps illustrate how an organization
delivers value and are in the context of a specific set of
stakeholders, and leverage business capabilities in
order to create stakeholder value and align to other
aspects of the Target Business Architecture.
Applying value streams:
Value streams provide valuable stakeholder context
into why the organization needs business capabilities,
while business capabilities provide what the
organization needs for a particular value stage to be
successful. Start with the initial set of value stream
models for the business documented in the
Description
Architecture Vision phase. Within the scope of the

specific Enterprise Architecture project, if sufficiently
larger in breadth, there may be a need for new value
streams not already in the repository. A new or
existing value stream can be analyzed within the scope
of the project through heat mapping (by value stream
stage) or by developing use-cases around a complete
definition of the value stream (see the baseline
example in the TOGAF® Series Guide: Value Streams;
see Referenced Documents). A project might focus on
specific stakeholders, one element of business value,
or stress some stages over others to develop better
requirements for solutions in later phases. The most
substantive benefits come from mapping relationships
between the stages in a value stream to business
capabilities, then performing a gap analysis for
capabilities (such as heat mapping) in the context of
the business value achieved by the value stream for a
specific stakeholder (see Mapping Value Streams to
Business Capabilities in the TOGAF® Series Guide:
Value Streams; see Referenced Documents).
 Value Stream  Value Stream

Metamodel
 Business Capability 
Entities
Value
 Actor  Capability
 Outcome
 Stakeholder
 Value Stream triggers other Value Stream(s)  Value Stream triggers other Value Stream(s)
Relationships
Metamodel
 Business Capability enables a Value Stream  Value being associated with trigger Relationship
 Actor triggers a Value Stream (TOGAF® Series  Capability serves a Value Stream
Guide: Value Streams; see Referenced
Documents)

Communicate Assess Interview Onboard
Define Position
Position Responses Candidates Employee
Program Mgmt. HR Mgmt. HR Mgmt. HR Mgmt. HR Mgmt.

Program/Human Employee Supply Employee Supply Benefits Mgmt. Onboard Tracking
Resource Matching and Demand Mgmt. and Demand Mgmt.
Terms Mgmt.
HR Mgmt. Position Advertising Skills Assessment Compensation Asset Mgmt.
Mgmt.
Competency Mgmt. Asset Allocation
Finance Mgmt. Agreement Mgmt.

Policy Mgmt. Labor Funding Agreement Facilities Mgmt.
Structuring
Policy Dissemination Space Allocation
Security Mgmt.
Employee
Background and ID
Information Mgmt.
Employee
Informaton Mgmt
Figure 24: Sample TOGAF Value Stream Map (including Business Capabilities) 19
Figure 25: Sample ArchiMate Value Stream Viewpoint
A.2 Phase B Graphical Artifacts

The Business Model Diagram, Business Capability Map, and Value Stream Map are available
for Phases A and B. These diagrams are already explained in Section A.1.
19
TOGAF® Series Guide: Value Streams; see Referenced Documents.
Table 13: TOGAF Business Footprint Diagram – ArchiMate Viewpoint Mapping

20
Business Footprint Diagram Layered Viewpoint
Name
A Business Footprint diagram describes the links The layered viewpoint pictures several layers and
between business goals, organizational units, business aspects of an Enterprise Architecture in one diagram.
functions, and services, and maps these functions to There are two categories of layers, namely dedicated
the technical components delivering the required layers and service layers. The layers are the result of
capability. the use of the “grouping” relationship for a natural
A Business Footprint diagram provides a clear partitioning of the entire set of objects and
traceability between a technical component and the relationships that belong to a model. The technology,
business goal that it satisfies, while also demonstrating application, process, and actor/role layers belong to the
ownership of the services identified. first category. The structural principle behind a fully
Description
layered viewpoint is that each dedicated layer exposes,

A Business Footprint diagram demonstrates only the by means of the “realization” relationship, a layer of
key facts linking organization unit functions to services, which are, further on, “serving” the next
delivery services and is utilized as a communication dedicated layer. Thus, we can easily separate the
platform for senior-level (CxO) stakeholders. internal structure and organization of a dedicated layer
from its externally observable behavior expressed as
the service layer that the dedicated layer realizes. The
order, number, or nature of these layers are not fixed.
The main goal of the layered viewpoint is to provide
an overview in one diagram. Furthermore, this
viewpoint can be used as support for impact of change
analysis and performance analysis or for extending the
service portfolio.
Metamodel
All metamodel entities are allowed. All metamodel entities are allowed.
Entities
All metamodel relationships are allowed. All metamodel relationships are allowed.
Relationships
Metamodel
20

SC5 – Plan Goods SC6 – Schedule & Execute
SC1 – Plan & Manage SC2 – Plan Sales & SC3 – Establish Inventory SC4 – Define Movements and Goods Movements,
Demand Operations Plan Manufacturing Plan Resources in the Storage, and
Distribution Network Transportation Decisions
SC11 – Monthly Forecast SC22 – Cross-UOT Demand & Supply Balancing and SC51 – Logistics Capacity SC61 – Warehouse
Generation LP S&OP Validation Planning Management
SC52 – Distribution Supply
SC12 – Monthly Forecast SC62 – Long Distance
SC21 – UOT and LPS Tactical Supply Planning Planning – Mid-Term
Collaboration Transportation
SC42 – Multi-Plant Planning SC53 – Distribution Supply
SC17 – Forecast Weekly SC32 – Inventory Management Planning – Short-Term SC63 – Short Distance
Update Rules Parameter Definition SC54 – Distribution Shortage Transportation
SC16 – Demand Explosion for Management GFB57 – Process Steps
Assembly SC41 – Plant Production Traceability
Planning SC55 – Deployment
SC13 – Planned Demand SC65 – Transportation
Consumption by Cust Order SC56 – Intra-Group Exchanges Administration
Management
SC14 – Allocation Definition Rules
SC57 – Procurement GFB58 – Product Traceability
for ATP (Monthly)
Exchanges Management
SC15 – Allocation Definition Rules
SC70 – Inventory Management (Physical and Planned Inventory, including Internal Transfer Orders)
for ATP (Daily)
SC07 – Inventory Norms

SC0 – Referential
Definition
GFB64 – Supply Chain Costs & Margin Referential
GFB62 – Supply Chain Referential – Production Process Model GBF61 – Supply Chain Referential – Logistics Resource
GFB63 – Demand Planning

GFB65 – Supply Chain Referential – Production & Distribution & Ship to Customer Network
Referential
GFB59 – Product & Services – Client Catalog
GFB50 – Product & Services Referential
GFB51 – Client Referential
SC91 – Demand SC92 – Tactical Planning SC93 – Inventory SC94 – Plant Planning SC95 – Distribution Planning SC96 – Logistics
SC9 BI / Reporting BI / Reporting BI / Reporting BI / Reporting BI / Reporting BI / Reporting
– BI
GFB70 – Global Cross-Domain Reporting & Analysis
Figure 26: Sample TOGAF Business Footprint Diagram
Figure 27: Sample ArchiMate Layered View
Table 14: TOGAF Business Service/Information Diagram – ArchiMate Viewpoint Mapping

21
Business Service/Information Diagram Business Process Viewpoint
Name
22
The Business Service/Information diagram shows the The business process viewpoint is used to show the
information needed to support one or more business high-level structure and composition of one or more
services. The Business Service/Information diagram business processes. Next to the processes themselves,
shows what data is consumed by or produced by a this viewpoint contains other directly related concepts,
business service and may also show the source of such as:
Description
information.  The services that a business process offers to the

The Business Service/Information diagram shows an outside world, showing how a process contributes
initial representation of the information present within to the realization of the company’s products
the architecture and therefore forms a basis for  The assignment of business processes to roles,
elaboration and refinement within Phase C: Data which gives insight into the responsibilities of the
Architecture. associated actors
 The information used by the business process
Each of these can be regarded as a “sub-view” of the
business process view.
 Business Service  Business Service

Metamodel
 Business Information  Business Object

Entities
 Business Process
 Business Role
(plus more optional entities)
 Business Service consumes Business Information  Business Service/Business Process accesses a

 Business Service produces Business Information Business Object
 Business Object is associated with flow relation

between two Business Services
Optional:
 Business Role being assigned to a Business
Process
 Business Process realizes a Business Service
 Business Service serves a Business Process
 Several more relationships connecting Business
Process and/or Business Services
(plus more optional relationships)
21
22
ArchiMate 2.1 Specification; see Referenced Documents.

Complaint
Fault
Complaint Handling
Common Faults Management
Service
Service
Customer Details
Customer
Complaint Customer Details

Resolution
Extended example showing actors

and service interactions
Lead
Management
Service
Figure 28: Sample TOGAF Business Service/Information Diagram
Figure 29: Sample ArchiMate Business Process View (Two Variants of “Information” Modeling)
Table 15: TOGAF Functional Decomposition Diagram – ArchiMate Viewpoint Mapping

23
Functional Decomposition Diagram Business Function Viewpoint
Name
23
24
The purpose of the Functional Decomposition diagram The business function viewpoint shows the main
is to show on a single page the capabilities of an business functions of an organization and their
organization that are relevant to the consideration of an relationships in terms of the flows of information,
architecture. value, or goods between them. Business functions are
By examining the capabilities of an organization from used to represent the most stable aspects of a company
in terms of the primary activities it performs,
Description
a functional perspective, it is possible to quickly

develop models of what the organization does without regardless of organizational changes or technological
being dragged into an extended debate on how the developments. Therefore, the business function
organization does it. architecture of companies that operate in the same
market often exhibit close similarities. The business
Once a basic Functional Decomposition diagram has function viewpoint thus provides a high-level insight
been developed, it becomes possible to layer heat in the general operations of the company, and can be
maps on top to show scope and decisions. For used to identify necessary competencies, or to
example, the capabilities to be implemented in structure an organization according to its main
different phases of a change program. activities.
 Function  Business Function

Metamodel
Entities
 Function composes other Function(s)  Business Function composes other Business

Relationships
Metamodel
Function(s)
24

Support Primary
Human Business Marketing &

Admin Finance Engineering Inventory Manufacturing Distribution
Resources Planning Sales
Develop & Research & Plan

Manage Public Plan Human Formulate Develop New Plan Material Engineer
Track Financial Develop Manufacturing
Relations Resources Strategy Business Requirements Packages
Plan Technology Requirements
Procure
Develop & Establish Engineer &
Provide Legal Appropriate Acquire Human Equipment, Perform Quality
Maintain Customer Design Ship Products
Services Funds Resources Material, & Engineering
Business Plan Requirements Products
Tools
Develop & Engineer & Convert

Perform Audit & Develop Obtain Sales Manage
Manage Design Resources to
Controls Employees Commitments Suppliers
Product Cost Processes Product
Provide Provide
Manage Manage Design Tools & Manage Control
Employee Customer
Transportation Payables Equipment Inventory Production
Services Support
Manage Maintain Plant

Maintain Manage Manage Union
Engineering Equipment &
Facilities Receivables Activities
Changes Tools
Provide Terminate Manage

Administrative Manage Assets Active Warranty
Services Employment Activities
Figure 30: Sample TOGAF Functional Decomposition Diagram
Figure 31: Sample ArchiMate Business Function View
Table 16: TOGAF Product Lifecycle Diagram – ArchiMate Viewpoint Mapping
Product Lifecycle Diagram Product Lifecycle Viewpoint

Name

sources.)
The purpose of the Product Lifecycle diagram is to We propose two variants (both based on the
assist in understanding the lifecycles of key entities ArchiMate definition of a product which differs from
within the enterprise. Understanding product lifecycles the TOGAF definition):
is becoming increasingly important with respect to Variant 1:
environmental concerns, legislation, and regulation
Description
where products must be tracked from manufacture to Showing the business processes changing a business
disposal. Equally, organizations that create products object representing the detailed state of a contract
that involve personal or sensitive information must being part of a product.
have a detailed understanding of the product lifecycle Variant 2:
during the development of Business Architecture in Showing the interaction between business processes
order to ensure rigor in design of controls, processes, and business services being part of a product and
and procedures. Examples of this would include credit business processes realizing business services.
cards, debit cards, store/loyalty cards, smart cards, user
identity credentials (identity cards, passports, etc.).
 Product (including lifecycle states) Both Variants:

 Product
Metamodel Entities
 Contract
 Business Object
Variant 2:
 Event
 Meaning
Variant 1:
 Product aggregates Business Service(s)
 Product aggregates Contract(s)
 Contract composes Business Object(s)
 Business Object/Business Service accesses a

Contract/Business Object
Variant 2:
 Product aggregates Business Service(s)
 Product aggregates Business Object(s)
 Business Object/Business Service accesses a
Contract/Business Object
 Business Process realizes a Business Service
 Event triggers a Business Process
 Meaning being associated with an access/realize
relationship

Introduction Growth Maturity Decline
Product B
Industry Sales
Product A
Time
Figure 32: Sample TOGAF Product Lifecycle Diagram
Figure 33: Sample ArchiMate Product Lifecycle View – Variant 1
Figure 34: Sample ArchiMate Product Lifecycle View – Variant 2
Table 17: TOGAF Organization Map – ArchiMate Viewpoint Mapping
Organization Map Actor Cooperation Viewpoint

Name

sources.)

26
A diagram showing the relationships between the The actor cooperation viewpoint focuses on the
primary entities that make up the enterprise, its relationships of actors with each other and their
partners, and stakeholders. environment. A common example of this is the
From Phase A: As traditional organizational charts “context diagram”, which puts an organization into its
often lack the necessary detail to reflect the full scope environment, consisting of external parties such as
of the enterprise activities, the architect can help to customers, suppliers, and other business partners. It is
identify and understand the complex web of very useful in determining external dependencies and
relationships between business entities as well as collaborations and shows the value chain or network in
where business capabilities are used and connected to which the actor operates.
value stream stages. These are refined and extended in Not used in this mapping approach:
subsequent phases. Another important use of the actor cooperation
From Phase B: A representation of the organizational viewpoint is in showing how a number of co-operating
structure of the business (including third-party business actors and/or application components
domains), depicting business units, the decomposition together realize a business process. Hence, in this
of those units into lower-level functions, and view, both business actors or roles and application
organizational relationships (unit-to-unit and mapping components may occur.
to business capabilities, locations, and other A common example of this is the “context diagram”,
attributes). which puts an organization into its environment,
Applying the organization map: An organization map consisting of external parties such as customers,
depicts the working relationships between the primary suppliers, and other business partners. It is very useful
entities that make up the enterprise, its partners, and in determining external dependencies and
Description
stakeholders, as distinct from an organizational chart collaborations and shows the value chain or network in
that only shows hierarchical reporting relationships. which the actor operates.
The map is typically depicted as a network or web of
relationships and interactions between the various
business entities.25 The business unit is the main
concept used to establish organization maps. In
keeping with the relatively unconstrained view of what
constitutes as enterprise, the enterprise may be one
business unit for the project underway, may include all
business units, or also include third parties or other
stakeholder groups. The interpretation depends on the
scope of the architecture effort. This map is a key
element of Business Architecture because it provides
the organizational context for the whole Enterprise
Architecture effort. While capability mapping exposes
what a business does and value stream mapping
exposes how it delivers value to specific stakeholders,
the organization map identities the business units or
third parties that possess or use those capabilities and
which participate in the value streams. The map
provides an understanding of which business units to
involve in the architecture effort, who and when to talk
about a given requirement, and how to measure the
impact of various decisions (for examples see the
TOGAF® Series Guide: Organization Mapping; see
Referenced Documents).
25
Organigraphs: Drawing How Companies Really Work, by Mintzberg and Van der Heyden, 1999; refer to:
https://hbr.org/1999/09/organigraphs-drawing-how-companies-really-work.
26
 (internal and external) Organization Unit  Business Actor

 Business Role
Metamodel
Entities
 Business Interface
Optional:
 Business Collaboration
 Organization Unit is related to another  Business Actor composes other Business Actor(s)
Organization Unit  Business Actor being assigned to a Business Role
 Business Actor/Business Role triggers another
Business Actor/Business Role

 Business Interface serves a Business Role
 Business Role composes Business Interface(s)
 Business Interface being assigned to a Business
Service
 Business Service serves Business Role(s)
Optional:
 Business Collaboration specializes a Business
Role
Role(s)
Key:
IT Warehouse
Enterprise
HR
Web
Services Business
Finance Unit
Central
Operations
Online Store Department
Quality Global
Assurance Companies,
External
Inc. Party
Product
Design
Product Collaborative
Suppliers Retail Team
Sales & Operations
Marketing
Japan
Retail US Store Store
Strategy
Team UK Store
Figure 35: Sample TOGAF Organization Map

Figure 36: Sample ArchiMate Actor Cooperation View
Table 18: TOGAF Organization Decomposition Diagram – ArchiMate Viewpoint Mapping

27
Organization Decomposition Diagram Organization Viewpoint
Name
An Organization Decomposition diagram describes the The organization viewpoint focuses on the (internal)
links between actor, roles, and location within an organization of a company, department, network of
organization tree. companies, or of another organizational entity. It is
Description
An organization map should provide a chain of possible to present models in this viewpoint as nested
command of owners and decision-makers in the block diagrams, but also in a more traditional way,
organization. Although it is not the intent of the such as organizational charts. The organization
Organization Decomposition diagram to link goal to viewpoint is very useful in identifying competencies,
organization, it should be possible to intuitively link authority, and responsibilities in an organization.
the goals to the stakeholders from the Organization
Decomposition diagram.
 Organization Unit  Business Actor

 Actor  Business Role
Metamodel
Entities
 Role  Location
 Location  Business Interface
Optional:
27
 Location contains Organization Unit(s) 

Location aggregates Business Actor(s)

 Organization Unit contains Actor(s)  Business Actor composes Business Actor(s)
 Actor performs task in Role  Business Actor being assigned to a Business Role
 Business Role composes Business Interface(s)
Optional:
Role
Role(s)
Figure 37: Sample ArchiMate Organization View
Table 19: TOGAF Process Flow Diagram – ArchiMate Viewpoint Mapping

28
Process Flow Diagram Business Process Viewpoint
Name
28

29
The purpose of the Process Flow diagram is to depict The business process viewpoint is used to show the
all models and mappings related to the process high-level structure and composition of one or more
metamodel entity. Process Flow diagrams show business processes. Next to the processes themselves,
sequential flow of control between activities and may this viewpoint contains other directly related concepts,
utilize swimlane techniques to represent ownership such as:
and realization of process steps. For example, the  The services that a business process offers to the
application that supports a process step may be shown outside world, showing how a process contributes
Description
as a swim-lane. In addition to showing a sequence of to the realization of the company’s products

activity, process flows can also be used to detail the  The assignment of business processes to roles,
controls that apply to a process, the events that trigger which gives insight into the responsibilities of the
or result from completion of a process, and also the associated actors
products that are generated from process execution.  The information used by the business process
Process Flow diagrams are useful in elaborating the
architecture with subject specialists, as they allow the Each of these can be regarded as a “sub-view” of the
specialist to describe "how the job is done" for a business process view.
particular function. Through this process, each process
step can become a more fine-grained function and can
then in turn be elaborated as a process.
 Role  Location
 Event  Business Actor
 Process  Business Role
Metamodel Entities
 Function  Business Event

 Product  Business Process
 Business Function
 Business Interaction
 Business Object
Optional:
29
 Organization Unit/Role performs/participates in  Location aggregates Business Actor(s)

Process  Business Actor is assigned to a Business Role
 Event is resolved by/is generated by Process  Business Role is assigned to a Business
 Process orchestrates/decomposes Function(s) Process/Business Function
 Process produces Product  Business Event triggers/is triggered by a Business
Process/Business Function/Business Interaction
Interaction triggers/specializes/aggregates/
composes a Business Process/Business

 Business Service triggers a Business
Business Service
Object
Optional:
 Application Service serves a Business Service/
Business Process/Business Function/Business
Interaction
Role
Role(s)
Figure 38: Sample ArchiMate Business Process View

Table 20: TOGAF Business Event Diagram – ArchiMate Viewpoint Mapping

30
Business Event Diagram Business Process Cooperation Viewpoint
Name
The purpose of the Business Event diagram is to depict The business process cooperation viewpoint31 is used
the relationship between events and process. to show the relationships of one or more business
Certain events – such as arrival of certain information processes with each other and/or with their
(e.g., customer submits sales order) or a certain point environment. It can both be used to create a high-level
in time (e.g., end of fiscal quarter) – cause work and design of business processes within their context and
certain actions need to be undertaken within the to provide an operational manager responsible for one
business. These are often referred to as “business or more such processes with insight into their
Description
events” or simply “events” and are considered as dependencies.

triggers for a process. It is important to note that the Important aspects of business process cooperation are:
event has to trigger a process and generate a business  Causal relationships between the main business
response or result. processes of the enterprise
 Mapping of business processes onto business
functions
 Realization of services by business processes
 Use of shared data
Each of these can be regarded as a “sub-view” of the
business process cooperation view.
 Event  Location
 Business Role
Metamodel Entities
 Business Event
 Business Function
 Business Interaction
 Business Object
Optional:
30
31
 Event is resolved by/is generated by Process  Location aggregates Business Actor(s)

 Business Actor is assigned to a Business Role
 Business Role is assigned to a Business
 Business Event triggers/is triggered by a Business
Interaction triggers/specializes/aggregates/
composes a Business Process/Business Function/

Business Interaction
 Business Service triggers a Business
Business Service
Object
 Optional: Application Service serves a Business
Service/Business Process/Business
Optional:
Role
Role(s)
Figure 39: Sample ArchiMate Business Process Cooperation View
Table 21: TOGAF Business Use-Case Diagram – ArchiMate Viewpoint Mapping

32
Business Use-Case Diagram Business Process Cooperation Viewpoint
Name
32

A Business Use-Case diagram displays the See mapping of Event diagram.

relationships between consumers and providers of
business services. Business services are consumed by
actors or other business services and the Business Use-
Case diagram provides added richness in describing
Description
business capability by illustrating how and when that

capability is used.
The purpose of the Business Use-Case diagram is to
help to describe and validate the interaction between
actors and their roles to processes and functions. As
the architecture progresses, the use-case can evolve
from the business level to include data, application,
and technology details. Architectural business use-
cases can also be re-used in systems design work.
 Actor  See mapping of Event diagram

Metamodel
 Business service
Entities
 Actor consumes/provides Business Service  See mapping of Event diagram

Relationships
Metamodel
Figure 40: Sample ArchiMate Business Process Cooperation View
Table 22: TOGAF Goal/Objective/Service Diagram – ArchiMate Viewpoint Mapping

33
Goal/Objective/Service Diagram Goal Realization Viewpoint
Name
The purpose of a Goal/Objective/Service diagram is to The goal realization viewpoint allows a designer to
define the ways in which a service contributes to the model the refinement of (high-level) goals into more
achievement of a business vision or strategy. tangible goals, and the refinement of tangible goals
into requirements or constraints that describe the
Description
Services are associated with the drivers, goals,

objectives, and measures that they support, allowing properties that are needed to realize the goals. The
the enterprise to understand which services contribute refinement of goals into sub-goals is modeled using
to similar aspects of business performance. The the aggregation relationship. The refinement of goals
Goal/Objective/Service diagram also provides into requirements is modeled using the realization
qualitative input on what constitutes high performance relationship.
for a particular service. In addition, the principles may be modeled that guide
the refinement of goals into requirements.
 Driver  (Driver)
 
Metamodel
Goal Goal
Entities
 Objective  Principle
 Business Service  Requirement
 Constraint
 No explicit metamodel relationships are defined  Goal aggregates other Goal(s)
 Goal influences another Goal

Relationships
Principle realizes/influences a Goal

Metamodel
 Requirement/Constraint realizes/influences a
Principle
 Requirement/Constraint influences another
Requirement/Constraint
 Business Service realizes a Requirement/
Constraint
33

Figure 41: Sample ArchiMate Goal Realization View
A.3 Phase C: Data Architecture Graphical Artifacts

Table 23: TOGAF Conceptual Data Diagram – ArchiMate Viewpoint Mapping

34
Conceptual Data Diagram Information Structure Viewpoint
Name
34
The key purpose of the Conceptual Data diagram is to The information structure viewpoint is comparable to
depict the relationships between critical data entities the traditional information models created in the
within the enterprise. This diagram is developed to development of almost any information system. It
address the concerns of business stakeholders. shows the structure of the information used in the
Description
Techniques used include: enterprise or in a specific business process or

application, in terms of data types or (object-oriented)
 Entity relationship models class structures. Furthermore, it may show how the
 Simplified UML class diagrams information at the business level is represented at the
application level in the form of the data structures used
there, and how these are then mapped onto the
underlying technology infrastructure; e.g., by means of
a database schema.
 Data Entity
35
 Business Object
Metamodel

Entities
Representation
 Meaning
 Data Object
 Artifact
 No explicit metamodel relationships are defined  Artifact realizes a Data Object
 Data Object realizes a Business Object

Relationships
Meaning is associated to a Representation

Metamodel
 Representation realizes a Business Object

 Several relationships from Business Object to
Business Object
 Several relationships from Data Object to Data
Object
 Several relationships from Artifact to Artifact
Figure 42: Sample ArchiMate Information Structure View
35
This could be replaced by business information in future releases.

Table 24: TOGAF Logical Data Diagram – ArchiMate Viewpoint Mapping

36
Logical Data Diagram Information Structure Viewpoint
Name
The key purpose of the Logical Data diagram is to The information structure viewpoint is comparable to
show logical views of the relationships between the traditional information models created in the
critical data entities within the enterprise. This diagram development of almost any information system. It
is developed to address the concerns of: shows the structure of the information used in the
Description
 Application developers enterprise or in a specific business process or

 Database designers application, in terms of data types or (object-oriented)
class structures. Furthermore, it may show how the
information at the business level is represented at the
application level in the form of the data structures used
underlying technology infrastructure; e.g., by means of
a database schema.
 Data Entity  Business Object

Metamodel
 Logical Data Component 

Entities
Representation
 Meaning
 Data Object
 Artifact
 Logical Data Component encapsulates Data Entity  Artifact realizes a Data Object
 Data Object realizes a Business Object

Relationships
Meaning is associated to a Representation

Metamodel
 Representation realizes a Business Object

 Several relationships from Business Object to
Business Object
Object
36
Table 25: TOGAF Data Dissemination Diagram – ArchiMate Viewpoint Mapping

37
Data Dissemination Diagram Information Structure Viewpoint
Name
37

The purpose of the Data Dissemination diagram is to The information structure viewpoint is comparable to
show the relationship between data entity, business the traditional information models created in the
service, and application components. The diagram development of almost any information system. It
shows how the logical entities are to be physically shows the structure of the information used in the
realized by application components. This allows enterprise or in a specific business process or
effective sizing to be carried out and the IT footprint to application, in terms of data types or (object-oriented)
be refined. Moreover, by assigning business value to class structures. Furthermore, it may show how the
Description
data, an indication of the business criticality of information at the business level is represented at the
application components can be gained. application level in the form of the data structures used
Additionally, the diagram may show data replication there, and how these are then mapped onto the
and application ownership of the master reference for underlying technology infrastructure; e.g., by means of
data. In this instance, it can show two copies and the a database schema.
master-copy relationship between them. This diagram
can include services; that is, services encapsulate data,
and they reside in an application, or services that
reside in an application and access data encapsulated
within the application.
 Business Service  Business Object

 
Metamodel Entities
Data Entity Representation

 Logical Data Component  Meaning
 Logical Application Component  Data Object
 Physical Application Component  Artifact
 Application Function
 Value
 Business Service provides/consumes Data Entity  Artifact realizes a Data Object
 Logical Data Component encapsulates Data Entity  Data Object realizes a Business Object
 Logical Application Component uses Logical  Meaning is associated to a Representation
Data Component  Representation realizes a Business Object

 Physical Application Component realizes Logical  Several relationships from Business Object to
Application Component Business Object
Object
 Application Service accesses Data Object
 Application Function realizes an Application
Service
 Application Component being assigned to an
Application Function
 Value being associated with Data Object
Sales Order Order
Fulfillment
Order History
Service
Customer
Stock
Product
Billing Distribution
Customer Customer
Balance Stock
Invoice Purchase Order
Figure 44: Sample TOGAF Data Dissemination Diagram
Table 26: TOGAF Data Security Diagram – ArchiMate Viewpoint Mapping

38
Data Security Diagram Information Structure Viewpoint
Name
38

Data is considered as an asset to the enterprise and The information structure viewpoint is comparable to
data security simply means ensuring that enterprise the traditional information models created in the
data is not compromised and that access to it is development of almost any information system. It
suitably controlled. shows the structure of the information used in the
The purpose of the Data Security diagram is to depict enterprise or in a specific business process or
which actor (person, organization, or system) can application, in terms of data types or (object-oriented)
access which enterprise data. This relationship can be class structures. Furthermore, it may show how the
shown in a matrix form between two objects or can be information at the business level is represented at the
Description
shown as a mapping. application level in the form of the data structures used
The diagram can also be used to demonstrate underlying technology infrastructure; e.g., by means of
compliance with data privacy laws and other a database schema.
applicable regulations (the Health Insurance
Portability and Accountability Act (HIPAA),
Sarbanes-Oxley, etc.). This diagram should also
consider any trust implications where an enterprise’s
partners or other parties may have access to the
company’s systems, such as an outsourced situation
where information may be managed by other people
and may even be hosted in a different country.

 Logical Data Component  Representation
 
Metamodel Entities
Physical Data Component Meaning

 Organization Unit  Data Object
 Actor  Artifact
 Logical Application Component  Driver
 Physical Application Component  (Security) Principle
 (Security) Requirement
 (Security) Constraint
 Business Role
 Logical Data Component encapsulates Data Entity  Artifact realizes a Data Object
 Physical Data Component realizing Logical Data  Data Object realizes a Business Object
Component  Meaning is associated to a Representation
 Logical Application Component uses Logical  Representation realizes a Business Object
Data Component  Several relationships from Business Object to
 Physical Application Component realizes Logical Business Object
Application Component  Several relationships from Data Object to Data

 Physical Application Component uses Physical Object
Data Component  Several relationships from Artifact to Artifact
 Organization Unit owns Data Entity  (Security) Requirement/ (Security) Constraint
 Actor consumes Data Entity (realizing (Security) Principle) being associated
with Driver
 Requirement/Constraint being realized by
Application Component
 Requirement/Constraint being associated with
Data Object
 Business Role being served by (Application
Interface being composed by) Application
Component
 Application Component (is assigned to
Application Function) accesses Data Object

Table 27: TOGAF Data Migration Diagram – ArchiMate Viewpoint Mapping
Data Migration Diagram No viewpoint mapping available from different

Name
sources.
Data migration is critical when implementing a The Work Group created an explicit viewpoint based
package or packaged service-based solution. This is on the ArchiMate viewpoint mechanism.
particularly true when an existing legacy application is
replaced with a package or an enterprise is to be
migrated to a larger package/packaged services
footprint. Packages tend to have their own data model
and during data migration the legacy application data
may need to be transformed prior to loading into the
package.
Data migration activities will usually involve the
following steps:
 Extract data from source applications (baseline
systems)
 Profile source data
 Perform data transformation operations, including
Description
data quality processes:

— Standardize, normalize, de-duplicate source
data (data cleansing)
— Match, merge, and consolidate data from
different source(s)
— Source-to-target mappings
 Load into target applications (target systems)
The purpose of the Data Migration diagram is to show
the flow of data from the source to the target
applications. The diagram will provide a visual
representation of the spread of sources/targets and
serve as a tool for data auditing and establishing
traceability. This diagram can be elaborated or
enhanced as detailed as necessary. For example, the
diagram can contain just an overall layout of migration
landscape or could go into individual application
metadata element level of detail.

Metamodel
 
Entities
Logical Data Component Data Object

 Physical Data Component  Application Process/Function
 Logical Application Component  Application Component
 Physical Application Component
 Logical Data Component encapsulates Data Entity  Data Object realizes Business Object
 Physical Data Component realizing Logical Data  Application Function/Process accesses Data
Relationships
Component Object
Metamodel
 Logical Application Component uses Logical  Application Component is assigned to Application

Data Component Function
 Physical Application Component uses Physical
Data Component
 Physical Application Component realizes Logical
Figure 47: Sample ArchiMate Data Migration View
Table 28: TOGAF Data Lifecyle Diagram – ArchiMate Viewpoint Mapping
Data Lifecycle Diagram No viewpoint mapping available from different

Name
sources.

The Data Lifecycle diagram is an essential part of The Work Group created an explicit viewpoint based
managing business data throughout its lifecycle from on the ArchiMate viewpoint mechanism.
conception until disposal within the constraints of the
business process.
Description
The data is considered an entity in its own right,

decoupled from business process and activity. Each
change in state is represented on the diagram which
may include the event or rules that trigger that change
in state.
The separation of data from process allows common
data requirements to be identified which enables
resource sharing to be achieved more effectively.
 Data Entity  Data Object

Metamodel
 Business Process 
Entities
Meaning
 Business Service  Business Event
 Business Service provides/consumes Data Entity  Application Service accesses Data Object
Relationships
Metamodel
 Business Process orchestrates/decomposes  Meaning being associated with access relationship

Business Service  Business Event triggers Business Process
 Application Service serves Business Process
Figure 48: Sample ArchiMate Data Lifecycle View
A.4 Phase C: Application Architecture Graphical Artifacts
Table 29: TOGAF Application Communication Diagram – ArchiMate Viewpoint Mapping

39
Application Communication Diagram Application Cooperation Viewpoint
Name
The purpose of the Application Communication The application cooperation viewpoint describes the
diagram is to depict all models and mappings related relationships between application components in terms
to communication between applications in the of the information flows between them, or in terms of
Metamodel entity. the services they offer and use. This viewpoint is
typically used to create an overview of the application
Description
It shows application components and interfaces

between components. landscape of an organization. This viewpoint is also
used to express the (internal) cooperation or
Interfaces may be associated with data entities where orchestration of services that together support the
appropriate. Applications may be associated with execution of a business process; see the TOGAF® 9.1
business services where appropriate. Framework and ArchiMate® 2.1 Modeling Language
Communication should be logical and should only Harmonization: Glossaries Comparison, White Paper
show intermediary technology where it is (see Referenced Documents).
architecturally relevant.
 Logical Application Component 

Metamodel Entities
Location
Optional:  Application Component/Collaboration
 Application Process/Function/Interaction
 Data Object
39

 No explicit relationships between Logical  Location aggregates all core entities (application
Application Components in metamodel function)
 Application Collaboration specializes Application
Component
 Application Collaboration aggregates Application
Component
 Application Component composes Application
Interface
 Application Interface serves Application

Component
 Application Interface is assigned to Application
Service
 Application Component is assigned to Application
Function
 Application Collaboration is assigned to
Application Interaction
 Application Service serves Application
Function/Application Interaction
 Application Function/Application Interaction
realizes Application Service
 Application Function/Interaction triggers/flows to
Application Function/Interaction
 Application Service/Function/Interaction access
Data Entity
App App
B C
IQ e e IQ
e IQ e BOB e IQ
App App App

A D E
Figure 49: Sample TOGAF Application Communication Diagram
Figure 50: Sample ArchiMate Application Cooperation View – Logical Level40
Figure 51: Sample ArchiMate Application Cooperation View – Physical Level
Table 30: TOGAF Application and User Location Diagram – ArchiMate Viewpoint Mapping
Application and User Location Diagram No viewpoint mapping available from different
Name
sources.
40
Three variants with different detailing levels.

The Application and User Location diagram shows the The Work Group recommends a specific diagram
geographical distribution of applications. based on the ArchiMate viewpoint mechanism.
It can be used to show where applications are used by
the end user; the distribution of where the host
application is executed and/or delivered in thin client
Description
scenarios; the distribution of where applications are

developed, tested, and released; etc.
Analysis can reveal opportunities for rationalization,
as well as duplication and/or gaps.
The purpose of this diagram is to clearly depict the
business locations from which business users interact
with the applications, but also the hosting location of
the application infrastructure.
 Location  Location
Metamodel

Entities
Business Role
 Physical Application Component  Application Function
 Location aggregates Physical Application  Location aggregates Application Function

Relationships
Metamodel
Component  Location aggregates Application Component

 Application Function/Component serves Business
Role
Location 1 Location 3 Location 4
Application 1 Application 3 Application 4 Application 1
Application 5
Location 2
Application 2
Figure 52: Sample TOGAF Application and User Location Diagram
Figure 53: Sample ArchiMate View – Logical Level
Figure 54: Sample ArchiMate View – Physical Level
Table 31: TOGAF Application Use-Case Diagram – ArchiMate Viewpoint Mapping
Application Use-Case Diagram No viewpoint mapping available from different

Name
sources.

An Application Use-Case diagram displays the The Work Group recommends a specific diagram
relationships between consumers and providers of based on the ArchiMate viewpoint mechanism.
application services.
Application services are consumed by actors or other
application services and the Application Use-Case
Description
diagram provides added richness in describing

application functionality by illustrating how and when
that functionality is used.
The purpose of the Application Use-Case diagram is to
help to describe and validate the interaction between
actors and their roles with applications. As the
architecture progresses, the use-case can evolve from
functional information to include technical realization
detail.
 Actor  Business Role

Metamodel
 Information System Service  Application Service

Entities
 Logical Application Component  Application Function
 Actor consumes/provides Information System  Application Service serves Business Role

Relationships
Metamodel
Service  Application Function realizes Application Service
Update
Register
Customer
Customer
Details
(from System Customer Administrator (from System
Use-Case) Use-Case)
Create (from Actors)
Order
Register De-Register
(from System
Sales Clerk Use-Case) Product Product
(from Actors)
Stock Control (from System (from System
Product Administration
System Use-Case) (from Actors) Use-Case)
Ship (from Actors)
Products
Update
(from System Product
Fulfillment Clerk
Use-Case) Details
(from Actors)
Update (from System

Invoice <<include>>
Statement of Use-Case)
Customer
Accounts
(from System
Use-Case) <<include>>
Process
Payment
(from System
Account Clerk Use-Case) Bank System
(from Actors) (from Actors)
<<extend>>
Instalment
Payment
(from System
Use-Case)
Figure 55: Sample TOGAF Application Use-Case Diagram
Figure 56: Sample ArchiMate View

Table 32: TOGAF Enterprise Manageability Diagram – ArchiMate Viewpoint Mapping
Enterprise Manageability Diagram No viewpoint mapping available from different

Name
sources.
The Enterprise Manageability diagram shows how one The Work Group recommends a specific diagram
or more applications interact with application and based on the ArchiMate viewpoint mechanism.
technology components that support operational We recommend moving this viewpoint to Phase E – as
Description
management of a solution. it is related to “physical” application and technology

This diagram is really a filter on the Application components and their relationships.
Communication diagram, specifically for enterprise
management class software.
Analysis can reveal duplication and gaps, and
opportunities in the IT service management operation
of an organization.

Metamodel
 Physical Technology Component  Technology Service

Entities
 Physical Technology Component serves Physical  Application Function composes Application

Relationships
Metamodel
Application Component Function

 Technology Service serves Application Function
Table 33: TOGAF Process/Application Realization Diagram – ArchiMate Viewpoint Mapping
Process/Application Realization Diagram Application Usage Viewpoint41

Name
The purpose of the Process/Application Realization The application usage viewpoint42 describes how
diagram is to clearly depict the sequence of events applications are used to support one or more business
when multiple applications are involved in executing a processes, and how they are used by other
business process. applications. It can be used in designing an application
It enhances the Application Communication diagram by identifying the services needed by business
Description
by augmenting it with any sequencing constraints, and processes and other applications, or in designing
hand-off points between batch and real-time business processes by describing the services that are
processing. available. Furthermore, since it identifies the
dependencies of business processes upon applications,
It would identify complex sequences that could be it may be useful to operational managers responsible
simplified and identify possible rationalization points for these processes.
in the architecture in order to provide more timely
information to business users. It may also identify
process efficiency improvements that may reduce
interaction traffic between applications.

 Business Service  Business Role
 Physical Application Component  Business Collaboration
 Logical Application Component  Business Process/Function

Metamodel Entities
Business Interaction
 Business Event
 Business Object
 Application Collaboration
 Application Process/Function
 Application Interaction
 Data Entity
41
42

 Process orchestrates Business Service  Business Actor is assigned to Business Role

 Logical Application Process realizes Business  Business Role is assigned to Business
Service Process/Function/Interaction
 Physical Application Component realizes Logical  Business Event/Process/Function/Interaction
Application Component triggers Business Event/Process/Function/
Interaction
 Business Process/Function/Interaction access
Business Object
 Application Interface serves Business Role
 Application Interface serves Business Process/
Function/Interaction
 Application Service serves Business
Process/Function/Interaction
 Data Object realizes Business Object
Component
Component
Interface
 Application Function serves Business Process
Component
 Application Interface serves Business Process
 Application Interface is assigned to Application
Service
 Application Component is assigned to Business
Process/Function/Interaction
 Application Component realizes Application
Service
 Application Component (via Application
Process/Function/Interaction) access Data Object
 Application Service access Data Entity
Figure 58: Sample ArchiMate Application Usage View – Logical Layer
Figure 59: Sample ArchiMate Application Usage View – Physical Layer
Table 34: TOGAF Software Engineering Diagram – ArchiMate Viewpoint Mapping
Software Engineering Diagram Application Structure Viewpoint43

Name
The Software Engineering diagram breaks applications The application structure viewpoint shows the
into packages, modules, services, and operations from structure of one or more applications or components.
a development perspective. This viewpoint is useful in designing or understanding
Description
It enables more detailed impact analysis when the main structure of applications or components and
planning migration stages, and analyzing opportunities the associated data; e.g., to break down the structure of
and solutions. the system under construction, or to identify legacy
application components that are suitable for
It is ideal for application development teams and migration/integration.
44
application management teams when managing
complex development environments.
 Physical Application Component  Application Component

Metamodel Entities
 Data Object
Optional:
 Application Collaboration
43
44

 No relationships defined in the metamodel  Application Component composes Application

between Physical Application Components Interface
Component
 Application Component accesses Data Object
 Application Function realizes Application Service
 Application Function composes Application
Function
Optional:
Component
Component
Figure 60: Sample ArchiMate Application Structure View – Logical Layer
Figure 61: Sample ArchiMate Application Structure View – Physical Layer
Table 35: TOGAF Application Migration Diagram – ArchiMate Viewpoint Mapping
Application Migration Diagram No viewpoint mapping available from different

Name
sources.
The Application Migration diagram identifies The Work Group recommends a specific diagram
application migration from baseline to target based on the ArchiMate viewpoint mechanism.
application components. It enables a more accurate
Description
estimation of migration costs by showing precisely

which applications and interfaces need to be mapped
between migration stages.
It would identify temporary applications, staging areas,
and the infrastructure required to support migrations
(for example, parallel run environments, etc.).
 Physical Application Components  Application Component

Metamodel

Entities
Application Function
 Data Object
 Plateau
 Physical Application Component realizes Logical  Application Component is assigned to Application
Relationships

Metamodel
 No relationship defined in metamodel between  Application Function realizes Application Service

Physical Application Components  Application Service serves Application Service
 Application Function access Data Object
 Plateau aggregates any core entity (Application
Service, Application Function, Data Object)

Table 36: TOGAF Software Distribution Diagram – ArchiMate Viewpoint Mapping
Software Distribution Diagram Application Structure Viewpoint45

Name
The Software Distribution diagram shows how The application structure viewpoint shows the
application software is structured and distributed structure of one or more applications or components.
across the estate. It is useful in systems upgrade or This viewpoint is useful in designing or understanding
application consolidation projects. the main structure of applications or components and
Description
This diagram shows how physical applications are the associated data; e.g., to break down the structure of
distributed across physical technology and the location the system under construction, or to identify legacy
of that technology. application components that are suitable for
migration/integration.46
This enables a clear view of how the software is
hosted, but also enables managed operations staff to We recommend moving the Software Distribution
understand how that application software is maintained diagram to Phase E.
once installed.

Metamodel
 Physical Technology Component 

Entities
Node
 Device
 System Software
 Location
 Physical Technology Component serves Physical  Application Function composes other Application
Relationships
Metamodel

 Node serves Application Function
 Node composes Device/System Software
 Location composes any core element (Node)
45
46
Figure 63: Sample ArchiMate Application Structure View
A.5 Phase D Graphical Artifacts

Table 37: TOGAF Environments and Locations Diagram– ArchiMate Viewpoint Mapping
Environments and Locations Diagram Infrastructure Viewpoint47

Name
48
The Environments and Locations diagram depicts The infrastructure viewpoint contains the software
which locations host which applications, identifies and hardware infrastructure elements supporting the
what technologies and/or applications are used at Application Layer, such as physical devices, networks,
Description
which locations, and finally identifies the locations or system software (e.g., operating systems, databases,
from which business users typically interact with the and middleware).
applications.
This diagram should also show the existence and
location of different deployment environments,
including non-production environments, such as
development and preproduction.
47
48

 Physical Technology Component  Node
Metamodel Entities
 Logical Technology Component  Communication Path

 Physical Application Component  Communication Network
 Logical Application Component  Device/System Software
 Technology Function
 Technology Interface
 Technology Service
 Artifact
 Location contains Physical Application  Location aggregates any core metamodel entity
Component/Physical Technology Component (Node/Communication Network/Device/
 Physical Application Component realizes Logical Technology Function/Application Function)
Application Component  Communication Network realizes Communication
 Physical Technology Component realizes Logical Path
Technology Component  Device/System Software specializes Node
 Logical Technology Component serves Logical  Device is assigned to System Software
Application Component  Node composes Technology Interface
 Physical Technology Component serves Physical  Technology Interface serves Node

Application Component  Technology Interface is assigned to Technology
Service
 Node is assigned to Technology Function
 Technology Function realizes Technology Service
 Technology Service serves Technology Function
 Technology Function triggers/flows to
Technology Function
 Technology Service/Technology Function
accesses Artifact
 Artifact realizes System Software
 Technology Function (realizes Technology
Service) serves Application Function
 Technology Function is associated to
communication Path
 Device is associated to communication Path
Location 1
Linux
Location 2
Windows 10
Windows 7
Location 3
UNIX
Location 4
Figure 64: Sample TOGAF Environments and Locations Diagram
Figure 65: Sample ArchiMate Infrastructure View (Logical)

Figure 66: Sample ArchiMate Infrastructure View (Physical)
Table 38: TOGAF Platform Decomposition Diagram – ArchiMate Viewpoint Mapping
Platform Decomposition Diagram Technology Usage Viewpoint (named “Infrastructure

Usage Viewpoint” in Glossaries Comparison49)
Name
49
The Platform Decomposition diagram depicts the The technology usage viewpoint shows how
technology platform that supports the operations of the applications are supported by the software and
Information Systems Architecture. The diagram covers hardware technology: the technology services are
all aspects of the infrastructure platform and provides delivered by the devices; system software and
an overview of the enterprise’s technology platform. networks are provided to the applications. This
The diagram can be expanded to map the technology viewpoint plays an important role in the analysis of
platform to appropriate application components within performance and scalability, since it relates the
a specific functional or process area. This diagram physical infrastructure to the logical world of
may show details of specification, such as product applications. It is very useful in determining the
versions, number of CPUs, etc. or simply could be an performance and quality requirements on the
informal "eye-chart" providing an overview of the infrastructure based on the demands of the various
technical environment. applications that use it.
The diagram should clearly show the enterprise
applications and the technology platform for each
Description
application area can further be decomposed as follows:

 Hardware:
— Logical Technology Components (with
attributes)
— Physical Technology Components (with
attributes)
 Software:
— Logical Technology Components (with
attributes)
— Physical Technology Components (with
attributes)
Depending upon the scope of the Enterprise
Architecture work, additional technology cross-
platform information (e.g., communications, telco, and
video information) may be addressed.
 Logical Technology Component  Node

Metamodel Entities
Device/System Software
 Communication Path
 Communication Network

 Physical Technology Component realizes Logical  Device/System Software specializes Node

Technology Component  Device is assigned to System Software
 Node composes Technology Interface
 Technology Interface is assigned to Technology

Service
 Technology Function (realizes Technology
Service) serves Application Function
 Technology Function serves Application
Component
 Technology Interface serves Application
Component
Platform Decomposition (Application Support)
Hardware Software
Logical Technology Physical Technology Logical Technology Physical Technology

Components Components Components Components
Tech Function Tech Function Tech Function Tech Function
Web Server Layer Web Server Layer Web Server Layer Web Server Layer
Application Layer Application Layer Application Layer Application Layer
Database Layer Database Layer Database Layer Database Layer
Attributes: Attributes:
• Name • Product Name
• Model/Type • Vendor
• Clusters • OS
• Number of Components • Software Components
• Vendor • License Type
• Server Type (Mainframe, Mid-range, RISC, Intel) • License Expiry, etc.
• Server Logical Name
• IP Address, etc.
Figure 67: Sample TOGAF Platform Decomposition Diagram
Figure 68: Sample ArchiMate Infrastructure Usage View – Logical Level
Figure 69: Sample ArchiMate Infrastructure Usage View – Physical Level
Table 39: TOGAF Processing Diagram – ArchiMate Viewpoint Mapping
Processing Diagram Infrastructure Viewpoint50

Name
50

51
The Processing diagram focuses on deployable units of The infrastructure viewpoint contains the software
code/configuration and how these are deployed onto and hardware infrastructure elements supporting the
the technology platform. A deployment unit represents Application Layer, such as physical devices, networks,
grouping of business function, service, or application or system software (e.g., operating systems, databases,
components. The Processing diagram addresses the and middleware).
following:
 Which set of application components need to be
Description
grouped to form a deployment unit

 How one deployment unit connects/interacts with
another (LAN, WAN, and the applicable
protocols)
 How application configuration and usage patterns
generate load or capacity requirements for
different technology components
The organization and grouping of deployment units
depends on separation concerns of the presentation,
business logic, and data store layers and service-level
requirements of the components.
 All metamodel entities are allowed  Location

 Node
Metamodel Entities
 Device/System Software
 Artifact
51
 All metamodel relationships are allowed  Location aggregates any core metamodel entity
(Node/Communication Network/Device/
Technology Function/Application Function)
 Communication Network realizes Communication
Path
 Device/System Software specializes Node
 Device is assigned to System Software
 Technology Interface serves Node

 Technology Interface is assigned to Technology
Service
 Technology Service serves Technology Function
 Technology Function triggers/flows to
Technology Function
 Technology Service/Technology Function
accesses Artifact
 Artifact realizes System Software
 Technology Function serves Application Function
 Technology Function is associated to
communication Path
 Device is associated to communication Path
Technology Platform Deployment Unit (Application Components) Protocols Network Required Bandwidth
Figure 70: Sample TOGAF Processing Diagram

Figure 71: Sample ArchiMate Infrastructure View
Table 40: TOGAF Network and Communications Diagram – ArchiMate Viewpoint Mapping
Network and Communications Diagram No viewpoint mapping available from different

Name
sources.
The Network and Communications diagram describes

the means of communication – the method of sending
and receiving information – between these assets in the
Technology Architecture; insofar as the selection of
package solutions in the preceding architectures put
Description
specific requirements on the communications between

the applications.
The Network and Communications diagram will take
logical connections between client and server
components and identify network boundaries and
network infrastructure required to physically
implement those connections. It does not describe the
information format or content, but will address
protocol and capacity issues.

Metamodel Entities
Node
 Device
 System software
 No explicit relationships defined between  Device/System Software specializes Node
Physical Technology Components in metamodel  Device is assigned to System Software

 Node composes Device/System Software
 Device/System Software realizes Application
Component
 Device is associated to Communication Path
 Technology Function realizes (Technology
Service serving) Application Function
 Path being associated with (Node being assigned
to) Technology Function

Figure 73: Sample ArchiMate View (Target/Logical)
A.6 Phase E Graphical Artifacts

Table 41: TOGAF Project Context Diagram – ArchiMate Viewpoint Mapping
Project Context Diagram Implementation and Migration Viewpoint 52

Name
52

A Project Context diagram shows the scope of a work The implementation and migration viewpoint is used
package to be implemented as a part of a broader to relate programs and projects to the parts of the
transformation roadmap. The Project Context diagram architecture that they implement. This view allows
links a work package to the organizations, functions, modeling of the scope of programs, projects, and
services, processes, applications, data, and technology project activities in terms of the plateaus that are
that will be added, removed, or impacted by the realized or the individual architecture elements that are
project. affected. In addition, the way the elements are affected
The Project Context diagram is also a valuable tool for may be indicated by annotating the relationships.
project portfolio management and project Furthermore, this viewpoint can be used in
mobilization. combination with the programs and projects viewpoint
to support portfolio management:
Description
 The programs and projects viewpoint is suited to

relate business goals to programs and projects; for
example, this makes it possible to analyze at a
high level whether all business goals are covered
sufficiently by the current portfolio(s)
 The implementation and migration viewpoint is
suited to relate business goals (and requirements)
via programs and projects to (parts of) the
architecture; for example, this makes it possible to
analyze potential overlap between project
activities or to analyze the consistency between
project dependencies and dependencies among
plateaus or architecture elements
 etc.
 Work Package  Work Package
Metamodel Entities
 All domain-specific metamodel entities are  Goal

allowed  Outcome
 Implementation Event
 Deliverable
 Business Actor
 Business Role
 All core metamodel entities are allowed
 All metamodel relationships between domain-  Work Package composes other Work Package
Relationships
Metamodel
specific entities are allowed  Work Package realizes core element

 All core metamodel relationships are allowed
RFQ Order
Customer
External Offering External Ordering

Process Process
Regional
DES Affiliate
RFQ Office Order
Internal Offering Internal Ordering

Process Process
RFQ Order
R&D Engineering Logistics Admin
Figure 74: Sample TOGAF Project Context Diagram
Figure 75: Sample ArchiMate Implementation and Migration View 53
53

Figure 76: Sample ArchiMate Project View
Table 42: TOGAF Benefits Diagram – ArchiMate Viewpoint Mapping
Benefits Diagram No viewpoint mapping available from different

Name
sources.
The Benefits diagram shows opportunities identified in The Work Group proposes a sub-view of goal
Description
an architecture definition, classified according to their realization viewpoint.

relative size, benefit, and complexity. This diagram
can be used by stakeholders to make selection,
prioritization, and sequencing decisions on identified
opportunities.
 All metamodel entities  Goal

Metamodel
 Outcome
Entities
 All metamodel relationships  Outcome realizes a Goal

Relationships
Metamodel
Figure 77: Sample TOGAF Benefits Diagram

Figure 78: Sample ArchiMate View54
54
B ArchiMate Constructs to Model TOGAF Matrices
While it would be possible to map TOGAF matrices to ArchiMate viewpoints, we decided that
for this activity we focus on the mapping of the TOGAF graphical artifacts to ArchiMate
viewpoints. In most cases a TOGAF matrix can be represented by a simple report out of some
repository.
To ensure completeness of coverage of our ArchiMate metamodel, we list in this chapter all
matrices with the TOGAF description and used metamodel entities and relationships and map
them to ArchiMate viewpoints.
In some cases we explicitly show an ArchiMate viewpoint to map to a specific TOGAF matrix.
B.1 Phase B Matrices

Table 43: TOGAF Standard – Architecture Content: Business Interaction Matrix – ArchiMate
Viewpoint Mapping
Business Interaction Matrix

Name
Description
The purpose of this matrix is to depict the relationship interactions between organizations and business functions
across the enterprise. Understanding business interaction of an enterprise is important as it helps to highlight
value chain and dependencies across organizations.

Metamodel
 Business Function 
Entities
Business Function
 Business Role (“Role”) as Consumer/Provider of
the Business Service
 Business Service communicates with Business  Business Actor being assigned to Business Role
Relationships
Metamodel
Service relationships being assigned to Business Function realizing

 Business Service is dependent on Business Business Service
Service relationships  Business Actor being assigned to Business Role
being assigned to Business Function being served
by Business Service

Consuming Business Services Engineering Procurement Manufacturing Sales & Distribution Customer Service
Engineering
Procurement
Contract for supply of Contract for supply of
Manufacturing
materials sales forecasts
Contract for supply of Contract for
Sales & Distribution
product specification supply of products
Contract for fulfillment of
Customer Service
customer orders
Figure 79: Sample TOGAF Business Interaction Matrix55
Table 44: TOGAF Standard – Architecture Content: Actor/Role Matrix – ArchiMate Viewpoint
Mapping
Actor/Role Matrix
Name
Description
The purpose of this matrix is to show which actors perform which roles, supporting definition of security and
skills requirements.
Understanding Actor-to-Role relationships is a key supporting tool in definition of training needs, user security
settings, and organizational change management.
 Actor  Business Actor

Metamodel

Entities
 Actor performs Role relationships  Business Actor is assigned to Business Role

Relationships
Metamodel
Business Unit Third-Party Implementation

Actors Actors Actors
Technical
Business Architecture Procurement Solution Design Service Service
Activity Project Team Team Commercial Provider Authority Introduction Management
Publish Functional Requirements AR C
Publish Non-Functional Requirements AR C C C I
Publish Logical Architecture A C R I
Provide Reference Architecture & Guidelines AR
Issue RFP or Specification (as appropriate) R C A I C
Complete QG2 Checklist C C I C AR I
Figure 80: Sample TOGAF Business Interaction Matrix
55
TOGAF® Series Guide: Value Streams; see Referenced Documents.
Table 45: TOGAF Standard – Architecture Content: Value Stream/Capability Matrix – ArchiMate
Viewpoint Mapping
Value Stream/Capability Matrix

Name
Description
The purpose of this matrix is to show the capabilities required to support each stage of a value stream.
More details can be found in the TOGAF® Series Guide: Value Streams; see Referenced Documents.

Metamodel
 Business Capability
Entities
(used as mapping for Value Stream and Value

Stream Stage)
 Capability
 Business Capability enables a Value Stream Stage  Capability serves Value Stream
Relationships
Metamodel
(see TOGAF® Series Guide: Value Streams; see

Referenced Documents)
There is no sample available from the TOGAF template library, but a graphical sample is
available from the TOGAF® Series Guide: Value Streams; see Figure 81.
Communicate Assess Interview Onboard

Define Position
Position Responses Candidates Employee
Program Mgmt. HR Mgmt. HR Mgmt. HR Mgmt. HR Mgmt.

Program/Human Employee Supply Employee Supply Benefits Mgmt. Onboard Tracking
Resource Matching and Demand Mgmt. and Demand Mgmt.
Terms Mgmt.
HR Mgmt. Position Advertising Skills Assessment Compensation Asset Mgmt.
Mgmt.
Competency Mgmt. Asset Allocation
Finance Mgmt. Agreement Mgmt.

Policy Mgmt. Labor Funding Agreement Facilities Mgmt.
Structuring
Policy Dissemination Space Allocation
Security Mgmt.
Employee
Background and ID
Information Mgmt.
Employee
Informaton Mgmt
Figure 81: Sample TOGAF Value Stream Map (including Business Capabilities)

Table 46: TOGAF Standard – Architecture Content: Strategy/Capability Matrix – ArchiMate
Viewpoint Mapping
Strategy/Capability Matrix
Name
Description
The purpose of this matrix is to show the capabilities required to support specific strategy statements.
 Course of Action  Course of Action

Metamodel

Entities
 Course of Action influences Business Capability  Capability realizes Course of Action

Relationships
Metamodel
There is no sample available from the TOGAF template library, nor from the TOGAF® Series
Guide: Business Capabilities (see Referenced Documents).
Table 47: TOGAF Standard – Architecture Content: Capability/Organization Matrix – ArchiMate
Viewpoint Mapping
Capability/Organization Matrix
Name
Description
The purpose of this matrix is to show the organization elements that implement each capability.
More details can be found in the TOGAF® Series Guide: Organization Mapping; see Referenced Documents.

Metamodel

Entities
 (Resource)
Relationships  Organization Units have one or more Business  Business Actor realizing (resource being assigned
Metamodel
Capabilities to) Capability
There is no sample available from the TOGAF template library, nor from the TOGAF® Series
Guide: Business Capabilities.
B.2 Phase C: Data Architecture Matrices

Table 48: TOGAF Standard – Architecture Content Data Entity/Business Function Matrix –
ArchiMate Viewpoint Mapping
Data Entity/Business Function Matrix

Name
The purpose of the Data Entity/Business Function matrix is to depict the relationship between data entities and
business functions within the enterprise. Business functions are supported by business services with explicitly
defined boundaries and will be supported and realized by business processes. The mapping of the Data Entity-
Description
Business Function relationship enables the following to take place:

 Assign ownership of data entities to organizations
 Understand the data and information exchange requirements business services
 Support the gap analysis and determine whether any data entities are missing and need to be created
 Define application of origin, application of record, and application of reference for data entities
Enable development of data governance programs across the enterprise (establish data steward, develop data
standards pertinent to the business function, etc.)

Metamodel

Entities
 Function is bound by Business Service  Business Function accesses Business Object

Relationships
Metamodel
 Business Service provides/consumes Data Entity

Physical Data Components Map to Business Functions
Business Function 1 Organization's Unit

Physical Data Entity 1
Figure 82: Sample TOGAF Data Entity/Business Function Matrix
Table 49: TOGAF Standard – Architecture Content Application/Data Matrix – ArchiMate

Viewpoint Mapping
Application/Data Matrix
Name
The purpose of the Application/Data matrix is to depict the relationship between applications (i.e., application
components) and the data entities that are accessed and updated by them. Applications will create, read, update,
Description
and delete specific data entities that are associated with them. For example, a CRM application will create, read,
update, and delete customer entity information.
The data entities in a package/packaged services environment can be classified as master data, reference data,
transactional data, content data, and historical data. Applications that operate on the data entities include
transactional applications, information management applications, and business warehouse applications.

Metamodel
 Data Entity  Data Object

Entities
 (Application Component)
 Logical Data Component uses (Logical Data  Application Function accesses Data Object
Relationships
Metamodel
Component encapsulates)  (Application Component being assigned to

 Data Entity Application Function)
Physical Application Components Map to Data Entities
Physical App Component 1 Physical App Component 2 Physical App Component 3 Physical App Component 4 Physical App Component 5 Physical App Component 6
Figure 83: Sample TOGAF Physical Application/Organization Matrix
B.3 Phase C: Application Architecture Matrices
Table 50: TOGAF Standard – Architecture Content: Application/Organization Matrix – ArchiMate
Viewpoint Mapping
Application/Organization Matrix
Name
The purpose of this matrix is to depict the relationship between applications and organizational units within the
enterprise. Business functions are performed by organizational units. Some of the functions and services
performed by those organizational units will be supported by applications. The mapping of the Application
Description
Component-Organization Unit relationship is an important step as it enables the following to take place:
 Assign usage of applications to the organization units that perform business functions
 Understand the application support requirements of the business services and processes carried out by an
organization unit
 Support the gap analysis and determine whether any of the applications are missing and as a result need to
be created
 Define the application set used by a particular organization unit
 
Metamodel Entities
Organization Unit Business Actor

 (Actor)  (Application Interface)
 (Business Service)  Application Component
 Physical Application Component  Business Role
 Logical Application Component  Business Process/Function
 Organization Units owns Business Service  Application Interface serves Business Actor
 Actor belongs to Organization Units  Application Component composes Application
Relationships
Metamodel
 Actor uses Business Service Interface

 Business Service is realized by Logical/Physical  Business Actor is assigned to Role is assigned to
Application Components Business Process
 Logical Application Component is realized by  Business Process is served by Application Service
Physical Application Component  Application Service is realized by Application
Function
Logical Application Components Map to Organization's Units
Organization's Unit 1 Organization's Unit 2 Organization's Unit 3 Organization's Unit 4 Organization's Unit 5 Organization's Unit 6
Logical App Component 1
Figure 84: Sample TOGAF Logical Application/Organization Matrix

Physical Application Components Map to Organization's Units
Organization's Unit 1 Organization's Unit 2 Organization's Unit 3 Organization's Unit 4 Organization's Unit 5 Organization's Unit 6
Physical App Component 1
Figure 85: Sample TOGAF Physical Application/Organization Matrix
Table 51: TOGAF Standard – Architecture Content: Role/Application Matrix – ArchiMate

Viewpoint Mapping
Role/Application Matrix
Name
The purpose of the Role/Application matrix is to depict the relationship between applications and the business
roles that use them within the enterprise. People in an organization interact with applications. During this
interaction, these people assume a specific role to perform a task; for example, product buyer. The mapping of
the Application Component-Role relationship is an important step as it enables the following to take place:
 Assign usage of applications to the specific roles in the organization
 Understand the application security requirements of the business services and processes supporting the
function, and check these are in line with current policy
Description
be created
 Define the application set used by a particular business role; essential in any move to role-based computing
The Role/Application matrix is a two-dimensional table with Logical Application Component on one axis and
Role on the other axis.
The relationship between these two entities is a composite of a number of metamodel relationships that need
validating:
 Role accesses Function
 Function is bounded by Service
 Services are realized by Logical/Physical Application

Metamodel
 (Logical) Application Component  Application Function

Entities
 Role uses (performs Process orchestrates  Business Role is assigned to (Business Process is
Relationships
Metamodel
Business Service is realized through) (Logical) served by Application Service is realized by)
Application Component Application Function
Logical Application Components Interaction Map to Roles
Role 1 Role 2 Role 3 Role 4 Role 5 Role 6

Figure 86: Sample TOGAF Role/Logical Application Matrix
Physical Application Components Map to Roles
Role 1 Role 2 Role 3 Role 4 Role 5 Role 6

Figure 87: Sample TOGAF Role/Physical Application Matrix
Table 52: TOGAF Standard – Architecture Content: Application/Function Matrix – ArchiMate

Viewpoint Mapping
Application/Function Matrix
Name
The purpose of the Application/Function matrix is to depict the relationship between applications and business
functions within the enterprise. Business functions are performed by organizational units. Some of the business
functions and services will be supported by applications. The mapping of the Application Component-Function
relationship is an important step as it enables the following to take place:
 Assign usage of applications to the business functions that are supported by them
 Understand the application support requirements of the business services and processes carried out
Description
be created
 Define the application set used by a particular business function
The Application/Function matrix is a two-dimensional table with Logical Application Component on one axis
and Function on the other axis.
The relationship between these two entities is a composite of a number of metamodel relationships that need
validating:
 Function is bounded by service
 Services are realized by Logical/Physical Application Components

Metamodel

Entities

Relationships  Function is bounded by Service  Business Function is served by (Application Service
Metamodel
 Services are realized by Logical/Physical is realized by) Application Function

Application Components
Logical Application Components Interaction Map to Business Functions
Business Function 1 Business Function 2 Business Function 3 Business Function 4 Business Function 5 Business Function 6
Figure 88: Sample TOGAF Logical Application/Function Matrix
Physical Application Components Map to Business Functions
Business Function 1 Business Function 2 Business Function 3 Business Function 4 Business Function 5 Business Function 6
Figure 89: Sample TOGAF Physical Application/Function Matrix
Table 53: TOGAF Standard – Architecture Content: Application Interaction Matrix – ArchiMate
Viewpoint Mapping
Application Interaction Matrix

Name
The purpose of the Application Interaction matrix is to depict communications relationships between
applications.
The mapping of the application interactions shows in matrix form the equivalent of the Interface catalog or an
Description
Application Communication diagram.

The Application Interaction matrix is a two-dimensional table with Application Service, Logical Application
Component, and Physical Application Component on both the rows and the columns of the table.
The relationships depicted by this matrix include:
 Application Service consumes Application Service
 Logical Application Component communicates with logical Application Component
 Physical Application Component communicates with Physical Application Component
 Information System Service  Application Service

Metamodel

Entities
 Physical Application Component  Application Component
 “Communication” between Information System  Flow between Application Service/Function

Relationships
Metamodel
Service/Logical Application Component/Physical

Logical Application Components Interaction Map
Logical App Component 1 Logical App Component 2 Logical App Component 3 Logical App Component 4 Logical App Component 5 Logical App Component 6
consumes
communicates with communicates with
consumes
Figure 90: Sample TOGAF Logical Application Interaction Matrix
Physical Application Components Map
consumes
consumes
Figure 91: Sample TOGAF Physical Application Interaction Matrix
B.4 Phase D Matrices

Table 54: TOGAF Standard – Architecture Content: Application/Technology Matrix – ArchiMate
Viewpoint Mapping
Application/Technology Matrix
Name
Description
The Application/Technology matrix documents the mapping of applications to technology platform.

This matrix should be aligned with and complement one or more platform decomposition diagrams.

 
Metamodel Entities
Logical Application Components Application Function

 Physical Application Components  Application Component
 Technology Services  Technology Service
 Logical Technology Components  Technology Function
 Physical Technology Components  Node
 Device
 System Software
 Physical Technology Component realizes  Node (Device, System Software) (composes
Relationships
Metamodel
Physical Application Component Technology Interface which) serves Application

Component
Logical Application Components / Logical Technology Components Map
Logical Tech Component 1
consumes
consumes
Figure 92: Sample TOGAF Logical Application/Technology Matrix
Physical Application Components / Physical Technology Components Map
Physical Tech Component 1
consumes
consumes
Figure 93: Sample TOGAF Physical Application/Technology Matrix
C ArchiMate Constructs to Model TOGAF Catalogs
While it would be possible to map the TOGAF catalogs to ArchiMate viewpoints, we decided to
focus on the mapping of the TOGAF graphical artifacts to ArchiMate viewpoints.
In all cases, a TOGAF catalog can be represented by a simple report out of some repository.
To ensure the completeness of coverage for the ArchiMate metamodel, we list in this chapter all
catalogs with the TOGAF description and used metamodel entities and relationships and map
them to the ArchiMate Specification.
C.1 Preliminary Phase Catalogs

Table 55: TOGAF Standard – Architecture Content: Principles Catalog – ArchiMate Viewpoint
Mapping
Principles Catalog
Name
Description
The Principles catalog captures principles of the business and Architecture Principles that describe what a “good”
solution or architecture should look like. Principles are used to evaluate and agree an outcome for architecture
decision points. Principles are also used as a tool to assist in architectural governance of change initiatives.
 Principle  Principle
Metamodel

Entities
Driver
 Goal
 Outcome
 Driver is a row in the Principles catalog, but there  Goal is associated with Driver
relationships
Metamodel
is no relationship between Principle and  Goal realizes a Driver

Driver/Goal in the metamodel  Outcome realizes a Goal
 Principle realizes an Outcome

Architecture Principles
Architecture Design Created/
ID Name Description Date Category Priority Source Motivation/Driver Implication Amended Owner
PRN_ARC_01
PRN_ARC_02
PRN_ARC_03
PRN_ARC_04
PRN_ARC_05
Figure 94: Sample TOGAF Principles Catalog
C.2 Phase A Catalogs

Table 56: TOGAF Standard – Architecture Content: Stakeholder Catalog – ArchiMate Viewpoint
Mapping
Stakeholder Catalog Stakeholder Viewpoint56

Name
The purpose of the Stakeholder catalog is to identify The stakeholder viewpoint allows the analyst to model
the stakeholders for the architecture engagement, their the stakeholders, the internal and external drivers for
influence over the engagement, and their key change, and the assessments (in terms of strengths,
questions, issues, or concerns that must be addressed weaknesses, opportunities, and threats) of these
by the architecture framework. drivers. Also, the links to the initial (high-level) goals
Description
Understanding stakeholders and their requirements that address these concerns and assessments may be
allows an architect to focus effort in areas that meet described. These goals form the basis for the
the needs of stakeholders. requirements engineering process, including goal
refinement, contribution and conflict analysis, and the
Due to the potentially sensitive nature of stakeholder derivation of requirements that realize the goals.
mapping information and the fact that the Architecture
Vision Phase is intended to be conducted using
informal modeling techniques, no specific metamodel
entities will be used to generate a Stakeholder catalog.
 All metamodel entities are allowed  Stakeholder

Metamodel
 Driver
Entities
 Goal
 All metamodel relationships are allowed  A Stakeholder is associated with a Driver, which
Relationships
Metamodel
is associated with a Goal
56
Stakeholder Map
Stakeholder Involvement Class Power Level of Interest Concerns Communication Plan Views Viewpoints/Relevant Artifacts
CxO This stakeholder group is interested in Keep High Medium IT Budgets, Business Footprint
the high-level drivers, goals, and Satisfied Demonstrable Goal/Objective/Service Model
objectives of the organization, and how Benefits Organization Chart
these are translated into an effective
process and IT architecture to advance
the business.
Program This stakeholder group is interested in Keep Medium High Usability Roadmaps
Management prioritizing, funding, and aligning change Satisfied Business Footprint
Office activity. An understanding of project Application
content and technical dependencies Communication
adds a further dimension of richness to Functional
portfolio management and decision- Decomposition
making.
HR Key features of the Enterprise Keep Low Medium Resourcing Organization Chart
Architecture are roles and actors that Informed Organization/Actor/Location
support the functions, applications, and
technology of the organization. HR are
important stakeholders in ensuring that
the correct roles and actors are
represented.
Figure 95: Sample TOGAF Stakeholder Catalog (Stakeholder Map)
Figure 96: Sample ArchiMate Stakeholder View

C.3 Phase B Catalogs
Table 57: TOGAF Standard – Architecture Content: Business Glossary Catalog– ArchiMate
Viewpoint Mapping
57
Business Glossary Catalog
Name
This catalog contains the name and unambiguous description of all elements contained in or interacting with the
Description
Enterprise Architecture.
Optional information could include element enterprise synonyms, abbreviations/acronyms, and relationships with
other elements. This catalog provides the semantics to be used by all analysts (e.g., business, information, and
system) for their architecture products, including information/data models, and evolves throughout the ADM.
 All entities  All entities

Metamodel
Entities
Relationships
Metamodel
Table 58: TOGAF Standard – Architecture Content: Business Capabilities Catalog – ArchiMate
Viewpoint Mapping
Business Capabilities Catalog

Name
Description
A definitive listing of particular abilities that a business may possess or exchange to achieve a specific purpose.
More details can be found in the TOGAF® Series Guide: Business Capabilities; see Referenced Documents.
57
New with the TOGAF Standard – Architecture Content (see Referenced Documents).

Metamodel
Entities
Relationships
Metamodel
Table 59: TOGAF Standard – Architecture Content: Value Stream Catalog – ArchiMate Viewpoint
Mapping
Value Stream Catalog

Name
Description
A definitive listing of end-to-end collections of value-adding activities that create an overall result for a
customer, stakeholder, or end user.

Metamodel
Entities
Relationships
Metamodel

Table 60: TOGAF Standard – Architecture Content: Value Stream Stage Catalog– ArchiMate
Viewpoint Mapping
Value Stream Stages Catalog

Name
Description
A definitive listing of end-to-end collections of the different stages for the value-adding activities that create an
overall result for a customer, stakeholder, or end user.
 Value Stream  Value Stream (used as mapping for Value Stream

Metamodel
 Value Stream Stage (no explicit metamodel

Entities
and Value Stream Stage)

entity)  Capability
 Business Capability
 Business Capability enables a Value Stream Stage  Capability serves Value Stream
Relationships
Metamodel
(information is from the TOGAF® Series Guide:

Value Streams)
A sample is available from the TOGAF® Series Guide: Value Streams; see Referenced
Documents.
Figure 97: Sample TOGAF Value Stream Stage Catalog
Table 61: TOGAF Standard – Architecture Content: Organization/Actor Catalog – ArchiMate
Viewpoint Mapping
Organization/Actor Catalog
Name
The purpose of the Organization/Actor catalog is to capture a definitive listing of all participants that interact
with IT, including users and owners of IT systems.
Description
The Organization/Actor catalog can be referenced when developing requirements in order to test for
completeness.
For example, requirements for an application that services customers can be tested for completeness by verifying
exactly which customer types need to be supported and whether there are any particular requirements or
restrictions for user types.
 Organization  Business Actor

Metamodel
 Actor
Entities
(used as mapping for Organization Unit and Actor)

 Location (may be included in this catalog if an  Location
independent Location catalog is not maintained)
 Organization Unit contains Actor  Business Actor aggregates other Business Actor
Relationships
Metamodel
 Organization Unit/Actor operates in Location  Location aggregates Business Actor
Actor (Core)
ID Name Description Category Source Owner #FTEs Actor Goal Actor Tasks
BA_ACT_01
BA_ACT_02
BA_ACT_03
BA_ACT_04
BA_ACT_05
Figure 98: Sample TOGAF Organization/Actor Catalog

Table 62: TOGAF Standard – Architecture Content: Role Catalog – ArchiMate Viewpoint Mapping
Role Catalog
Name
The purpose of the Role catalog is to provide a listing of all authorization levels or zones within an enterprise.
Frequently, application security or behavior is defined against locally understood concepts of authorization that
create complex and unexpected consequences when combined on the user desktop.
If roles are defined, understood, and aligned across organizations and applications, this allows for a more
Description
seamless user experience and generally more secure applications, as administrators do not need to resort to
workarounds in order to enable users to carry out their jobs.
In addition to supporting security definition for the enterprise, the Role catalog also forms a key input to
identifying organizational change management impacts, defining job functions, and executing end-user training.
As each role implies access to a number of business functions, if any of these business functions are impacted
then change management will be required, organizational responsibilities may need to be redefined, and
retraining may be needed.

Metamodel
Entities
Relationships
Metamodel
Role (Core)
ID Name Description Category Source Owner #FTEs

BA_ROL_01
BA_ROL_02
BA_ROL_03
BA_ROL_04
BA_ROL_05
Figure 99: Sample TOGAF Role Catalog
Table 63: TOGAF Standard – Architecture Content: Business Service/Business Function Catalog –
Business Service/Business Function Catalog (two separate catalogs)

Name
The purpose of the Business Service/Business Function catalog is to provide a functional decomposition in a
form that can be filtered, reported on, and queried, as a supplement to graphical Functional
Description
Decomposition diagrams.
The Business Service/Function catalog can be used to identify capabilities of an organization and to understand
the level that governance is applied to the functions of an organization. This functional decomposition can be
used to identify new capabilities required to support business change or may be used to determine the scope of
change initiatives, applications, or technology components.

Metamodel
 
Entities
Function Business Function

 Optional: Information System Service  Optional: Application Service
 Organization Unit owns Business Service  Business Actor is assigned to Business Function
Relationships
Metamodel
 Organization Unit owns Function which realizes a Business Service

 Business Actor is assigned to Business Function
 Optional: Application Service serves a Business
Function
Business Service (Core)

Standard Last Standard Next Standard
ID Name Description Category Source Owner Standards Class Creation Date Review Date Review Date Retire Date
BA_SVC_01
BA_SVC_02
BA_SVC_03
BA_SVC_04
BA_SVC_05
Figure 100: Sample TOGAF Business Service Catalog
Function (Core)
BA_FCT_01
BA_FCT_02
BA_FCT_03
BA_FCT_04
BA_FCT_05
Figure 101: Sample TOGAF Function Catalog

Table 64: TOGAF Standard – Architecture Content: Location Catalog – ArchiMate Viewpoint
Mapping
Location Catalog
Name
The Location catalog provides a listing of all locations where an enterprise carries out business operations or
houses architecturally relevant assets, such as data centers or end-user computing equipment. Maintaining a
definitive list of locations allows change initiatives to quickly define a location scope and to test for
Description
completeness when assessing current landscapes or proposed target solutions. For example, a project to upgrade
desktop operating systems will need to identify all locations where desktop operating systems are deployed.
Similarly, when new systems are being implemented a diagram of locations is essential in order to develop
appropriate deployment strategies that comprehend both user and application location and identify location-
related issues, such as internationalization, localization, time zone impacts on availability, distance impacts on
latency, network impacts on bandwidth, and access.
Metamodel
Entities
Relationships
Metamodel
Location (Infrastructure Consolidation Extension)
ID Name Description Category Source Owner

BA_LOC_01
BA_LOC_02
BA_LOC_03
BA_LOC_04
BA_LOC_05
Figure 102: Sample TOGAF Location Catalog
Table 65: TOGAF Standard – Architecture Content: Driver/Goal/Objective Catalog – ArchiMate
Viewpoint Mapping
Driver/Goal/Objective Catalog
Name
The purpose of the Driver/Goal/Objective catalog is to provide a cross-organizational reference of how an

Description
organization meets its drivers in practical terms through goals, objectives, and (optionally) measures.
Publishing a definitive breakdown of drivers, goals, and objectives allows change initiatives within the enterprise
to identify synergies across the organization (e.g., multiple organizations attempting to achieve similar
objectives), which in turn allow stakeholders to be identified and related change initiatives to be aligned or
consolidated.
 Driver  Driver
 Goal  Goal (no differentiation between Goal an Objective
Metamodel Entities
 Objective in the ArchiMate language)

 Organization Unit  Stakeholder
Optional:  Requirement
 Constraint
 Measure
Optional:
 Outcome
 Principle
 Goal addresses Driver  Goal is associated to Driver
 Objective realizes Goal  Goal aggregates other Goal(s)

Optional:  Requirement realizes Goal
 Constraint specializes Requirement
 Measure sets performance criteria for Objective
 Stakeholder is associated to Goal
Optional:
 Outcome realizes Goal
 Principle realizes Goal
 Requirement realizes Principle
Driver (Motivation Extension)

BA_DRV_01
BA_DRV_02
BA_DRV_03
BA_DRV_04
BA_DRV_05
Figure 103: Sample TOGAF Driver/Catalog

Goal (Motivation Extension)

BA_GOL_01
BA_GOL_02
BA_GOL_03
BA_GOL_04
BA_GOL_05
Figure 104: Sample TOGAF Goal Catalog
Objective (Motivation Extension)

BA_OBJ_01
BA_OBJ_02
BA_OBJ_03
BA_OBJ_04
BA_OBJ_05
Figure 105: Sample TOGAF Objective Catalog
Table 66: TOGAF Standard – Architecture Content: Contract/Measure Catalog – ArchiMate

Viewpoint Mapping
Contract/Measure Catalog
Name
Description
The Contract/Measure catalog provides a listing of all agreed service contracts and the measures attached to
those contracts. It forms the master list of service levels agreed to across the enterprise.

Metamodel
 Contract  Contract
Entities
 Measure  Metrics
Optional:
 Information System Service
 Contract governs/measures Business Service  Business Service accesses Contract
 Measure Sets performance criteria for Business  Metrics is associated to Business Services
Relationships
Metamodel
Service
 Service Quality applies to Business Service
Optional:
 Information System Service automates Business
Service
Contract (Governance Extension)
Service Serviceability
Behavior Service Name Name Service Quality Availability Manageability Characteristic
ID Name Description Category Source Owner Characteristics "Caller" "Called" Characteristics Characteristics Service Times Characteristics s
BA_CTR_01
BA_CTR_02
BA_CTR_03
BA_CTR_04
BA_CTR_05
Quality of Contract Locatability Localization

Performance Reliability Information Control Result Control Recoverability Characteristi Security Privacy Integrity Credibility Characteristic
ID Characteristics Response Reqmts. Characteristics Required Reqmts. Reqmts. Characteristics cs Characteristics Characteristics Characteristics Characteristics s
BA_CTR_01
BA_CTR_02
BA_CTR_03
BA_CTR_04
BA_CTR_05
Internationaliza Extensibility
tion Interoperability Scalability Portability Characteristic Capacity Throughput Peak Profile Peak Profile
ID Characteristics Characteristics Characteristics Characteristics s Characteristics Throughput Period Growth Growth Period Short-Term Long-Term
BA_CTR_01
BA_CTR_02
BA_CTR_03
BA_CTR_04
BA_CTR_05
Figure 106: Sample TOGAF Contract Catalog
Measure (Governance Extension)

BA_MES_01
BA_MES_02
BA_MES_03
BA_MES_04
BA_MES_05
Figure 107: Sample TOGAF Measure Catalog
Service Quality (Governance Extension)

BA_SVQ_01
BA_SVQ_02
BA_SVQ_03
BA_SVQ_04
BA_SVQ_05
Figure 108: Sample TOGAF Service Quality Catalog

Table 67: TOGAF Standard – Architecture Content: Process/Event/Control/Product Catalog –
Process/Event/Control/Product Catalog
Name
The Process/Event/Control/Product catalog provides a hierarchy of processes, events that trigger processes,
Description
outputs from processes, and controls applied to the execution of processes.

This catalog provides a supplement to any Process Flow diagrams that are created and allows an enterprise to
filter, report, and query across organizations and processes to identify scope, commonality, or impact.
For example, the Process/Event/Control/Product catalog allows an enterprise to see relationships of processes to
sub-processes in order to identify the full chain of impacts resulting from changing a high-level process.
 Process  Business Process

Metamodel
 
Entities
Event Business Event

 Control  Constraint
 Product  Product
 Event is resolved by (is generated by) Process  Business Event triggers/is triggered by Business
Relationships
Metamodel
 Control ensures correct execution of Process Process

 Product is produced by Process  Constraint is realized by Business Process
 Business Process access (“writes”) Business Object
Process (Core)
Standard Last Standard Next Standard Process Manual or Process
ID Name Description Category Source Owner Standards Class Creation Date Review Date Review Date Retire Date Criticality Automated Volumetrics
BA_PRO_01
BA_PRO_02
BA_PRO_03
BA_PRO_04
BA_PRO_05
Figure 109: Sample TOGAF Process Catalog
Event (Process Extension)

BA_EVT_01
BA_EVT_02
BA_EVT_03
BA_EVT_04
BA_EVT_05
Figure 110: Sample TOGAF Event Catalog
Control (Process Extension)

BA_CTL_01
BA_CTL_02
BA_CTL_03
BA_CTL_04
BA_CTL_05
Figure 111: Sample TOGAF Control Catalog
Product (Process Extension)

BA_PRD_01
BA_PRD_02
BA_PRD_03
BA_PRD_04
BA_PRD_05
Figure 112: Sample TOGAF Product Catalog
C.4 Phase C: Data Architecture Catalogs

Table 68: TOGAF Standard – Architecture Content: Data Entity/Data Component Catalog –
Data Entity/Data Component Catalog

Name
Description
The purpose of the Data Entity/Data Component catalog is to identify and maintain a list of all the data use
across the enterprise, including data entities and also the data components where data entities are stored. An
agreed Data Entity/Data Component catalog supports the definition and application of information management
and data governance policies and also encourages effective data sharing and re-use.

Metamodel
 Logical Data Component  Data Object

Entities
 Physical Data Component  Artifact
 Logical Data Component encapsulates Data  Data Object realizes Business Object
Relationships
Metamodel
Entity  Artifact realizes Data Object

 Physical Data Component realizes Logical Data
Component

Information Systems - Data
Retention
ID Name Description Date Category Priority Source Data Category Privacy Classification Classification Owner
ISA_DE_01
ISA_DE_02
ISA_DE_03
ISA_DE_04
ISA_DE_05
Figure 113: Sample TOGAF Data Entity Catalog

Last Next
Standard Standard Standard
Standards Creation Review Review Retire
ID Name Description Date Category Priority Source Class Date Date Date Date Owner
ISA_LDC_01
ISA_LDC_02
ISA_LDC_03
ISA_LDC_04
ISA_LDC_05
Figure 114: Sample TOGAF Logical Data Component Catalog

Last Next
Standards Creation Review Review Retire
ID Name Description Date Category Priority Source Class Date Date Date Date Owner
ISA_PDC_01
ISA_PDC_02
ISA_PDC_03
ISA_PDC_04
ISA_PDC_05
Figure 115: Sample TOGAF Physical Data Component Catalog
C.5 Phase C: Application Architecture Catalogs

Table 69: TOGAF Standard Application Portfolio Catalog – ArchiMate Viewpoint Mapping
Application Portfolio Catalog

Name
The purpose of this catalog is to identify and maintain a list of all the applications in the enterprise. This list helps
Description
to define the horizontal scope of change initiatives that may impact particular kinds of applications. An agreed
Application Portfolio allows a standard set of applications to be defined and governed.
The Application Portfolio catalog provides a foundation on which to base the remaining matrices and diagrams.
It is typically the start point of the Application Architecture Phase.
 Information System Service  Application Component

Metamodel

Entities
 Physical Application Component  Application Service
 Logical Application Component realizes  Application Function realizes Application Service

Relationships
Metamodel
Information System Service  Application Component is assigned to Application

 Physical Application Component realizes Logical Function
Information System Services (Services

Extension)
ISA_SRV_01
ISA_SRV_02
ISA_SRV_03
ISA_SRV_04
ISA_SRV_05
Figure 116: Sample TOGAF IS Service Portfolio Catalog
Logical Application Components (CORE)

Standard Creation Next Standard Retire
ID Name Description Category Source Owner Standards Class Date Last Standard Review Date Review Date Date
ISA_LAC_01
ISA_LAC_02
ISA_LAC_03
ISA_LAC_04
ISA_LAC_05
Figure 117: Sample TOGAF Logical Application Portfolio Catalog

Physical Application Components (Infrastructure Consolidation Extension)
Standard Creation Next Standard
ID Name Description Category Source Owner Standards Class Date Last Standard Review Date Review Date Retire Date
ISA_PAC_01
ISA_PAC_02
ISA_PAC_03
ISA_PAC_04
ISA_PAC_05
Date of Last Date of Next Retirement Servicability Performance

ID Lifecycle Status Initial Live Date Release Release Date Availability Characteristics Service Times Managability Characteristics Characteristics Characteristics
ISA_PAC_01
ISA_PAC_02
ISA_PAC_03
ISA_PAC_04
ISA_PAC_05
Reliability Recoverability Locatability Security Privacy Credibility Internationalizatio Interoperability

ID Characteristics Characteristics Characteristics Characteristics Characteristics Integrity Characteristics Characteristics Localization Characteristics n Characteristics Characteristics
ISA_PAC_01
ISA_PAC_02
ISA_PAC_03
ISA_PAC_04
ISA_PAC_05
Scalability Portability Extensibility Capacity Peak Profile Short- Peak Profile

ID Characteristics Characteristics Characteristics Characteristics Throughput Throughput Period Growth Growth Period Term Long-Term
ISA_PAC_01
ISA_PAC_02
ISA_PAC_03
ISA_PAC_04
ISA_PAC_05
Figure 118: Sample TOGAF Physical Application Portfolio Catalog
Table 70: TOGAF Standard – Architecture Content: Interface Catalog – ArchiMate Viewpoint
Mapping
Interface Catalog58
Name
The purpose of the Interface catalog is to scope and document the interfaces between applications to enable the
overall dependencies between applications to be scoped as early as possible. Applications will create, read,
update, and delete data within other applications; this will be achieved by some kind of interface, whether via a
batch file that is loaded periodically, a direct connection to another application’s database, or via some form of
API or web service.
Description
The mapping of the Application Component-Application Component entity relationship is an important step as it
enables the following to take place:
 Understand the degree of interaction between applications, identifying those that are central in terms of their
dependencies on other applications
 Understand the number and types of interfaces between applications
 Understand the degree of duplication of interfaces between applications
 Identify the potential for simplification of interfaces when considering the target Application Portfolio
be created
58
Work Group recommendation: should be a matrix Application Component – Application Component.

Metamodel
 Physical Application Component 

Entities
 “Application communicates with application  Application Function realizes Application Service

relationship”  Application Service serves Application Function
Relationships
Metamodel
 Application Component is assigned to Application

Function
Interface
 Application Interface serves Application Function
Logical Application Components Map
Figure 119: Sample TOGAF Interface Catalog (Logical-Level Matrix)
Physical Application Components Map
Figure 120: Sample TOGAF Interface Catalog (Physical-Level Matrix)

C.6 Phase D Catalogs
Table 71: TOGAF Standard – Architecture Content: Technology Portfolio Catalog – ArchiMate
Viewpoint Mapping
Technology Portfolio Catalog

Name
The purpose of this catalog is to identify and maintain a list of all the technology in use across the enterprise,
including hardware, infrastructure software, and application software. An agreed technology portfolio supports
lifecycle management of technology products and versions and also forms the basis for definition of technology
standards.
Description
The Technology Portfolio catalog provides a foundation on which to base the remaining matrices and diagrams.
It is typically the start point of the Technology Architecture phase.
Technology registries and repositories also provide input into this catalog from a baseline and target perspective.
Technologies in the catalog should be classified against the defined taxonomy in use in the enterprise, such as the
TOGAF TRM (The TOGAF® Series Guide: The TOGAF Technical Reference Model (TRM); see Referenced
Documents) – adapted as necessary to fit the classification of technology products in use.
 Technology Service  Technology Service

Metamodel
 Logical Technology Component  Technology Function

Entities
 Physical Technology Component  Technology Component

Relationships
Metamodel
Platform Services
Created/ Standards
ID Name Description Date Category Source Amended Class
TA_PS_01
TA_PS_02
TA_PS_03
TA_PS_04
TA_PS_05
Figure 121: Sample TOGAF Technology Service Portfolio Catalog
Logical Technology Components
Last Next
Created/ Standards Creation Review Review Retire
ID Name Description Date Category Source Amended Class Date Date Date Date
TA_LTC_01
TA_LTC_02
TA_LTC_03
TA_LTC_04
TA_LTC_05
Figure 122: Sample TOGAF Logical Technology Component Portfolio Catalog
Physical Technology Components

Last Next
Created/ Standards Creation Review Review Retire Product Module
ID Name Description Date Category Source Amended Class Date Date Date Date Name Name Vendor Version
TA_PTC_01
TA_PTC_02
TA_PTC_03
TA_PTC_04
TA_PTC_05
Figure 123: Sample TOGAF Physical Technology Component Portfolio Catalog
Table 72: TOGAF Standard – Architecture Content: Technology Standards Catalog – ArchiMate
Viewpoint Mapping
Technology Standards Catalog

Name
The Technology Standards catalog documents the agreed standards for technology across the enterprise covering
technologies, and versions, the technology lifecycles, and the refresh cycles for the technology. Depending upon
the organization, this may also include location or business domain-specific standards information. This catalog
provides a snapshot of the enterprise standard technologies that are or can be deployed, and also helps identify
the discrepancies across the enterprise.
If technology standards are currently in place, apply these to the Technology Portfolio catalog to gain a baseline
view of compliance with technology standards.
Description
This can be realized by a simple report from the repository

Work Group recommendation:
There are two distinct variants of standards which could be addressed by such a catalog:
 Industry Standard and the question of the compliance to it by (physical) components/functions of the own
company
Sometimes versions of a standard are of interest
— One sample could be, that a company decides to support just actual version minus-1
— One sample could be that a company decides to always support two versions of the standard in parallel
 Company standards for (physical) components (on level of functions)
The second one seems to be of more practical relevance.

 Technology Service  Technology Service

Metamodel
 Logical Technology Component  Technology Function

Entities
 Physical Technology Component  Technology Component

Relationships
Metamodel
Technology Standards
Created/ Standards
ID Name Description Date Category Source Amended Class
Figure 124: Sample TOGAF Technology Standards Catalog
C.7 Phase E and Phase F Catalogs (Migration Planning Tables)

Table 73: TOGAF Standard – Architecture Content: Architecture Definition Increments Table –
Architecture Definition Increments Table

Name
Description
Planning of Transition Architectures and Project Assignment

 Planning a series of transitional architectures that demonstrate the state of the Enterprise Architecture at set
times
 Unique assignment of delivery results of each project to each particular transitional architecture
 All metamodel entities of all architecture domains  All metamodel entities of all architecture layers are
Metamodel
Entities
are allowed allowed

 Work Package  Work Package
Relationships  Work Package realizes Architecture Element  Work Package (realizes Deliverable) realizes
Metamodel
Architecture Element
Figure 125: Sample TOGAF Architecture Definition Increments Table
Figure 126: Sample ArchiMate Implementation and Migration View

Table 74: TOGAF Standard – Architecture Content: Transition Architecture State Evolution Table
– ArchiMate Viewpoint Mapping
Transition Architecture State Evolution Table

Name
Representation of the state change of the architecture according to the development of Transition Architectures.
Categorization of the planned development of the Enterprise Architecture according to the TOGAF TRM (The
Description
TOGAF® Series Guide: The TOGAF Technical Reference Model (TRM); see Referenced Documents).
All solution building blocks should be described with their effects in relation to the respective services of the
TOGAF TRM.
The progress of the development of the Enterprise Architecture should be presented (especially the achievement
of the target state should be emphasized).
 All metamodel entities of all architecture domains  All metamodel entities of all architecture layers are
Metamodel
Entities
are allowed allowed

 Work Package  Plateau
 Work Package
 Work Package realizes Architecture Element  Work Package (realizes Deliverable) realizes
Relationships
Metamodel
Architecture Element
 Plateau aggregating any Architecture Element
Transition Architecture State Evolution Table
Transition Transition Transition

Sub-Domain Service
Architecture 1 Architecture 2 Architecture 3
Infrastructure Information Solution System A Solution System B-1 Solution System B-2
Applications Exchange Services (replace) (transition) (new)
Data Management Solution System D Solution System D Solution System D

Services (retain) (retain) (retain)
… … … … …
Figure 127: Sample TOGAF Transition Architecture State Evolution Table
C.8 Requirements Management Catalogs
Table 75: TOGAF Standard – Architecture Content: Requirements Catalog – ArchiMate Viewpoint
Mapping
Requirements Catalog
Name
The Requirements catalog captures things that the enterprise needs to do to meet its objectives.
Description
Requirements generated from architecture engagements are typically implemented through change initiatives
identified and scoped during Phase E (Opportunities & Solutions).
Requirements can also be used as a quality assurance tool to ensure that a particular architecture is fit-for-
purpose (i.e., can the architecture meet all identified requirements).
One catalog per entity type (Requirement, Assumption, Constraint, Gap).
 Requirement  Requirement
Metamodel
 
Entities
Assumption Assumption
 Constraint  Constraint
 Gap  Gap
 No relationships covered by this catalog

Relationships
Metamodel
Requirements Log
ID Requirement Item Description Category Priority Date Source Owner

GOV_REQ_01
REQ_C_02
REQ_C_03
REQ_C_04
REQ_C_05
Figure 128: Sample TOGAF Requirements Catalog

Constraint
ID Constraint Comments Source Owner Status Probability Impact
Figure 129: Sample TOGAF Constraints Catalog
D Extended Use of ArchiMate Viewpoints
D.1 Phase A Motivation Viewpoints

A number of standard viewpoints for modeling motivational aspects have been defined. Each of
these viewpoints presents a different perspective on modeling the motivation that underlies some
Enterprise Architecture and allows a modeler to focus on certain aspects. Therefore, each
viewpoint considers only a selection of the elements and relationships that have been described
in the preceding sections.
Table 76: ArchiMate 3.1 Specification Stakeholder Viewpoint
Name Stakeholder Viewpoint
Description The stakeholder viewpoint allows the analyst to model the stakeholders, the
internal and external drivers for change, and the assessments (in terms of
strengths, weaknesses, opportunities, and threats) of these drivers. Also, the
links to the initial (high-level) goals that address these concerns and
assessments may be described. These goals form the basis for the
requirements engineering process, including goal refinement, contribution
and conflict analysis, and the derivation of requirements that realize the
goals.
Metamodel Entities  Stakeholder

 Driver
 Assessment
 Goal
 Outcome

Figure 130: Sample ArchiMate Stakeholder View 59
Table 77: ArchiMate 3.1 Specification Goal Contribution Viewpoint
Name Goal Contribution Viewpoint
Description The goal contribution viewpoint focuses on modeling and analyzing the
influence relationships between goals (and requirements).
Metamodel Entities  Goal

 Requirement
Metamodel Relationships  Goal/Requirement influences another Goal/Requirement
59
Figure 131: Sample ArchiMate Goal Contribution View60
Table 78: ArchiMate 3.1 Specification Principles Viewpoint
Name Principles Viewpoint
Description The principles viewpoint focuses on modeling the relevant principles and
the goals that motivate these principles.
Metamodel Entities  Goal

 Principle
Metamodel Relationships  Principles realizes Goal

 Principle influences Goal
60

Figure 132: Sample ArchiMate Principle View61
Table 79: ArchiMate 3.1 Specification Outcome Realization Viewpoint
Name Outcome Realization Viewpoint
Description The outcome realization viewpoint is used to show how the highest-level,
business-oriented results are produced by the capabilities and underlying
core elements.
Metamodel Entities  Outcome

 Capability
 Value stream
 Resource
 Value
 Meaning
 Core element
Metamodel Relationships  Principles realizes Goal

 Principle influences Goal
Figure 133: Sample ArchiMate Outcome Realization View62
61
62
D.2 Phase E (F) Implementation and Migration Viewpoints
Table 80: ArchiMate 3.1 Specification Project Viewpoint
Name Project Viewpoint
Description A project viewpoint is primarily used to model the management of

architecture change. The “architecture” of the migration process from an old
situation (current state Enterprise Architecture) to a new desired situation
(target state Enterprise Architecture) has significant consequences on the
medium and long-term growth strategy and the subsequent decision-making
process. Some of the issues that should be addressed by the models
designed in this viewpoint are:
 Developing a fully-fledged organization-wide Enterprise Architecture
is a task that may require several years
 All systems and services must remain operational regardless of the
presumed modifications and changes of the Enterprise Architecture
during the change process
 The change process may have to deal with immature technology
standards (e.g., messaging, security, data, etc.)
 The change has serious consequences for the personnel, culture, way of
working, and organization
Furthermore, there are several other governance aspects that might constrain
the transformation process, such as internal and external cooperation,
project portfolio management, project management (deliverables, goals,
etc.), plateau planning, financial and legal aspects, etc.
Metamodel Entities  Work package

 Goal
 Outcome
 Implementation event
 Deliverable
 Business actor
 Business role
Metamodel Relationships  Work Package realizes Goal

 Work Package realizes Deliverable
 Work Package triggers another Work Package
 Flow from one Work Package to another Work Package
 Role is assigned to Work Package
 Business Actor is assigned to Role

Figure 134: Sample ArchiMate Project View63
Table 81: ArchiMate 3.1 Specification Migration Viewpoint
Name Migration Viewpoint
Description The migration viewpoint entails models and concepts that can be used for
specifying the transition from an existing architecture to a desired
architecture.
Metamodel Entities  Plateau

 Gap
Metamodel Relationships  Plateau is associated to Gap
Figure 135: Sample ArchiMate Migration View64
The migration viewpoint could be used to show how a business capability is realized in
incremental steps. These incremental steps could be defined by capability increments by using
the technique of capability-based planning.
D.3 Physical Viewpoints

The physical viewpoint addresses the entities of the Physical Layer, which is an extension of the
Technology Layer in the ArchiMate 3.1 Specification release.
63
64
Table 82: ArchiMate 3.1 Specification Physical Viewpoint
Name Physical Viewpoint
Description The physical viewpoint contains equipment (one or more physical

machines, tools, or instruments) that can create, use, store, move, or
transform materials, how the equipment is connected via the distribution
network, and what other active elements are assigned to the equipment.
Metamodel Entities  Facility

 Equipment
 Location
 Node
 Device
 Path
 Communication network
 Distribution network
 Material
Metamodel Relationships  Facility is assigned to an Equipment

 Facility/Equipment access Material
 Equipment is associated to a Communication Network
Figure 136: Sample Physical View

E Mapping of Metamodel Entities
In this appendix we show a list of all TOGAF metamodel entities being used in the different
TOGAF artifacts with our proposal of the most appropriate ArchiMate metamodel entity, being
used as mapping.
Table 83: TOGAF Standard – Architecture Content: ArchiMate 3.1 Specification Metamodel Entity
Mapping
Actor: Business Actor:

A person, organization, or system that has a role A business entity that is capable of performing
that initiates or interacts with activities; for behavior.
example, a sales representative who travels to visit
customers. Actors may be internal or external to an
organization. In the automotive industry, an
original equipment manufacturer would be
considered an actor by an automotive dealership
that interacts with its supply chain activities.
Application Service: Application Service:

The automated elements of a business service. An Represents an explicitly defined exposed
application service may deliver or support part or application behavior.
all of one or more business services.
Assumption: Assumption as a special kind of Constraint:

A statement of probable fact that has not been fully A constraint represents a factor that limits the
validated at this stage, due to external constraints. realization of goals.
For example, it may be assumed that an existing
application will support a certain set of functional
requirements, although those requirements may not
yet have been individually validated.
Business Capability: Capability:

A particular ability that a business may possess or Represents an ability that an active structure
exchange to achieve a particular purpose. element, such as an organization, person, or
system, possesses.
Business Information: Business Object:

Represents a concept and its semantics used within Represents a concept used within a particular
the business. business domain.
Business Service: Business Service:

Supports the business by encapsulating a unique Represents an explicitly defined exposed business
element of business behavior; a service offered behavior.
external to the enterprise may be supported by
business services.
Capability: Capability:
An ability that an organization, person, or system Represents an ability that an active structure
possesses. element, such as an organization, person, or
Note: This a general-purpose definition. See system, possesses.
Business Capability for how this concept is refined
for usage in Business Architecture.
Constraint: Constraint:
An external factor that prevents an organization Represents a factor that prevents or obstructs the
from pursuing particular approaches to meet its realization of goals.
goals. For example, customer data is not
harmonized within the organization, regionally or
nationally, constraining the organization’s ability
to offer effective customer service.
Contract: Contract:
An agreement between a consumer and a provider Represents a formal or informal specification of an
that establishes functional and non-functional agreement between a provider and a consumer that
parameters for interaction. This applies to all types specifies the rights and obligations associated with
of service interactions within the metamodel. a product and establishes functional and non-
functional parameters for interaction.
Control: Constraint:
A decision-making step with accompanying Represents a factor that limits the realization of
decision logic used to determine execution goals.
approach for a process or to ensure that a process A constraint is a specialization of a requirement.
complies with governance criteria. For example, a
sign-off control on the purchase request processing A requirement represents a statement of need that
process that checks whether the total value of the must be met by the architecture.
request is within the sign-off limits of the
requester, or whether it needs escalating to higher
authority.
Course of Action: Course of Action:

Direction and focus provided by strategic goals and An approach or plan for configuring some
objectives, often to deliver the value proposition capabilities and resources of the enterprise,
characterized in the business model. undertaken to achieve a goal.
Data Entity: Business Object:

Represents data that is recognized by the business Represents a concept used within a particular
as a distinct concept. business domain. (We use this mapping when data
entity is used in a more conceptual way.)

Data Object:
Represents data structured for automated
processing. (We use this mapping when data entity
is used in a more logical way; i.e., for the direct
access by an application function = logical
application component.)
Driver: Driver:
An external or internal condition that motivates the Represents an external or internal condition that
organization to define its goals. An example of an motivates an organization to define its goals and
external driver is a change in regulation or implement the changes necessary to achieve them.
compliance rules which, for example, require
changes to the way an organization operates; i.e.,
Sarbanes-Oxley in the US.
Event: Business Event:

An organizational state change that triggers A business behavior element that denotes an
processing events; may originate from inside or organizational state change. It may originate from
outside the organization and may be resolved and be resolved inside or outside the organization.
inside or outside the organization.
Function: Business Function:

A set of business behaviors based on a chosen set A collection of business behavior based on a
of criteria. Functions are usually close-coupled chosen set of criteria (typically required business
to/with organizational units. resources and/or competencies), closely aligned to
an organization, but not necessarily explicitly
governed by the organization.
Gap: Gap:
A statement of difference between two states. Used Represents a statement of difference between two
in the context of gap analysis, where the difference plateaus.
between the Baseline and Target Architecture is
identified.
Goal: Goal:
A high-level statement of intent or direction for an Represents a high-level statement of intent,
organization. Typically used to measure success of direction, or desired end state for an organization
an organization. and its stakeholders.
Location: Location:
A place where activities occur. Locations can be A place or position where structure elements can
composed and decomposed. be located, or behavior can be performed.
Logical Application Component: Application Function:

An encapsulation of application functionality that Represents automated behavior that can be
is definable by services offered and data performed by an application component.
maintained, independently of implementation and
technology.
Logical Data Component: Data Object:

A data structure composed of logically-related data Represents data structured for automated
entities. processing.
Measure: Assessment:
An indicator or factor that can be tracked, usually Represents the result of an analysis of the state of
on an ongoing basis, to determine success or affairs of the enterprise with respect to some driver.
alignment with objectives and goals. Metric:
Specialization of driver.
The extent, quantity, amount, or degree of
something, as determined by measurement or
calculation (for example, specializations of
motivation elements of the ArchiMate language
customization mechanisms).
If a basic ArchiMate metamodel has to be used, we
would use “Assessment”.
Objective: Business Objective:

An organizational aim that is declared in a Simple, Specialization of goal.
Measurable, Actionable, Realistic, and Timebound A time-bound milestone for an organization used to
(SMART) way; for example, "Increase capacity demonstrate progress towards a goal (for example,
utilization by 30% by the end of the year, to specializations of motivation elements of the
support the planned increase in market share". ArchiMate language customization mechanisms).
Organization Unit: Business Actor:

A self-contained unit of resources with goals, A business entity that is capable of performing
objectives, and measures. Organization units may behavior.
include external parties and business partner
organizations.
Stakeholder:
The role of an individual, team, or organization (or
classes thereof) that represents their interests in the
outcome of the architecture.
Comment: We propose to use the ArchiMate
definition of “Stakeholder” when using the
TOGAF definition of “Organization Unit” with
relations to “Measure”, “Goal”, or “Objective”.
Physical Application Component: Application Component:

A realization of logical application functionality Represents an encapsulation of application
using components of functionality in applications functionality aligned to implementation structure,
that may be hired, procured, or built. which is modular and replaceable. It encapsulates
its behavior and data, exposes services, and makes
them available through interfaces.

Physical Data Component: Artifact:

A data structure that realizes related logical data Represents a piece of data that is used or produced
components represented in the format or schema in a software development process, or by
required by a particular technology. deployment and operation of an IT system.
Physical Technology Component: Technology Component:

A realization of logical technology functionality A node represents a computational or physical
using a particular technology product that may be resource that hosts, manipulates, or interacts with
deployed. other computational or physical resources.
Principle: Principle:
A qualitative statement of intent that should be met Represents a qualitative statement of intent that
by the architecture. Has at least a supporting should be met by the architecture.
rationale and a measure of importance.
Note: A sample set of Architecture Principles is
defined in the TOGAF Standard – ADM
Techniques (see Referenced Documents).
Process: Business Process:

Processes represent a sequence of activities that Represents a sequence of business behaviors that
together achieve a specified outcome, can be achieves a specific outcome such as a defined set
decomposed into sub-processes, and can show of products or business services.
operation of a function or service (at next level of
detail).
Processes may also be used to link or compose
organizations, business capabilities, services, and
processes. A process may realize one service
and/or orchestrate subordinate services.
Product: Product:
An outcome generated by the business to be A product represents a coherent collection of
offered to customers. Products include materials services and/or passive structure elements,
and/or services. accompanied by a contract/set of agreements,
which is offered as a whole to (internal or external)
customers.
For most artifacts, “Business Object” would be a
good mapping for the TOGAF definition of
“Product”, as it was defined very generically in
past TOGAF releases.
Requirement: Requirement:
A quantitative statement of business need that must Represents a statement of need that must be met by
be met by a particular architecture or work the architecture.
package.
Role: Business Role:

The usual or expected function of an actor, or the The responsibility for performing specific
part somebody or something plays in a particular behavior, to which an actor can be assigned, or the
process or event. An actor may have a number of part an actor plays in a particular action or event.
roles.
See also Actor.
Service Quality: Service Quality Profile (based on the ArchiMate

A configuration of non-functional requirements or profiling mechanism).
attributes that may be assigned to a Business, An alternative would be a “Requirement”.
Application, or Technology service. A requirement represents a statement of need that
must be met by the architecture.
Technology Service: Technology Service:

A technical capability required to provide enabling Represents an explicitly defined exposed
infrastructure that supports the delivery of technology behavior.
applications.
Value Stream: Value Stream:

A representation of an end-to-end collection of Represents a sequence of activities that create an
value-adding activities that create an overall result overall result for a customer, stakeholder, or end
for a customer, stakeholder, or end-user. user.
Work Package: Work Package:

A set of actions identified to achieve one or more Represents a series of actions identified and
objectives for the business. A work package can be designed to achieve specific results within
a part of a project, a complete project, or a specified time and resource constraints.
program.

F Mapping of Metamodel Relationships
In this appendix we show a list of all TOGAF metamodel relationships with our proposal of the
most appropriate ArchiMate metamodel relationships to be used for mapping.
Composition Triggering Serving
Aggregation Flow Access
Assignment Specialization Influence

++
Realization Association
Figure 137: ArchiMate Relationship Types
Table 84: TOGAF Standard – Architecture Content: ArchiMate 3.1 Specification Metamodel
Relationship Mapping
Harmonization Project: Consolidated Metamodel

TOGAF Standard –
Architecture Content Derived Relation Original Relation(s)
See right.
Capability
is delivered
by
delivers
Work Package
TOGAF Standard –
See right.
Driver
creates
addresses
Goal
See right.
Driver
decomposes
See right.
Goal
is made
specific
realizes
Objective
Business Objective as an example of the

specialization of an Element (Goal),
Use of specific icon for Business
Objective different from Goal
recommended.
See right.
Goal
decomposes
Measure
sets
performance is tracked
criteria for against
Objective
See right.
Objective
decomposes

TOGAF Standard –
Organization Unit
is motivated
by
motivates
Objective
See right.
Goal
is realized
by
realizes
Course of Action
Course of Action
influences
participates
in
Oragnization Unit
Course of Action
influences
is produced
by
Product
See right.
Measure
decomposes
See right.
Value Stream
is
influenced
by influences
Organization Unit
TOGAF Standard –
See right.
Business Capability
is
influenced
by influences
Course of Action
Business Function Influences

Function Course of Action.
is Relationship not available in
influenced the ArchiMate language.
by influences
Proposal: Business Function
Course of Action realizes Course of Action
(alternative: Association).
See right.
See right.
Function
decomposes
See right.
Function
communicates
with
Organization Unit
delivers
Is used by
Business Capability
Capabilities are more abstract

than elements of the Business,
Application, and Technology
Layers. Therefore, realization is
the standard relation. Serving is
not allowed.

TOGAF Standard –
See right.
Business Capability
is delivered
by
delivers
Value Stream
Realizes Relationship available

Business Capability
based on definition of
is “Capability” deleted. The
operationalized Strategy Layer is more abstract
by operationalizes
than the Business, Application,
Value Stream
and Technology Layers.
Therefore, the relation from
these layer elements to strategy
layer elements is realization.
See right.
Value Stream
is
operationalized
by operationalizes
Process
See right.
Value Stream
In the Value Stream guide,
is triggered Stakeholder is used.
by, involves performs a
task in
Course of Action
See right.
Business Capability
enables
is enabled
by
Value Stream
TOGAF Standard –
Business Capability
uses
is used by
Business
Information
Course of Action
influences
is influenced
by
Business
Information
See right.
Business Service
is derived
from used to
derive
Business
information
See right.
Process
uses
is used
by
Business
Information
Business See right.

Information
is realized
by
realizes
Data Entity

TOGAF Standard –
See right.
Organization Unit
contains
belongs
to
Actor
Organization Unit
owns and is owned

governs and
governed
Business Service
Organization Unit
enables
is owned
by
Function
Business Actor realizes a No relation in Harmonization

Organization Unit Product not valid in the Metamodel
delivers
ArchiMate language.
is
produced Product is defined differently in
by
the TOGAF and ArchiMate
Product
Standards (see Entity Mapping
Table for details):
Proposal (Relation from
Process to Product below
depending on use-case):
Business Actor accesses a
Business Object
TOGAF Standard –
Business Actor realizes a

Business Service
See right.
Organization Unit
decomposes
See right.
Actor
performs is
task in performed
by
Role
Actor
consumes
is provided
to
Role
Actor
interacts
with,
performs
Function
Actor
participates,
triggers is produced
by, supports
Function

TOGAF Standard –
Actor
generates, is resolved
resolves by, is
generated by
Function
See right.
Role
performs,
participates in is performed
by, involves
Process
See right.
Role
decomposes
See right.
Function
(Ignoring the term Interface.)
is bounded provides
by governed interface
to access
Business Service
See right.
Process
Two relationships:
orchestrates, supports = serves;
decomposes supports, is
realized is realized by =
is realized by;
Business Service (Business Process aggregates
Business Services not available
in the ArchiMate language)
TOGAF Standard –
No direct relation between

Process Process und Product in the
delivers is
Harmonization Metamodel.
produced (The ArchiMate language only
by
allows association and flow
Product from Process to Product;
association, flow, realization
and serving, from Product to
Process). The access relation from Business
Proposal, depending on the Process to Business Object shows a
context: write-access with the arrow towards the
Business Object. This should be seen as
Process accesses a Business one example. It could be a read-access
Object with the arrow pointing to the Business
See right. Process or read-/write-access with both
arrows. This holds true for all cases in
this mapping table.
In this specific case write is the right
mapping because the product is
produced by the process.
Business Process realizes a

Business Service.
See right.
See right.
Process
The ArchiMate language
generates, provides two triggering
resolves relations – one in each direction
to map this relation from the
Event
TOGAF Standard, using this
kind of mapping with two
triggering relations in the
ArchiMate language.
Control not part of the

Process ArchiMate Metamodel.
is guided ensures Proposal: Mapping of
by correct Requirement to Control.
operation of
A Business Process realizing a
Control Requirement.

TOGAF Standard –
See right.
Process
decomposes
See right.
Process
precedes,
follows
Event
is resolved
by resolves
Business Service
The ArchiMate language
provides Triggering relations
between all behavioral elements
in both directions (could be
seen as extensions).
See right.
Contract
No direct relation between
governs, is governed, Business Service and Contract
measures and is in the Harmonization
measured by
Metamodel.
Business Service (The ArchiMate language only
allows association between the
two and access from Business
Service to Contract.)
No entity Service Quality

Contract available in the ArchiMate
language.
meets
Proposal: Mapping of Service
Quality to Requirement (Non-
Service Quality Functional Requirement
(NFR)).
Relation: A contract realizes a
Service Quality.
TOGAF Standard –
No entity Service Quality

Business Service available in the ArchiMate
language.
meets
Proposal: Mapping of Service
Quality to Requirement (NFR).
Service Quality Relation: A Business Service
realizes a Service Quality.
See right.
Business Service
decomposes
See right.
Business Service
consumes
Actor
supplies or
consumes is supplied or
consumed by
Data Entity
(Access relation with “direction

of flow“ to model “supplies”
versus “consumes”.)
See right.
Actor
decomposes
See right.
Business Service
(Access relation with “direction
provides, of flow“ to model “provides”
consumes is accessed and versus “consumes”.)
updated through
Data Entity

TOGAF Standard –
Business Service
uses
automates
some or all of
Application Service
Proposal: Serves relation.
Realization relation is also
allowed in the ArchiMate
language.
We do not model this Based on the Harmonization Metamodel

Business Service
relationship because we think it this would be a really long relation:
is is a poor modeling design (a Technology Function –>
implemented provides a direct relationship from the Technology Service –>
on platform for
technology domain to the Application Function –>
Logical Technology business domain). Application Service –>
Component Business Function –>
Business Service
(In the ArchiMate language this is
available as a Cross-Layer Dependency:
Technology Function realizes a Business
Process/Function which realizes a
Business Service.)
See right.
Data Entity
Based on the definition of
resides Logical Data Component an
within aggregation/composition
encapsulates
relationship would be the
Logical Data correct mapping, as long as
Component Data Entity is seen as logical
element of the Information
Systems Architecture.
TOGAF Standard –
In cases where Data Entity is

used in a more conceptual
meaning we would recommend
that using a realize relationship
is not really fitting to the
encapsulate-relationship.
See right.
Data Entity
decomposes
See right.
Data Entity
relates to
Logical Data See right.

Component
is realized
by
Physical Data
Component
See right.
Application Service
is realized
through
Physical Data
Component

Component The ArchiMate language used
is realized the assignment relationship
by
realizes
(realization relationship is also
allowed).
Physical Data
Component

TOGAF Standard –
See right.
Data Entity
In this case we map the
used by TOGAF Data Entity to the
uses
ArchiMate Data Object instead
of the ArchiMate Business
Application Service Object. The Application Layer
behavior elements accesses the
Data Object which is an “IT-
Realization” of the business
object.

Component (Access relation with “direction
used by of flow“ to model “kind” of
uses
usage.)
Logical Application
Component
Physical Data
Component
used by
Physical
Application
Component
Application Service
is served
by
serves
Technology Service
TOGAF Standard –
Logical Application
Component
is served
by
serves
Logical Technology
Component
Physical
Application
Component
is served
by
serves
Physical
Technology
Component
See right.
Technology Service
is supplied
by
supplies
Logical Technology
Component
Logical Technology See right.

Component The ArchiMate language used
is realized the assignment relationship (the
by realization relationship is also
realizes
allowed).
Physical Technology
Component
Logical Application See right.

Component
decomposes

TOGAF Standard –
Logical Application See right.

Component
communicates
with
Physical Application See right.

Component
decomposes
Physical Application
Component
communicates
with

Component
decomposes

Component
is dependent
on
Physical See right.

Technology
Component
decomposes
Physical See right.

Technology
Component
is dependent
on
Physical Data See right.

Component
decomposes
G Metamodel Based on the ArchiMate Modeling Language
In this appendix we show how we constructed the minimal metamodel based on the ArchiMate
Specification phase by phase (domain by domain for Phase C) and consolidated the results
afterwards for Chapter 5. It should be obvious that all viewpoints defined to be used in Phases B
to D could be used in Phase E, too. We do not reflect this explicitly in the metamodel for Phase
E.
Figure 138: Metamodel Covering the TOGAF Artifacts of Phase A

Figure 139: Metamodel Covering the TOGAF Artifacts of Phase B
Figure 140: Metamodel Covering the TOGAF Artifacts of Phase C: Data Architecture

Figure 141: Metamodel Covering the TOGAF Artifacts of Phase C: Application Architecture
Figure 142: Metamodel Covering the TOGAF Artifacts of Phase D
Figure 143: Metamodel Covering the TOGAF Artifacts of Phase E

H Minimal Metamodel based on the ArchiMate Modeling
Language Structured as the TOGAF Metamodel
This appendix shows the minimal metamodel based on the ArchiMate modeling language (see
Chapter 5) in a structure analogous to the TOGAF metamodel. This is intended to give TOGAF
experts without knowledge of the ArchiMate Specification easier access to our approach.
Figure 144: Minimal ArchiMate Metamodel Structured Like the TOGAF Enterprise Metamodel
Figure 145 shows an extended version of the metamodel based on the one in Figure 144
covering all metamodel entities and relationships – not just the ones necessary for the existing
TOGAF artifacts.

Figure 145: Minimal ArchiMate Metamodel in the Structure of the TOGAF Metamodel
I Pure TOGAF Metamodel Using the ArchiMate Modeling
Language
This appendix presents a description of the TOGAF metamodel by using ArchiMate notation in
a straightforward way. Relational names from the TOGAF metamodel are used in just one way.
Two-way names can be found in the TOGAF metamodel.

Figure 146: TOGAF Metamodel Using the ArchiMate Modeling Language
Acronyms & Abbreviations
ADM Architecture Development Method
BIAN Banking Industry Architecture Network
COTS Commercial Off-The-Shelf
ERP Enterprise Resource Planning
IoT Internet of Things
ITIL IT Infrastructure Library
JSON JavaScript Object Notation
MRI Magnetic Resonance Imaging
NFR Non-Functional Requirement
OMG Object Management Group
SLA Service-Level Agreement
SQL Structured Query Language
UML Unified Modeling Language
VPN Virtual Private Network
XML eXtensible Markup Language

Index
ABB........................................................ 7 business function .................................. 11
Active Structure aspect ........................... 4 Business Function catalog .................. 125
actor cooperation viewpoint ................. 52 business function viewpoint ................. 47
Actor/Role matrix ............................... 106 Business Glossary catalog .................. 120
Application and User Location business information entity .................. 11
diagram ............................................ 76 Business Interaction matrix ................ 105
Application Architecture ........................ 3 Business Model Canvas ....................... 36
Application Communication diagram .. 73 Business Model diagram ...................... 36
application component concept ............ 14 business object ..................................... 11
application components .......................... 9 business object element ........................ 17
application cooperation viewpoint ....... 73 business process ................................... 11
Application Interaction matrix ........... 114 business process cooperation viewpoint
Application Migration diagram ............ 85 ................................................... 34, 58
Application Portfolio catalog ............. 132 business process viewpoint ............ 45, 56
application service concept................... 14 business role ......................................... 11
application structure viewpoint ...... 83, 86 Business Service catalog .................... 125
application usage viewpoint ................. 81 business service concept ...................... 14
Application Use-Case diagram ............. 78 Business Service/Information diagram 45
Application/Data matrix ..................... 110 Business Use-Case diagram ................. 60
Application/Function matrix .............. 113 Capability Architecture .......................... 9
Application/Organization matrix ........ 111 capability map viewpoint ..................... 38
Application/Technology matrix .......... 115 Capability/Organization matrix .......... 108
ArchiMate aspects .................................. 4 communication network element ......... 17
ArchiMate core language ..................... 13 Conceptual Data diagram ..................... 63
ArchiMate Full Framework .................... 5 conceptual elements ............................. 10
ArchiMate layers .................................... 4 contract ................................................. 12
ArchiMate viewpoint ............................ 20 contract element ................................... 12
Architecture Continuum ......................... 8 Contract/Measure catalog................... 128
Architecture Definition Increments Data Architecture ................................... 3
Table .............................................. 138 Data Dissemination diagram ................ 66
architecture descriptions ......................... 6 Data Entity/Business Function matrix 109
Architecture Landscape .......................... 9 Data Entity/Data Component catalog . 131
architecture partitions ............................. 9 Data Lifecycle diagram ........................ 72
Architecture Roadmap .......................... 21 Data Migration diagram ....................... 70
artifact .................................................. 11 data object ............................................ 11
artifact descriptions ................................ 2 Data Security diagram .......................... 68
Baseline Architecture ........................... 17 dedicated layers .................................... 43
Behavior aspect ...................................... 4 deployed solutions .................................. 7
Benefits diagram ................................ 102 derivation rules ..................................... 16
black-box view ..................................... 16 domain-specific metamodel ................. 26
building block ......................................... 7 Driver/Goal/Objective catalog ........... 127
business actor ....................................... 11 Enterprise Manageability diagram ....... 80
business actor concept .......................... 14 Environments and Locations diagram .. 87
Business Architecture ............................. 3 external behavior elements ................... 16
Business Capabilities catalog ............. 120 flow relationship .................................. 12
Business Capability map ...................... 38 Functional Decomposition diagram ..... 47
business domain concept ...................... 16 goal concept ......................................... 17
Business Event diagram ....................... 58 goal contribution viewpoint ............... 144
Business Footprint diagram .................. 43 goal realization viewpoint .................... 61
Goal/Objective/Service diagram .......... 61 representation element ......................... 18
grouping concept .................................. 16 Requirements catalog ......................... 141
Implementation and Migration resource concept ................................... 18
elements ............................................. 5 resource map viewpoint ....................... 29
implementation and migration resource realization viewpoint ............. 29
viewpoint ....................................... 100 Role catalog........................................ 124
information structure viewpoint .... 63, 64, Role/Application matrix ..................... 112
66, 68 sample views .......................................... 2
Information Systems Architecture .......... 3 SBB ........................................................ 7
infrastructure viewpoint ................. 87, 94 Segment Architecture ............................. 9
Interface catalog ................................. 134 service layers ........................................ 43
internal active structure element ........... 14 serving relationship .............................. 12
internal active structure node element .. 17 SLA ...................................................... 12
layered viewpoint ................................. 43 Software Distribution diagram ............. 86
Location catalog ................................. 126 Software Engineering diagram ............. 83
logical abstraction level ........................ 17 Solution Concept diagram .................... 29
logical application component ................ 9 Solutions Continuum .............................. 7
logical components ................................. 8 Stakeholder catalog ............................ 118
Logical Data diagram ........................... 64 stakeholder viewpoint ........................ 143
logical elements .................................... 11 Statement of Architecture Work .......... 20
mapping approach ................................ 12 Strategic Architecture............................. 9
metamodel relationships ..................... 156 Strategy elements ................................... 5
migration viewpoint ........................... 148 strategy viewpoint ................................ 29
Motivation elements ............................... 5 Strategy/Capability matrix ................. 108
node concept ......................................... 14 Target Application Architecture........... 23
Organization Decomposition diagram .. 54 Target Architecture .............................. 17
organization map .................................. 52 Target Business Architecture ............... 21
organization viewpoint ......................... 54 Target Data Architecture ...................... 22
Organization/Actor catalog ................ 123 Target Technology Architecture .......... 24
outcome concept ................................... 17 Technology Architecture ........................ 4
outcome realization viewpoint ........... 146 technology components .......................... 9
Passive Structure aspect ......................... 4 Technology Portfolio catalog ............. 136
path element ......................................... 17 technology service concept .................. 14
physical abstraction level ..................... 17 Technology Standards catalog ........... 137
physical application component ............. 9 technology usage viewpoint ................. 91
physical elements ................................. 11 TOGAF ADM ........................................ 1
Physical elements ................................... 5 TOGAF architecture domains ................ 3
physical viewpoint ...................... 148, 149 TOGAF Enterprise Continuum .............. 6
plateau concept ..................................... 17 TOGAF graphical artifacts ................... 20
Platform Decomposition diagram......... 91 Transition Architecture State Evolution
Principles catalog ............................... 117 Table.............................................. 140
principles viewpoint ........................... 145 Transition Architectures ....................... 17
Process Flow diagram .......................... 56 two-way names .................................. 180
Process/Application Realization Value Chain diagram............................ 34
diagram ............................................ 81 value concept........................................ 17
Process/Event/Control/Product Value Stream catalog ......................... 121
catalog ........................................... 130 Value stream map ................................. 41
Processing diagram............................... 94 Value Stream Stages catalog .............. 122
product.................................................. 12 value stream viewpoint ........................ 41
Product Lifecycle diagram ................... 49 Value Stream/Capability matrix ......... 107
Project Context diagram ..................... 100 viewpoint mechanism..................... 18, 20
project viewpoint ................................ 147 white-box view ..................................... 16
relational names .................................. 180

ArchiMate Modeling Language

Uploaded by

Copyright:

Available Formats

ArchiMate Modeling Language

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ArchiMate Modeling Language

Uploaded by

Copyright:

Available Formats

The Open Group Guide

How to Use the ArchiMate® Modeling Language to

The Open Group Guide

Published by The Open Group, April 2022.

ii The Open Group Guide (2022)

2 Modeling Foundational TOGAF Concepts with ArchiMate Concepts ..................... 3

3 Additional Benefits of the ArchiMate Structure and Concepts ............................... 13

4 ArchiMate Viewpoints to Model the TOGAF ADM Graphical Artifacts .............. 20

5 Metamodel Based on the ArchiMate Specification................................................. 25

A ArchiMate Viewpoints to Model the TOGAF ADM Graphical Artifacts .............. 27

B ArchiMate Constructs to Model TOGAF Matrices............................................... 104

C ArchiMate Constructs to Model TOGAF Catalogs............................................... 116

D Extended Use of ArchiMate Viewpoints .............................................................. 142

E Mapping of Metamodel Entities............................................................................ 149

F Mapping of Metamodel Relationships .................................................................. 155

G Metamodel Based on the ArchiMate Modeling Language ................................... 172

H Minimal Metamodel based on the ArchiMate Modeling Language Structured

iv The Open Group Guide (2022)

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

ITIL is a registered trademark of AXELOS Limited.

Microsoft is a registered trademark of Microsoft Corporation.

vi The Open Group Guide (2022)

Mats Gejnevall, Minnovate & Biner Consulting

Bernd Ihnen, BiZZdesign

Rolf Knoll, Novatec Consulting GmbH

Marc Lankhorst, BiZZdesign

The Open Group gratefully acknowledges the authors of this document:

viii The Open Group Guide (2022)

x The Open Group Guide (2022)

1.2 Guidance for the Reader

1.4 Future Directions

2 The Open Group Guide (2022)

2.1 Scope and Level of Detail

2.2 Mapping TOGAF Domains to ArchiMate Layers and Aspects

The Term “Physical”

4 The Open Group Guide (2022)

Together, this gives us the ArchiMate Full Framework, as shown in Figure 2.

Figure 2: ArchiMate Full Framework

 Implementation and Migration elements are used in Phase E (Opportunities and

Figure 3: Correspondence Between the ArchiMate Language and TOGAF ADM

2.3 TOGAF Enterprise Continuum and Building Blocks

6 The Open Group Guide (2022)

Figure 4: The TOGAF Enterprise Continuum1

Figure 5: TOGAF Enterprise Continuum Mapped to ArchiMate Elements

2.4 TOGAF Logical and Physical Components

8 The Open Group Guide (2022)

2.5 TOGAF Architecture Level and Architecture Partitions

There are three levels:

Architectures are partitioned because:

It is not advisable to map TOGAF logical components to application components in the

10 The Open Group Guide (2022)

TOGAF Standard ArchiMate Specification ArchiMate Layer

Conceptual Business Information Business Object Business

Logical Logical Data Component Data Object Application

Physical Physical Data Component Artifact Technology

This yields the picture shown in Figure 7.

2.7 Modeling using ArchiMate Concepts for TOGAF Artifacts

12 The Open Group Guide (2022)

3.1 Using Different Relationship Types

3.2 Generic Language Structure