The Most Useful ArchiMate Diagram Types


ArchiMate is very powerful notation, it provides many elements (concepts) divided into layers and aspects (figure 1 below). There can be lots of diagram types to be used within each layer and aspect. However, most of the cases can be modelled with only small set of diagram types, which can be created with subset of ArchiMate elements. By identifying the most relevant diagram types and related elements, and providing simple examples of each diagram types, an organization can enable a simplified modelling approach. You know, “seeing is believing”, and visualization is the key to mutual understanding…

Figure 1: ArchiMate 3.0.1 Full Framework.

The most useful diagram types are as follows:
1. Motivation View – to define the value and meaning of the development target (with ArchiMate Motivation elements).
2. Layered View – to define all the relevant elements into one overall view (with elements from different layers and aspects)
3. Interaction View – to illustrate information flows between the actors or processes or applications.

With these diagram types, every development target, service etc. can be modeled to provide enough information for decision making and development purposes. These diagram types can be used for analyzing following questions related to certain development target:

  • TO WHOM this is meaningful?
  • WHY this  is important and valuable, why we need this?
  • WHAT exactly needs to be achieved?
  • HOW we can get this, or how to go there?
  • WITH WHAT building blocks this can be implemented? What are the behavioral and structural elements, and how they interact with each other?

These diagram types are related to the Goal-Driven Approach (GDA), which focuses on goals first, before any actions are to be taken. It is important to analyze first, why we actually need something to be changed, what is exactly the problem that needs to be solved, what are the drivers for change, what are the root causes. This analysis helps us to emphasize what is the intrinsic added value of this specific need, condition, state of affairs etc. what we would like to achieve. To start with analyzing why-questions first with the Goals View (inspired by Simon Sinek’s Start With Why -concept), enforces us to first define clearly the actual problem statement more detailed. This means, that every epic, feature or user story should be derived from specific goals. (Requirements for any change actions can be derived from the goals, if defined).

Starting with the goals (why-questions) means, that we first try to identify the root cause(s), the purpose, the inner motivation to do something. The Goals View can be a starting point for each change initiative.

1. Motivation View (Goals View)

This view can be used to define the purpose, value and meaning of a development target. For every demand, it is always important to define the goals for each development target first, before any actions are to be taken. The following questions can be analyzed with the Goals View:

– to whom this development target is meaningful?
– what are the drivers for this, explaining why this is important?
– what are the exact goals we are trying to achieve? What are the change requirements (derived from the goals) that should be realized?

…the reasoning chain follow from stakeholders, drivers and goals to outcomes, principles and finally to requirements. After these analysis with the Goals View, the analysis can continue to strategic actions to be taken, or then to concrete on solutions such as certain capabilities or services etc.

Figure 3: Motivation View – Pattern.

The questions “TO WHOM?” “WHY?” and “WHAT?” can be analyzed with ArchiMate Motivation-layer concepts as follows: Stakeholder, Driver and Assesment, and Goal, Outcome, Principle and Requirement -concepts.

The Goals View, that is composed with ArchiMate Motivation -elements, can be used as a starting point for each and every development case. Then, depending on the case, modelling can continue e.g. to 1) strategy modelling, 2) business modelling or 3) behavior and structure modelling (the architecture building blocks), or any combination of these.

  1. Strategy modelling can be done with ArchiMate strategy concepts Course of Action, Capability and Resource (link).
  2. Business modelling can continue by utilizing e.g. the Business Model Canvas (BMC) view (link).
  3. Behavior and structure modelling can be done by utilizing ArchiMate core-elements (link), the Layered View and Interaction Views for example.

2. Layered View

This is the most useful and valuable ArchiMate diagram, as it combines elements from different layers into one overall view. This diagram can be used for modelling WHAT parts are related to the development target. E.g. what are the customers, which business services and processes are concerned, which application services and applications are supporting the business layer etc. What is the contexts of this specific development target in questions.

Figure 4: Layered view – Overview (Context Diagram).

3. Interaction View (Information Flow Diagram)

This view can be used to define interactions between the elements. This diagram type illustrates the co-operation between the elements: what information is moving to which direction. This view can be applied to several layers with different variations such as:

  • Business Actor Interaction View (figure 5)
  • Business Process Interaction View (figure 6)
  • Application Interaction View (figure 7).

Business Actor Interaction View

Figure 5: Business Actor Co-operation – Pattern.

Business Process Interaction View

Figure 6: Business Process Interaction – Pattern.

Application Interaction View

Figure 7: Integration View / Application Interaction View.

4. Other useful diagram types

Other useful diagram types are as follows:

  • Conceptual Data Model View
  • Data Model View
  • Business Model Canvas (BMC)
  • Service Blueprint
  • Infrastructure / Technology Platform View
  • Process View

More information about these diagram types can be found from the “ArchiMate Cookbook“: link.

More examples can be found from the “ArchiMate Examples” post : link.

4.1 Conceptual Data Model View

In addition to those diagram types mentioned above, there are few other useful diagram types such as conceptual data model. Quite often it is beneficial to analyse what are the basic concepts of the problem domain. The conceptual data model (figure below) can be utilized when the development target consists of special business concepts and specific relations between them. It is valuable to get better understanding WHAT are the core concepts and how they relate with each other. This analysis provides good starting point to further analysis, for instance to model the co-operation diagrams: what information the processes and actors are switching, and with what data the applications interact with each other. As such, the conceptual data model can be one of the very first diagrams to be modelled – after the “goals diagram” of the development target.

Figure 8: Business Objects View (Conceptual Data Model).


ArchiMate is powerful modeling notation, which provides lots of elements for different layers and aspects (as shown in the figure 1 above). However, in practice, ArchiMate can be utilized by using only a subset of elements and only few diagram types to cover the most important aspects of each development target. This applies in most of the cases, no matter of the size or scale of the development target. It can be a new service or application, a business domain area etc.

Latest ArchiMate version 3.x provides catalog of viewpoints (link) with descriptions and elements to be used within each viewpoint. Earlier ArchiMate version 2.x provided viewpoints (link) with example diagrams, which were quite useful (but not very practical) for newbies to get the idea how modelling can support the development. These diagram types introduced here can form the basic foundation of the architecture landscape: 1) Goals View (Vision), 2) Layered View (Overview)  and 3) Interaction Views (Integration). These diagram types (and variations of them) can be modeled per each development target. This continuously adds new content to the architecture repository, as new development targets created or existing ones are modified.

If same kind of diagram types are used with all the services, development targets etc., it keeps the architecture landscape coherent. If all of these diagram types (mentioned above) are used for each case, then the modelling approach is consistent and analogous. And finally, when using specific diagram types for each case for visualization, those cases can be easier to understand, shared and communicated among different stakeholders.

All in all, it depends on the case which diagram type to use: whether to emphasize the business relevance and value, or just pure analysis why the development target is important. However, modelling should be easy task, and therefore such a diagram types should be used which are the most easy to produce and interpret (with available resources and competencies). Finally, it is a matter of taste which diagram best describes all the relevant aspects of development target.