Which modelling language to use

A notation is a set of answers, and it is only useful if you were asking the question it answers. The four on this site were written by different people, in different decades, for different rooms - and the reason the comparison feels slippery is that three quarters of it is a category error. Before comparing anything, it helps to read them as four questions rather than four toolkits.

Read that way, most pairings dissolve. Comparing C4 with UML compares a table of contents with a typeface, which is the subject of its own article. Comparing ArchiMate with BPMN compares a map of a country with a set of driving directions. What is left after the category errors are removed is three real overlaps, and those are worth arguing about.

Process flow. A BPMN process and a UML activity diagram describe the same thing: work in sequence, with branches, parallelism and participants. They are drawn differently and they are aimed at different rooms, but a diagram of an order-to-cash process is legitimate in either. This is the only overlap where the two candidates are genuinely interchangeable for the reader, so it gets a full comparison of its own.

Application structure. An ArchiMate application component and a UML component both name a piece of software and the interfaces it offers. The difference is depth of field: ArchiMate stops at the component and looks sideways, at the business process it serves and the node it runs on; UML keeps zooming in, to the classes inside it. If the next question is "and what does it consist of", you want UML. If the next question is "and who cares if it stops", you want ArchiMate.

The container-sized box. A C4 container, an ArchiMate application component and a UML component are frequently the same deployable thing drawn three ways. All three notations are correct here, and this is the overlap where teams most often argue past each other: the disagreement is nearly always about which level of detail the diagram is for, not about which notation is right.

Where a real choice exists, three questions decide it faster than any feature comparison. Answer them in order and the fourth answer is usually already obvious.

1. Who has to read it without being taught? This is the constraint that outranks correctness, because a diagram nobody reads is worth nothing however legal it is. Developers read UML and C4 on sight. Business analysts and operations managers read BPMN on sight, and most of them have never been shown a UML activity diagram. Enterprise architects and the people who fund programmes read ArchiMate, and almost nobody else does.

2. How much is in scope? One system, or the estate around it? UML and C4 are system-scoped: they describe a thing that has a boundary, a repository and a team. ArchiMate is estate-scoped, and applying it to a single application produces a model that is correct, expensive and less useful than the two UML diagrams it replaced. The reverse mistake is more expensive: answering "which applications does this business capability depend on" by drawing forty component diagrams.

3. What has to survive the meeting? If the answer is "a shared understanding", any notation the room reads will do, and the least formal one wins. If it is "a file another tool can open", you need a notation with an interchange format - UML has XMI, ArchiMate has The Open Group's exchange format, BPMN has its own XML, and C4 has whatever your drawing tool saves. If it is "something an engine runs", the answer is BPMN and there is no second candidate.

Most organisations past a certain size use three of the four, and that is not a failure of governance. The failure is subtler and much more common: two notations on one canvas, with nothing on the page saying which box belongs to which. A reader then has to guess whether a rounded rectangle is an ArchiMate application service or a BPMN task, and a diagram that has to be guessed at is a diagram that gets ignored.

Three habits prevent nearly all of it. Label the view with its notation and its level, the way an ArchiMate viewpoint is named for the question it answers. Keep one element for one real-world thing, so the same service is one entry in the model no matter how many views draw it. And let the views disagree in detail but never in fact - if two diagrams show different dependencies for the same component, the model has already stopped being true.

That last habit is the one a drawing tool cannot help with, because a drawing tool has no model behind the pictures. It is the difference between a folder of diagrams and a model with views onto it, and it is why the starting templates here are per-notation rather than per-picture: the notation you pick decides the vocabulary, and the vocabulary is what the model is made of. If you would rather see that before reading further, the fifteen-second demo builds one and hands it back as a file.