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

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

Copyright © 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:

[email protected]



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.

ProcessApplication

Domain- and company-specific concepts

Enterprise architectureconcepts

Generic concepts

mor

e ge

neric

mor

e sp

ecifi

c

Entity

Relation

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.

Technology

Application

Business

Environment

Passivestructure

Behavior Activestructure

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 Figure 14 gives an overview of the Architecture Content Framework (ACF) concepts that support the 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 defined in the ArchiMate core.

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 defined in the ArchiMate core.

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 in the ArchiMate core.

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 defined in the ArchiMate core.

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 in the ArchiMate core.

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 Figure 17 gives an overview of the Architecture Content Framework (ACF) concepts that support the 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 Figure 19 gives an overview of the Architecture Content Framework (ACF) concepts that support the 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.