In machine-based symbolic processing, ambiguity is the original sin. But in human communications it is not so simple. Every legal document demonstrates that attempting to eliminate ambiguity tends to produce language that is utterly unintelligible to most people.
Recently I downloaded a copy of Archi, a free tool for drawing architectural diagrams in the ArchiMate visual modelling language. It’s a well built little tool and it allowed me to really give ArchiMate a try for the first time.
One of the stated goals of the ArchiMate project is to remove confusion:
The… ambiguities and confusion [resulting from differing modelling conventions] stand in the way of the flexibly and efficiently operating organizations we envisage.
ArchiMate wants to do away with these ambiguities. It presents a unified way of modelling enterprise architectures, integrating the various domains and describing them in an easily readable way.
The project decided structural consistency would require eliminating confusion and ambiguity. The authors specified an abstract model of a generic architecture – complete with structure diagrams.
Which is to say ArchiMate followed the software engineering path of formal languages. Archimate is designed the way a database architecture or programming language is defined. The authors have gone to some lengths to remove ambiguity from the language and impose internal consistency.
Unfortunately, while taking aim at ambiguity, the designers shot themselves in the foot.
The authors of Archimate overlooked that while formal consistency is a necessary condition for removing ambiguity, it is far from sufficient.
In machine-based symbolic processing, ambiguity is the original sin. But in human communications it is not so simple. Every legal document demonstrates that attempting to eliminate ambiguity tends to produce language unintelligible to most people.
If a modelling language for enterprise architecture is to communicate to all relevant stakeholders, it should be easily readable. So much so I expect it to meet the US government’s plain language program criteria for writing,
Plain language (also called Plain English) is communication your audience can understand the first time they read or hear it.
There are two ways the plain language test applies to ArchiMate.
First, do the elements of language represent concepts that are easy to comprehended?
Let’s look at the business service element. Service management is a well established practice. However, the project decided not to use an existing definition and wrote its own.
I call this sneaky jargon. ArchiMate applies its own convoluted definitions to ordinary words. It reduces inconsistency, but at the cost of confusing readers. As a language written to remove ambiguity Archimate is an exercise in irony.
Secondly, are ArchiMate definitions themselves intelligible?
Lets go to Fight the Bull and measure the Business Service definition on the Felsch-Knicaid index. The result is 35, near the level where a university education is needed. And this only measures sentence and word length. Include the sneaky jargon and readability is much worse.
I don’t think many architects will apply Archimate pedantically or even bother diligently learning the grammar and the relationships between entities that proscribe their use. Rather most will just use the symbols according to commonly held understanding.
Nonetheless, using ArchiMate as it is intended will lead to more meetings where Cheshire-cat architects find themselves explaining to Alice-in-Wonderland stakeholders, “When I use a word like ‘product’….”
The unfortunate result is that Archimate was designed without much reference to human cognition, and the cognitive models embedded in the language habits of the authors was assumed, by them, to be normative. Now I fear Archimate, for which there is a real need, is doomed to be a tool restricted to a coterie of specialist users.
Antipatterns 