ArchiMate is not a language

ArchiMate has been labeled an `architecture language’. It certainly has aspects of a language. The combination of actors, behaviours and acted-upon objects resembles subject-verb-object of a normal language. And that is intentional: the designers of the language had this in mind. But what makes a language?

Note: the content of this post has been superseded (amended and extended) by the content on this issue in my book Mastering ArchiMate. Follow this link to the book page (with downloadable PDF)  for more information.

There are two issues I’d like to discuss here (and yes, they have a practical application in EA work):

1. Redundancy in a language
2. Syntax versus semantics (grammar versus meaning)

To start with the latter: take the following natural language sentence: “The customer drinks a bicycle”. Assuming that there is no cocktail called “the bicycle”, this is not a valid sentence in the English language. You can’t drink a bicycle. Grammatically, the sentence is correct, but semantically, it is nonsense.

We can do the same in ArchiMate. It is easy to use relations to connect objects in a grammatically correct but meaningless way. E.g. using a word processing application to steer the LHC magnets. Easy to model in ArchiMate, but meaningless in practice.

Not only the form your sentences take is important, but also the words itself. So, take a good look at ArchiMate: its objects are word types, not actual words. Without a label, views become rather meaningless (incidentally, we use an anonymizing script in BiZZdesign Architect before we send models to BiZZdesign’s help desk to help prevent the leaking of confidential business information). ArchiMate looks more like an architecture grammar, than an architecture language.

This means that thinking about the labels becomes important. If you are language speaker with perfect control of grammar, you still need to find the right words.

Thinking about the communication of our views, we decided early on to keep the type name of an object in the label of an object. This is of course redundant, as (with the right colour coding) every object is already visually different from another. But it is useful. For people who do not read models every day, the addition “business process” at the end of the label speeds up understanding the model. “Business process” immediately triggers the right pattern in their brain, the icon does not. In fact, adding this simple redundancy has in my opinion immensely speeded the use of ArchiMate views in our organisation. Our infrastructure people have expressed an interest to replace their own visualisations (spreadsheets, drawings) with our ArchiMate views. That is something you generally are told are not to be expected. “Don’t expect to be able to use large and complex ArchiMate views outside of your core architect group”, you are told. In practice: a little redundancy goes a long way towards readability.

We have more guidelines for labeling of objects. These have to do with easy use and especially reconciliation and integration with other models that exist in other tools in the organisation, e.g. the CMDB, the proces- or risk modeling tool, the software design tool and others. More about those another time, maybe.

So, is this practical? In my experience yes: forget the nice grammar for a moment: the power of language in the end lies in semantics. And there, redundancy improves communicability. There is nothing new there: nature has done it first: natural language is full of communication-enhancing redundancy (to the great pleasure of code breakers through the ages, by the way).

Architects are normally inclined to simplify, have a single definition, etc., in other words do everything that reduces complexity, to rationalise to make logical. But architecture relates strongly to the real world, where logic, certainly pure logic, has its limitations and too much of it actually makes matters worse.