Enough time has passed since the launch of ArchiMate 3.0 that it feels like it’s possible to identify some themes in the reaction of the Enterprise Architecture community to this latest version of the Open Group’s modeling language. Now, enough has been written by enough clever people that I don’t feel that I have anything to add regarding the changes introduced in ArchiMate 3. In particular, Gerben Wierda of Mastering ArchiMate has already evaluated the changes to a far higher rigor than I think anyone else could.
At the same time, some of the reactions expressed related to issues that have a wider scope than just ArchiMate, and I wanted to highlight one that caught my eye in particular. One of the interesting concerns that have been expressed is that the ArchiMate language might be becoming too complex, possibly complex enough to make it too intimidating for those not already used to it, and too unwieldy to use in a practical sense for anyone else.
Now, I can remember some of the exact same concerns being expressed when BPMN 2.0 came out. And at the same time, it’s possible to argue that the largest jump in ArchiMate complexity was between version 1 and version 2 of the ArchiMate specification, not between version 2 and version 3. Just to take one example, the jump from version 1 to version 2 increased the number of elements by 53%, while the jump from version 2 to version 3 increased them by 14%.
But the more general concern is completely valid – is there a point where a particular given language can become too unwieldy to use practically? That question is just as valid for a modeling language as for any other type.
The purpose of a language is to enable communication, and rules are a necessary part of languages for them to accomplish this goal. With apologies to Humpty Dumpty, a word that means ‘anything’ means, in practice, nothing. At the same time, rules around grammar (which is effectively rules for how you combine the words) are also necessary for the combinations of words to make sense. The same is true of types of modeling entities and their relations – I often like to say that without an agreed meta-model you’re stuck talking about “things” that do “things” to other “things”, which in turn do other “things” with other “things”. In fact, with modeling languages the rules are even more vital because ambiguity in communication, while sometimes useful in natural language, is a serious problem when the goal is clear.
But, at the same time, if a language is too complex it becomes useless for communication between anyone except highly trained specialists – which also undermines the end goal. What’s needed is some sense of where the sweet spot is for different types of audience and different types of communication.
Normally I try to come up with an opinion on any given topic, since at least an opinion can be challenged and proven wrong, leading you further to the real truth. But on the question of where we balance the rigor of a modeling language versus its usability – or even what rules of thumb might exist to help us decide the correct tradeoffs – I have to admit that I’m at a loss. An area for some research to be done by someone, it seems…
Why not draw your own conclusions by trying out our free ArchiMate 3.0 stencils and templates in Visio? Simply click below to get your copy!