The ArchiMate layers
Six layers and three aspects. Between them they place every element type in the language, which means the grid is not a summary of ArchiMate - it is most of ArchiMate.
9 min readArchiMate 42 of 4
01Why it is a grid
Most languages hand you a list of element types to memorise. ArchiMate hands you two short lists and a multiplication. Six layers, three aspects, and the promise that a cell means the same thing in every row: a service is a behaviour element that some other element realizes and that serves something above it, whether it is a business service, an application service or a technology service.
That regularity is worth leaning on hard while learning. If you know what an application component is, you know what a node is - the same cell one layer down. If you know a business process is assigned from a business role, you know a technology process is assigned from a node.
02The three aspects
| Element | Notation | What it means |
|---|---|---|
| Active structure | square-cornered rectangle | Something that can do things. Business actor and role, application component, node, device. It performs behaviour; it never is behaviour. |
| Behaviour | rounded rectangle | Something being done. Process, function, interaction, event, service. This is where the verbs live. |
| Passive structure | rectangle with a top band | Something behaviour acts upon. Business object, contract, data object, artifact, material. |
The three come with a grammar that is worth learning as a sentence: active structure is assigned to behaviour, behaviour accesses passive structure, behaviour serves other behaviour. Nearly every well-formed ArchiMate model is that sentence repeated. If a line in your model does not fit one of those three shapes, look at it twice.
03The three core layers
Business.The organisation described in its own words: actors and the roles they play, the processes they run, the services customers consume, the objects those processes handle. The test for whether something belongs here is whether a non-technical colleague would recognise the name. "Claims handling" passes; "ClaimServiceImpl" does not.
Application. The software. A component is a deployable, replaceable piece of software - the same idea as a UML component, at coarser grain. An application service is what that software offers to the business layer, named as a capability rather than as an endpoint: "claim registration", not POST /claims.
Technology.What the software runs on. Nodes, devices, system software, networks, and the artifacts (binaries, images, files) deployed onto them. In a cloud estate a node is usually a service or a cluster rather than a machine, and that is fine - a node is "a computational resource", which a managed database certainly is.
04Strategy, physical, implementation
The other three layers are used less often and are worth knowing exist, because reaching for a business process when you meant a capability produces a model that argues with itself.
| Element | Notation | What it means |
|---|---|---|
| Strategy | resource, capability, course of action, value stream | What the organisation is ableto do, deliberately independent of how. "Claims processing" is a capability; "claims handling" is the process that currently realizes it. Swapping the process leaves the capability standing, and that is exactly the point. |
| Physical | equipment, facility, distribution network, material | The technology layer for things that are not computers. Manufacturing lines, warehouses, vehicles, raw material. Ignorable in a pure software estate, indispensable in logistics or utilities. |
| Implementation | work package, deliverable, implementation event, plateau, gap | How you get from the current architecture to the intended one. A plateau is a state the architecture rests at; a gap is what is missing between two of them. This is the layer that turns a model into a roadmap. |
Plateaus are the underrated one.Two plateaus - "today" and "after the migration" - each aggregating the elements valid in that state, give you a before-and-after architecture in one model rather than two files that drift apart. The gap between them is a first-class element you can attach work packages to.
05Motivation cuts across everything
Motivation elements are not a layer under technology - they attach to elements anywhere in the model, and they answer the question no other layer can: why is the architecture shaped like this?
| Element | Notation | What it means |
|---|---|---|
| Stakeholder | a role with an interest | Someone whose opinion of the architecture matters. Usually a role. |
| Driver | a steering wheel glyph | Something creating pressure to change. Cost, regulation, competition. |
| Assessment | a magnifier glyph | A finding about a driver. The evidence, dated and specific. |
| Goal | a target glyph | An intended end state, stated so you could tell whether you got there. |
| Outcome | a hit target | A result actually achieved. The past tense of a goal. |
| Requirement | Something the system must do to realize a goal. Realization is the relationship that connects the two. | |
| Principle | same glyph as requirement | A rule that applies to the whole architecture rather than one system. |
| Constraint | same glyph again | A restriction on how a goal may be realized, not on what it is. |
Influence is the relationship that only motivation uses, and it is deliberately weaker than the rest: it says the source affects the target without claiming how much or in which direction. It can carry a +, -, or a weight, which is how you say that one goal helps a driver and another one hurts it.
06How much of this to use
Reach for it when
- Business, application and technology - almost every model needs these three
- Motivation, as soon as anyone will ask why in six months
- Strategy, when the conversation is about capability rather than systems
- Implementation, when the deliverable is a roadmap and not a snapshot
Reach for something else when
- Physical, unless the organisation moves atoms as well as bits
- Every layer at once in one view - split by viewpoint instead
- Strategy as a synonym for business - a capability is not a process
- Motivation as a place to paste the requirements document
A first useful model is usually three layers and a handful of motivation elements. The other three layers are there when the question needs them, and a model that uses all six is either a genuinely large enterprise or a model nobody will maintain.
In one line each
- 01Six layers times three aspects places every element type in the language.
- 02Active structure does, behaviour is done, passive structure is acted upon.
- 03Square corners, rounded corners and a top band are the three outlines that say which.
- 04A service is behaviour - a rounded box - not the component that offers it.
- 05Strategy is capability, business is process; they are different layers on purpose.
- 06Motivation attaches anywhere and is the only layer that records why.
Related reading