The ArchiMate metamodel

This article introduces a complete, navigable and clickable representation of the ArchiMate metamodel standard. The model is created using UML. This is not because I wanted to translate ArchiMate into UML, but because UML should be well-suited to define a language such as ArchiMate in. And after all, also the standard itself defines its metamodel using something that looks like UML. In fact I think the ArchiMate forum should decide to formally specify ArchiMate in UML and “own” the UML profile for tool vendors and other interested parties to keep up.

Metamodelling and ArchiMate

Any language needs a specification. What are the rules? What is the format (its syntax)?

ArchiMate is no different. Its specification is part of the standard, published in document format by the Open Group, of which you can find the latest version here:

• ArchiMate 3.1: http://pubs.opengroup.org/architecture/archimate3-doc/

The language specification consists partly of what ArchiMate calls its metamodel. For language designers the use of this term in the context of ArchiMate is somewhat problematic, because what ArchiMate calls a metamodel should more properly be defined as a class model. Also the lack of a proper metamodel layer in ArchiMate is revealed by the fact that ArchiMate is not specified in itself, but in what should be regarded as a handicapped UML.

Many people, including myself, have argued for ArchiMate to be specified as a UML profile. Unfortunately this has not happened yet.

(OMG is actually working on this, and the effort is well underway, even to the level of MOF definitions, which I was very happy to learn)

The reasons can only be speculated upon, since most of the tool vendors were forced to do exactly that anyway. Language users (i.e. architects) need a “proper” metamodel, but that is much more so for tool builders. In fact I would think that the language designers need this as well because I cannot for the life of me imagine how I would go about working on the next version of the standard without a proper metamodel, accessible through a repository-based representation such as the one introduced here. But anyway.

Probably as a result of this, the language specification is inconsistent, ambiguous and contains several errors. This has improved somewhat in the latest 3.1 version. This article and especially the models will show these problems because the effort of creating the UML models of the standard made these problems explicit.

The goal of this article is to represent the ArchiMate metamodel as published by the Open Group in a slightly improved format, using “correct” UML. Doing that enabled me to:

1. create (better) UML profiles for use in tools (using an XMI version of the metamodel)
2. create much more usable documentation of the standard itself:
   1. clickable ArchiMate concepts, linking to the specification of that concept. For an example, please visit the model, for example the Business Service concept)
   2. diagrams with all defined/allowed relations of a specific ArchiMate concept (for an example, please visit the model, for example the Artefact concept). The standard itself for example provides a table with all allowed relations, containing several errors which are hoped to be corrected soon.
3. create a “one-pager” of the entire metamodel (something Gerben Wierda also did for his book Mastering ArchiMate, on the 2.1 and 3.0.1 version of ArchiMate) or those parts you want to focus on
4. extend the metamodel for specific customers
5. and of course, for this article, detect and document problems (errors, ambiguities or vagueness) in the standard as published 😇

In fact I realised when creating this model that for me as an architect this is an infinitely more usable version of the specification than a stupid thing like a book with pictures.

The metamodel can also be downloaded in XMI format, for you to use in your tool of choice:

• ArchiMate 3.1.xmi (currently under development)

About ArchiMate metamodels

The metamodel for the 3.1 version of the standard is exported in HTML format. To view the metamodel, please use these links:

• ArchiMate 3.1 metamodel (currently under development)

As said earlier, the UML this article refers to should be “correct”. Please let me know if you notice issues. However, a few remarks should be kept in mind:

1. The use of colours is in line with the use in the standard. In 2.1 colours were used, in the 3.x standard shades of grey were used. We tried to comply to the colouring scheme in the standard.
2. Attempts have been made to create diagrams that are in line (mainly the layout) with those in the standard as much as possible. The goal was not to improve ArchiMate, but to detect/repair some of its problems.
3. Multiplicity will be added in the future. As ArchiMate 2.1 states (the 3.x standard is ominously silent on this…), most of the relations are zero or more (* in UML parlance) except where explicitly stated differently. Note that when ArchiMate talks about cardinality, UML (on the class level) talks about multiplicity.
4. The direction of a relation is still not clear. It is clear what it means in ArchiMate, and what it means in UML, but the semantics of direction in ArchiMate are different from those in UML. We stick to the ArchiMate semantics for now, but I think this disparity is one of the big problems in ArchiMate. In my view, direction is about dependencies, but that is not how ArchiMate sees it.
5. In this article, stereotypes (for relations or classes) have not been used. Obviously, if you want to create a UML profile for ArchiMate, this must be done.

The ArchiMate 3.1 metamodel

Work is underway, please be patient.

The ArchiMate 3.0.1 metamodel

For the entire model, please visit ArchiMate 3.0.1 metamodel.

The metamodel for ArchiMate 3.0.1, from a language specification perspective, is an improvement over its predecessor. All concepts have now been defined in the model. The above diagram shows the top-level concepts, the most generic ones, this time also including the relationships. It almost looks like a real metamodel!

Of course in the standard these are just pictures, so my hope is you will find these models useful. If you do, please do not hesitate to like this page using the LinkedIn and Twitter buttons in the top right!

List of detected issues

Below is a summary of the issues that I have stumbled on in making the models. The chapter in the standard is provided so that you can compare what the standard says with my proposed changes. The diagram in my repository is also hyperlinked for your convenience.

The elements hyperlinks do not always work correctly (sorry, this is due to the way the tool generated the HTML report, I am working on correcting this).

ArchiMate 3.0.1 issues

“Core Element” and “Element”

There is talk of “Core Element”, but it seems equivalent to what is also referred to as “Element”.

4.1: Behavior and Structure Elements

Notes

1. Diagram Behavior and Structure
2. For completeness I added the Collaboration concept, which is also an abstract class.
3. There is a problem in the standard with the abstract classes External Behavior Element and External Active Structure Element. These classes are nowhere explicitly specialised, for example a Business Service should be an External Behavior Element. I expect these diagrams to be added in the next revision of the standard.

4.2: Specializations of Structure and Behavior Elements

Notes

1. Diagram Specialisations of Core Elements
2. This diagram is not followed through with the specific subclasses of Process, Function and Interaction. Although it would potentially introduce multiple inheritance, these subclasses should be added, for example Business Process as a subclass of Process. Note that multiple inheritance in metamodels is not a problem, but should be avoided in “instance” models. The Business Process/Function/Interaction element is completely equivalent to Business Internal Behavior Element.

5: Relationships

Notes:

1. Diagram Relationships
2. The associations between Relationship and Element show the labels as UML. In the ArchiMate standard (p. 22) these are shown on the other end.
3. ArchiMate does not specify the multiplicity on the other side (related from). We show that an Element can participate in zero or more relations.

8.2: Active Structure Elements

Notes

1. Diagram Business Internal Active Structure Elements
2. The standard does not explicitly specify a generalisation relation between Business Internal Active Structure Element and Internal Active Structure Element. That seems to be an error.

8.3: Behavior Elements

Notes

1. Diagram Business Internal Behaviour Elements
2. One expects this diagram to repeat in the Application and Technology layers. It does not.
3. I have added the generalisation to Internal Behavior Element, which seems to be lacking from the standard.
4. There is a consistency problem with Specialisations of Core Elements diagram. This problem needs to be resolved!

Application Function/Process/Interaction

Notes

1. Diagram Application Function/Process/Interaction
2. This diagram has been added to model the not-really-existing Application Process/Function/Interaction concept properly. As was mentioned with the Business Internal Behavior concept, this concept should be named “Application Internal Behavior” for consistency.

10.1: Technology Layer Metamodel

Notes

1. Diagram Technology
2. As is noted with the concept, the Technology Process/Function/Interaction should be named “Technology Internal Behavior”.

Technology Internal Behavior

Notes

1. Diagram Technology Internal Behaviour
2. This diagram does not occur in the standard. Nowhere in the standard metamodel diagrams a Technology Function, Process or Interaction is shown, but its shared generalisation, incorrectly named Technology Process/Function/Interaction is.

11.1: Physical Elements Metamodel

Notes

1. Diagram Physical
2. In the standard (p. 91) the assignment between Equipment and Technology Process/Function/Interaction is shown explicitly. However since this relation is implied by the already existing one between Node and Technology Process/Function/Interaction in the Technology diagram and thus inherited by Equipment, it is omitted here.
3. The accesses relation between Technology Process/Function/Interaction as shown in the standard (p. 91) is also omitted here, since it is inherited from the same relation between Technology Object and Technology Process/Function/Interaction in the diagram Technology.

12.1: Alignment of Business Layer and lower layers

Notes

Quite a few problems with this metamodel in the standard (p. 96).

1. Diagrams Relationships between Business Layer and Application Layer Elements, and Relationships between Business Layer and Technology Layer Elements
2. The Business Actor/Role element should be the Business Internal Active Structure Element since also a Business Collaboration can use an Application Service. We have put the correct element in this diagram.

13.1: Implementation and Migration Elements Metamodel

Notes

1. Diagram Implementation and Migration
2. The accesses relation between Implementation Event and Deliverable as shown in the standard (p. 99) is omitted here since it is inherited from the one between Event and Passive Structure Element as shown in this diagram.
3. Same thing for all the trigger/flows between Event subclasses.

13.4: Cross-Aspect Dependencies

Notes

1. Diagram Relationships of Motivation Elements with Implementation and Migration Elements
2. Because of the realization relationship between Composite Element and Deliverable the same kind of relation is superfluous in the other diagram between Deliverable and Plateau.