What is ArchiMate?
The modelling language for enterprise architecture: one small vocabulary that describes a business process, the application behind it, and the server underneath - and, more usefully, the lines between them.
10 min readArchiMate 41 of 4
01What it is
ArchiMate is a modelling language for enterprise architecture - a standard of The Open Group, and the only widely used language built for the job. Where UML describes software and BPMN describes a process, ArchiMate describes an organisation: what it does, what supports it, and what it runs on, in one model with one vocabulary.
The thing it does that nothing else does is cross the boundaries. A class diagram cannot say that a piece of software supports a business process. A process diagram cannot say which server the process depends on. ArchiMate can say both in the same picture, using the same eleven relationship types throughout, and that is the entire reason it exists.
02The framework: layers and aspects
ArchiMate organises its whole element set on a grid. Down one side are the layers, which say how close to the metal an element is. Along the other are the aspects, which say what kind of thing it is. Every element type in the language sits in exactly one cell.
| Element | Notation | What it means |
|---|---|---|
| Strategy | resource, capability, course of action | What the organisation is able to do, before deciding how. |
| Business | actor, role, process, service, object | What the organisation does, in its own language. |
| Application | component, service, interface, data object | The software that supports it. |
| Technology | node, device, system software, artifact | What the software runs on. |
| Physical | equipment, facility, material | Things you could trip over. Manufacturing and logistics. |
| Implementation | work package, deliverable, plateau, gap | The change programme that gets you from here to there. |
| Motivation | stakeholder, driver, goal, requirement | Why any of it is the way it is. Cuts across every layer above. |
The layers, top to bottom. Motivation is not a layer in the same sense - it attaches to elements anywhere in the model.
The aspects are the second axis and are easier: an element is active (it does something - an actor, a component, a node), behaviour (something being done - a process, a function, a service), or passive (something acted upon - a business object, a data object, an artifact). Active elements are drawn with square corners, behaviour with round ones, and passive elements as an object shape.
Learning the grid is most of learning the language. Once you know that a "service" is a behaviour element and exists at every layer, you already know what a business service, an application service and a technology service each are, and the layers article is filling in detail rather than teaching something new.
03How elements are drawn
ArchiMate's notation is the opposite of UML's. UML gives each diagram kind its own shapes - ovals for use cases, rhombi for decisions, isometric boxes for nodes. ArchiMate gives almost everything a rectangle and distinguishes elements three other ways.
| Element | Notation | What it means |
|---|---|---|
| Colour | yellow, blue, green, purple | The layer. Business yellow, application blue, technology green, motivation purple. Conventional rather than mandated, but universal in practice. |
| Corners | square vs rounded | Square is an active structure element, rounded is behaviour. A rounded blue box is an application function or service; a square one is a component. |
| Corner glyph | small icon, top right | Which element type within the cell. The arrow for a process, the circle for a service, the person for an actor. |
| Nesting | a box inside a box | A relationship drawn as containment instead of a line - usually composition or aggregation. Legal, compact, and ambiguous unless the model says which. |
04The relationships are the language
Elements are the easy half. The eleven relationship types are where models go right or wrong, and four of them carry most of the meaning:
| Element | Notation | What it means |
|---|---|---|
| Serving | The source provides functionality to the target. The workhorse: it is how a layer supports the layer above it. | |
| Realization | The source makes the more abstract target concrete. A process realizes a service; a component realizes an application service. | |
| Assignment | An active element performs a behaviour. Ball on the doer, arrow on the thing done. | |
| Access | Behaviour reads or writes a passive element - an object, an artifact. |
Four of eleven. The other seven, and the rules for which pairs are legal, are the subject of their own article.
The distinction people get wrong first is serving versus realization. Realization says "this is that, made real"; serving says "this helpsthat". A payment component realizes the payment service (they are the same capability at two levels of abstraction) and the payment service serves the checkout process (two different things, one useful to the other). Getting these backwards produces a model that looks fine and answers impact questions wrongly - see the relationships article.
05ArchiMate or UML?
Compare that with the hero diagram. The UML version knows Claim.submittedOn is a date; the ArchiMate version has no idea. The ArchiMate version knows that the claims database going down eventually stops a policyholder submitting a claim; the UML version cannot express the question.
Reach for it when
- The question spans business, application and infrastructure at once
- You are doing impact analysis - what breaks if this is retired
- Stakeholders include people who do not read software diagrams
- You need one model, not fourteen diagram kinds, to stay consistent
Reach for something else when
- You are designing the internals of one system - use UML
- You need attributes, types, and multiplicities - use a class diagram
- You are specifying a process to be executed - use BPMN
- The model is a database schema - use an ER diagram
The two are complements rather than rivals, and a healthy practice uses both: ArchiMate for the landscape, UML for the systems inside it. What does not work is one language stretched to do both jobs, which in practice means an ArchiMate model with attributes bolted on or a class diagram with servers drawn next to the classes.
06What goes wrong first
- Modelling the whole enterprise. Nobody finishes and nobody reads it. Model the part a decision depends on, and stop.
- Using association for everything. A model whose lines are all plain associations carries no more information than a whiteboard photo. If you cannot pick a specific relationship, you do not yet understand the connection.
- One giant view. The model is the model; a view is a window onto it for one audience. Five focused views beat one poster. Viewpoints are the mechanism.
- Application components named after teams. Teams get reorganised twice a year and the systems do not. Name the system.
- Skipping the motivation layer. Six months later nobody remembers which requirement justified the odd-looking bit, and it gets removed.
In one line each
- 01ArchiMate describes an organisation end to end: business, application, technology.
- 02Every element sits in one cell of a layer-by-aspect grid; learning the grid is most of learning the language.
- 03Square corners are active structure, rounded are behaviour, object shapes are passive.
- 04Colour signals the layer by convention, not by specification.
- 05Realization means "is that, made concrete"; serving means "helps that".
- 06Use ArchiMate for the landscape and UML for the systems in it - not one for both.
Related reading