How to draw an ArchiMate diagram

An ArchiMate model can hold hundreds of elements. Nobody draws them all at once. You draw a view: one diagram that shows a part of the model. A good view answers one question for one kind of reader. So before you open a tool, write the question down.

This article follows one example from start to finish: the small clinic from the application layer article. Patients book visits on a web page, and a receptionist books visits for patients who phone. The person who runs the clinic asks: "Which systems does booking a visit depend on, and what stops if the database server fails?"

Next, pick a viewpoint. A viewpoint is the rule for a kind of view: who it is for and which element types it may show. ArchiMate 3.2 defines a set of them. Four cover most first diagrams:

The viewpoints article lists the rest and how to choose. In Archyno you pick the viewpoint when you create an ArchiMate diagram. The palette then lists only the element types that viewpoint allows, with a Show all link for the rest. Layered allows every type.

Write a plain list first. For each element, write its name and its type, grouped by layer. For the clinic's question, the list is short:

• Business: Patient (business actor), Receptionist (business role), Book a visit (business process).
• Application: Online booking page and Reception screen (application interfaces), Appointment booking (application service), Booking system (application component).
• Technology: Database service (technology service), Database server (node).

Leave things out on purpose. The clinic's application layer also has Calendar management, Confirm booking and Appointment data. They are real, but they do not help answer this question. They stay in the model and out of this view. Another view, for another question, can show them.

Name each element the way its readers do. Give behaviour a verb phrase, such as Book a visit. Give structure a noun, such as Booking system. Name a service by what its user gets: Appointment booking, not "Booking API".

Put the business layer at the top, the application layer in the middle and the technology layer at the bottom. The specification does not require this layout, but ArchiMate readers expect it. It also makes most lines point the same way, because lower layers serve the layers above them.

Inside a layer, put each element close to the ones it will connect to. Appointment booking goes right under Book a visit, because it will serve it. Booking system goes right under the service it makes real. Each interface goes under the person who uses it. Then most lines will be short and straight, and no line has to cross a box.

Choose each shape from the element's type, not from taste. Readers use the shape to tell an active element from behaviour or data. Many tools also colour the layers: yellow for business, blue for application, green for technology. The specification does not require colours, but readers know these, and Archyno's editor uses them. The figure at the top of this article is the view after this step.

Now draw the lines. ArchiMate 3.2 lists, in Appendix B of the specification, which relationships may join which two element types. You do not need to learn the table. In a layered view, three relationships do most of the work:

Work from the top down. Who does the business work? Which application services serve it, and through which interfaces? Which component realizes each service? Which technology serves each component?

ZoomSwipe to see the whole diagram →Open full size

The view now answers the question. Book a visit uses Appointment booking. Booking system realizes that service, Database service serves Booking system, and Database server realizes Database service. If the database server fails, the service stops, and both the patients' web page and the receptionist's screen lose it.

One line is a shortcut. Strictly, Booking system is assigned to behaviour that realizes the service, as the application layer article shows. Drawing the realization straight from the component is a derived relationship. It is allowed, and it keeps this view on its question. When you connect two elements in Archyno's editor, it offers only the relationships the 3.2 table allows for that pair.

A line the table allows can still say the wrong thing. Both lines on the left below are allowed. Both are still mistakes.

ZoomSwipe to see the whole diagram →Open full size

Run five checks before you share a view:

1. Every line is allowed. Look up each pair in Appendix B, or let a tool do it. Archyno's editor lists a line the table does not allow in its Issues tab, together with other problems such as an element with no name.
2. Every line is as specific as you know. Association only says "related somehow". If you know that Booking system makes the service real, draw realization.
3. Every line points the right way. Serving points at the user. The left side says that the business process serves the software, which is the wrong way round.
4. Every shape matches its type. A service drawn with square corners reads as a structure element, such as a component.
5. Someone else can read it. Give the view to a person who does not know the model and ask them the question. If they need you to explain the view, change the view.

Give the view a title that says its question, and name its viewpoint. Then readers know what the view shows and what it leaves out on purpose. "Booking: what it depends on (Layered)" tells a reader more than "Clinic overview".

Choose the format by what the reader will do. People who only read the view need an image: SVG for documents and wikis, where it stays sharp, or PNG for slides and chat. People who will change the model in another ArchiMate tool need a model file in The Open Group's exchange format. Archyno exports all of these, and PDF too.

A view goes out of date when the systems change. The article on keeping a model current covers how to keep it true after you share it.

Source: the official ArchiMate 3.2 Specification from The Open Group. The allowed relationships are in its Appendix B.