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:

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

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

The design goals for the exchange file format are:

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.

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.

The exchange file format contains model information including:

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

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:

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

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:

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.

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

Example scenarios are:

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.

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

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.

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

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

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.

The ArchiMate 3.1 Specification [1], talks about adding additional attributes to ArchiMate elements and relations:

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

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.

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

Possible data values for these attributes might be:

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.

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

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:

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:

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:

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

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:

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:

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:

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:

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:

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:

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:

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:

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

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":

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

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

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