Using the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 2.0 Modeling Language

®
Using the TOGAF 9.1
Architecture Content
Framework with the
®
ArchiMate 2.0 Modeling
Language

A White Paper by:
Henk Jonkers (Ed.), Iver Band, Dick Quartel, Henry Franken,
Mick Adams, Peter Haviland, and Erik Proper

July 2012

Using the TOGAF® 9.1 ACF with the ArchiMate® 2.0 Modeling Language

Copyright © 2012, 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/bookstore.

ArchiMate®, Jericho Forum®, Making Standards Work®, The Open Group®, TOGAF®, UNIX®, and the “X”®
device are registered trademarks and Boundaryless Information Flow™, DirecNet™, FACE™, and The
Open Group Certification Mark™ are trademarks of The Open Group. All other brands, company, and
product names are used for identification purposes only and may be trademarks that are the sole property of
their respective owners.

Using the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 2.0 Modeling Language
Document No.: W129

Published by The Open Group, July 2012.
Any comments relating to the material contained in this document may be submitted to:
The Open Group, 44 Montgomery St. #960, San Francisco, CA 94104, USA
or by email to:
ogpubs@opengroup.org

www.opengroup.org A White Paper Published by The Open Group 2


Table of Contents

Executive Summary ..............................................................................4

Motivation ............................................................................................5

TOGAF Architecture Content Framework ...........................................6

The ArchiMate Modeling Language .....................................................8

Architecture Principles, Vision, and Requirements.............................13

Business Architecture .........................................................................17

Information Systems Architecture ......................................................26

Technology Architecture.....................................................................31

Conclusion ..........................................................................................34

References ..........................................................................................35

Acknowledgements .............................................................................35

About the Authors ..............................................................................36

About The Open Group ......................................................................37



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

Executive Summary

A thorough comparison of the ArchiMate 2.0 metamodel with the Content Metamodel
from the TOGAF 9.1 Architecture Content Framework reveals that these two Open
Group standards are highly compatible. The ArchiMate 2.0 visual modeling language
is therefore well suited for architecture initiatives guided by the TOGAF 9.1 standard,
and this White Paper provides both theoretical preparation and practical guidance for
users of the ArchiMate language working on such initiatives.

This work supports The Open Group vision of Boundaryless Information Flow by
further enabling the combined use of the TOGAF standard and the ArchiMate
modeling language for consistent representation of architectural information across
diverse organizations, systems, and initiatives.



Motivation
Organizations constantly face new challenges when evolving complex business, application, and technology
portfolios. To meet these challenges, organizations are embracing Enterprise Architecture, a discipline that
requires:

• A comprehensive architecture framework

• An architecture process that is scalable both with respect to the size of organizations and to the different
maturity levels of these organizations

• A formally grounded modeling notation and guidelines for modeling

The Open Group currently maintains two standards related to Enterprise Architecture: the TOGAF® 9.1
standard and the ArchiMate® 2.0 modeling language. An earlier White Paper [2] shows that these two
standards complement each other. This earlier White Paper observes that:

• The TOGAF 9 and ArchiMate 1.0 standards have a firm, common foundation in their use of viewpoints,
and the concept of an underlying common repository of architectural artifacts and models.

• The TOGAF 9 and ArchiMate 1.0 standards complement each other with respect to the definition of an
architecture development process and the definition of an Enterprise Architecture modeling language.

The ArchiMate 1.0 standard chiefly supports modeling of the architectures in Phase B (Business
Architecture), Phase C (Information Systems Architecture), and Phase D (Technology Architecture) in the
TOGAF ADM. The resulting models are used as input for the subsequent ADM phases.

The ArchiMate 2.0 standard builds on the first version with two major extensions. The Motivation extension
supports the TOGAF ADM Preliminary Phase and Phase A (Architecture Vision), as well as the
Requirements Management aspects of each phase. The Implementation & Migration extension supports the
later ADM phases, including Phase E (Opportunities and Solutions), Phase F (Migration Planning), and
Phase G (Implementation Governance).

This White Paper analyzes how the ArchiMate 2.0 standard covers the modeling concepts of the TOGAF
standard as defined in its Architecture Content Framework (ACF). The purpose of this analysis is to:

• Demonstrate in more detail the suitability of the ArchiMate modeling language in combination with the
TOGAF standard, including the added advantages of the ArchiMate 2.0 extensions

• Describe and analyze a mapping from TOGAF concepts to ArchiMate concepts

• Provide practical guidance for users of the ArchiMate language working on architecture initiatives based
on the TOGAF standard

This White Paper shows how individual TOGAF ACF concepts can be represented using the ArchiMate
language. It does not explicitly demonstrate how TOGAF ACF viewpoints can be realized with ArchiMate,
although it provides a sound basis for that work.



TOGAF Architecture Content Framework
One of the six main components of the TOGAF standard is the Architecture Content Framework (ACF),
which is a detailed model of architectural work products, including deliverables, artifacts within deliverables,
and the architecture building blocks that deliverables represent.

The Content Metamodel defines all the types of building blocks that may exist within an architecture and
shows how these building blocks can be described and related to each other.

The TOGAF Content Metamodel consists of a core metamodel and a number of extensions (see Figure 1).
The core metamodel provides a minimum set of architectural content to support traceability across artifacts.
The extensions contain additional metamodel concepts to support more specific or more in-depth modeling.
Since all extension modules are optional, organizations should select from among them during the
Preliminary Phase of the ADM.

Figure 1: TOGAF Content Metamodel Core and Extensions (from [4], Section 34.2.1, Fig. 34-1)

The TOGAF standard further classifies Content Metamodel concepts based on the ADM phase(s) in which
they are primarily used. Figure 2 groups the main Content Metamodel concepts by ADM phase and also
includes two composite content groups: “Architecture Principles, Vision, and Requirements” (orange block)
and “Architecture Realization” (red block).



Figure 2: Overview of the TOGAF Content Metamodel (from [4], Section 34.3.3, Fig. 34-7)



The ArchiMate Modeling Language
The ArchiMate Enterprise Architecture modeling language provides a uniform representation for architecture
descriptions. It offers an integrated architectural approach that describes and visualizes the different
architecture domains and their underlying relationships and dependencies.

Language Structure
The ArchiMate language is based on some general ideas, principles, and assumptions, as illustrated in Figure
3.

Entity Generic concepts
more specific
more generic

Relation

Enterprise architecture
Application Process concepts

Domain- and company-
specific concepts

Figure 3: Structure of the ArchiMate Language (from [1], Section 2.1, Fig. 1)

The language is structured according to the ArchiMate framework, as shown in Figure 4. The structure of
each of the layers (Business, Application, and Technology) is similar, with concepts to describe the aspects’
passive structure (information), behavior, and active structure. For example, within the Application Layer, an
ArchiMate application component is an active structure element that can perform behavior (modeled as
application functions), such as reading from or writing to a data object, which is a passive structure element.

Environment

Business

Application

Technology

Passive Behavior Active
structure structure

Figure 4: The ArchiMate Framework (from [1], Section 2.6, Fig. 4)



ArchiMate 2.0 permits extension (refinement) of concepts through the addition of attributes which are
properties that can take various values.

Business Layer
The Business Layer shows how the business operates, including the main business processes, the actors (or
roles) executing these processes, the system used in the execution of the processes, and the information
(objects) exchanged between the processes. It can be used for purposes such as business strategy
development, risk management, system development, organizational design or restructuring, and process
improvement. Figure 5 summarizes the concepts that the ArchiMate language defines for the Business Layer.

Figure 5: ArchiMate Business Layer Metamodel (based on [1], Chapter 3)

Application Layer
The Application Layer shows the applications or application components, their relationships, and their
functionality. Figure 6 summarizes the concepts that the ArchiMate language defines to model the
Application Layer. Note that the ArchiMate language models the data domain as the passive structure aspect
of the Application Layer (Figure 4), instead of defining a separate Data Architecture as the TOGAF standard
does.

Figure 6: ArchiMate Application Layer Metamodel (based on [1], Chapter 4)



Technology Layer
The Technology Layer shows nodes on which applications are deployed as well as the devices and system
software composing these nodes. Furthermore, it defines networks connecting these nodes and artifacts that
represent the physical deployment of application components or data objects. Figure 7 summarizes the
concepts that the ArchiMate language defines to model the Technology Layer.

Figure 7: ArchiMate Technology Layer Metamodel (based on [1], Chapter 5)

Motivation Extension
The core concepts of the ArchiMate language focus on what could be called the “extensional” aspects of the
enterprise; i.e., its appearance as an operational entity. The Motivation extension covers the “intentional”
aspects – i.e., the business goals, principles, requirements, and other aspects that motivate the design and
operation of the enterprise.

Figure 8 summarizes the concepts of the Motivation extension.

Figure 8: Motivation Extension Metamodel (based on [1], Chapter 10)

The core elements of an architectural description are related to motivational elements via requirements. Goals
and principles have to be translated into requirements before core elements, such as organization (parts),
teams, people, services, processes, and applications, can be assigned to realize them. Figure 9 illustrates how
requirements and constraints are realized by core elements. This White Paper refers generically to the various
types of core elements as “systems”.



Figure 9: Requirements and Constraints are Realized by Core Elements

Implementation & Migration Extension
The Implementation & Migration extension includes concepts for modeling implementation programs and
projects to support program, portfolio, and project management, as well as a plateau concept to support
migration planning. Figure 10 summarizes the implementation and migration concepts, their relationships,
and their relationships with the core concepts.

Figure 10: Implementation & Migration Extension (based on [1], Chapter 11)

Coverage of the ADM Phases
The core concepts mainly support the modeling of the architectures in Phases B, C, and D of the TOGAF
ADM. The Motivation extension adds concepts to support the Preliminary Phase, Phase A (Architecture
Vision), and the Requirements Management phase. The Implementation & Migration extension supports the
late ADM phases: Phase E (Opportunities and Solutions), Phase F (Migration Planning), and Phase G
(Implementation Governance). Figure 11 illustrates the ArchiMate language coverage of the TOGAF ADM.
The remainder of this White Paper demonstrates how users of the ArchiMate language can express the
TOGAF ACF concepts used throughout each of the ADM phases.



Figure 11: Coverage of the TOGAF ADM by the ArchiMate Core and its Extensions (from [1], Section 2.9, Fig. 8)



Architecture Principles, Vision, and Requirements
Figure 12 gives an overview of the Architecture Content Framework (ACF) concepts that support the
Preliminary and Architecture Vision phases of the TOGAF Architecture Development Method (ADM).

Figure 12: TOGAF ACF Concepts for the Preliminary, Architecture Vision, and Implementation & Migration Phases
(fragment from [4], Section 34.3.3, Fig. 34-7)

Each TOGAF ACF concept can be modeled using the ArchiMate language.

Core Concepts
Principle

TOGAF definition ([4], Section 34.5):

A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale
and a measure of importance.

The concept of “principle” in the TOGAF standard can be represented using the concept of “principle” as
defined in the Motivation extension of the ArchiMate language.

The ArchiMate language defines a principle as ([1], Section 10.2.8, Table 26):

A normative property of all systems in a given context, or the way in which they are realized.

The ArchiMate definition is compatible with the TOGAF definition. A “qualitative statement of intent”
(TOGAF) corresponds to the statement of a (qualitative) “normative property” (ArchiMate). This property
should guide the design and evolution of systems or solutions, and thus also their architecture. Guidance
means, ideally, that the intended property is met by the architecture, but exceptions are possible, as
represented by the word “should” in the TOGAF definition.

The “supporting rationale” of a principle in the TOGAF standard can be represented by one or more goals in
the ArchiMate language; a principle typically realizes one or more goals. Alternatively, the ArchiMate
language extension mechanism can be used to model the supporting rationale as an attribute of the principle
concept. The same can be done with the “measure of importance” of a principle in the TOGAF standard,
which can be modeled in the ArchiMate language as an attribute of the principle concept or indirectly as an
attribute of the goal concept.

Relationships:

• In the TOGAF standard, a principle may be associated with all objects. This may be expressed in the
ArchiMate Motivation extension by translating principles into requirements so that core elements such as
services, processes, or applications can be assigned to realize them. The stronger realization relationship
may be used in the ArchiMate language to express that a principle realizes one or more goals, or to
express that a principle is realized by one or more requirements or constraints.



Constraint


An external factor that prevents an organization from pursuing particular approaches to meet its goals. For
example, customer data is not harmonized within the organization, regionally or nationally, constraining the
organization's ability to offer effective customer service.

The ArchiMate language defines a constraint in its Motivation extension ([1], Section 10.2.8, Table 26):

A restriction on the way in which a system is realized.

In order to express TOGAF constraints that do not pertain directly or exclusively to system realization, users
of the ArchiMate language can use the more general requirement concept ([1], Section 10.2.8, Table 26):

A statement of need that must be realized by a system.

In the example within the TOGAF definition above, a hypothetical organization’s ability to deliver customer
service is limited by data that is not harmonized across organizations. Users of the ArchiMate language could
address this situation with requirements for customer service architectures to harmonize the data or
constraints that mandate the realization of systems without data harmonization.

Assumption


A statement of probable fact that has not been fully validated at this stage, due to external constraints. 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.

The ArchiMate language does not explicitly define the assumption concept. However, assumptions can be
added as attributes to any ArchiMate concept using the language extension mechanism.

Requirement


A quantitative statement of business need that must be met by a particular architecture or work package.

The concept of requirement in the TOGAF standard can be represented using the concept of requirement as
defined in the Motivation extension of the ArchiMate language.

The ArchiMate language defines a requirement as ([1], Section 10.2.8, Table 26):

A statement of need that must be realized by a system.

In the Motivation extension of the ArchiMate language, goals are used to represent the intentions of
stakeholders; i.e., what they want to achieve, while abstracting from how this can be done. These goals must
ultimately be realized by systems. Requirements are used to represent the properties that must be met by
some system; i.e., what is needed from the system to realize certain goals. Therefore, goals have to be
translated into requirements.

In the TOGAF Preliminary and Architecture Vision phases, requirements are typically called “business”
requirements, since they define the intended properties of elements in the Enterprise Architecture,
representing the needs of the business. The architecture elements and their properties are ultimately realized
in projects and their work packages.



Relationships:

• In the TOGAF ACF, a requirement may be associated with all objects. This may be expressed in the
ArchiMate Motivation extension with a realization or association relationship. The realization
relationship is used to express that a core or implementation and migration concept realizes some
requirement.

Gap


A statement of difference between two states. Used in the context of gap analysis, where the difference
between the Baseline and Target Architecture is identified.

The concept of “gap” in the TOGAF ACF can be represented using the concept of gap as defined in the
Implementation & Migration extension of the ArchiMate language.

The ArchiMate language defines a gap as ([1], Section 11.2.5, Table 34):

An outcome of a gap analysis between two plateaus.

In the ArchiMate language, a plateau is defined as ([1], Section 11.2.5, Table 34):

A relatively stable state of the architecture that exists during a limited period of time.

Relationships:

• In the TOGAF ACF, a gap may be associated with all objects. This may be expressed in the ArchiMate
Implementation & Migration extension with an association relationship between a gap and any of the
core or motivation concepts.

Work Package


A set of actions identified to achieve one or more objectives for the business. A work package can be a part of
a project, a complete project, or a program.

The ArchiMate Implementation & Migration extension also defines a “work package”.

The ArchiMate language defines a work package as ([1], Section 11.2.5, Table 34):

A series of actions designed to accomplish a unique goal within a specified time.

The ArchiMate language adds the explicit notion of a time constraint to the TOGAF concept. However, since
business objectives are generally time-constrained, the TOGAF concept can be represented by its ArchiMate
counterpart.

Relationships:

• In the TOGAF ACF, a work package may be associated with all objects. In the ArchiMate
Implementation & Migration extension, a realization relationship may be defined between a work
package and any of the following concepts: a deliverable; a Motivation extension requirement, constraint,
principle, or goal; or any core element.



Capability

The TOGAF ACF ([4], Section 34.5) defines capability in the context of work that is focused on achieving
particular business outcomes:

A business-focused outcome that is delivered by the completion of one or more work packages. Using a
capability-based planning approach, change activities can be sequenced and grouped in order to provide
continuous and incremental business value.

The TOGAF Introduction ([4], Section 3.26) provides a complementary definition:

An ability that an organization, person, or system possesses. Capabilities are typically expressed in general
and high-level terms and typically require a combination of organization, people, processes, and technology
to achieve. For example, marketing, customer contact, or outbound telemarketing.

The ArchiMate language defines a grouping relationship as ([1], Section 7.3.1):

The grouping relationship indicates that objects belong together based on some common characteristic.

Based on these definitions, users of the ArchiMate language can model capability using the grouping
relationship to combine relevant ArchiMate core elements. Within the grouping, the core elements represent
the “organization, people, processes, and technology” required to achieve a capability.

Summary
Users of the ArchiMate language can address the TOGAF ACF concepts and relationships that support the
Preliminary and Architecture Vision phases of the TOGAF ADM.

Figure 13: Relating ACF Concepts for the Preliminary, Architecture Vision, and Implementation & Migration Phases to
ArchiMate Extension Concepts

Solid lines indicate direct correspondence between TOGAF ACF and ArchiMate concepts, while dashed
lines indicate related concepts that provide comparable modeling capabilities.



Business Architecture
Business Architecture phase of the TOGAF Architecture Development Method (ADM).

Figure 14: TOGAF ACF Concepts for the Business Architecture Phase (fragment from [4], Section 34.3.3, Fig. 34-7)

Each concept is discussed separately below.

Core Concepts
Organization Unit


A self-contained unit of resources with goals, objectives, and measures. Organizations may include external
parties and business partner organizations.

The concept of organization unit in the TOGAF ACF can be represented using a specialization of the concept
of business actor as defined in the ArchiMate core.

The ArchiMate language defines a business actor as ([1], Section 3.5, Table 1):

An organizational entity that is capable of performing behavior.

Relationships:

• In the TOGAF ACF, an organization unit may be motivated by a driver. In the ArchiMate language, this
may be represented with an association relationship between an assessment1 and a business actor, or as
an association relationship between a stakeholder and a driver.2

• In the TOGAF ACF, an organization unit may decompose another organization unit. In the ArchiMate
language, this may be expressed with a composition relationship between business actors.

1
The ArchiMate language defines an assessment as the outcome of some analysis of some driver ([1], Section 10.2.8, Table 26).
2
The ArchiMate language defines a driver as something that creates, motivates, and fuels the change in an organization ([1], Section 10.2.8. Table 26).



Actor


A person, organization, or system that has a role that initiates or interacts with activities; for 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.

The concept of “actor” in the TOGAF ACF can be represented using the concept of “business actor” as
defined in the ArchiMate core.

The ArchiMate language defines a business actor as ([1], Section 3.5, Table 1):

An organizational entity that is capable of performing behavior.

Non-human actors (technical systems) may be represented by using the ArchiMate concept of application
component, which is defined as ([1], Section 4.4, Table 2):

A modular, deployable, and replaceable part of a software system that encapsulates its behavior and data
and exposes these through a set of interfaces.

Relationships:

• In the TOGAF ACF, an actor belongs to an organization unit. In the ArchiMate language, this may be
represented with a composition relationship between business actors. Also, system actors may be
represented by ArchiMate application components.

• In the TOGAF ACF, an actor may consume a (business or information system) service. In the ArchiMate
language, this may be represented by a used by relationship between a (business or application) service
and a business actor or application component.

Role


The usual or expected function of an actor, or the part somebody or something plays in a particular action or
event. An actor may have a number of roles.

The concept of “role” in the TOGAF ACF can be represented using the concept of “business role” as defined
in the ArchiMate core.

The ArchiMate language defines a business role as ([1], Section 3.5, Table 1):

The responsibility for performing specific behavior, to which an actor can be assigned.

Relationships:

• In the TOGAF ACF, a role may be performed by an actor. In the ArchiMate language, this may be
represented with an assignment relationship between a business or project actor and a business role.

• In the TOGAF ACF, a role may decompose another role. In the ArchiMate language, this may be
represented by a composition or aggregation relationship between business roles.



Function


Delivers business capabilities closely aligned to an organization, but not necessarily explicitly governed by
the organization. Also referred to as “business function”.

The concept of “function” in the TOGAF ACF can be addressed using the concept of “business function” as

The ArchiMate language defines a business function as ([1], Section 3.5, Table 1):

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

Users of the ArchiMate language can therefore express the behaviors performed through the execution of
TOGAF business capabilities using ArchiMate business functions.

Relationships:

• In the TOGAF ACF, a function may be owned by an organization unit, and performed by an actor. In the
ArchiMate language, both may be represented with an assignment relationship between a business actor
and a business function.

• In the TOGAF ACF, a function may be realized by a process. Users of the ArchiMate language can
express the significance of a business process to a business function with a used by relationship.

• In the TOGAF ACF, a function may be accessed by a role. In the ArchiMate language, this may be
represented with a used by relationship between a business function and a business role.

• In the TOGAF ACF, a function may be bounded by a business service. Users of the ArchiMate language
can address this relationship with a realization relationship between a business function and a business
service.

• In the TOGAF ACF, a function may decompose or communicate with another function. In the ArchiMate
language, this may be represented with a composition relationship and a flow relationship, respectively.

• In the TOGAF ACF, a function may be decomposed by or orchestrated by a process. In the ArchiMate
language, this may be represented with an aggregation relationship from a business process to a business
function.

Business Service


Supports business capabilities through an explicitly defined interface and is explicitly governed by an
organization.

The concept of “business service” in the TOGAF ACF can be represented using the concept of “business
service” as defined in the ArchiMate core.

The ArchiMate language defines a business service as ([1], Section 3.5, Table 1):

A service that fulfills a business need for a customer (internal or external to the organization).



Relationships:

• In the TOGAF ACF, a business service may be realized by a process. In the ArchiMate language, this
may be represented with a realization relationship between a business process and a business service.

• In the TOGAF ACF, a business service may provide a governed interface to access a function. In the
ArchiMate language, this may be represented with a realization relationship between a business function
and a business service.

• In the TOGAF ACF, a business service may be governed and measured by a contract. In the ArchiMate
language, a service or a collection of services is aggregated into a product together with the contract that
governs its use.

• In the TOGAF ACF, a business service may be owned and governed by an organization unit. In the
ArchiMate language, this may be represented with an association relationship between a business actor
and a business service.

• In the TOGAF ACF, a business service may consume or decompose another business service. In the
ArchiMate language, this may be represented with a used by and a composition relationship between
business services, respectively.

• In the TOGAF ACF, a business service may be tracked against a measure or meet a service quality. In
the ArchiMate language, a measure or service quality may be referenced in the name or description of an
assessment, or added as an attribute of a business service using the language extension mechanism.

Process


A process represents flow of control between or within functions and/or services (depends on the granularity
of definition).

Processes represent a sequence of activities that together achieve a specified outcome, can be decomposed
into sub-processes, and can show operation of a function or service (at next level of detail). Processes may
also be used to link or compose organizations, functions, services, and processes.

The concept of “process” in the TOGAF ACF can be represented using the concept of “business process” as

The ArchiMate language defines a business process as ([1], Section 3.5, Table 1):

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

Applications of both the TOGAF and ArchiMate standards typically only represent the main business
processes and possibly their division into sub-processes. For a detailed description of process flows, with
elements such as detailed activities, their sequencing, parallel or alternative paths, specialized process design
languages and standards such as BPMN [5] are more appropriate.

Relationships:

• In the TOGAF ACF, a process may involve an actor. In the ArchiMate language, this may be represented
with an assignment relationship between a business actor and a business process.

• In the TOGAF ACF, a process may generate and resolve an event. In the ArchiMate language, this may



be represented with a triggering relationship from a business process to an event, or from an event to a
business process, respectively.

• In the TOGAF ACF, a process may decompose another process. In the ArchiMate language, this may be
represented with a composition relationship between business processes.

• In the TOGAF ACF, a process may be guided by a control. TOGAF defines a control ([4], Section 34.5)
as: A decision-making step with accompanying decision logic used to determine execution approach for a
process or to ensure that a process complies with governance criteria. For example, a sign-off control on
the purchase request processing process that checks whether the total value of the request is within the
sign-off limits of the requester, or whether it needs escalating to higher authority.

• Users of the ArchiMate language can express controls as business processes, and describe their decision
logic formally or informally in a user-defined profile attribute. Various decision outcomes can be
represented using ArchiMate junctions ([1], Section 7.3.2), which can also be described with attributes
and specialized, for example, to depict AND or OR logic.

TOGAF Motivation Extension Concepts
Driver


An external or internal condition that motivates the organization to define its goals. An example of an
external driver is a change in regulation or compliance rules which, for example, requires changes to the
way an organization operates; i.e., Sarbanes-Oxley in the US.

The concept of “driver” in the TOGAF ACF can be represented using the concept of “driver” as defined in
the Motivation extension of the ArchiMate language.

The ArchiMate language defines an driver as ([1], Section 10.2.8, Table 26):

Something that creates, motivates, and fuels the change in an organization.

Relationships:

• In the TOGAF ACF, a driver may decompose another driver. In the ArchiMate language, this may be
represented with an aggregation relationship between drivers.

• In the TOGAF ACF, a driver may create a goal. In the ArchiMate language, this may be expressed with
an association relationship between a driver and a goal.

Goal


A high-level statement of intent or direction for an organization. Typically used to measure success of an
organization.

The concept of “goal” in the TOGAF ACF can be represented using the concept of “goal” as defined in the
Motivation extension of the ArchiMate language.

The ArchiMate language defines a goal as ([1], Section 10.2.8, Table 26):

An end state that a stakeholder intends to achieve.



Relationships:

• In the TOGAF ACF, a goal may be created by or address a driver. In the ArchiMate language, this may
be represented with an association relationship between an assessment and a goal and an influence
relationship between a goal and a driver, respectively.

• In the TOGAF ACF, a goal may be realized through an objective. Users of the ArchiMate language can
represent objectives as goals as explained below, and represent the contribution of an objective to a goal
through aggregation, specialization, or contribution relationships between goals.

• In the TOGAF ACF, a goal may decompose another goal. In the ArchiMate language, this may be
represented with an aggregation or composition relationship between goals.

Objective


A time-bounded milestone for an organization used to demonstrate progress towards a goal; for example,
“Increase capacity utilization by 30% by the end of 2009 to support the planned increase in market share”.

The concept of “objective” in the TOGAF ACF can also be represented using the concept of “goal” as
defined in the Motivation extension of the ArchiMate language, because the ArchiMate definition of “goal”
is broader than the TOGAF definition, and also includes measurable objectives as defined in the TOGAF
ACF.

The ArchiMate language defines a goal as ([1], Section 10.2.8, Table 26):

An end state that a stakeholder intends to achieve.

Roughly speaking, the distinction between goal and objective in the TOGAF ACF corresponds to the
distinction between soft goal and hard goal in approaches such as i* and KAOS [6]. In the ArchiMate
language, the language extension mechanism can be used to introduce a “soft/hard” attribute for the goal
concept.

Relationships:

• In the TOGAF ACF, an objective may decompose another objective. In the ArchiMate language, this
may be represented with an aggregation or composition relationship between goals.

TOGAF Governance Extension Concepts
Measure


An indicator or factor that can be tracked, usually on an ongoing basis, to determine success or alignment
with objectives and goals.

Using the ArchiMate language extension mechanism, a measure may be specified as an attribute of any
ArchiMate concept, including that of a goal, which is defined within the ArchiMate Motivation extension.



Contract


An agreement between a service consumer and a service provider that establishes functional and non-
functional parameters for interaction.

The concept of “contract” in the TOGAF ACF can be represented using the concept of “contract” as defined

The ArchiMate language defines a contract as ([1], Section 3.5, Table 1):

A formal or informal specification of an agreement that specifies the rights and obligations associated with a
product.

Relationships:

• In the TOGAF ACF, a contract may govern and measure a business service. In the ArchiMate language,
a service or a collection of services is aggregated into a product, together with the contract that governs
their use.

Service Quality


A preset configuration of non-functional attributes that may be assigned to a service or service contract.

Users of the ArchiMate language can employ the language extension mechanism to include quality attributes
of a business, application, or infrastructure service. Also, the “requirement” concept, as defined in the
Motivation extension of the ArchiMate language, can be used to specify service quality requirements.

TOGAF Process Extension Concepts
Event


An organizational state change that triggers processing events; may originate from inside or outside the
organization, and may be resolved inside or outside the organization.

The concept of “event” in the TOGAF ACF can be represented using the concept of “business event” as

The ArchiMate language defines a business event as ([1], Section 3.5, Table 1):

Something that happens (internally or externally) and influences behavior.

Relationships:

• In the TOGAF ACF, a business event may be resolved by an actor, a process, or a service. In the
ArchiMate language, this may be represented with a triggering relationship from a business event to a
business actor, business process, or business service.

• In the TOGAF ACF, a business event may be generated by an actor or a process. In the ArchiMate
language, this may be represented with a triggering relationship from a business actor or business process
to a business event.



Control


A decision-making step with accompanying decision logic used to determine execution approach for a
process or to ensure that a process complies with governance criteria. For example, a sign-off control on the
purchase request processing process that checks whether the total value of the request is within the sign-off
limits of the requester, or whether it needs escalating to higher authority.

Users of the ArchiMate language can express the behavioral aspect of a TOGAF control using the business
process or business function concepts. Modelers can also express straightforward decision logic using
specialized ArchiMate junctions as explained in Process above, and detailed logic can be expressed in profile
attributes using the ArchiMate language extension mechanism.

Product


Output generated by the business. The business product of the execution of a process.

The concept of “product” in the TOGAF ACF can be represented using the concept of “product” as defined

The ArchiMate language defines a product as ([1], Section 3.5, Table 1):

A coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole
to (internal or external) customers.

Relationships:

• In the TOGAF ACF, a product may be produced by an organization unit or a process. In the ArchiMate
language, this may be expressed with a realization relationship from a business actor or a business
process to a product.

TOGAF Infrastructure Consolidation Extension Concepts
Location


A place where business activity takes place and can be hierarchically decomposed.

The ArchiMate language defines a location as ([1], Section 3.5, Table 1):

A conceptual point or extent in space.

The ArchiMate definition of location clearly includes the TOGAF definition.

Summary
Users of the ArchiMate language can address the TOGAF ACF concepts and relationships that support the
Business Architecture phase of the TOGAF ADM.



Figure 15: Relating TOGAF ACF Business Architecture Core Concepts to ArchiMate Core Concepts

Circles indicate where individual ArchiMate concepts can be used to express multiple TOGAF ACF
concepts, or where individual TOGAF ACF concepts can be expressed by multiple ArchiMate concepts.

Figure 16: Relating TOGAF ACF Business Architecture Extension Concepts to ArchiMate Core and Extension Concepts

Solid lines indicate direct correspondence between TOGAF ACF and ArchiMate concepts, while dashed
lines indicate related concepts that provide comparable modeling capabilities. A circle indicates where an
individual ArchiMate concept can be used to express multiple TOGAF ACF concepts,



Information Systems Architecture
Information Systems Architecture phase of the TOGAF Architecture Development Method (ADM).

Figure 17: TOGAF ACF Concepts for the Information Systems Architecture Phase
(fragment from [4], Section 34.3.3, Fig. 34-7)


Core Concepts
Data Entity


An encapsulation of data that is recognized by a business domain expert as a thing. Logical data entities can
be tied to applications, repositories, and services and may be structured according to implementation
considerations.

The concept of “data entity” in the TOGAF ACF most closely resembles the concept of “data object” as
defined in the ArchiMate core. Specifically, a TOGAF data entity is a high-level data object which as a
whole has meaning to the business, and it groups more specific or implementation-oriented data objects.

The ArchiMate language defines a data object as ([1], Section 4.4, Table 2):

A passive element suitable for automated processing.

Relationships:

• In the TOGAF ACF, a data entity may be processed by a logical application component. This may be
expressed in the ArchiMate language with an access relationship from an application component or
function to a data object.

• In the TOGAF ACF, a data entity may be accessed and updated through a business service. Since this
relationship implies application behavior, users of the ArchiMate language can address this situation by
modeling an application service or an application function that accesses a data object, and is also used by
a business service. Users of the ArchiMate language may also specialize the access relationship to denote
write access.

• In the TOGAF ACF, a data entity may relate to another data entity. This can be expressed in the



ArchiMate language with an association relationship between data objects.

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.

The concept of “logical application component” in the TOGAF ACF can be represented using the
“application component” as defined in the ArchiMate core.

The ArchiMate language defines an application component as ([1], Section 4.4, Table 2):

A modular, deployable, and replaceable part of a software system that encapsulates its behavior and data
and exposes these through a set of interfaces.

Relationships:

• In the TOGAF ACF, a logical application component may be realized by a physical application
component. The ArchiMate equivalent of this is a realization relationship from an artifact to an
application component.

• In the TOGAF ACF, a logical application component may decompose another application component, or
communicate with another application component. This can be expressed in the ArchiMate language with
a composition relationship and a flow relationship between application components, respectively.

TOGAF Data Extension Concepts
Logical Data Component


A boundary zone that encapsulates related data entities to form a logical location to be held; for example,
external procurement information.

The concept of “logical data component” in the TOGAF ACF is most closely related to the concept of “data
object” as defined in the ArchiMate core.

The ArchiMate language defines a data object as ([1], Section 4.4, Table 2):

A passive element suitable for automated processing.

Relationships:

• In the TOGAF ACF, a logical data component resides within a data entity. If a user of the ArchiMate
language considers both the data entity and the logical data component to be the equivalent of a data
object in the ArchiMate language, he can use an aggregation relationship in the ArchiMate language. If
the user considers the data entity to be the equivalent of a business object in the ArchiMate language, he
can use a realization relationship from a data object to a business object to indicate how the TOGAF
logical data component implements the design of the data entity.

• In the TOGAF ACF, a logical data component may be realized by a physical data component. The
ArchiMate equivalent for this is a realization relationship from an artifact to a data object.



Physical Data Component


A boundary zone that encapsulates related data entities to form a physical location to be held. For example,
a purchase order business object, comprising purchase order header and item business object nodes.

The concept of “physical data component” in the TOGAF ACF can be represented by the concept of
“representation’ or a specialization of “artifact” as defined in the ArchiMate core, depending on whether it is
in non-electronic or electronic form.

The ArchiMate language defines a representation as ([1], Section 3.5, Table 1):

A perceptible form of the information carried by a business object.

The ArchiMate language defines an artifact as ([1], Section 5.5, Table 3):

A physical piece of data that is used or produced in a software development process, or by deployment and
operation of a system.

Relationships:

• In the TOGAF ACF, a physical data component may reside within a physical application component. In
the ArchiMate language, this can be represented by an artifact (realizing an application component) that
is composed of another artifact (realizing a data object).

• In the TOGAF ACF, a physical data component may be hosted in a location. This can be represented in
the ArchiMate language by assigning a location to an artifact.

• In the TOGAF ACF, a physical data component may decompose another physical data component. This
can be expressed in the ArchiMate language with a composition relationship between artifacts.

TOGAF Services Extension Concepts
Information System Service


The automated elements of a business service. An information system service may deliver or support part or
all of one or more business services.

The concept of “information system service” in the TOGAF ACF can be represented by the concept of
“application service” as defined in the ArchiMate core.

The ArchiMate language defines a application service as ([1], Section 4.4, Table 2):

A service that exposes automated behavior.

Relationships:

• In the TOGAF ACF, an information system service may be realized through a logical application
component. The ArchiMate equivalent of this is a realization relationship from an application component
or function to an application service.

• In the TOGAF ACF, an information system service is considered to be a fully automated specialization
of a business service. In the ArchiMate language, a used by relationship from an application service to a



business service signifies that the business service is at least partly automated by the application service.

Physical Application Component


An application, application module, application service, or other deployable component of functionality. For
example, a configured and deployed instance of a Commercial Off-The-Shelf (COTS) Enterprise Resource
Planning (ERP) supply chain management application.

The concept of “physical application component” in the TOGAF ACF can be represented by a specialization
of the concept of “artifact” as defined in the ArchiMate core.

The ArchiMate language defines an artifact as ([1], Section 5.5, Table 3):

A physical piece of data that is used or produced in a software development process, or by deployment and
operation of a system.

Relationships:

• In the TOGAF ACF, a physical application component may be hosted in a location. In the ArchiMate
language, this can be expressed by an assignment relationship from a location to a host device or system
software environment and in turn from the host device or environment to an artifact, or a direct
assignment of a location to an artifact.

• In the TOGAF ACF, a physical application component may be realized by a physical technology
component. In the ArchiMate language, this can be modeled with an assignment relationship from a
device or system software environment to an artifact.

• In the TOGAF ACF, a physical application component may decompose another physical application
component. This can be expressed in the ArchiMate language with a composition relationship between
artifacts.

• In the TOGAF ACF, a physical application component may communicate with another physical
application component. In the ArchiMate language, artifacts can realize a number of structural
components at the Application and Technology Layers, such as application components and system
software environments, that can communicate with each other via the flow relationship.

Summary
The data-related concepts of the TOGAF ACF can be addressed with information and data concepts in the
lower two layers of the ArchiMate language, and the mapping of the Application Architecture concepts of the
TOGAF ACF to the ArchiMate language is quite straightforward.



Figure 18: Relating TOGAF ACF Information Systems Architecture Concepts to the ArchiMate Language

Circles indicate where individual ArchiMate concepts can be used to express multiple TOGAF ACF
concepts.



Technology Architecture
Technology Architecture phase of the TOGAF Architecture Development Method (ADM).

Figure 19: TOGAF ACF Concepts for the Technology Architecture Phase (fragment from [4], Section 34.3.3, Fig. 34-7)


Core Concepts
Platform Service


A technical capability required to provide enabling infrastructure that supports the delivery of applications.

The concept of “platform service” in the TOGAF ACF can be represented by the concept of “infrastructure
service” as defined in the ArchiMate core.

The ArchiMate language defines an infrastructure service as ([1], Section 5.5, Table 3):

An externally visible unit of functionality, provided by one or more nodes, exposed through well-defined
interfaces, and meaningful to the environment.

Although the TOGAF ACF does not explicitly define the concept of an infrastructure interface, the existence
of a well-defined interface is implicit in its definition of a platform service.

The ArchiMate language defines an infrastructure interface as ([1], Section 5.5, Table 3):

A point of access where infrastructure services offered by a node can be accessed by other nodes and
application components.

Relationships:

• In the TOGAF ACF, a platform service is supplied by a logical technology component. In the ArchiMate
language, this is modeled as a realization relationship from a node to an infrastructure service.

• In the ArchiMate language, infrastructure services are exposed through an infrastructure interface, which
can be modeled by an assignment relationship.



Physical Technology Component


A specific technology infrastructure product or technology infrastructure product instance. For example, a
particular product version of a Commercial Off-The-Shelf (COTS) solution, or a specific brand and version
of server.

The concept of “physical technology component” in the TOGAF ACF can be represented by the concepts of
“device”, “network”, or “system software” as defined in the ArchiMate core, depending on the specific type
of technology component.

The ArchiMate language defines a device as ([1], Section 5.5, Table 3):

A hardware resource upon which artifacts may be stored or deployed for execution.

The ArchiMate language defines a network as ([1], Section 5.5, Table 3):

A communication medium between two or more devices.

The ArchiMate language defines system software as ([1], Section 5.5, Table 3):

A software environment for specific types of components and objects that are deployed on it in the form of
artifacts.

Relationships:

• In the TOGAF ACF, a physical technology component may be hosted in a location. In the ArchiMate
language, this can be expressed by an assignment relationship from a location to a host device or system
software environment.

• In the TOGAF ACF, a physical technology component may decompose another physical technology
component, and may depend on another physical technology component. This can be modeled in the
ArchiMate language with a composition relationship and a used by relationship, respectively, between
devices, networks, or system software.

Logical Technology Component


An encapsulation of technology infrastructure that is independent of a particular product. A class of
technology product; for example, supply chain management software as part of an Enterprise Resource
Planning (ERP) suite, or a Commercial Off-The-Shelf (COTS) purchase request processing enterprise
service.

The concept of “logical technology component” in the TOGAF ACF is most closely related to the concept of
“node” as defined in the ArchiMate core. In addition to this, the ArchiMate language defines a
“communication path” concept, which represents a logical communication link in the Technology Layer.

The ArchiMate language defines a node as ([1], Section 5.5, Table 3):

A computational resource upon which artifacts may be stored or deployed for execution.

The ArchiMate language defines a communication path as ([1], Section 5.5, Table 3):



A link between two or more nodes, through which these nodes can exchange data.

Relationships:

• In the TOGAF ACF, a logical technology component may be realized by a physical technology
component. ArchiMate allows for a realization relationship between a network and a communication
path, but not between a device or system software environment and a node. However, several other
relationships may apply to this situation, such as composition or aggregation relationships from a node to
a device or system software, or a specialization relationship from a device or system software to a node.

• In the TOGAF ACF, a logical technology component may decompose another logical technology
component, and may depend on another logical technology component. This can be modeled in the
ArchiMate language with a composition relationship and a used by relationship, respectively, between
nodes.

Summary
The TOGAF Content Metamodel and the ArchiMate language share three high-level Technology
Architecture concepts: platform service, logical technology component, and physical technology component.
For the latter two, the Technology Layer of the ArchiMate core provides modelers with the option of
expressing additional information:

At the logical level, the ArchiMate language defines a node, which is a logical grouping of hardware
components (devices) and system software components.

For the connection of nodes, the ArchiMate language provides the concept of a logical communication path,
which may be realized at the physical level by a network.

In the TOGAF ACF, these variants are represented in the Technical Reference Models, rather than the ACF.

Figure 20: Relating TOGAF ACF Technology Architecture Concepts to the ArchiMate Language

Circles indicate where individual TOGAF ACF concepts can be expressed by multiple ArchiMate concepts.



Conclusion
A thorough comparison of the TOGAF Architecture Content Framework and the ArchiMate language shows
that the ArchiMate 2.0 standard aligns well with the TOGAF 9.1 Content Metamodel. Therefore, the
ArchiMate language is very suitable for modeling within architecture initiatives guided by the TOGAF
standard.



References
[1] ArchiMate® 2.0 Specification, Open Group Standard, C118, ISBN: 1-937218-00-3, published by
The Open Group, January 2012; refer to: www.opengroup.org/bookstore/catalog/c118.htm.

[2] TOGAF® 9 and ArchiMate® 1.0, H. Jonkers, E. Proper, M. Turner, White Paper, W191, published
by The Open Group, November 2009; refer to: www.opengroup.org/bookstore/catalog/w191.htm.

[3] Extending Enterprise Architecture Modeling with Business Goals and Requirements,
W. Engelsman, D. Quartel, H. Jonkers, M. van Sinderen, Enterprise Information Systems, Vol. 5,
Issue 1, pp. 9-36, February 2011.

[4] TOGAF® Version 9.1, Open Group Standard, G116, published by The Open Group, December
2011; refer to: www.opengroup.org/bookstore/catalog/g116.htm.

[5] Business Process Model and Notation (BPMN) Specification 2.0, Object Management Group;
refer to: www.omg.org/spec/BPMN/2.0/.

[6] A Goal-Oriented Requirements Modeling Language for Enterprise Architecture, D. Quartel,
W. Engelsman, H. Jonkers, M. van Sinderen, UT Publications, University of Twente, pp. 5-7,
2009.

[7] Architecture Language Reference Manual, R. van Buren (Ed.), ArchiMate Deliverable D2.2.2b,
2004.

Acknowledgements
The authors would like to thank the following individuals for their contribution to this White Paper:

• Michelle van den Berg, Real IRM

• Peter Bryant, Logica

• Marc Lankhorst, Novay



About the Authors
Henk Jonkers (Editor) is a Senior Research Consultant at BiZZdesign. In this capacity, he is involved in the
company’s new developments in the area of Enterprise Architecture and enterprise engineering. He also
participates in multi-party research projects, contributes to training courses, and performs consultancy
assignments. Previously, he worked as a Member of Scientific Staff at Telematica Instituut (currently
Novay), where he was involved in various applied research projects in the areas of business process modeling
and analysis, Enterprise Architecture, service-oriented architecture, and model-driven development. Henk
was one of the main developers of the ArchiMate language and an author of the ArchiMate 1.0 and 2.0
standards, and is actively involved in the activities of the ArchiMate Forum of The Open Group.

Iver Band is the Vice-Chair of The Open Group ArchiMate Forum and an Enterprise Architect at Standard
Insurance Company in Portland, Oregon. Iver chose the TOGAF and ArchiMate standards for his IT
organization, and applies them enthusiastically to his daily responsibilities. He co-developed the examination
content for the ArchiMate 2.0 Certification for People, and contributed to various other aspects of the
ArchiMate 2.0 standard. He is TOGAF 9 Certified, ArchiMate 2 Certified, and a Certified Information
Systems Security Professional.

Dick Quartel is a Senior Research Consultant at BiZZdesign. In this role he contributes to the development
and improvement of BiZZdesign's products and services, is involved in research projects, supervises MSc
students and interns, and performs consultancy assignments. In addition, he is an author of many scientific
and professional publications, and an author of the ArchiMate 2.0 standard. Previously, he worked as a
Senior Researcher at Novay (formerly Telematica Instituut), where he acted as researcher and project
manager and contributed to the definition and acquisition of research projects, and as an Assistant Professor
at the University of Twente in the areas of distributed systems design, protocol design and implementation,
and middleware systems.

Henry Franken is the Managing Director of BiZZdesign, and is Chair of The Open Group ArchiMate
Forum. As Chair of The Open Group ArchiMate Forum, Henry led the development of the ArchiMate 2.0
standard. Henry is a speaker at many conferences and has co-authored several international publications and
Open Group White Papers. Henry is co-founder of the BPM-Forum. At BiZZdesign, Henry is responsible for
research and innovation.

Mick Adams is the chair of The Open Group Value Realization Work Group and an ex-Vice-Chair of The
Open Group Architecture Forum. He is the Chief Business Architect for Ernst & Young within Asia Pacific.
He has worked in a variety of industries including financial services, oil and gas, and the public sector. He is
an Open CA Distinguished Profession Leader within The Open Group Open CA program and is currently
working on the next definition of Business Architecture within The Open Group Architecture Forum.

Peter Haviland is Chief Architect within Ernst & Young's Global Architecture Practice. He has worked
around the world in Australia, Asia, North America, and Europe, working with clients to articulate how
business can better exploit technology, and set up architecture functions for success. Peter is a regular
contributor to various industry knowledge forums and has recently published articles on such topics as value-
centric architecture, risk mitigation via cultural governance, and improving business/IT alignment through
Enterprise Architecture. Peter holds a Bachelor of Mechanical Engineering in Industrial and Aeronautical
Aerodynamics in addition to a number of architecture-related qualifications including Level 3 Open CITS
and TOGAF 9.1.



Erik Proper is a Senior Research Manager at the Public Research Centre – Henri Tudor in Luxembourg,
where he leads the Services-oriented Enterprise Engineering research program. He is also a Professor at the
Radboud University Nijmegen, The Netherlands, where he leads the Theories for Enterprise Engineering
research program. Erik has a mixed background, covering a variety of roles in both academia and industry.
His professional passion is the further development of the field of enterprise engineering and Enterprise
Architecture. His long experience in teaching and coaching a wide variety of people enables him to involve
and engage others in this development. He has co-authored several journal papers, conference publications,
and books. His main research interests include Enterprise Architecture, enterprise engineering, enterprise
modeling, systems theory, business/IT alignment, and conceptual modeling.

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

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

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

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

• Operate the industry’s premier certification service

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


Using the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 2.0 Modeling Language

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (18)

Ähnlich wie Using the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 2.0 Modeling Language

Ähnlich wie Using the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 2.0 Modeling Language (20)

Mehr von Iver Band

Mehr von Iver Band (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Using the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 2.0 Modeling Language