Since ArchiMate says nothing about style, things like colors, sizes of objects, alignment etc., you are free to develop your own. ‘Style’ is an interesting subject. On the one hand, we know how style can influence user experience, so it is something with real value. On the other hand, it is often also a matter of taste, and disagreement is the normal state of affairs.
My ArchiMate book is a project without a marketing budget, actually without a budget at all. So, ‘promoting’ the book is not much more than this blog and my LinkedIn ArchiMate Group membership. From there came the following critique by Joost Lommers:
To me it looks like Gerben wants all diagrams to be neat and aligned, using only the “boxed” object symbols and the default color scheme. Which makes all architectures look the same. I want my architectures to stand out, and emphasize what is important in that particular diagram. If one process step takes more time than the others, I like it drawn longer. If one application component is more important in the landscape, I want to draw it bigger. Etc.
I think the commenter touches upon an important point. When he writes “I want my architectures to stand out, and emphasize what is important in that particular diagram.” he is making the point that it is the use of a diagram that defines how it must be laid out. If his use is to ’emphasize’ something, strict style guide rules may stand in his way.
I can be pretty simple on this one: I agree.
People having read the book probably could guess I would agree, as this is in line with Uncle Ludwig (see book). Not that Uncle Ludwig is the only measuring device in town, but generally, I find it indeed comes down to the point that the meaning of something lies hidden in its correct use. And if the use is to send a strong message, emphasis is a good instrument. I do it myself. The last time I did it was to color code business functions to years we were working on IT-support for them.
One of the basic messages behind the style section in the book is:
Keep your views as easy as possible on the eye. The ‘quieter’ the picture, the less the Human Visual System (HVS) has to cope with and the more of the actual content your audience can take in.
‘Emphasis’ (generally, but not always) makes a view less ‘quiet’, but it can also make a view more understandable. For me, that means that there is nothing wrong with using emphasis if you want to stress something, but using it a lot might have disadvantages too. Not just within a view: Suppose in one view, something is emphasized by making it big and red, for instance, the system that is to be replaced in the coming years. But later on, in another view, the system that is big and red stands for that it is a corner stone application in your landscape. A lot of such switching (and there are many types of it) in the head of the reader might become confusing. Maybe only subconsciously, but it is another aspect the reader needs to filter out. The problem does not occur of course if it is just that one single view that you need in your document for the board of directors. They won’t encounter the rest and they won’t run into the potential confusion. So, no problem there.
So, the question is: use emphasis and if yes, when? In my view, there are multiple uses in play here.
The underlying (boring) sort-of-reality
Your models in ArchiMate are often supposed to be models of reality. Either of the ‘current state’, or of (in the case of projects ‘parts of’) the ‘future state’. The idea of these models is that they are a common set of information for all who are stakeholders for that model, they are a sort-of-reality that acts as backdrop for the discussions. In the case of a current state model, the maintenance people, the auditors, etc. are stakeholders. In the case of a project model, the project executive, the project manager, the project members, the developers, the architects of other domains, etc. are all stakeholders. What these stakeholders use the views in the model for is as the common ground for their discussions. This common ground is in fact the (shared) documentation of the (‘current’ or ‘to be’) reality.
Our style came to be with these uses in mind. Here, a free use of ’emphasis’ is almost destructive, because it is not so much about that underlying (‘current’ or ‘to be’) reality at all but about a certain interpretation of it. Besides, all these different stakeholders will have different emphases, putting one in, makes it worse for all the others. Therefore, the views of sort-of-reality models need to be as neutral as possible to be a reliable means of communication between different parties. And the ‘quieter’ and ‘more consistent’ the views are, the easier they are for those who do not read ArchiMate for a living.
The captivating (architectural) message
Quite a different use is to use a view to present a captivating architectural message. It is more than just communicating the boring underlying sort-of-reality as good as possible. No, in this case, you want to emphasize, you want to focus people’s attention, you want to interpret, you want to make a point.
Should you limit yourself to a strict style guide here? I wouldn’t. Actually, I would not even restrict myself to ArchiMate here. Whatever gets the message across, I would say. Anything goes (as long as it is legal). But if you specifically want your messages to be illustrated using the ArchiMate grammar, don’t let style guides get in your way too much.
The difficult choices
The question is “Why, though?”. Why would you want to present your ‘captivating messages’ in ArchiMate? Is it because you want the audience of your message to ‘use’ ArchiMate as well? Is it an advantage that they see those typical ArchiMate grammatical elements because they will see them again in other settings and it will become part of their vocabulary? Then you end up in a difficult spot. Using emphasis much will make it more difficult for them to start understanding the grammar as it distracts. Not using it diminishes the power of your communication, as the commenter so rightly pointed out. It is a difficult choice and there is not an easy answer.
Another problem has to do with your model. Because ’emphasis’ it is not only a matter of style, but often also of modeling. Your modeling patterns may say that you need to include object types X, Y and Z in any model, fixed patterns to make analysis possible. But those patterns may be too detailed for the message you want to convey. Your ‘message’ views get bogged down in details that distract from the message.
So you add specific views for those messages you want to convery. But add more views with other (new, added) shortcut relations and different patterns and your model will drown in its own noise. I do not know of tooling where you can make a difference between relations that way. Besides, every extra different view means extra maintenance. Change something in one view, how do you make sure you won’t forget changing it in another of that same model? Forget about automatic support for this, even for deletion there are scenarios where it goes haywire.
The conclusions
For me, these aspects lead to the following conclusions:
- ‘sort-of-reality’ models should have neutral views, no emphasis
- creating ‘captivating message’ views, with visual ’emphasis’, in ArchiMate comes with risks, so:
- Create your ‘captivating message’ views without ArchiMate, or
- Create ArchiMate-grammar based ‘captivating message’ views, but
- Never mind the style guide here, except for the basic tenet: keep it as quiet as the message permits
- Use separate models to prevent too much ‘damage’ to the clear structure of your models
- Watch out for the subtle conflict between creating a common language based on ArchiMate in your organization and freedom of expression. Too much of that freedom for you, the architect, makes learning the language for the others difficult. Too little freedom limits your communicative power. It’s like learning a new language all over again for your organization and you want to use all the freedom in that language to say difficult things to them while they are in the process of learning the language.
The style I proposed in the book is clearly not by definition the best solution for all uses. I think the problem mentioned by the commenter is a good example: if your use of a view is to convey a message to a board, a different style may be required than the one proposed by me to support shared use of ‘common ground’ models and views. There is nothing wrong with that.
R&A IT Strategy & Architecture 