ArchiMate for Developers: The 12 Elements You Need

Developers usually meet ArchiMate in a review meeting: an architect shows a diagram full of coloured boxes and asks where the new service fits. The specification is long, the element list looks endless, and the natural reaction is to ignore it and draw your own boxes. That costs you the one thing ArchiMate is good at: a shared vocabulary between the people who write the code and the people who decide what the IT landscape should look like. You do not need the whole language for that. Twelve elements and five relationships cover most of what a development team has to say.

TL;DR

• ArchiMate is large; teams that use it well stick to a small, stable subset and ignore the rest until a real question requires it.
• Twelve elements cover the essentials: Business Actor, Business Role, Business Process, Business Object, Capability, Application Component, Application Service, Application Interface, Data Object, Node, System Software, Technology Service.
• Five relationships carry most of the meaning: Serving, Realization, Assignment, Flow and Access.
• Three views answer most developer questions: the application landscape, capability support and deployment.
• ArchiMate 4 (April 2026) renames layers to domains and merges per-layer processes and services into generic ones; the subset still holds.

Why learn a subset of ArchiMate instead of the whole language?

Because ArchiMate adoption fails by excess, not by lack of notation. The specification maintained by The Open Group defines dozens of element types. A team that uses them all produces models only their author can read, which stop being updated when that person moves on.

A subset works because readers recognise every box, two developers describing the same system make the same choices, and the core elements survive an exchange between any two ArchiMate tools.

New to ArchiMate diagrams? Read our beginner's guide to ArchiMate notation first for the layers, symbols and colours; this article focuses on what to actually use.

Which 12 ArchiMate elements do developers actually need?

The twelve elements below are enough to say who does what, which software supports it, which data it handles and where it runs. They span the business, application and technology layers, plus one strategy element, Capability, that ties the model to what the organisation is trying to do.

Four translation rules help developers map their world onto these elements:

• A repository is not automatically an Application Component. The component is the unit the rest of the organisation recognises: a service, a product, a packaged application. Three microservices released together can be one component.
• An endpoint belongs to an interface; what it does is a service. POST /invoices is part of the Billing REST API (interface); "Issue invoice" is the service it gives access to.
• Business Object and Data Object are two views of the same thing. "Invoice" is what finance talks about; "invoice record" is what the billing service stores.
• Node is deliberately broad. A VM, a cluster or a serverless platform can all be Nodes. Use System Software for what is installed on them.

Which five relationships should you know?

Five relationships carry most of the meaning in a working model: Serving, Realization, Assignment, Flow and Access. ArchiMate defines others (composition, aggregation, triggering, association…), but these five come up every week.

Two habits keep them honest. Use Flow for data exchanged between components and Serving for "uses": a nightly export is a Flow, an API that one application relies on is Serving. And use Access only towards a passive object (a Business Object or a Data Object), never between two components.

Which three views cover most developer questions?

Three views answer most of what a development team is asked: what talks to what, which applications support which capability, and where things run. ArchiMate 3.2 ships example viewpoints close to each (Application Cooperation, Capability Map, Technology Usage), but the subset above is enough to build them.

• Application landscape. Application Components connected by Flow relationships, with the Data Objects exchanged on the main flows. It answers "who consumes this API?" and "what breaks if this service is down?".
• Capability support. Capabilities on one side, the Application Components that support them on the other. It answers "which applications support Billing?" and exposes capabilities with no application, or with four overlapping tools.
• Deployment. Application Components, the System Software they rely on and the Nodes they run on, linked by Serving. It answers "which applications are affected by the PostgreSQL upgrade?".

Below the component level (containers inside a service, classes inside a module) ArchiMate is the wrong tool. Our comparison of C4, ArchiMate and UML explains which notation answers which question and how C4 elements map onto ArchiMate.

Do it by hand in Archi if you are one architect with one model. If several teams must keep the landscape current, UrbaHive's free plan (1 user, 25 applications, no credit card) lets you start a shared repository and export it to Archi when you need the notation.

What are the most common ArchiMate mistakes?

The most common mistake is confusing a component with a service, followed by over-linking, overloaded views and code-level detail.

• Component versus service. "Billing" drawn as a service when it is a deployable system, or "Issue invoice" drawn as a component. If you can deploy it, restart it or put it on a server, it is a component; if it is a verb phrase describing what something offers, it is a service.
• Too many relationships. Everything linked to everything with Association because the right relationship is unclear. An Association says almost nothing; ask what the reader needs to know.
• Unreadable views. One diagram meant to show everything. A view answers one question for one audience; past twenty or so elements, split it.
• Modelling at code level. Classes, tables and endpoints as ArchiMate elements turn the model into a second, stale copy of the code. Keep ArchiMate at landscape level.

What changes with ArchiMate 4?

ArchiMate 4, published by The Open Group in April 2026 to supersede version 3.2, simplifies the language without discarding its core. "Layer" becomes "domain"; process, function, event and service become generic elements shared across domains; Business Role becomes a generic Role; interaction elements, Constraint, Contract, Gap and Representation are removed. The Open Group stresses strong user-level compatibility.

For this subset, Business Process becomes a Process assigned to business actors or roles, Application Service and Technology Service become Services, and Business Role becomes Role. The other elements and the five relationships keep their meaning. Tools are catching up: Archi 5.10 (September 2026) still implements ArchiMate 3.2.

Where does UrbaHive fit?

UrbaHive is not an ArchiMate modeller: there is no notation editor and no Strategy, Motivation or Implementation layer. It is a shared repository of programs, applications, flows, servers, capabilities, processes and people, built for mid-sized organisations (50 to 5,000 employees), where non-architects keep the inventory current without learning the notation.

The bridge to ArchiMate is the Open Exchange Format (XML), both ways. The import reads a model made in Archi, or any tool that exports that format, and shows per item whether it will be created, updated or ignored. The export covers applications, programs, vendors, roles, servers and infrastructures, architecture documents and flows, with three generated views: applications arrive in Archi as Application Components, servers as Nodes, flows as Flow relationships. Capabilities and processes stay in UrbaHive, with a capability × application coverage matrix and an impact analysis of direct upstream and downstream dependencies.

FAQ

How long does it take to learn ArchiMate?

The twelve elements and five relationships in this article can be learned in a few hours of practice on a system you know. Mastering the full language takes much longer; The Open Group runs a certification programme for those who need it.

Do developers need ArchiMate?

Not to write code, but it helps whenever their work crosses a system boundary: designing an integration, retiring a service, presenting a change to an architecture board. The subset lets a developer read the architect's diagrams and describe their own system in terms the organisation can reuse.

Is Archi free?

Yes. Archi is a free, open-source ArchiMate modelling tool. Its current version supports ArchiMate 3.2 and the Open Exchange Format, which is how models move between Archi and other tools, including UrbaHive.

Should I learn ArchiMate 3.2 or ArchiMate 4?

Learn the concepts, which barely change, and use the version your tool supports. The concepts behind the twelve elements, and the five relationships, exist in both; ArchiMate 4 mostly renames and merges the per-layer processes and services.

Start with twelve elements

ArchiMate becomes useful the day a team agrees on a small vocabulary and keeps a model current, not the day someone masters the specification. Draw the three views for one domain with the twelve elements and see which questions they answer. When the landscape needs more than one maintainer, create a free UrbaHive account: 1 user, 25 applications, no credit card, and an ArchiMate export to Archi whenever you need the notation. For the surrounding vocabulary, see the IT mapping and enterprise architecture glossary.