Architects generally wrestle with the problem of communicating their complex world of dependencies to stakeholders. Those that created the ArchiMate language hoped that making a better language would enable clearer communication. While ArchiMate does enable more precise communication than your average set of lines and boxes in a presentation, the precision does not make things by definition clearer.
This is true in many disciplines. For my original university study, Physics, the same is true. The formula (Newtonian gravity)
is more precise than this set of picturesbut the second one is a lot easier to understand than the first one, let alone the currently best variant (Einsteinian gravity):Physicists communicate with each other using the precise formulas, but when they talk to normal people, they better use more easy to understand ways.
A while back, I wrote the post ArchiMate is overrated (and underrated) in which I argued that the structure that ArchiMate brings to the table only confuses its intended management audience in simple views, whereas it does enable rigorous analysis in large models. Before moving on to another post on infrastructure patterns that allow such analysis and reporting, this post is a small intermezzo, providing another small illustration of the potentially adverse effect of using ArchiMate in communicating to non-architect stakeholders.
Suppose we want to show our CEO the two ways in which we serve our customers: via a Call Center and via a self-service portal (Yes, yes, I know, I also wrote “I, Robot” – there is no such thing as ‘Customer Self-Service’, but I’m also a pragmatist, not Don Quixote). Everything is positioned nicely in ‘The Cloud‘. If we model that according to what ArchiMate tells us, we get something like this:
Now, this is not really complicated, and even the CEO will understand it without much trouble, skipping over the finer details of the different types of boxes and lines used. If we drop ArchiMate altogether, and we just go for a nice visual, we get something like this:
I suspect the second picture is easier for the CEO to immediately understand than the first. First, he is not distracted by different relation types, by icons in the boxes, by the architect’s layering-fetish and so forth. Of course, I can bring the ArchiMate picture back to the same number of boxes and only a single relation type:
But I’ve now moved real (ArchiMate) structure to unstructured information (labels). Not a problem for this single view, but I have now lost structured information in my model that is useful for discussions, namely the answer to: “What are the business services we provide to our customers?”. In an Enterprise Architecture model you want that information, even if you don’t want it in every view. ArchiMate’s ‘derived relations’ were invented to combine both, but in practice the syntactical (structure) mechanism is too weak to do the semantical (meaning) job.
Using ArchiMate — let alone, just using ArchiMate visuals — doesn’t add much value for toy-sized models & views. ArchiMate actually obfuscates communication to most stakeholders. It shines (warts and all) when used for serious modelling by serious architects. ArchiMate is in my view very useful for modelling large complex situations, potentially using —for fellow architects and designers — many views, and — for management and other non-architect stakeholders — analysis and reports to communicate the content. It is not that effective for visualisation towards an audience that doesn’t regularly use the language. Worse even: in practice, ArchiMate makes communication with those not very familiar with the language more difficult.
Aside: would you trust a physicist who can only talk in simple pictures? Why then do you trust an enterprise architect who can only talk in simplistic pictures, but not in the true complex ways required to be more precise? The ideal enterprise architect is a bit like the physicist Richard Feynman, able to handle the complexity and able to communicate about it clearly. Given that most of us are not as smart as Richard, we struggle.
I wholeheartedly agree! While I love modelling tools for precision, I have a completely different approach for senior executives. I use one slide with only the drawing tools that the presentation tool provides. It forces me to distill a model to the essence of what needs to be communicated.
Thanks, not being able to convince the business or even the technical managers. I ended up deciding not to use this modeling language, to communicate ideas. The SQA manager complained about the colour scheme not being compatible with colour impaired people. The senior software architects, that worked with some of the authors thought that math was the only way to represent a system. And senior management didn’t understand the models and didn’t allow me to spend time on them. I have been disillusioned with archimate as a communication tool, and will use math, python (as pseudocode) and plain English instead.
ArchiMate is a modelling language. For small models, it does not add much, but when things get large and complicated, it really helps to have a language that is ‘holistic’ and can handle architectural details.
The originators of ArchiMate thought that they could create a language ‘for all uses’. That, I think, is an illusion (and an old one at that). But that doesn’t mean it is not good for *any* use. Personally, I think you need something like ArchiMate when things get really complicated. And at that point, the model becomes a tool for other things, such as analysis and reporting. And the language really works well for architects as it does help you to be complete when used well.
What I have done with some success is to establish a mapping between Archimate artifacts and ‘boxes-and-lines’ ones before such a presentation. In that way I knew what I was talking about and they also did not feel overwhelmed. For example a ‘SmartArt’ graphic for a business process, boxes for components, ‘drums’ for entities with simple arrows connecting them.
When I present a model to whatever level in the hierarchy I stick to Archimate. I start by showing the metamodel of the model that I am about to discuss. That helps explaining a few concepts, I “never” go into detail about the deeper meaning of relations. Difference between aggregation and composition is not relevant to a CxO. I “always” start modelling in the yellow layer, with at least a process and a business service. Business people in my organisation have to pay a lot of attention to processes and services. Since you are talking about their activities you immediately get their attention. It makes it easier to explain the blue layer and the relations between layers.
I couldn’t resist:
The ideal enterprise architect is a bit like the physicist Richard Feynman, able to handle the complexity and able to communicate about it clearly. Given that most of us are as smart as Dick, we struggle.