ArchiMate core - Viewpoints

Bas van Gils & Sven van Dijk
Posted by Bas van Gils & Sven van Dijk on Jun 25, 2012

Enterprise Architecture, ArchiMate

Welcome to our blog. This is an archived post, most of our knowledge and advice remain valid but some material or links may be outdated. Click here to see our most recent posts.

In this series on ArchiMate we have so far focused on the fundamentals of the language, and on tailoring it for use in your own organization. In the course of this series, we have touched upon the subject of using ArchiMate to communicate with various stakeholders in the organization. This is the main subject of this posting.


Views and viewpoints

Chapter 8 of the ArchiMate specification covers the viewpoint mechanism of ArchiMate. The rationale is fairly straightforward: different stakeholders have different concerns and therefore we must make different (kinds) of views for each stakeholder. The following diagram – taken from the specification – illustrates how this works:


The diagram shows that key stakeholders may have different types of concerns (pertaining to designing, deciding, or just to be informed) and therefore views addressing these concerns need different levels of detail. So far so good, but there is a second factor that determines what view works best for every individual stakeholder: communication styles / preferences.

Communication styles and preferences

It is a well-known fact that not everyone likes diagrams, and not everyone likes text. The group of people who like diagrams can be even further divided into sub-groups when we consider whether diagrams should be formal or informal and so on. (Note: for those interested in reading more on this subject consider getting a copy of Dan Roam’s book called “The back of the napkin, solving problems and selling ideas with pictures”). Two examples illustrate this, all within the context of ArchiMate.

The figure on the left shows how business objects are interrelated, and how they align with business functions. The mapping to business functions is made using colors. The figure on the right shows the same information, but now in a tabular form where a green cell indicates that an object is related to some function.

In this case both options are graphical. Both are based on ArchiMate modeling using BiZZdesign Architect. However, the left version shows graphical relations whereas the right one uses different visualizations and graphical composition (for one client we made a new viewpoint definition that automatically changes the shapes of the symbols, making it easy to go back and forth between the two types of visualization).

The modeling process

The extent to which models are effective against the intended goals depends for a great deal on the skills and creativity of the modeler. Using a structured approach in terms of steps to take when setting up models also helps a lot. In this paragraph we list a number of guidelines for the modeling process, before we conclude this posting with some practical tips and tricks. Note that the guidelines in this paragraph focus on creating models. As mentioned in this posting a prominent guideline is to only create a model where a model is the best way to communicate about architecture. If necessary you could use text, matrices or even cartoons instead. Whatever works best to get the message across!

  • Begin with one element. A modeling exercise often has one element playing a central role in the situation. That can for example be a new product or a new service.
  • Add elements in various dimensions. A first step is to break down the central element into components, for example different elements that make up a new product or service. From this point gradually add detail in the various directions of the Archimate framework:
    - Up: Who are the users of the new product and service (internal, external)?
    - Down: How is this product created (processes and IT that realize the product)?
    - Horizontal: What is the relation with other products and services (context)?
  • Check and reiterate: Preliminary versions of a model should always be checked with stakeholders. It is often impossible to work all the ideas and requirements into a model in one go. Also as the model evolves both the architect and the stakeholder will gain more insight in the situation. This often leads to new requirements that should be reflected in the model.
  • Keep in mind that there are some physical limitations for humans to read models. If a model contains more than 30 components it becomes very challenging to gain full understanding. If a model contains many components, use grouping and aggregation to make the model more digestible.
  • For further optimization of models, use general guidelines to reduce visual complexity (grouping, spacing, direction of causal relations from left to right, etc.). Visual aids such as coloring can be used to highlight specific elements in the models. The use of text in the model should adhere to conventions (such as naming conventions).

Tips and tricks

Success with ArchiMate largely depends on (a) the quality of the analyses we make, and (b) the quality of the views that we present to stakeholders. Some tips to be successful:

  • Begin with the end in mind: know the audience that you are creating the view for, and what is the message they need to get from the diagram? A good model is a model that answers the questions asked and is presented in a communicable way.
  • Take the time to think about what type of view is necessary: do we want text? Picture? Formal? Informal? It is quite normal to take a few hours to figure this out.
  • When making a view for a group of stakeholders: as soon as the view becomes too complex, consider making several views to get the point across.
  • Remember that “less is more”. Especially with solid tooling it is easy to put more and more information on a view, which may not always make it better in practice.
  • If you decide to go with an informal napkin sketch that captures the key point from a formal ArchiMate analysis: make sure to also give your stakeholders the formal ArchiMate model: they have a right to know you did your homework!

A lot more can be said about creating effective views. If you have any questions or tips and tricks you wish to share: let us know!

More information

If you’d like to know more, please leave a comment. The next post in this series covers common modeling patterns in ArchiMate. It is scheduled to be posted on the 9th of July.

Archimate® and TOGAF® are registered trademarks of the Open Group.



Join 10.000+ others! Get BiZZdesign's latest articles straight
to your inbox. Enter your email address below:


Subscribe to Email Updates

comments powered by Disqus