A Guide to the ArchiMate® Model

Exchange File Format

The Open Group Guide
Table of Contents
A Guide to the ArchiMate Model Exchange File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
The Open Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
About the Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Referenced Documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Design Goals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. A Specification for Exchange. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3. Exchange versus Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4. Exchange File Format Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2. Use-Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Exporting and Importing Models as a One-Off Exchange Operation . . . . . . . . . . . . . . . . . . . . . . . 12
2.2. Repeated Exporting and Importing Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Round-Trip Exporting and Importing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. Optionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Mandatory Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Graphical Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Properties (Attributes). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2. An Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3. Multi-Language String Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4. Representing Stereotypes and Specialization of Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5. Representing Graphical Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. ArchiMate Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.2. Representing Other Types of Graphical Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Representing Graphical Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. ArchiMate Connections. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2. Representing Other Types of Graphical Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7. Organizations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
7.1. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. XML Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9. XSD Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
 9.1. Basic XML Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10. Testing Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
A Guide to the ArchiMate Model
Exchange File Format
The Open Group Guide

A Guide to the ArchiMate® Model Exchange File Format 1

Copyright © 2015-2020, The Open Group

The Open Group hereby authorizes you to use this document for any purpose, PROVIDED THAT any
copy of this document, or any part thereof, which you make shall retain all copyright and other
proprietary notices contained herein.

This document may contain other proprietary notices and copyright information.

Nothing contained herein shall be construed as conferring by implication, estoppel, or otherwise any
license or right under any patent or trademark of The Open Group or any third party. Except as
expressly provided above, nothing contained herein shall be construed as conferring any license or
right under any copyright of The Open Group.

Note that any product, process, or technology in this document may be the subject of other intellectual
property rights reserved by The Open Group, and may not be licensed hereunder.

This document is provided “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR
IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. Some jurisdictions do not allow the
exclusion of implied warranties, so the above exclusion may not apply to you.

Any publication of The Open Group may include technical inaccuracies or typographical errors.
Changes may be periodically made to these publications; these changes will be incorporated in new
editions of these publications. The Open Group may make improvements and/or changes in the
products and/or the programs described in these publications at any time without notice.

Should any viewer of this document respond with information including feedback data, such as
questions, comments, suggestions, or the like regarding the content of this document, such information
shall be deemed to be non-confidential and The Open Group shall have no obligation of any kind with
respect to such information and shall be free to reproduce, use, disclose, and distribute the
information to others without limitation. Further, The Open Group shall be free to use any ideas,
concepts, know-how, or techniques contained in such information for any purpose whatsoever
including but not limited to developing, manufacturing, and marketing products incorporating such
information.

If you did not obtain this copy through The Open Group, it may not be the latest version. For your
convenience, the latest version of this publication may be downloaded at www.opengroup.org/library.

The Open Group Guide

A Guide to the ArchiMate® Model Exchange File Format
ISBN: 1-947754-51-5
Document Number: G204

Published by The Open Group, March 2020.

Comments relating to the material contained in this document may be submitted to:
The Open Group, Apex Plaza, Forbury Road, Reading, Berkshire, RG1 1AX, United Kingdom
or by electronic mail to: ogspecs@opengroup.org

2 The Open Group Guide (2020-03-02)

Preface The Open Group

Preface
The Open Group
The Open Group is a global consortium that enables the achievement of business objectives through
technology standards. Our diverse membership of more than 700 organizations includes customers,
systems and solutions suppliers, tools vendors, integrators, academics, and consultants across multiple
industries.

The mission of The Open Group is to drive the creation of Boundaryless Information Flow™ achieved
by:

• Working with customers to capture, understand, and address current and emerging requirements,
establish policies, and share best practices

• Working with suppliers, consortia, and standards bodies to develop consensus and facilitate
interoperability, to evolve and integrate specifications and open source technologies

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

• Developing and operating the industry’s premier certification service and encouraging
procurement of certified products

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

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

This Document
This document is a Guide to the ArchiMate Model Exchange File Format. It has been developed and
approved by The Open Group.

The high-level structure of this document is summarized as follows:

• Chapter 1, Introduction includes the objectives and overview, conformance requirements,

normative references, and terminology definitions

• Chapter 2, Use-Cases describes the primary use-case for this version of the exchange file format and
discusses additional use-cases, such as exchange of partial models or updates to existing models

• Chapter 3, Optionality describes optionality in the exchange file format, and the consequences of
that

• Chapter 4, Properties describes a mechanism for defining referenceable property definitions

• Chapter 5, Representing Graphical Nodes describes how graphical nodes are represented

A Guide to the ArchiMate® Model Exchange File Format 3

This Document Preface

• Chapter 6, Representing Graphical Connections describes how graphical connections are

represented

• Chapter 7, Organizations describes how organizations of objects are represented

• Chapter 8, Metadata describes how Dublin Core™ Metadata is represented

• Chapter 9, XSD Schema describes the XSD schema for this version of the exchange file format

• Chapter 10, Testing Resources describes where to find resources for interoperability testing

The audience for this document is developers and users of the ArchiMate Exchange File Format.

4 The Open Group Guide (2020-03-02)

About the Authors

About the Authors

Phil Beauvoir

Phil Beauvoir has been developing, writing, and speaking about software tools and development for
over 30 years. He was Senior Researcher and Developer at Bangor University, and, later, the Institute
for Educational Cybernetics at Bolton University, both in the UK. During this time, he co-developed a
peer-to-peer learning management and groupware system, a suite of software tools for authoring and
delivery of standards-compliant learning objects and metadata, and tooling to create IMS Learning
Design-compliant units of learning. In 2010, working with the Institute for Educational Cybernetics,
Phil created the open source ArchiMate® Modeling Tool, Archi®. Since 2013 he has been curating the
development of Archi independently. Phil holds a degree in Medieval English and Anglo-Saxon
Literature.

Frans Faase

Frans Faase is a Senior Software Engineer at Bond High Performance 3D Technology. He has an MSc
degree in Computer Science from the University of Twente. He was previously at BiZZdesign, where he
was involved in designing the repository being used by BiZZdesign Architect, which implements the
ArchiMate® Standard. He designed a locking mechanism that allows smooth cooperation between
multiple users on a single model. He also worked on many import functions from other tools requiring
reverse engineering, scanning, and parsing of used file formats. Many of these file formats are based
on XML.

Andrew Josey

Andrew Josey is VP Standards and Certification overseeing all certification and testing programs of The
Open Group. He also manages the standards process for The Open Group. Andrew has been closely
involved with the standards development, certification, and testing activities of The Open Group. He
has led many standards development projects including specification and certification development
for the ArchiMate®, TOGAF®, POSIX® and UNIX® programs. Most recently, he has led the
development of the TOGAF Business Architecture Level 1 certification credential and DPBoK
Foundation certification. He has led the automation of The Open Group standards development using a
Git-based automated build toolchain. He is a member of the IEEE, USENIX, and the Association of
Enterprise Architects (AEA). He holds an MSc in Computer Science from University College London.

A Guide to the ArchiMate® Model Exchange File Format 5

 Trademarks

Trademarks
ArchiMate®, DirecNet®, Making Standards Work®, Open O® logo, Open O and Check® Certification
logo, OpenPegasus®, Platform 3.0®, The Open Group®, TOGAF®, UNIX®, UNIXWARE®, and the Open
Brand X® logo are registered trademarks and Agile Architecture Framework™, Boundaryless
Information Flow™, Build with Integrity Buy with Confidence™, Dependability Through Assuredness™,
Digital Practitioner Body of Knowledge™, DPBoK™, EMMM™, FACE™, the FACE™ logo, FBP™, FHIM
Profile Builder™, the FHIM logo, IT4IT™, the IT4IT™ logo, O-AAF™, O-DEF™, O-HERA™, O-PAS™, Open
FAIR™, Open Platform 3.0™, Open Process Automation™, Open Subsurface Data Universe™, Open
Trusted Technology Provider™, O-SDU™, Sensor Integration Simplified™, SOSA™, and the SOSA™ logo
are trademarks of The Open Group.

Archi® is a registered trademark of Phillip Beauvoir.

Dublin Core™ is a protected under common law trademark of the Dublin Core™ Metadata Initiative
with global recognition.

POSIX® is a registered trademark of the IEEE, Inc.

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

6 The Open Group Guide (2020-03-02)

Acknowledgments

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

• Harm Bakker

• Alan Batchelder

• Phil Beauvoir

• Remco de Boer

• Frans Faase

• Sonia Gonzalez

• Andrew Josey

• Jamie Knowles

• Wilbert Kraan

• Erwin Oord

• Samuel Rinnetmäki

• Raina Wissing

• James Yorston

A Guide to the ArchiMate® Model Exchange File Format 7

 Referenced Documents

Referenced Documents
The following documents are referenced in this Guide.

(Please note that the links below are good at the time of writing but cannot be guaranteed for the
future.)

[1] ArchiMate® 3.1 Specification, a standard of The Open Group (C197), November 2019,
published by The Open Group; refer to www.opengroup.org/library/c197

[2] ArchiMate® Model Exchange File Format for the ArchiMate Modeling Language, Version 3.1,
November 2019 (C19C), published by The Open Group; refer to
www.opengroup.org/library/c19c

[3] Dublin Core™ Metadata Element Set, Version 1.1, June 2012, published by the Dublin Core
Metadata Initiative (DCMI); refer to www.dublincore.org/specifications/dublin-core/dces

8 The Open Group Guide (2020-03-02)

Chapter 1. Introduction 1.1. Design Goals

Chapter 1. Introduction

The ArchiMate® Model Exchange File Format is a standard file format that can be used to exchange
ArchiMate models between tools that create or interpret ArchiMate models.

The standard [2] is structured as follows:

• Chapter 1, Introduction, describes the objective, overview, and context for the standard, including
the requirements for conformance

• Chapter 2, Definitions, describes which documents should be referred to for definitions of

terminology used in the standard

• Chapter 3, Requirements, describes the requirements for the exchange file format, which are
intended to be implementation-independent requirements

• Chapter 4, XML/XSD Overview, provides an overview of the XSD and XML structures and their
component parts

• Chapter 5, Model Exchange, describes the core of the exchange file format; that is, the minimum
amount of information required for exchange; this is an implementation-independent description

• Chapter 6, View Exchange, describes the view and viewpoint aspects of the exchange file format;
this is an implementation-independent description

• Chapter 7, Diagram Exchange, describes the visual aspects of the exchange file format; this is an
implementation-independent description

• Chapter 8, Metadata, describes the use of optional metadata in the exchange file format; this is an
implementation-independent description

• Chapter 9, Properties and Attributes, describes the use of properties and attributes of the exchange
file format; this is an implementation-independent description

• Chapter 10, Organizational Information, describes the use of optional organizations and items in
the exchange file format; this is an implementation-independent description

• Appendix A, XML Examples, describes where to find example models in the exchange file format

• Appendix B, Rationale, includes additional information about the contents of the standard and why
features were included or discarded by the standard developers

1.1. Design Goals

The design goals for the exchange file format are:

• Portability: importing and exporting a model file should be software and hardware platform-
independent

• Completeness: it should be possible to represent a model file accurately when moving between

A Guide to the ArchiMate® Model Exchange File Format 9

1.2. A Specification for Exchange Chapter 1. Introduction

tools, as per the concepts and relationships defined in the ArchiMate 3.1 Specification, including
the graphical representation

• Robustness to Errors: it should be possible to detect model file errors reliably

• Interchangeability: any tool conforming to the standard shall be capable of reading all conforming
model files

• Simplicity: developers should be able to implement the exchange file format easily

• Flexibility: future extensions and private additions should be allowed for without compromising
the interchangeability of standard model files

1.2. A Specification for Exchange

The ArchiMate Model Exchange File Format specification describes data structures that can be used to
exchange data between systems that wish to import, export, aggregate, and disaggregate ArchiMate
models. ArchiMate exchange files enable exporting content from one ArchiMate modeling tool or
repository and importing it into another while retaining information describing the model in the file
and how it is structured, such as a list of model elements and relationships. The specification focuses
on the packaging and transportation of ArchiMate models.

1.3. Exchange versus Persistence

The exchange file format is not intended as the definitive representation of an ArchiMate model.
Neither is it intended for use as a persistent file format or as a native file format for tools.

The exchange file format is intended as an intermediate representation, a commonly agreed

representation for exchange; similar to the use of the Esperanto language. It is not the native language
of expression for any one tool, but one that each tool can understand enough to interpret for export
and import. A more successful example is the Comma-Separated Values (CSV) format for exchange
between spreadsheets, databases, etc. – a relatively simple exchange format that is used to
import/export to target applications that then represent the data being exchanged in their own way.

The data contained in the exchange file format is meant to be processed by an “ArchiMate aware” tool,
thus ruling out stand-alone semantic inference. Once the instance data has been imported into an
ArchiMate tool, that tool will probably save it in its own proprietary file format and the exchange file
will be discarded.

1.4. Exchange File Format Overview

The exchange file format contains model information including:

• Concepts of all ArchiMate types

• Relationship details between concepts

• Properties of objects

10 The Open Group Guide (2020-03-02)

Chapter 1. Introduction 1.4. Exchange File Format Overview

• Organization information related to possible organizational structures of objects

• Diagrammatic information

• Metadata to describe the model

A Guide to the ArchiMate® Model Exchange File Format 11

2.1. Exporting and Importing Models as a One-Off Exchange Operation Chapter 2. Use-Cases

Chapter 2. Use-Cases
This chapter describes the primary use-case for this version of the exchange file format and discusses
additional use-cases, such as the exchange of partial models or updates to existing models.

2.1. Exporting and Importing Models as a One-Off Exchange

Operation
The exchange file format is used as a mechanism for exchanging model information from one system
to another.

This is the use-case scenario supported by this version of the ArchiMate Model
NOTE
Exchange File Format standard.

Once the information has been exported from System A and imported into System B, the exchange file
can be seen as dispensable since it has served its purpose.

In this use-case the exchange file format should not be considered as the canonical, or definitive,
model itself, but rather as a simple transport mechanism. There are a number of scenarios in which
this can be used:

• Company X has created a model for Company Y

Both companies are using modeling Tool A. When Company X is ready with the work, the model is
exported into an exchange file and the file is sent by email to Company Y. Company Y imports the
file into Tool A.

• Company X has decided that modeling Tool A no longer meets its requirements and that they will
migrate to Tool B

The models created with Tool A are exported into exchange files and imported into Tool B, after
which Tool A can be decommissioned within Company X. Company X can continue to undertake
work for Company Y even though they now use different tools, since all deliveries of models
between the two companies use the exchange file format.

• Company X has created a reference model with Tool A and wants to distribute it among its
customers and partners

Company X exports the reference model to an exchange file format and publishes this on its
website along with some links to various tools that can be used to import the model.

• Company X provides a cloud solution for showing models on the web

Companies who want to make use of this service create an exchange file from their tool and upload
this to the service of Company X.

12 The Open Group Guide (2020-03-02)

Chapter 2. Use-Cases 2.2. Repeated Exporting and Importing Models

2.2. Repeated Exporting and Importing Models

Exchange files are used to transfer incremental changes made from one system into another system.

This use-case scenario is not supported by this version of the ArchiMate Model
NOTE
Exchange File Format standard.

Each time a transfer is required, an export file is made by the first system and sent to the second
system to be imported. Example scenarios of this are:

• Divisions Q and P of Company X use Tool A for maintaining an up-to-date model of their business
processes

They are required to send updates to the head office. When needed, they create exchange files and
send these to the head office, which imports them into the company-wide model managed by Tool
B.

• Company X created a reference model but because regulations have changed, the model needs to
be updated

Company X publishes the new reference model along with the old reference model on their website
for its customers.

In order to import an incremental update of a model, the importing tool needs some means to
determine the changes. This requires some form of identification of the elements of the model. For
example, the name of the elements could be used, but names could change. As an alternative, the
object’s identifier could be used or a property could be defined, which contains a unique identifier.
Special care has to be taken with how to recognize that concepts or relationships have been removed.

The current exchange file format has no built-in support for incremental updates, and only some
requirements on consistency with respect to concepts that are referred to in relationships. It might be
possible to define a property to indicate that an element or relationship has become obsolete and
needs to be removed. This means that the exporting tool needs to have some capability to track
changes and generate an exchange file with the desired information.

2.3. Round-Trip Exporting and Importing

Exchange files are used to exchange incremental changes in two directions.

This use-case scenario is not supported by this version of the ArchiMate Model
NOTE
Exchange File Format standard.

Example scenarios are:

• Company X is undertaking a modeling project for Company Y, and has to take into account changes

A Guide to the ArchiMate® Model Exchange File Format 13

2.3. Round-Trip Exporting and Importing Chapter 2. Use-Cases

made by Company Y on certain parts of the model

Company Y creates a (partial) export of its model into an exchange file. Company X imports this
exchange file and, after having completed additional changes to the model, exports the updates to
an exchange file. Company Y imports the exchange file to integrate the changes with its existing
model.

• Architect M of Company X wants to work off-line on a large model stored in the repository
managed by Tool A

She creates a partial export to an exchange file and imports this into Tool B. The next day she
creates an exchange file with Tool B and imports this into Tool A.

Round-trip exchange puts some additional requirements on the tools used. The tools need to match
sufficiently, such that the exported concepts and relationships can be recognized from earlier exports.
For this, external identifiers need to be preserved while modifying a model. Also, with respect to the
graphical properties of the models, there should be a good match. For example, in the case when unit
conversion (between metric and imperial units) during import/export is needed, the position and
dimensions may change due to rounding errors, leading to false updates.

14 The Open Group Guide (2020-03-02)

Chapter 3. Optionality 3.1. Mandatory Features

Chapter 3. Optionality
As each ArchiMate tool will support different features and implement them in different ways it may
not be possible to exchange all of the features that are defined in the ArchiMate Exchange File Format,
particularly graphical features. Thus, many features that are supported in the exchange file format are
optional. One consequence of this is that using the ArchiMate Exchange File Format does not and
cannot guarantee lossless “round-tripping” between tools.

Some examples:

• Tool A exports multi-language element names, while Tool B supports only English language strings

In this case, Tool B will ignore any non-English strings in the exchange file when importing.

• Tool A does not support line width for graphical nodes, while Tool B does support line width for
graphical nodes

In this case, Tool A does not export values for node line widths, while Tool B provides a default
value when importing.

Because an ArchiMate tool may not support certain features when importing an ArchiMate exchange
file, a re-export of that same model may or may not contain all of the original features exported from
the originating tool. This is why 100% lossless “round-tripping” between tools is not possible using the
ArchiMate Exchange File Format.

3.1. Mandatory Features

The ArchiMate Exchange File Format declares the following minimum mandatory features for an
exchange file:

• The ArchiMate model container with name and unique identifier

• If the elements tag is present then at least one ArchiMate element with type, name, and unique
identifier

All other features, properties, and attributes are optional. Of course, the usefulness of a model with
minimal features is subjective. At the very least, a model that might be regarded as useful to exchange
between tools would typically contain ArchiMate elements, relationships, and graphical views with
nodes and connections together with their respective names, properties, and graphical features.

3.2. Graphical Features

Typically, an ArchiMate tool will present graphical features such as nodes and connections in its own
way.

For example, Tool A might present a Business Actor node as a “stick man” figure with a label for a

A Guide to the ArchiMate® Model Exchange File Format 15

3.2. Graphical Features Chapter 3. Optionality

name. Tool B might present it as a yellow rectangle with an icon in the top-right corner, and Tool C
might present it as Tool B’s presentation together with a colored fill gradient and a drop shadow.

Because an ArchiMate tool may or may not support the full range of graphical features, the ArchiMate
Exchange File Format does not capture all information on how a node should be presented beyond the
minimum required to sensibly render the node. The minimal mandatory features for an ArchiMate
concept node that can be exchanged (and would typically be supported by all tools) are:

• X and Y coordinates

• Width and height size

• Z-order

• A reference to an existing ArchiMate concept in the model

The ArchiMate Exchange File Format currently provides for exchanging the following optional
graphical features:

• Fill color

• Line color

• Line width

• Opacity

• Font (name, size, bold/italic, and color)

• Nesting

• Connection bend-points and anchor points

• Non-ArchiMate type nodes (notes, labels)

If an importing tool is able to support these additional graphical features then it may choose to use this
information in the presentation of the node. However, this is not required if the importing tool chooses
to present the node in an alternative manner.

16 The Open Group Guide (2020-03-02)

Chapter 4. Properties 4.1. Properties (Attributes)

Chapter 4. Properties
4.1. Properties (Attributes)
The ArchiMate 3.1 Specification [1], talks about adding additional attributes to ArchiMate elements and
relations:

“…users might want to be able to, for example, perform model-based

performance or cost calculations, or to attach supplementary information
(textual, numerical, etc.) to the model elements and relationships. Every
concept in an ArchiMate model can have attributes attached to it.”

— Archimate 3.1 Specification, Section 15.1 “Adding Attributes to ArchiMate Elements and Relationships”

The specification also suggests a method to combine these attributes into sets of “profiles”:

“A profile is a data structure which can be defined separately from the

ArchiMate language but can be dynamically coupled with elements or
relationships; i.e., the user of the language is free to decide whether and when
the assignment of a profile to a model element is necessary.”

— Archimate 3.1 Specification, Section 15.1 “Adding Attributes to ArchiMate Elements and Relationships”

The ArchiMate Exchange File Format supports a mechanism for defining referenceable Property
Definitions that declare Property Name and Property Type. These may be referenced by ArchiMate
concepts and relations (and also by other artefacts, such as the model itself and the graphical nodes
and connections) and given actual values.

The ArchiMate Exchange File Format uses the word “Properties” and “Property”
together with the XML tags properties and property. These can be regarded as
NOTE
“attributes” and “attribute” in ArchiMate terms. This is also to avoid possible confusion
with XML (or similar binding) attributes.

A Guide to the ArchiMate® Model Exchange File Format 17

4.2. An Example Chapter 4. Properties

4.2. An Example
As shown in Table 1, the ArchiMate 3.1 Specification provides an example of a set of attributes for a
“Service Profile”:

Table 1. Attributes for a “Service Profile”

Attribute Type

Fixed Cost Currency

Variable Cost Currency

Service Time Time

Possible data values for these attributes might be:

• Fixed Cost: $5,000

• Variable Cost: $6,000

• Service Time: 09:00:00

The ArchiMate Exchange File Format can represent these attributes and types by the use of Property
Definitions, and references to these with actual Property Values; see Table 2.

Table 2. The Use of Property Definitions

Property ID Property Property Type Property Value

Name

pid-1 Fixed Cost currency $5000

pid-2 Variable Cost currency $6000

pid-3 Service Time time 09:00:00

The three Property Definitions are declared in the XML file as follows:

<propertyDefinitions>
<propertyDefinition identifier="pid-1" type="currency">
<name xml:lang="en">Fixed Cost</name>
</propertyDefinition>
<propertyDefinition identifier="pid-2" type="currency">
<name xml:lang="en">Variable Cost</name>
</propertyDefinition>
<propertyDefinition identifier="pid-3" type="time">
<name xml:lang="en">Service Time</name>
</propertyDefinition>
</propertyDefinitions>

18 The Open Group Guide (2020-03-02)

Chapter 4. Properties 4.2. An Example

The <propertyDefinitions> tag is the container tag for all Property Definition declarations. It occurs
only once. Each Property Definition is declared in a <propertyDefinition> tag together with a unique
identifier, a name, and a type.

Supported data types for the ArchiMate Exchange File Format are:

• string

• boolean

• currency

• date

• time

• number

Once the Property Definitions have been declared they may be referenced and given actual values
within ArchiMate concepts or other objects. For example, the following Business Service element
references the three Property Definitions and adds actual values:

<element identifier="id-e1" xsi:type="BusinessService">

<name xml:lang="en">Provide a Service</name>
<properties>
<property propertyDefinitionRef="pid-1">
<value>$5000</value>
</property>
<property propertyDefinitionRef="pid-2">
<value>$6000</value>
</property>
<property propertyDefinitionRef="pid-3">
<value>09:00:00</value>
</property>
</properties>
</element>

The Property Definitions can of course be referenced by other ArchiMate concepts and other objects
more than once. For example, another Service may contain only one “Fixed Cost” property and yet
contain a different value. In this case it need only reference the required Property Definition and
provide a new instance value:

A Guide to the ArchiMate® Model Exchange File Format 19

4.3. Multi-Language String Values Chapter 4. Properties

<element identifier="id-e2" xsi:type="BusinessService">

<name xml:lang="en">Provide another Service</name>
<properties>
<property propertyDefinitionRef="pid-1">
<value>$100</value>
</property>
</properties>
</element>

Property Definitions can be re-used and referenced as many times as required in the ArchiMate
Exchange File Format.

4.3. Multi-Language String Values

Multi-language string keys and values for Properties are declared by using more than one value
declaration for the given Property with an xml:lang attribute.

For example:

<propertyDefinitions>
<propertyDefinition identifier="pid-4" type="string">
<name xml:lang="en">Comment</name>
<name xml:lang="fr">Commentaire</name>
</propertyDefinition>
</propertyDefinitions>

<element identifier="id-e3" xsi:type="BusinessService">

<label xml:lang="en">Provide another Service</label>
<properties>
<property propertyDefinitionRef="pid-4">
<value xml:lang="en">A comment in English.</value>
<value xml:lang="fr">Un commentaire en français.</value>
</property>
</properties>
</element>

20 The Open Group Guide (2020-03-02)

Chapter 4. Properties 4.4. Representing Stereotypes and Specialization of Concepts

4.4. Representing Stereotypes and Specialization of

Concepts
The ArchiMate 3.1 Specification allows the specialization of elements and relationships, so that new
concepts may be used that derive from existing ArchiMate concepts:

“Specialization is a simple and powerful way to define new elements or

relationships based on the existing ones. Specialized elements inherit the
properties of their generalized elements… A specialized element or
relationship strongly resembles a stereotype as it is used in UML. The
stereotype notation with angled brackets may also be used to denote a
specialized concept. Finally, for a specialized concept, certain attributes may
be predefined, as described in the previous section.”

— ArchiMate 3.1 Specification, Section 15.2 “Specialization of Elements and Relationships”

There is no predefined strategy to represent a specialized concept, stereotype, or profile when

exporting an ArchiMate model using the ArchiMate Exchange File Format, and a future version of the
exchange file format may provide more comprehensive support for these. In the meantime, Properties
may be used to describe the concept. The following is a suggested approach, note that there may be
alternate ways to represent this in the ArchiMate Exchange File Format:

1. Declare a Property Definition:

<propertyDefinitions>
<propertyDefinition identifier="pid-1" type="string">
<name>Stereotype</name>
</propertyDefinition>
</propertyDefinitions>

2. For the specialized element, use an existing ArchiMate concept and add a Property that references
the Property Definition and a value that provides a name for the specialized element or stereotype:

<element identifier="PG_354820954" xsi:type="BusinessEvent">

<name xml:lang="en">Work-Related Safety Incident</name>
<documentation xml:lang="en"></documentation>
<properties>
<property propertyDefinitionRef="propid-0">
<value xml:lang="en">«Threat Event»</value>
</property>
</properties>
</element>

A Guide to the ArchiMate® Model Exchange File Format 21

5.1. ArchiMate Nodes Chapter 5. Representing Graphical Nodes

Chapter 5. Representing Graphical Nodes

5.1. ArchiMate Nodes
In order to represent a graphical node instance of an ArchiMate element in XML, a <node> tag is created
with an elementRef attribute referencing an ArchiMate element that is declared elsewhere in the XML
document.

For example:

1. Declare an <element> tag within the <elements> tag:

<element identifier="id-123" xsi:type="BusinessRole">

<name xml:lang="en">Customer's Bank</name>
</element>

2. Declare a <node> tag within a parent <node> tag, or a parent <view> tag. The elementRef attribute
should have the same value as the identifier attribute of the referenced element. Ensure that the
xsi:type attribute has the value “Element”:

<node identifier="id-3732" elementRef="id-123" xsi:type="Element" x="610" y="360"

w="150" h="120">
<style>
<fillColor r="255" g="255" b="181" a="100" />
<lineColor r="92" g="92" b="92" />
<font name="Segoe UI" size="9">
<color r="0" g="0" b="0" />
</font>
</style>
</node>

5.2. Representing Other Types of Graphical Nodes

In order to represent a graphical node that does not reference an ArchiMate element, such as a group
box, textual note, or label, a <node> tag is created without a reference to an ArchiMate element.

For example, to represent a group type node that contains other nodes:

Declare a <node> tag within a parent <node> tag, or a parent <view> tag. Ensure that the xsi:type
attribute has the value “Container”. Child nodes can be included within the parent node:

22 The Open Group Guide (2020-03-02)

Chapter 5. Representing Graphical Nodes 5.2. Representing Other Types of Graphical Nodes

<node identifier="id-1234" x="120" y="72" w="400" h="140" xsi:type="Container">

<label xml:lang="en">Group</label>
<style>
<fillColor r="210" g="215" b="215" a="100" />
<lineColor r="92" g="92" b="92" a="100" />
<font name="Segoe UI" size="9">
<color r="0" g="0" b="0" />
</font>
</style>
</node>

To represent a “note” or “label” type graphical node:

Declare a <node> tag within a parent <node> tag, or a parent <view> tag. Ensure that the xsi:type
attribute has the value “Label”, and do not include any child nodes:

<node identifier="id-a54f2861-d8d0-4608-8dec-76bdf78c34ed" xsi:type="Label" x="177"

y="264" w="185" h="80">
<label xml:lang="en">Some text</label>
<style>
<fillColor r="255" g="255" b="255" a="100" />
<lineColor r="92" g="92" b="92" a="100" />
<font name="Segoe UI" size="9">
<color r="0" g="0" b="0" />
</font>
</style>
</node>

A Guide to the ArchiMate® Model Exchange File Format 23

6.1. ArchiMate Connections Chapter 6. Representing Graphical Connections

Chapter 6. Representing Graphical Connections

6.1. ArchiMate Connections
In order to represent a graphical connection instance of an ArchiMate relationship in XML, a
<connection> tag is created with a relationshipRef attribute referencing an ArchiMate relationship that
is declared elsewhere in the XML document.

For example:

1. Declare two <element> tags within the <elements> tag:

<element identifier="id-123" xsi:type="BusinessActor">

<name xml:lang="en">Customer</name>
</element>
<element identifier="id-124" xsi:type="BusinessRole">
<name xml:lang="en">Customer Role</name>
</element>

2. Declare a <relationship> tag within the <relationships> tag that references these two elements as
source and target elements:

<relationship identifier="id-125" source="id-123" target="id-124"

xsi:type="Assignment" />

3. Declare two <node> tags within a parent <node> tag, or a parent <view> tag. The elementRef attributes
should have the same values as the identifier attribute of the referenced elements declared above.
Ensure that the xsi:type attributes have the value “Element”:

24 The Open Group Guide (2020-03-02)

Chapter 6. Representing Graphical Connections 6.2. Representing Other Types of Graphical Connections

<node identifier="id-3732" elementRef="id-123" xsi:type="Element" x="610" y="360"

w="150" h="120">
<style>
<fillColor r="255" g="255" b="181" a="100" />
<lineColor r="92" g="92" b="92" />
<font name="Segoe UI" size="9">
<color r="0" g="0" b="0" />
</font>
</style>
</node>
<node identifier="id-3733" elementRef="id-124" xsi:type="Element" x="810" y="380"
w="150" h="120">
<style>
<fillColor r="255" g="255" b="181" a="100" />
<lineColor r="92" g="92" b="92" />
<font name="Segoe UI" size="9">
<color r="0" g="0" b="0" />
</font>
</style>
</node>

4. Declare a <connection> tag within a parent <view> tag. The relationshipRef attribute should have the
same value as the identifier attribute of the referenced relationship. The source attribute should
have the same value as the identifier attribute of the referenced source <node> and the target
attribute should have the same value as the identifier attribute of the referenced target <node>.
Ensure that the xsi:type attribute has the value “Relationship”:

<connection identifier="id-145" relationshipRef="id-125" xsi:type="Relationship"

source="id-3732" target="3733">
<style>
<lineColor r="0" g="0" b="0" />
<font name="Segoe UI" size="9">
<color r="0" g="0" b="0" />
</font>
</style>
</connection>

6.2. Representing Other Types of Graphical Connections

In order to represent a graphical connection that does not reference an ArchiMate relationship, such
as a plain line, a <connection> tag is created without a reference to an ArchiMate relationship.

For example, to represent a line that connects a label node to another node:

A Guide to the ArchiMate® Model Exchange File Format 25

6.2. Representing Other Types of Graphical Connections Chapter 6. Representing Graphical Connections

Declare a <connection> tag within a parent <view> tag. Ensure that the xsi:type attribute has the value
“Line”:

<connection identifier="id-1234" xsi:type="Line" source="id-9876" target="id-8654">

<style>
<lineColor r="0" g="0" b="0" />
<font name="Segoe UI" size="9">
<color r="0" g="0" b="0" />
</font>
</style>
</connection>

26 The Open Group Guide (2020-03-02)

Chapter 7. Organizations 7.1. XML Example

Chapter 7. Organizations
This chapter describes how to represent organizations of objects that are declared within the XML
document. An “organization” may represent a hierarchical tree structure, a table of contents, or a
folder structure in the user interface of an ArchiMate tool, for example.

The use of organizations is entirely optional and may not be supported in some
NOTE
ArchiMate tools or services.

An item tag represents a structural node in a particular organization of the model concepts, views, or
diagram objects. An item tag may be a parent or sibling of other item tags, each one representing a
unique structural node.

An item tag may reference an ArchiMate concept, view, graphical object, or nothing (in which case it is
a structural container).

One or more <organizations> tags may be declared within the XML document. Nested item tags are
included within this.

7.1. XML Example

The following represents a simple folder structure consisting of a folder named “Business”. This folder
contains a reference to an ArchiMate concept with the identifier "id-123" and a sub-folder named
“Business Services” which contains a reference to an ArchiMate concept with the identifier "id-124":

<organizations> ①
<item> ②
<label xml:lang="en">Business</label> ③
<documentation xml:lang="en">Business Folder</documentation> ④
<item identifierRef="id-123" /> ⑤
<item> ⑥
<label xml:lang="en">Business Services</label> ⑦
<item identifierRef="id-124" /> ⑧
</item>
</item>
</organizations>

① The <organizations> main tag.

② An <item> main tag. This does not have an identifierRef attribute so represents a container type
(folder).

③ The <label> tag. This represents the displayed label of the item. In this example it represents the
name of the folder, “Business”.

④ Some optional documentation related to the folder.

A Guide to the ArchiMate® Model Exchange File Format 27

7.1. XML Example Chapter 7. Organizations

⑤ A sub-item referencing an ArchiMate concept declared elsewhere in the XML document.

⑥ A sub-item that represents a sub-folder. This does not have an identifierRef attribute so represents
a container type (folder).

⑦ The <label> tag. This represents the displayed label of the item. In this example it represents the
name of the folder, “Business Services”.

⑧ A sub-item referencing an ArchiMate concept declared elsewhere in the XML document.

28 The Open Group Guide (2020-03-02)

Chapter 8. Metadata

Chapter 8. Metadata
A model may be further described by the use of metadata constituting an optional set of elements that
can be used to describe the model itself. The use of metadata to further describe a model can be useful
to assert such information as publisher, rights and usage, copyright, and licensing.

The exchange file format provides for the inclusion of more than one metadata schema and instance,
to allow for alternative metadata descriptions of the model. If one metadata schema is used, it is
recommended that it is the Dublin Core Metadata Element Set.

The Dublin Core Metadata Element Set consists of 15 metadata elements; see Table 3.

Table 3. The Dublin Core Metadata Element Set

XML tag Description

title A name given to the resource

creator An entity primarily responsible for making the resource

subject The topic of the resource

description An account of the resource

publisher An entity responsible for making the resource available

contributor An entity responsible for making contributions to the resource

date A point or period of time associated with an event in the lifecycle of the
resource

type The nature or genre of the resource

format The file format, physical medium, or dimensions of the resource

identifier An unambiguous reference to the resource within a given context

source A related resource from which the described resource is derived

language A language of the resource

relation A related resource

coverage The spatial or temporal topic of the resource, the spatial applicability of the
resource, or the jurisdiction under which the resource is relevant

rights Information about rights held in and over the resource

Each Dublin Core element is optional and may be repeated. For further information, see [3].

A Guide to the ArchiMate® Model Exchange File Format 29

8.1. XML Example Chapter 8. Metadata

8.1. XML Example

The <metadata> tag is declared in the root element, as in this example:

<metadata> ①
<schema>Dublin Core</schema> ②
<schemaversion>1.1</schemaversion> ③
<dc:title>The Open Group Interoperability Test Snippet 10</dc:title> ④
<dc:creator>The Open Group</dc:creator>
<dc:subject>The Open Group Interoperabillity testing</dc:subject>
<dc:description>A supporting model for the ArchiMate Exchange File
Format</dc:description>
<dc:publisher>The Open Group</dc:publisher>
<dc:contributor>The Open Group</dc:contributor>
<dc:date>November 2019</dc:date>
<dc:format>The Open Group ArchiMate Exchange File Format V3.1</dc:format>
<dc:identifier>3.1-2019-11-15</dc:identifier>
<dc:rights>Copyright The Open Group. See Copyright notice for
permissions.</dc:rights>
</metadata>

① The root tag. This can appear a maximum of once.

② The name of the schema, in this case “Dublin Core”.

③ The schema version, “1.1”.

④ The metadata elements as described above. Each element tag is prefixed with dc: to associate it
with the correct Namespace.

30 The Open Group Guide (2020-03-02)

Chapter 9. XSD Schema 9.1. Basic XML Construction

Chapter 9. XSD Schema

There are three XSD schema files that constitute the exchange file format standard:

1. archimate3_Model.xsd – includes all the concepts in an ArchiMate model (elements and

relationships) as well as organization of those model concepts, and properties and property
definitions. In addition, this file has constructs that can be used to extend the exchange file format
for a non-standard specific purpose.

2. archimate3_View.xsd – includes the concept of a generic view and viewpoint. This file must be
extended to be useful. Extensions could include other artefact types besides diagrams (e.g., catalogs
and matrices). This file includes Model XSD.

3. archimate3_Diagram.xsd – includes all the concepts needed to produce a diagram, which can then
be exchanged through the format. This includes a graphical representation of an element and
relationships as well as some other diagrammatical features. This file includes View XSD.

The schema namespace for this version of the standard is:

www.opengroup.org/xsd/archimate/3.0/

The schema locations for this version of the standard are:

www.opengroup.org/xsd/archimate/3.1/archimate3_Model.xsd

www.opengroup.org/xsd/archimate/3.1/archimate3_View.xsd

www.opengroup.org/xsd/archimate/3.1/archimate3_Diagram.xsd

It is possible to create an XML document that contains no visual information and to reference the first
of the XSD schema files (archimate3_Model.xsd) but typically the diagram schema XSD is referenced as
this contains references to the other two.

9.1. Basic XML Construction

A basic XML document must contain a root model tag, constructed as follows:

<model xmlns="http://www.opengroup.org/xsd/archimate/3.0/" ①
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" ②
xsi:schemaLocation="http://www.opengroup.org/xsd/archimate/3.0/
http://www.opengroup.org/xsd/archimate/3.1/archimate3_Diagram.xsd" ③
identifier="id-1d0ef6fe-f1de-40cc-8509-4b3b641f2ac9"> ④
<name xml:lang="en">Test Model</name> ⑤
</model>

① ArchiMate Exchange File Format Namespace declaration (mandatory)

② Schema declaration (mandatory)

A Guide to the ArchiMate® Model Exchange File Format 31

9.1. Basic XML Construction Chapter 9. XSD Schema

③ Schema location consisting of ArchiMate Exchange File Format Namespace, one or more spaces,
online schema location (mandatory)

④ Unique identifier of the model (mandatory)

⑤ Name of the model (mandatory)

If Dublin Core Metadata is included in the XML document, its schema declaration must also be
included in the root element:

<model xmlns="http://www.opengroup.org/xsd/archimate/3.0/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:dc="http://purl.org/dc/elements/1.1/" ①
xsi:schemaLocation="http://www.opengroup.org/xsd/archimate/3.0/
http://www.opengroup.org/xsd/archimate/3.1/archimate3_Diagram.xsd
http://purl.org/dc/elements/1.1/ http://www.opengroup.org/xsd/archimate/3.1/dc.xsd"
②
identifier="id-1d0ef6fe-f1de-40cc-8509-4b3b641f2ac9">
<name xml:lang="en">Test Model</name>
</model>

① Dublin Core prefix Namespace declaration

② Dublin Core schema location consisting of Dublin Core Namespace, one or more spaces, online
schema location

32 The Open Group Guide (2020-03-02)

Chapter 10. Testing Resources

Chapter 10. Testing Resources

A number of resources are available from The Open Group to assist with testing. These are available
initially from:

www.opengroup.org/xsd/archimate/3.1/examples/

A Guide to the ArchiMate® Model Exchange File Format 33

 Index

Index
A S
archimate3_Diagram.xsd, 31 schema locations, 31
archimate3_Model.xsd, 31
archimate3_View.xsd, 31 T
testing resources, 33
B
basic XML example, 31 U
use-case, 12
D
Dublin Core Metadata, 29 X
XSD schema, 31
G
graphical connections, 24
graphical features, 15
graphical nodes, 22

I
Introduction, 9
Design Goals, 9
Exchange File Format Overview, 10
Exchange versus Persistence, 10
Specification for Exchange, 10

M
mandatory features, 15
metadata, 29
metadata example, 30
multi-language string values, 20

O
one-off exchange, 12
optionality, 15
organizations, 27

P
properties, 17

R
referenceable property definitions, 17
repeated export and import, 13
round-tripping models, 13

34 The Open Group Guide (2020-03-02)