Tag: archimate

The ArchiMate metamodel

This article introduces a complete, navigable and clickable representation of the ArchiMate metamodel standard (both the 2.1 and the 3.0.1). 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.

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:

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.

(Note: it seems that 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.0.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.

Note: if your browser does not show the models properly, please refresh your browser cache, since the model is regularly updated.

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

About ArchiMate metamodels

The metamodel for the 2.1 and 3.0.1 version of the standard are exported in HTML format. To view the metamodel, please use these links:

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.0 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.0.1 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 2.1 metamodel

For the entire model, please visit ArchiMate 2.1 metamodel.

Generic Metamodel : Logical Diagram

This is the highest specification of the basic ArchiMate 2.1 concepts. It shows the three “columns”, but not the three layers (Business, Application and Technology) since these are not linked with generic ArchiMate concepts (i.e. there is no such thing as “Technology Layer Element” nor should there be one).

One diagram I added, because it is discussed in the text but not shown in any diagram. It is shown below:

Missing Core Elements : Logical Diagram

The ArchiMate 3.0.1 metamodel

For the entire model, please visit ArchiMate 3.0.1 metamodel.

Top-Level Hierarchy : Logical Diagram
Top-Level Hierarchy : Logical Diagram

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 2.1 issues

For an overview of the issues, please see the repository where all comments can be found. I have focussed for now on the new ArchiMate 3.0 standard, of which the issues are copied from the repository below.

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


  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


  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


  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


  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


  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


  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


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

Technology Internal Behavior


  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


  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


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


  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


  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.


Business-centred ArchiMate


This article attempts to reconcile the ArchiMate modelling language with Business-Centred design principles, principles I strongly advocate.

ArchiMate as a language (or, as some would say, a grammar, since a rigid definition of its semantics does not exist) is very “traditional” in the sense that:

  • it is very IT-centric
  • it explicitly invites the modeller to use a data-centric world view
  • it does not exploit the power of distributed systems (for example as it should be doing with microservices)
  • it has a very familiar but also frightfully traditional layered structure
  • it has never understood the real power of object-orientation

It is my conviction that it is not so much the language that determines the scalability and flexibility of your solutions. But if the language and its usually implicit assumptions about how the world is structured is all you know, it does. So what is important, if you want to reap the benefits of business-centred design and the scalability and flexibility it offers, is to look elsewhere. It is not in the ArchiMate and EA community where you should look, with a very few exceptions (such as Tom Graves and his ilk, usually seen as rogue architects). Maybe we really should expand on the PureArchi idea 😉.

But having adopted this “rogue” world view, not much should prevent you to make models of your solutions using ArchiMate, models that do not distort your axioms too much.

Re-writing ArchiMate

From the standard

This is what the ArchiMate 2.1 standard has to say about Business Models (Chapter 3.2):

The active structure aspect at the business layer refers to the static structure of an organization, in terms of the entities that make up the organization and their relationships. The active entities are the subjects (e.g., business actors or business roles) that perform behavior such as business processes or functions (capabilities). Business actors may be individual persons (e.g., customers or employees), but also groups of people (organization units) and resources that have a permanent (or at least long-term) status within the organizations. Typical examples of the latter are a department and a business unit.

Architectural descriptions focus on structure, which means that the inter-relationships of entities within an organization play an important role. To make this explicit, the concept of business collaboration has been introduced. Business collaborations have been inspired by collaborations as defined in the UML 2.0 standard [7], [10], although the UML collaborations apply to components in the application layer. Also, the ArchiMate business collaboration concept has a strong resemblance to the “community” concept as defined in the RM-ODP Enterprise Language [6], as well as to the “interaction point” concept, defined in Amber [11] as the place where interactions occur.

The concept of business interfaces is introduced to explicitly model the (logical or physical) locations or channels where the services that a role offers to the environment can be accessed. The same service may be offered on a number of different interfaces; e.g., by mail, by telephone, or through the Internet. In contrast to application modeling, it is uncommon in current business layer modeling approaches to recognize the business interface concept.”

The business-centred variant

Now the same text, attempted for a different architectural style: the business-centred one, taking advantage from so-called active objects.

The active structure at the business core refers to the dynamic elements of an organisation. The dynamic, active entities in the model are related to entities in the “real” world usually regarded as passive business objects. The active entities in the real world, the subjects that perform behaviour such as business processes or functions (capabilities) are modelled as passive. These are the actors in the real world, such as individual persons (e.g., customers or employees), but also groups of people (organisation units) and resources that have a permanent (or at least long-term) status within the organisations. These are all modelled as passive objects. Typical examples of the latter are a department and a business unit.

Architectural descriptions focus on behaviour, which means that the inter-relationships of active entities in the model play an important role. These relations reflect the collaborative behaviour of these entities. Examples are accounts, products, invoices, contracts. This collaborative behaviour is modelled in Business Collaborations.

Business-centred ArchiMate

For architectural descriptions to remain intelligible this strategy pays of when our models scale. Behaviour is related to that active structure element in our model which in the “real” world is that which a subject operates upon or works with. Everything related to responsibilities of subjects in the “real” world is allocated in the model to the active structure elements. For example a carpenter works with wood to create a chair. In the model the chair works with a carpenter to create itself. All behaviour needed to make chairs is allocated to the chair by assigning the chair to this behaviour. This makes our models simpler. A chair can only make chairs. A car can only make cars. An insurance product can only make insurance products. And sell insurance products.

All active structure elements in our models must be requested to perform the behaviour they are assigned to. This request is directed towards their interface. The service may be offered on a number of different interfaces. These interfaces are actively employed by the users (clients) of those interfaces: other active structure elements.

Simplified ArchiMate

In fact the three “columns” of traditional ArchiMate are sometimes too convoluted even for “traditional” architects. We could very well do without the “passive” column, certainly for enterprise architecture. But extended models using the traditional approach often run against a wall for actors and roles performing more and more complex behaviour.

The approach above can do the trick. It is also called the Active-Passive Pattern.