Free ArchiMate 3.2 Overview PDFs in multiple languages

For years, I’ve been distributing ArchiMate Overview PDFs, updated whenever I got around to adapting them after the ArchiMate standard was updated. Generally, the overview sheets are the first thing that is updated when I start to work with a new version of the standard. The current version is from ArchiMate 3.2. They are available in English, French, German, Japanese, Portuguese, and Russian.

My thanks go to the translators: Thomas Bodenmann (German), Alexander Efremov (Russian), Thierry Farescour (French), Yoshiyuki Kishikawa (Japanese), Antonio Carlos Plais do Couto (Portuguese), and Ievgenii Vasiuk (Ukrainian). Give them a thanks (the links are to their LinkedIn pages, you can find mine here in case you want to follow my stuff).

The overview is distributed as full-vector (infinitely scalable, perfectly printable) PDF, in two versions: one in my preferred Mastering ArchiMate colours (colours that are like the absolute original ArchiMate colours, which I think support faster reading, learning and understanding), and one in ‘simple’ layered colours (most widely used these days as most tools use these by default). Colours have no official meaning in ArchiMate by the way, it is all a matter of taste, convention, and what you want in certain cases (e.g. colour all the elements with a lot of technical debt ‘red’). I have found that my scheme (and labeling scheme) helps communicating about them, especially with people who are new to ArchiMate.

Below you find downloads for all versions. Further updates (small typo fixes, things like that, you’re welcome to report issues) will be minimal and silent. The ones with a preview contain all 4 sheets for all 5 languages. Below that: a story of how they were created. Enjoy.

PDFs In Mastering ArchiMate 9-colour scheme

PDFs in ‘simple layered’ colour scheme

PPS. Many architects (I’m one of these) have something with ‘design’ and ‘aesthetics’, which often also shows itself when they work with the notion of ‘elegant’ designs (just like mathematicians like ‘elegant’ proofs, and physicists like ‘elegant’ theories). If you too are into those aspects of design, you might want to study the PDFs in detail (zoom in and look at line hops, how relations attach to elements, typography). And then maybe wonder: “how was this created?”. Look at this from the Portuguese translation:

Notice the triggers from the left, how they are jumped by the orange relations (they are not simply one line plotted over another, but the one ‘below’ actually has holes in it to stress the ‘tunnel’ effect). Notice also how they attach to the true outline of the event, not some ‘bounding box’, like this:

The upper/lower most right relations in my diagram have the same ‘perfect’ attachment. Neat, right? So, how was this one? Well…

The technology that produces these sheets (and the diagrams in the book)

This whole thing got quite out of hand in 2020–2021. It started when I wanted to create diagram output from my modelling tool — I use BiZZdesign Enterprise Studio — using the same font that I use for the book (currently still ArchiMate 3.1). BES did not support that. So, starting from the models, I created my own graphics backend. For that I used TeX, with which I am familiar and which was also used to typeset my other book. To be precise, I did not use LaTeX (that many will know by name), but I used ConTeXt a different macro package. In fact, I used LMTX (LuaMetaTeX — a modern very powerful development that combines ConTeXt, METAPOST, Metafun, and Lua) and is especially strong at graphics and precision control. I wrote Lua code to parse the model, METAPOST/Metafun is generated and run from Lua to produce the graphics, and ConTeXt is used inside METAPOST to typeset text. I created a few years ago for Edition 3.1 for the diagrams. The sheets are then a ConTeXt document that includes the diagrams. So, the full stack is: shell/python – ConTeXt – PDF ( created by LMTX: Lua, METAPOST, ConTeXt). I had to learn both lua and METAPOST for this project.

The very first diagrams produced from a small test model looked like this. Simply testing the whole setup and nothing written yet for specific elements or relations:

The green form was a placeholder I wrote to display elements I had not written real graphics code for yet. The red dots were my first ‘development support elements’ (these ones show me origins of the elements). The lines were placeholders for relations with nice smooth corners and all that. No nice crossings.

METAPOST is hard (for me, at least). It is a macro language, for one, and it is in fact a math language: it can solve equations. That is for instance how I am able to calculate the intersections between relations and elements and create perfect attachments, like in the example above.

Some images from during the development process:

The complete control over generated graphics gave me the option to do some sick stuff:

Next to that you see two other niceties. The aggregate start heads are transparent and extend a bit in the element. This gives a better illusion of them being ‘attached’ to it. And of course I created a few small jokes, like the winking person logo in BPMN (yes, I can also do BPMN). I made it female at one point just to make the point that in our field, there are simply too few of them, but ultimately decided against this as it could be interpreted wrongly.

There were small glitches/errors in my input files (data is never perfect), sometimes, so I invented an ‘override’ mechanism via a separate XML file. This override mechanism lets me repair/change stuff with respect to the actual model or make multiple views from a single one in the model file (e.g. to hide certain elements in a view, that is how I create images of only a relation, something no modelling tool can do). At some point I realised it was also a perfect engine for the creation of special non-ArchiMate ‘elements’, which you see at the end of the gallery above. Instead of using the ‘abstraction’ that is in the standard, I just created a few special elements that had multiple logos to mark them as ‘any of these’. Easier for the reader than to have to work with abstractions.

I had added the ability to override labels. But that in turn meant I could actually create labels with LMTX. That gave me all the typesetting power of TeX on any label text, again, something no tool can do. Which means that I can do things like colour and format text, as shown here, which not all tools can do. Some UTF-8-replacement trickery with this stack of tech was needed to get TeX ‘code’ (E.g. {\bf ArchiMate} means the word ‘ArchiMate’ is typeset in boldface) from the override file through all the parsing into the deepest use of the typesetting engine, though.

I can have text run along the relations (slightly distanced, that was quite a challenge) as can be seen in some of the diagrams in the sheets PDF. This is Metafun fun. Labels get autosized, but that process is not yet perfect, so I often have to override the result by hand by setting a sizing factor.

At the end it hit me: with this mechanism, it was quite easy to create translations! And because I wanted to show off, I started with a translation in Russian as that would force me to also use special fonts. Alexander helped me out and the 3.1 sheets were first published in Russian just to make that point.

Just for illustrative purposes, the single override XML file for the single model that contains the diagrams used for these sheets is about 2000 lines and looks like this:

I can have generic text elements that are reused. I can override per identifier in a view or in a model (view overrides model). I can create two types of output, output where the view/model identifiers of elements and relations are shown so I know what to put in the XML file. It is all rather labour-intensive, but extremely powerful.

All override files together is roughly 3000 lines of XML (most of the time. All model files together is 150,000 lines of XML so most of the time I do not need to override anything, it just works directly from the model.

A bit of lua code (2500 lines in total) that uses the override mechanism. It changes the text rotation of the label inside the element, but only if there is an override for it. It then calculates sizes for the label:

And a bit of METAPOST/Metafun code (3500 lines in total) that typesets a label:

It’s not perfect code (quite a bit of hard coded values, for instance), a lot is quick-and-dirty to get the job done. And the tools are not perfect, for instance there is hardly any useful feedback from LMTX when certain things go wrong, like when reading XML or producing output. Hence all the ‘debug’ code. But what you end up with is this:

Which I think is rather cool.

I went full-crazy on design/graphics, that is clear. But at the same time activities like these are also a conscious part of keeping my engineering skills (and thus insights and usefulness) alive as an architect. I’ve done the same with infrastructure (e.g. Docker, traefik, postfix, dovecot, MinIO, nginx, OPNsense, haproxy, unbound/nsd, pf, etc.). It is use it, or lose it. I do this, so I can keep on having useful discussions with engineers who really know their stuff and with a little energy I might be able to still understand what is going on or what the issue really is. The same on other subjects outside of IT. As an enterprise architect, one needs to be able to understand it all well enough so that enterprise-affecting choices are as healthy as they can be.