togaf framework and archimate modeling...

TOGAF® Framework and ArchiMate® Modeling Language Harmonization A Practitioner’s Guide to Using the TOGAF® Framework and the ArchiMate® Language

A White Paper by:

William A. Estrem PhD, Metaplexity Associates LLC

Sonia Gonzalez, Dux Diligens

Serge Thorn, Metaplexity Associates LLC

<month>, 2014

A Practitioner’s Guide to Using the TOGAF® Framework and the ArchiMate® Language

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

Copyright © 2014, 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. This White Paper is an informational document and does not form part of the TOGAF documentation set. Readers should note that this document has not been approved through the formal Open Group Standards Process and does not represent the formal consensus of The Open Group Architecture Forum. ArchiMate®, DirecNet®, Jericho Forum®, Making Standards Work®, OpenPegasus®, The Open Group®, TOGAF®, UNIX®, and the Open Brand (“X Device”) are registered trademarks and Boundaryless Information Flow™, Build with Integrity Buy with Confidence™, Dependability Through Assuredness™, FACE™, IT4IT™, Open Platform 3.0™, Open Trusted Technology Provider™, UDEF™, and The Open Group Certification Mark (“Open O”) are trademarks of The Open Group. UML® and Unified Modeling Language® are registered trademarks and BPMN™ and Business Process Modeling Notation™ are trademarks of Object Management Group, Inc. in the United States and/or other countries. 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. TOGAF® Framework and ArchiMate® Modeling Language Harmonization: A Practitioner’s Guide to Using the TOGAF® Framework and the ArchiMate® Language Document No.: Wnnn Published by The Open Group, <month>, 2014. 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

Introduction .................................................................................... 6!

Glossary Harmonization .................................................................. 7!

Content Metamodel Entity Harmonization ...................................... 8!

Content Metamodel Relationships Harmonization ......................... 10!

Viewpoints Harmonization ............................................................ 12!

References ..................................................................................... 14!

Acknowledgements ........................................................................ 14!

About the Authors ......................................................................... 15!

About The Open Group ................................................................. 16!

UnknownField Code ChangedUnknownField Code ChangedUnknownField Code ChangedUnknownField Code ChangedUnknownField Code ChangedUnknownField Code ChangedUnknownField Code ChangedUnknownField Code Changed



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

Executive Summary

The purpose of this guide is to facilitate the combined use the TOGAF® Enterprise Architecture (EA) framework and the ArchiMate® EA modeling language. It contains a summary of three documents that were created by members of Project Harmony (also known as the TOGAF 9.1 Framework and ArchiMate 2.1 Language Harmonization Project). These three documents analyze the two standards in terms of terminology, viewpoints, and metamodels; and provide recommendations on how they can be used together.

TOGAF, an Open Group standard, is an EA framework that can be used to develop and implement enterprise systems, processes, and structures. ArchiMate, an Open Group standard, specifies a modeling language that can be used to create EA descriptions.

The TOGAF standard provides an Architecture Development Method (ADM) as a consistent process for developing and delivering EA artifacts. The TOGAF Architecture Content Framework (ACF) provides a comprehensive set of artifacts and deliverables that can be used create architecture descriptions. The ACF is defined by the Content Metamodel, which describes the entities, their attributes, and the relationships between entities. The artifacts can be catalogs, matrices, or diagrams. In addition, the ACF also provides a set of standard definitions for modeling artifacts and ADM deliverables. Another key feature of the TOGAF standard is a set of glossaries that define standard terminology that is used in architecture activities.

The TOGAF standard is intended to be a general EA framework that can be used to develop a broad range of architectures. It is intended to utilize a variety of modeling



languages and notations. Therefore, the TOGAF standard does not specify the language or languages that can be used for modeling. The practitioner can choose the best tools for describing the architecture; for example, the Unified Modeling Language (UML), Business Process Modeling Notation (BPMN), the ArchiMate modeling language, or any other notation, or combination of notations that is appropriate to the task.

The ArchiMate standard specifies an EA modeling language to support the description, analysis, and visualization of architectures within and across business domains in a clear and unambiguous manner. The ArchiMate language is widely used for developing EA models, usually in conjunction with the TOGAF standard as the reference framework. Even though the TOGAF and ArchiMate standards are intended to be used together for developing EA artifacts, there are some differences between the two standards that may cause confusion when constructing the different views and artifacts. In this context, the Project Harmony team has worked to address these practitioner’s concerns. We offer guidance regarding how to apply the TOGAF standard as a reference framework and the ArchiMate standard as a modeling language and also, in a later second phase, enhance the harmonization of the next versions of the TOGAF standard and the ArchiMate modeling language.

This document presents a summary for the recommendations and guidelines that have been delivered by that project for the initial phase. The use of modeling techniques applying the best practices and aligning EA general concepts with modeling languages such as the ArchiMate language can support a better communication with stakeholders inside and outside organizations, supporting The Open Group vision of: Boundaryless Information Flow™.



Introduction The first phase of Project Harmony has focused on comparing the current versions of each of the standards. This has resulted in the creation of three documents that cover the following topics:

• Glossary harmonization • Content Metamodel Entity and Relationships harmonization • Viewpoints harmonization

This guide summarizes the main findings of the project work.

For further detail refer to the following White Papers:

• TOGAF® Framework and ArchiMate® Modeling Language Harmonization: Glossaries Comparison • TOGAF® Framework and ArchiMate® Modeling Language Harmonization: Content Metamodel

Harmonization: Entities and Relationships • TOGAF® Framework and ArchiMate® Modeling Language Harmonization: Viewpoints Mapping



Glossary Harmonization The TOGAF 9.1 and ArchiMate 2.1 standards work well together and are compatible and complementary for EA development. However, current differences in the terms and definitions may cause confusion for practitioners, especially in cases in which their architecture initiative has been using the terminology that is defined in the TOGAF 9.1 standard and later the decision is taken to formally adopt the ArchiMate modeling language.

Here are some of the conclusions derived from the comparison of the TOGAF and ArchiMate glossaries:

• Some terms from the ArchiMate 2.1 glossary come from the TOGAF 9.1 standard or have a similar connotation. Such terms can easily be used while modeling architecture descriptions using the ArchiMate language and following the TOGAF standard as an EA framework.

• There are some terms used in the ArchiMate 2.1 specification for which there are no corresponding terms in the TOGAF specification.

• There may be issues when the meaning differs between the two standards and the practitioners have to interpret what is best for the organization, which may lead to different approaches for modeling. If the organization is committed to using a business vocabulary based on the TOGAF standard, the models will have to be aligned with it, sometimes slightly changing the set of concepts within and relationships between architecture domains as described in the ArchiMate standard. One of the alternatives would be to use the native ArchiMate concepts and add notes on each model explaining the differences. Another would be to keep the ArchiMate models independent from the TOGAF framework, which could create misunderstanding amongst the stakeholders. A real example is the concept of the Organization/Actor catalog, where Organization does not exist in the ArchiMate language – from an ArchiMate perspective, we could describe the Organization as an Actor and decide that the detailed Actor levels be removed, or we could define several levels of Actors.



Content Metamodel Entity Harmonization The TOGAF and ArchiMate metamodels are very similar, but they do have some significant differences. The TOGAF metamodel provides a single view that encompasses all four of its architecture domains. The entities are defined at a high level that is appropriate for the purposes intended for the EA framework. The ArchiMate specification, as a modeling language, provides a more detailed set of metamodels. It defines a metamodel for each of its layers, as well as its extensions. All of these metamodels are guided by a generic metamodel.

A comparison of the entities between the TOGAF Content Metamodel and the ArchiMate metamodels shows that many of the entities are strongly related to each other. There are some entities where the entity names are the same, but the semantic meanings of entity names are different. There are some TOGAF entities that are modeled using different entities in the ArchiMate standard.

These differences should be taken into account when creating architecture descriptions. However, many of these differences concern the structure of the respective metamodels, and should not inhibit practitioners from applying them together in a coherent and consistent manner.

For example, the ArchiMate language distinguishes between active, passive, and behavioral entities. The relationships in the ArchiMate language are also classified as structural or dynamic. The TOGAF standard does not make these distinctions. The TOGAF standard defines a set of attributes for each entity type. The ArchiMate language does not define attributes for its entities, but provides the profile mechanism for extending model entities to include such attributes.

ArchiMate entities and relationships have a higher level of detail and a more specific notation. ArchiMate concepts and notations can be leveraged for modeling EAs in projects based on the TOGAF standard. The ArchiMate language is focused on the graphical representation of concepts related to the TOGAF standard.

Architecture practitioners need to consider the ramifications of these differences and how they might impact the quality of the architecture descriptions they create. General guidelines and conclusions are presented in the following section.

General Conclusions Derived from the Comparison of TOGAF and ArchiMate Metamodel Entities

There are some entities that are present in the ArchiMate metamodels that do not exist in the TOGAF metamodel and vice versa. In these cases, the mapping of entities between the standards can be performed by either defining attributes (profiling) or through specialization.

For example, in the TOGAF metamodel, entities related to the governance metamodel extension, such as measure and service quality, are not represented in the ArchiMate language. They could be mapped in the ArchiMate language using an attribute assigned to a core element like business service or they could be modeled as a specialization of the contract entity. The service quality entity could be mapped as a service attribute for any of the ArchiMate core concepts, such as a business service that requires a quality of service parameter.

The TOGAF motivation metamodel extension has the objective entity that does not have an exact match in the ArchiMate language. A mapping can be accomplished using a specialization from a goal entity because an objective can be considered as a type of goal.



The TOGAF process modeling metamodel extension has the event, control, and product entities that are not represented exactly in the ArchiMate language. They can be mapped. For example, the event and control entities can be mapped to the ArchiMate trigger entity and the flow dynamic relation. However, the complete meaning of the TOGAF control element has some governance information that needs to be modeled. In this case, it would be necessary to provide additional entity attributes or entity specialization to fully express this relationship in the ArchiMate language.

• The ArchiMate business collaboration and application collaboration entities can be mapped using an actor or application component composition.

• ArchiMate entities like business interface, application interface, and technology interface can be represented in the TOGAF framework as particular kinds of business roles, and application and technology component specializations respectively.

• The ArchiMate infrastructure function entity and also the application function can be mapped as a TOGAF logical technology component or logical application component that performs a specific function. It could also be mapped as a property or attribute of a logical technology or application component that represents the function performed by the component.

• The TOGAF standard refers to logical and physical forms of data, application, and technology components. In the ArchiMate language these abstraction levels are managed using more specific concepts such as a data object for a logical data component and an artifact for a physical data component. Similarly, the ArchiMate node can be mapped to a logical technology component and a device can be mapped to a physical technology component. These mappings can improve the alignment of entities, concepts, and abstraction levels making it easier to accurately model TOGAF architecture descriptions using the ArchiMate language.

Further details regarding these findings and conclusions can be found in the White Paper: TOGAF® Framework and ArchiMate® Modeling Language Harmonization: Content Metamodel Harmonization: Entities and Relationships.



Content Metamodel Relationships Harmonization This part of the document provides some conclusions and analysis of the main differences between TOGAF 9.1 and ArchiMate 2.1 entity relationships and also how the relationships can be mapped.

Relationships in the ArchiMate language have a classification (structural, dynamic, others) and also a specific graphical notation, they can be read from source to target and from target to source with the same conceptual meaning, and can allow derived or indirect relations following a specific set of rules.

On the other hand, relationships in the TOGAF framework are not classified, do not have a specific notation, and do not provide rules regarding how to handle indirect relationships. The main reason for these differences is that the TOGAF standard is not a modeling notation, it is an EA framework, so the relations and entities are more general and the guideline for practitioners is to take them as the basis and apply any notation or modeling language (such as the ArchiMate language).

However, if the TOGAF and ArchiMate standards are used together the following conclusions can be helpful for practitioners.

General Conclusions Derived from the Comparison of TOGAF and ArchiMate Relationships

Due to the fact that the ArchiMate language has fewer relationships (they are classified) they will be taken as the basis for the analysis.

• TOGAF relations that are related with governance such as governs, measures, is governed and measured by, or tracked against do not have exact matches in the ArchiMate language; however, specialization and profiling can be applied for the contract entity. Even though contract is an entity from the Business Layer, it can be applied in other ArchiMate domains and extensions. Also the ArchiMate Implementation and Migration extension can also be applied for governance purposes using the work package entity through special attributes that can be defined for governance, control, and metrics.

• The ArchiMate influence relationship depicts the fact that some motivational element may have a positive or negative influence on another motivational element. The influence relationship does not have a pairing in the TOGAF metamodel; however, additional attributes can be defined for the entities in the ArchiMate Motivation extension to show the positive or negative influences between them.

• The relationships between the TOGAF logical technology component and physical technology component have some slightly different meanings than in the ArchiMate Technology Layer, but can be mapped in order to deliver the architecture descriptions. For example, node could represent the logical technology component and device or system software could represent the physical technology component. The realization relationship that exists between these concepts in the TOGAF standard can be represented using the specialization that the ArchiMate standard defines between a node and device and system software and also as a composition between a device and system software composing a node.

• The ArchiMate aggregation relationship, conceived as a “temporary grouped” concept, cannot be mapped exactly in the TOGAF framework because it only considers the decompose relationship which could not have the same meaning. In this case using aggregation or composition for making the mapping with decompose could be done depending on the context for any particular modeling situation.

• The specialization concept does not exist explicitly in the TOGAF standard; however, the framework



does state that additional taxonomies, classifications, and extensions can be applied to the core metamodel to depict more complex real-life situations.

• The ArchiMate dynamic relationships, like triggering and flow, are not present in the TOGAF standard. The closest mapping could be orchestrates or precedes/follows that are defined only between functions, business services, and processes.

• The ArchiMate access relationship has no direct mapping in the TOGAF standard; however, the consume relationship could map the relationship between a business service and data entity. However, the meaning of the relationship could change depending on the particular modeling situation.

• The ArchiMate uses/used by relationship is not present in the TOGAF standard. The consumes/supplies relationship has similar meaning, but it may not be applicable to all situations. For example, a business service can use a data entity. Similarly, the support relationship between a process and a business service can be mapped with uses/used by or the realization relationship in the ArchiMate language. As previously noted, the mapping would depend on the particular modeling context. This can also be true for the assignment relationship. It can only be mapped using perform task in, operates in, or participates in, even though this example is between an actor and a process rather than a role and a process.

• In the TOGAF standard, there is no realization relationship between a process and a service – the closest mapping might be orchestrates; however, there is a realized by relationship between the service and the process. These details have to be taken into consideration in modeling practical situations.

• TOGAF entities such as principle, constraint, assumption, gap, and requirement are associated with all entities and do not have explicitly defined relationships. The work package entity is related to the capability concept even though there is no specific entity for capability in the TOGAF standard. The ArchiMate Implementation and Migration extension is used for modeling the stages of deployment of an architecture and defines specific relationships between those entities; it also depicts how a work package can be related to any core ArchiMate entity that will deliver capabilities so that the ArchiMate language can provide more specific elements for modeling the transition architectures and their migration roadmap leveraging the TOGAF standard in this way.

Further details regarding these findings and conclusions can be found in the White Paper: TOGAF® Framework and ArchiMate® Modeling Language Harmonization: Content Metamodel Harmonization: Entities and Relationships.



Viewpoints Harmonization The TOGAF and ArchiMate standards provide a set of viewpoints that can be applied for modeling the different architectures.

Even though some of these viewpoints are very similar, there are others in which the mapping is not so straightforward and in some cases viewpoints have to be adapted, complemented, or joined to address stakeholders’ needs.

Is it important to reiterate that the ArchiMate standard is a modeling language and not a framework, and therefore the viewpoint definitions are more detailed and they specify the stakeholders, concerns, level of detail or abstraction level, and also the entity types involved in the viewpoints. In the TOGAF standard this is presented in a more general way (due to the fact that the ArchiMate language is a graphical modeling notation) so sometimes there cannot be a one-to-one mapping between the entities and some interpretation or transformation will be required. Also, the different viewpoints use the entities and relationships that belong to the standard metamodels, so according to the analysis made in the previous sections, the differences between their metamodels and definitions are inherited in a certain way by the viewpoints.

These issues are important to consider while doing the mapping. The following guidelines and conclusions can be helpful while trying to model the TOGAF suggested viewpoints using the ArchiMate language.

Going through the ADM cycle, viewpoints like Solution Concept diagram can be mapped with an ArchiMate Introductory viewpoint or with the Landscape Map viewpoint if modeled at a high level of detail.

For the Business Layer, viewpoints like the Organization Decomposition diagram and artifacts like the Organization/Actor catalog can be mapped with the Organization viewpoint and even with the Actor Co-operation viewpoint even though this viewpoint utilizes entities like business collaborations that do not exist in the TOGAF framework.

Some views can be mapped easily. This is the case for the Business Function viewpoint and the Functional Decomposition diagram and the Business Process viewpoint with the Business Service/Information diagram and the Process Flow diagram, and also with the Value Chain diagram. Another example is the Business Process Co-operation viewpoint and the Event diagram.

In other cases, like the Product viewpoint, it does not have a straightforward match with the TOGAF standard, but it can depict artifacts such as the Process/Event/Control/Product catalog or the Product Lifecycle diagram.

For Phase C, a mapping can be done between the ArchiMate Application Behavior viewpoint and the TOGAF Application Use-case diagram, and an even more exact match can be found between the Application Co-operation viewpoint and the Application Communication diagram and between the Application Structure viewpoint and the Application Interaction matrix and Application Portfolio catalogs (entities and relations present in the views) and with the Software Engineering diagram even though this last one is more focused on application engineering and application development. Other mappings such as the ArchiMate Application Usage viewpoint can be mapped with a TOGAF Process/Application Realization diagram and also with the ArchiMate Service Realization viewpoint because this diagram can also sometimes depict business services realized by applications.



For the information viewpoints, some TOGAF views such as the Data Security diagram, do not have an exact viewpoint correspondence with the ArchiMate language; however, some variations from the ArchiMate Information Structure viewpoint (with additional entities added to the viewpoint) or the Service Realization viewpoint can contain data objects, business objects, and services that can be modeled as security services through specialization. Also, information can be modeled using some of the ArchiMate Technology Layer viewpoints, such as the Infrastructure viewpoint or the Implementation and Deployment viewpoint. Also, the Information Structure viewpoint can be mapped with the TOGAF Conceptual Data diagram. Other TOGAF viewpoints such as, for example, the Data Dissemination diagram, do not have an exact match; however, the stakeholders’ needs addressed by this viewpoint can be depicted in the ArchiMate language using some viewpoint combinations or adaptations for views such as the Service Realization viewpoint, the Information Structure viewpoint, and the Application Usage or Application Co-operation viewpoint.

For Phase D, the mapping between TOGAF and ArchiMate viewpoints can be achieved more easily; for instance, the Infrastructure viewpoint can be mapped with the Processing diagram or the Environments and Locations diagram and others like the ArchiMate Infrastructure Usage viewpoint with the Platform Decomposition diagram and the Implementation and Deployment viewpoint with the TOGAF Networked Computing/Hardware diagram.

For the ArchiMate Motivation extension as well as the Implementation and Migration extension, some mappings can be done. For example, the TOGAF Goal/Objective/Service diagram can be mapped to the ArchiMate Requirements Realization viewpoint. For the ArchiMate Motivation extension the mapping can be easily done between TOGAF catalogs and matrices like objectives, goals, drivers, requirements, and principles because the TOGAF standard has fewer viewpoints than the ArchiMate language for strategic modeling. Regarding the Implementation and Migration, the mappings can be done between the ArchiMate Project viewpoint and the TOGAF Project Context diagram and the Implementation and Migration viewpoint and the Project Context diagram. The ArchiMate Migration viewpoint cannot be easily mapped to TOGAF standard because the TOGAF standard does not have the plateau entity in its metamodel.

For more completed views that comprise entities from several domains or layers, a match can be made between a Business Footprint diagram and an ArchiMate Layered viewpoint.

Here are some of the conclusions derived from the comparison of TOGAF and ArchiMate viewpoints:

• It is important to realize that there must first be an understanding of the terms used in the ArchiMate 2.1 specification and the eventual corresponding terms in the TOGAF specification for considering the viewpoints.

• Even if the description of the viewpoints may look similar between the two standards, there may be differences because the definition of the terms are not equivalent.

• In some cases viewpoints have to be adapted, complemented, or joined to address stakeholders’ needs. • The ArchiMate viewpoints have a standardized representation linked to the use of predefined shapes, but

the TOGAF viewpoints can be built according to various notations’ styles.

Further details regarding these findings and conclusions can be found in the White Paper: TOGAF® Framework and ArchiMate® Modeling Language Harmonization: Viewpoints Mapping.



References • ArchiMate® 2.1 Specification, Open Group Standard (C13L), December 2013, published by The Open

Group; available at www.opengroup.org/bookstore/catalog/c13l.htm. • TOGAF® Framework and ArchiMate® Modeling Language Harmonization: Glossaries Comparison,

White Paper (W14A), August 2014, published by The Open Group; available at: www.opengroup.org/bookstore/catalog/w14a.htm .

• TOGAF® Framework and ArchiMate® Modeling Language Harmonization: Content Metamodel Harmonization: Entities and Relationships , White Paper (W14x), <month> 2014, published by The Open Group; available at: www.opengroup.org/bookstore/w14x.htm.

• TOGAF® Framework and ArchiMate® Modeling Language Harmonization: Viewpoints Mapping, White Paper (W14B), August 2014, published by The Open Group; available at: www.opengroup.org/bookstore/catalog/w14b.htm

• TOGAF® Version 9.1, Enterprise Edition, Open Group Standard (G116), December 2011, published by The Open Group; available at www.opengroup.org/bookstore/catalog/g116.htm.

• Using the TOGAF® 9.1 Architecture Content Framework with the ArchiMate® 2.0 Modeling Language, White Paper (W129), July 2012, published by The Open Group; available at: www.opengroup.org/bookstore/catalog/w129.htm.

Acknowledgements The Authors of the Project Harmony Phase 1 reports would like to acknowledge the contributions and support that they have received from the members who have participated in the project and also to The Open Group staff for their guidance and support.

In particular, we would like to acknowledge: Marc Lankhorst, Henry Franken, Chris Forde, Cathy Fox, Kirk Hansen, Henk Jonkers, Andrew Josey, and Raina Wissing.



About the Authors William A. Estrem PhD is President at Metaplexity Associates LLC. Bill is a long-serving member representative of The Open Group. He was an early contributor to the development of the TOGAF standard and currently provides consulting and education services related to Enterprise Architecture. He holds several Open Group Certifications including: TOGAF® 9 Certified, ArchiMate® 2 Certified, and Open FAIR Foundation. He has served as the Chairman of the Architecture Forum. He is currently serving on the Editorial Board for the Journal of Enterprise Architecture.

Sonia Gonzalez is a Senior Consultant at Dux Diligens. Sonia provides consulting and training services in the areas of business innovation, business process modeling, and Enterprise Architecture. In this position she is involved in the development of new products and services that the company is offering to its customers in Latin America and Spain. She is also TOGAF® 9 Certified and ArchiMate® 2 Certified, and is a trainer for an accredited training course provider and has developed workshops and EA consultancy projects using the TOGAF standard as a reference framework and the ArchiMate standard as a modeling language. As a representative of an Open Group member organization, she is participating in several projects in the Architecture and ArchiMate Forums.

Serge Thorn is an Associate of Metaplexity Associates LLC. He has worked in the IT Industry and Consultancy (Banking-Finance, Biotechnology-Pharma/Chemical, Telcos), for over 30 years, in a variety of roles, which include: Development and Systems Design, Project Management, Business Analysis, IT Operations, IT Management, IT Strategy, Research and Innovation, IT Governance, Project and Portfolio Management, Enterprise Architecture and Service Management (ITIL), Products Development, and Coaching-Mentoring. For 10 years, he has been Chairman of the itSMF (IT Service Management Forum) Swiss chapter, involved with The Open Group Architecture and ArchiMate Forums, chairing the Localization Standing Committee and co-chairing the TOGAF-ArchiMate Harmony Project. He is based in Geneva, Switzerland.



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.

togaf framework and archimate modeling...

Documents