ArchiMate viewpoints
The model is one thing; a view is a window cut into it for one audience and one question. Viewpoints are how ArchiMate stops a large model from becoming a poster nobody reads.
8 min readArchiMate 44 of 4
01The model is not the picture
This is the idea ArchiMate is built around and the one most likely to be missed by someone arriving from a drawing tool. There is one model: a set of elements and the relationships between them, stored once. A view is a selection from that model, arranged for a purpose. The same application component appears on six views and is still one element - rename it and all six change.
A viewpoint is the recipe a view is made from: which stakeholders it is for, which concern it addresses, and which element and relationship types are allowed on it. The viewpoint is the definition; the view is an instance of it.
02One model, two views
Notice what each view leaves out. The layered view has nothing to say about billing; the cooperation view has nothing to say about the cluster the software runs on. Both omissions are the point - a view that included everything would answer neither question well.
This is also why viewpoints and derived relationships work together. The layered view shows the cluster serving the process directly, which is a derivation of a longer chain stored in the model. The audience gets the short answer; the model keeps the long one.
03The standard viewpoints
The specification defines a catalogue of them. You do not need to memorise it, but you should know roughly which exist, because reaching for a named viewpoint is faster than inventing a layout and produces a view other architects recognise on sight.
| Element | Notation | What it means |
|---|---|---|
| Layered | every layer, one column | The overview. Business over application over technology, with the serving and realization chain between them. The one to draw first and the one executives actually look at. |
| Application cooperation | components and the flows between | The integration landscape. What talks to what, and what moves. The view an integration team lives in. |
| Application usage | services meeting processes | Which business processes depend on which application services. The impact analysis view. |
| Technology | nodes, networks, artifacts | Infrastructure on its own terms, for the people who run it. |
| Business process | processes, roles, events | The process chain with the roles assigned to it. Where a reader might otherwise expect BPMN - and often should get BPMN instead. |
| Motivation | stakeholders, drivers, goals | Why. Stakeholders, what is pushing them, and the goals in play. |
| Goal realization | goals down to requirements | The chain from an abstract goal to the specific requirements meant to achieve it. Good for arguments about scope. |
| Implementation and migration | work packages, plateaus, gaps | The roadmap, expressed as architecture rather than as a Gantt chart. |
| Capability map | nested capabilities | What the organisation can do, independent of who does it or what supports it. The starting point for strategy conversations. |
Nine of the standard set, chosen because they cover most real work. The full catalogue is in the specification and the rest are variations on these.
04Picking one for an audience
A viewpoint is defined by stakeholder and concern, so choosing one starts with a sentence of the form "X needs to decide Y". If you cannot finish that sentence, the view has no audience and should not be drawn.
| Element | Notation | What it means |
|---|---|---|
| Executive sponsor | layered, capability map | Wants the shape of the whole and where the money goes. Twelve elements maximum, no technology detail. |
| Integration architect | application cooperation | Wants interfaces and what moves across them. Flows labelled, always. |
| Infrastructure lead | technology, deployment | Wants nodes, networks and what is deployed where. |
| Product owner | application usage, business process | Wants to know which systems their process leans on. |
| Programme manager | implementation and migration | Wants plateaus, gaps and work packages, in that order. |
05Defining your own
The standard set is a starting point and the specification expects you to add to it. A custom viewpoint is worth defining when the same filtered view keeps getting drawn by hand - a "systems in scope for the migration" view, say, or a "what touches personal data" view.
Reach for it when
- The same selection of element types keeps being drawn for the same audience
- A compliance or audit question needs a repeatable, defensible view
- A domain has vocabulary the standard viewpoints do not surface
- You want a view a tool can regenerate rather than one somebody maintains
Reach for something else when
- It would be the layered viewpoint with two extra element types - just use that
- The real problem is that the model is too big, not that the views are wrong
- Nobody has asked the question the viewpoint would answer
- The definition would allow every element type, which is not a viewpoint
Write the definition down: name, stakeholders, concern, permitted element types, permitted relationship types. A viewpoint that only exists as a habit in one architect's head produces views that quietly drift apart, which is the problem viewpoints were introduced to solve.
In one line each
- 01One model, many views; a viewpoint is the recipe a view is made from.
- 02A view is defined by a stakeholder and a concern - name both or do not draw it.
- 03What a view leaves out is as deliberate as what it shows.
- 04Start with the layered viewpoint; it is the one non-architects read.
- 05Derived relationships let a view show the short answer without losing the long one.
- 06The single everything-view is a symptom, and splitting by audience is the cure.
Related reading