ArchiMate® 3.0 – Improved Notation and Viewpoints

Jul 1, 2016
Written by
Marc Lankhorst
Marc Lankhorst

ArchiMate® 3.0 – Improved Notation and Viewpoints

In our previous blog, we introduced the new 3.0 version of the ArchiMate standard and outlined some of its improvements. In this blog, we focus on the improvements of the language in the way it is presented: its notation and viewpoints.


The notation of ArchiMate models has been improved in several places. To denote the layer of an element, you may use a letter in the top-left corner as a notational hint to identify a Motivation, Strategy, Business, Application, Technology, Physical, or Implementation & Migration element. In Enterprise Studio you can easily switch this notational cue on and off, simply by clicking in the corner of the object. The model below shows an example of this.

Figure 1. New notational hints for layers.

In Figure 1, you also see another notational change. The assignment relationship now has a directed notation, for example where the business actor ‘Customer’ is assigned to the business role ‘Insurant’. This new notation helps you in the analysis of relationship chains, where this direction plays a role; the old, undirected notation still remains valid, however.

Another improvement is the extra line in the notation for the contract and representation elements, to distinguish these from business object and deliverable, as shown in Figure 2.


Figure 2. New notation for contract and representation.

The UML «stereotype» notation is now the default way to denote specialized concepts as described in the chapter on language customization mechanisms. The model in Figure 3 shows an example in which this notation is used to represent specializations of elements related to decisions and business rules.

Figure 3. Use of stereotyped elements for modeling decisions and rules.


A view on an architecture presents a part of that architecture that addresses a specific set of concerns of one or more stakeholders, in a way that is understandable to these stakeholders. A viewpoint is the way in which you create such a view, i.e., the perspective you use to look at the architecture; a view is what you then see.

This already implies how you typically define a viewpoint in ArchiMate:

  1. Identify which concepts from the language are relevant in addressing your stakeholders’ concerns.
  2. Define how you want to visualize these, so that the resulting representation is understood by these stakeholders. That may of course be in the form of diagrams, but lists of elements (‘catalogs’ in TOGAF-speak) and cross-reference tables (‘matrices’) are other common forms.

Previous versions of the ArchiMate standard included an extensive list of viewpoints that had a normative character. More important than these particular viewpoints, however, is the ability to define viewpoints that fit a particular situation. In version 3.0, this viewpoint mechanism is therefore explained more clearly, and the list of viewpoints has been put in an informative appendix to make it clear that these are only examples, not a normative or exhaustive list. Those of you who took the ArchiMate Foundation exam in the past may remember that you had to study these closely; this is no longer needed for ArchiMate 3.0.

Visualization for Different Stakeholders

It is important to keep in mind that the standard notation of ArchiMate was designed for use by architects and designers. Other user groups may need a completely different depiction. For example, many business managers are less interested in the structure of the architecture itself than in its properties and consequences, such as cost, risk and adaptability. Presenting them with complicated diagrams is not the way to go; rather, dashboards with management information such as those created with the portfolio management functionality of Enterprise Studio provide them with the right insights. But still, these dashboards are rooted in the same model, supporting fact-based decision making on change.