ArchiMate: Friend or Foe?

A hunebed in Drenthe: enterprise architecture, ca. 3500 BC. The Dutch have always taken structure seriously.

After years of ignoring and not needing certifications to do my job well as an architect, I was enrolled in a group training for ArchiMate. Before that I had heard rumors that this was coming, it would enable us to specify everything well enough that code can simply be generated from it, it offered traceability from design to code to runtime systems. Architecture as code, they said. Poetry, they said.

The training was a year ago, and at work we started using the tool in the usual clunky way enterprises implement these things – top heavy and flowing down to the ranks like wet mud. My exam vouchers were good for a year, so I scrambled to register, giving myself 6 weeks to prepare.

From what I’d seen so far, it neither appealed to my logical mind nor was it useful to acquire in life. It was simply to comply and tick a box. So I procrastinated. Told myself that I don’t need 6 weeks, 3 days are enough.

Here I am, preparing for two exams on the subject (Archimate, not Asterix & Obelix). Day 2 of 3 of exam prep. As you can see, I am very focused on ArchiMate, though only the exam result will tell whether this kind of focus helped.

While reading the material, I started wondering (nobody wonders about this unless forced into close contact with the stuff):

What’s the general opinion about ArchiMate language? Is it used much outside the NL?

I conclude from exploring online, that broadly, ArchiMate is respected, not loved. Why, I’ll come to. But first, for anyone who hasn’t had the pleasure: a quick definition.

What ArchiMate is

ArchiMate is an open, independent enterprise architecture modelling language for describing, analysing, and visualising architecture within and across business domains – unambiguously. It sits at the right level of abstraction: specific enough to be useful, abstract enough to communicate across audiences (Wikipedia).

The pitch is that it gives enterprise architecture a shared vocabulary that spans business, application, technology, strategy, motivation, and the migration/change in between. That cross-layer coverage is the genuine strength – the one thing it does that a pile of boxes-and-lines diagrams cannot. When someone tells you ArchiMate is good, this is the part they’re pointing at.

It was never meant to be universal, though – not the way UML once aspired to be. ArchiMate is a specialist’s instrument for enterprise architecture, not a notation every engineer reaches for.

Respected, not loved

The criticism, when you go looking for it, is remarkably consistent: ArchiMate is semantically neat but socially heavy. It is disciplined – though, by its own admission, not exhaustively so; it follows the 80-20 rule, modelling the concepts that matter most and deliberately leaving the long tail unspecified. It is also the kind of thing that stakeholders do not naturally read. You hand a senior person an ArchiMate view and watch their eyes do the polite thing eyes do. Even architects – the people it is for – misuse the relationship types, over-model, and produce diagrams that are technically correct and communicatively dead.

That last phrase struck a note. The language is so capable of being correct that correctness becomes the goal, and the diagram quietly stops being a thinking tool and becomes a compliance artifact. Architecture as code, they promised. Architecture as paperwork, it turned out.

You can feel this happening inside an enterprise rollout – it arrives top-down, and the incentive quietly shifts to “produce a valid model” rather than “understand the system.” The tool is not to blame for this, but it doesn’t resist it either.

Is it used outside the NL?

This was my original suspicion, and it’s roughly right – with caveats. ArchiMate has strong Dutch roots and the Netherlands still has unusually high familiarity with it. But it is an Open Group standard with international certification, accredited training, global exam delivery, and real tool support, so not “just a Dutch thing”.

A fairer map:

• High familiarity: Netherlands, parts of northern/western Europe, public sector, banking, insurance, telecom, the big consultancies.
• Moderate: UK, Germany, the Nordics, Belgium, Australia/NZ, TOGAF-heavy or defence-adjacent organizations.
• Low everyday visibility: US tech, startups, product engineering – where C4, ADRs, BPMN, cloud-vendor diagrams and whiteboard conventions rule, and nobody is reaching for a motivation layer.

It’s worth separating ArchiMate from TOGAF here, because they travel together and get confused. TOGAF is the globally recognized framework/certification brand; ArchiMate is the more specialized modelling language that can sit underneath it. ArchiMate earns its keep when an organization genuinely wants a formal architecture repository – capability/application/technology mapping, impact analysis, migration planning. When architecture instead lives as decisions, roadmaps, and governance conversations, ArchiMate is answering a question nobody asked.

Tooling: Archi and the beast

A language needs tooling that supports it. It must, for otherwise no one can use it: the tools are to ArchiMate what an instrument is to sheet music – the notation is inert until something can play it.

ArchiMate has Archi (open source), Sparx, BiZZdesign, LeanIX. I have only tried the open source tool, Archi, and am straight-jacketed into one of the heavyweight commercial ones – not by personal choice. What I notice with the tools: Archi is lightweight and simpler, doable if you absolutely must do ArchiMate. The commercial option, by contrast, can turn you into a stormtrooper – a mindless executor of process and templates. Its interface fights you the whole way: drawing a simple diagram feels like operating a submarine to park a car. And the features are hard to find – as if no one, not even their mother, is proud of them, so they’re kept out of sight.

Simple diagrams with a handful of boxes and connectors can be made to look good in any tool. But for real complex diagrams, even when simplified for high level views, the ArchiMate toolset I’ve seen so far has no nice layout options. So added to clunky, the output looks terrible most of the time, and to prettify that would cost exponential effort.

Deploying the beast brings its own angst

The deployment model can amplify or soften the problems of such a tool, especially at enterprise scale with many concurrent users. There are smooth and rocky ways to deploy something like this across hundreds of people.

The smooth ones: a browser-based SaaS tool, or a local app on each person’s machine syncing to one shared repository – and it’s that shared repository, not any particular delivery method, that actually keeps everyone consistent.

The rocky, uphill option is to put everyone inside a single shared environment they all connect to remotely; it delivers the same consistency, but drags performance to a crawl, and that sluggishness becomes part of how the tool is experienced. None of which is ArchiMate’s fault, or even the tool’s; it’s purely a matter of how the thing gets delivered. But it’s how users will actually experience it.

My preferred alternatives

Because of the strictness of the language specification, you don’t get any shapes other than the ones inside the language: so I found during exam prep, that I could not use the Archi tool to create meta models of the language. I went to trusty draw.io for that. Speaking of diagramming alone, I’ve used and loved lucidchart, draw.io, PlantUML – all way more lightweight and easy to use and generate diagrams that don’t require certifications to understand. Bonus with the latter – diagrams can be represented as text (XML, etc.) so can be version controlled and diffed like normal code.

The traceability claim

This is the part of the original rumor I most wanted to interrogate, because it was the grandest promise – traceability from design to code to runtime, code practically generating itself. So I asked the obvious skeptic’s question:

How does the language afford traceability? Isn’t that more from versioning and version control of text-based representations?

The answer is that these are two different things people keep blurring (like I just did) – usually to ArchiMate’s advantage in the sales deck.

Version control gives you historical traceability: who changed what, when, and (if commit messages are honest) why. “On 12 June, Alice changed Payment Service from v1 to v2 and added a relationship to Customer Onboarding App.” That’s git’s job, and ArchiMate is bad at it on its own.

What ArchiMate actually affords is semantic traceability – the dependency chains between typed architectural concepts:

“This business capability is realized by these application services, served by these applications, deployed on these nodes, and affected by this migration work package.”

That comes from the typed elements and typed relationships, the bit that makes ArchiMate more than a drawing. It lets you ask real questions – if we retire this application, which business processes break? Which requirements does this design actually satisfy? Which systems support this capability? – and follow meaningfully named links to an answer instead of asking three people and hoping.

Type of traceability	Mostly provided by
Who changed what, when	Git / version control / model repository
Why a change was made	Commit messages, ADRs, decision logs, Jira
Which concepts depend on each other	ArchiMate relationships
Which change affects which system/process	ArchiMate + disciplined modelling
How the model evolved over time	Repository / versioning
Whether the diagram communicates at all	View design, not ArchiMate itself

The crucial line is in that last row, and in the words disciplined modelling.

ArchiMate gives you the grammar; it does not give you the discipline.

A model in BiZZdesign or LeanIX or Archi only becomes traceable when the organization treats it as a living repository with stable identifiers, ownership, naming discipline and change governance.

A key personal observation in a large enterprise: in such a tool, you need to have a single block defined to represent a single system. If the core systems are not defined up front before everyone is let loose on the tool, you get slightly differently named representations of the core systems in everyone’s own workspace, and all the beautiful inter-connectedness of ArchiMate evaporates: every architect’s diagram is on their own island.

The language affords structural traceability; the organization has to add a few key ingredients on top, such as the discipline of creating a representation exactly once, naming conventions, and version control. Without that we get a mess worse than before ArchiMate entered our lives.

What about the generated code?

The other half of the rumor was juicier still: specify the architecture well enough and the code falls out of the far end. This one doesn’t survive contact with the abstraction levels. The very thing that makes ArchiMate good at talking across audiences – it models capabilities, services, components and nodes, not classes, functions and API contracts – is exactly what makes it useless as a source for code. A model can tell you that a payment service is realised by an application component deployed on a node. It says nothing about how: the validation rules, the data shapes, the error handling, the thousand small decisions that are the actual program.

And it isn’t that code is the missing 20% of ArchiMate’s proclaimed 80-20 rule – that 20% is about which architectural concepts get left out. Code sits a whole abstraction level below the lot, beneath the whole 100% – the 80 it captures and the 20 it skips: the micro-decisions a model never descends to. You can generate scaffolding from a model – empty interfaces, stub components, a deployment skeleton – and some tools will happily do that. But scaffolding isn’t the building. The gap between the two is the actual engineering – the work no certificate does for you.

So, the verdict

Two days into cramming for an exam I signed up for to tick a box: not fun but manageable.

ArchiMate is at its best as a controlled internal grammar for architects: a repository, an impact-analysis engine, a way to keep current-state and target-state honest. It is at its worst when treated as the primary way you communicate with everyone, at which point you are producing rigorous diagrams that nobody outside the little Gaulish village can read.

It is not the magic potion. There is no cauldron that turns a model into running code while you sleep (we now have LLMs that turn prompts into code, but that’s a whole other post). What there is, used with restraint, is a disciplined way to write down how the pieces of an enterprise depend on each other – and a very fast way to manufacture unreadable architecture drama if you don’t. The indomitable village holds out a while longer either way; ArchiMate just decides whether the map of the village is worth reading.

Now back to exam prep.

---

The views here are my own, and about the discipline, the language, and the tools as a category – not about any particular employer.