#ArchiMate is overrated (and underrated)

In every field of inquiry, it is true that all things should be made as simple as possible – but no simpler — often attributed to Albert Einstein but coined that way by journalist Sydney. J.Harris in 1964.

I’m going to tell a little story:

Somewhere during the mid-90’s of te previous century, a nearby university built themselves a new library. Planned during the steep upwards slope of the dot com bubble, they planned to build a completely new type of library. Instead of large halls with books, they would provide the visitors with computer screens where they could search for and order their books. These would then be delivered at a small desk where they could pick it up. By the way, yes this is about ArchiMate. Eventually 🙂

The advantages of the new library setup were numerous. It would be far more efficient, for one, and a lot cheaper. And people would have a far easier time searching for their books. Note, this was before Google, Amazon reviews, etc., so searching meant searching a catalog on author, title and summary on some basic keywords.

When the library had opened its doors, the library people were in for a surprise. The number of books taken out and returned increased twentyfold. A lot of the efficiency advantages were lost. When they investigated, they found that people ordered not one book, but they ordered many, many more (on average!), scanned through them and then returned the ones they did not want to take with them. For every book actually taken out, twenty were delivered and nineteen were returned within half an hour or so. You could see many people standing at small tables with large stacks of books. People had invented a workaround, because they needed a bit more than just that basic information to decide if they wanted to read that book. I used the example a few times during those years (the 90’s leading up to the dot-com bust) to talk about the limits of the brave new digital world.

Searching is about ‘recall’ (do you get everything that is relevant for your search?) and ‘precision’ (do you get only what is relevant for your search and nothing more?) One day, when I was looking for something quite different in our small library at work, my eye fell on a book standing next to another one I had looked at. That second book was called “What Computers (Still) Can’t Do” by Hubert Dreyfus. I was intrigued and decided to read. It became one of the most important books I have read concerning my area of work, which is often also about what we can and cannot do with (digital) computers. I found that book not by searching for it, I found it by accident. It was serendipity (the luxury buzzword for ‘by accident’) that got me that book. So, when looking at ‘finding what you need’, the story was that we not only need ‘recall’ and ‘precision’, but also that essential trace element that is called ‘serendipity’. While computer giants work hard on improving recall and precision (when they’re not trying to steer us to things that are profitable for them and in the meantime sell data about us to their real customers), serendipity is having a hard time. Luckily, serendipity is rife in other environments, like social networks.

Aside: I am reminded of the following Mick Jagger/Rolling Stones lyrics: “You can’t always get what you want, but if you try sometimes, you might find, you get what you need.” Yep, that is what serendipity does for you too.

Now, what has all of this to do with ArchiMate? Well, as you might know, I find ArchiMate pretty useful. But what I find ArchiMate useful for differs from what ArchiMate was initially mainly intended to be useful for. ArchiMate’s usefulness might also be a case of serendipity.

Why was ArchiMate invented in the first place? The original research document that defines the ArchiMate language — Concepts for Architectural Descriptions — says this about it:

Because architectures are often complex and hard to understand, architects need ways to express these architectures as clearly as possible: both for their own understanding and for communication with other stakeholders, such as system developers, end-users and managers. To date, there is no standard language for describing architectures; they are often described in informal pictures that lack a well-defined meaning. This leads to misunderstandings, and makes it very difficult to provide tools for visualisation and analysis of these architectures.

Marc Lankhorst’s book also makes it clear already in the introduction: Each stakeholder requires specific information presented in an accessible way, hence for both engineers and decision makers. ArchiMate has been designed to fill those gaps. But if you look at use of the language, such as presented in white papers, examples (ArchiSurance for instance), conference proceedings and so forth, the attention has been mostly on the gap towards the decision makers. ArchiMate has been sold as the language that makes it easier for decision makers to come to grips with the complexity of the architecture of their enterprise. Also because really large scale complex models are hard to use during simple presentations, the message has often been one with overly simplified examples.

Now, my experience is, this modelling ‘language’, with its own slightly more strict element and relation forms, does not automatically provide that easy communication at all. I know no enterprise architect who uses a modelling language (UML, ArchiMate, etc.) that really makes communication with the decision makers easier. The only language that comes close is the graphical part of BPMN, as its visual basis can be used in a way (swim lanes with activities) that is pretty intuitive for the non-modellers among us. But, go into BPMN detail with complex exceptions and gateways, and everybody except the specialist is lost. The decision makers tend not to agree (not immediately, in any case) with the enthusiast enterprise architects when these tout the superiority of their nice modelling language.

So, the most effective way of communicating to the decision makers is often still simple graphics with those ambiguous lines and boxes. Adding ArchiMate’s structure to simple graphics adds little for management and is capable of complicating a lot. The structure and logic ArchiMate brings adds to the message and it becomes more complex . Yes, some ambiguity is removed and it enables analytical use (except that this requires a modelling rigour that is hardly ever mentioned and tooling that supports it), but at a cost. The decision makers actually don’t mind the ambiguity and are not interested in analytical thought. ArchiMate offers them something they neither want nor need. It is here, that in my experience ArchiMate is often overrated.

Now, there is an obvious place where rigor, structure and logic really help: when the situation to model becomes very large and complex and you still want to get to grips with it. Then, using structured approaches (especially if applied in a disciplined fashion) helps. But those are models that are definitely not for management. They are complex instruments that require a high level of ‘engineering attitude’ to set up and that can be used by those actually working in the detailed reality of those complex domains. This is an approach that is unpopular with many enterprise architects, especially those that constantly search for ways to make their subject matter simpler so it can be managed and communicated more easily. “We’re not interested in details”, they say, “those are not important for our strategy”. Sadly for them, though, ‘not ignoring details’ often matters. As Confucius said: “people stumble not over mountains, they stumble over molehills”. Just ignoring details often leads to disasters, one needs a way to find and address relevant details. ArchiMate in itself is not going to help you here, as it cannot tell you which details to model and which to ignore. But using ArchiMate, you at least have a language that is actually can be used to model the full enterprise complexity in a powerful way. In the immense complexity of our real enterprises is where a language like ArchiMate actually can really shine, not when communicating rather simple ideas to management. And it is here, that in my experience ArchiMate is often underrated.

Let’s end with the full quote from Sydney Harris (Chicago Daily News (Jan. 2, 1964)):

In every field of inquiry, it is true that all things should be made as simple as possible – but no simpler. (And for every problem that is muddled by over-complexity, a dozen are muddled by over-simplifying).

I have especially found that seldom mentioned addition about over-simplification very true in the real life of an Enterprise Architect, especially when you analyse why some projects or programmes fail, go massively over time and budget limits and so forth. ArchiMate — as a way to handle complexity and large scale better that loosely drawn over-simplistic visuals — can really help in fighting that aspect. It is, however, not something you can do by letting a consultant come over for a couple of months, you need to make good modelling part of your foundation of doing EA.

And, now that we are on the subject of Harris quotes, here is another one:

An idealist believes the short run doesn’t count. A cynic believes the long run doesn’t matter. A realist believes that what is done or left undone in the short run determines the long run.

The EA variant of this could read:

An idealist Enterprise Architect believes details don’t count. A cynical Enterprise Architect believes the big picture doesn’t matter. A realist Enterprise Architect believes that ignoring or not ignoring relevant details determines the outcome in the end.

And what is really funny is the ‘Droste effect‘ here. Recently, I had to explain what EA was to someone unacquainted with EA (and largely IT). He had been hearing stories, apparently, because before I started he asked me: “are you going to explain ArchiMate to me?” I told him: “I think ArchiMate is mentioned only once in my presentation, as an example in a detail”. Modelling (let alone: modelling in ArchiMate) is a detail in EA.

Funny, to realise that I have written a detailed 220 page large full colour book about what amounts to a ‘detail’ in EA. But the fact that something — like ArchiMate — is a detail, does not make it irrelevant…