Free starter resource
Architecture diagram templates (ArchiMate & Visio starting points)
Six ready-to-adapt enterprise-architecture views that most teams need sooner or later — described so you can recreate each one in ArchiMate, Visio or directly in Archilu. For every view you get what it shows, the core elements and relationships to use, when it earns its keep, and how to build it in Archilu. These are neutral starting points to adapt to your own organisation, not a finished model.
No binary stencil or .archimate file is provided here on purpose — element names and notations evolve, and a clear, paraphrased description travels better across ArchiMate, Visio and Archilu than a locked file. Copy the structure below into your tool of choice.
What is an ArchiMate viewpoint?
A viewpoint is a deliberately narrowed picture of your architecture aimed at one audience and one question — for example, "which applications support this capability?" or "what breaks if this server goes down?". Rather than drawing everything at once, you pick the few element types and relationships that answer the question and leave the rest out. ArchiMate organises elements into layers (broadly: business, application and technology, plus motivation and implementation) and gives each a standard notation, so the same view reads the same way to everyone. The six views below are the workhorses; build them once and reuse them.
Business capability map
ArchiMate layer: Business / strategy
What it shows
A stable, technology-neutral picture of WHAT the organisation does — its capabilities — grouped into a small number of top-level areas with a layer of more specific sub-capabilities beneath.
Core elements & relationships
Capability elements arranged in a nested grid (typically two or three levels of decomposition). Relationships are mostly composition/aggregation (a capability is made up of sub-capabilities). Avoid mixing in processes, org units or applications — those belong on other views.
When to use it
As the backbone for investment decisions, application rationalisation and target-state planning — because capabilities change far more slowly than org charts or systems.
Build it in Archilu
Build the capability tree in Archilu, then link applications, cost and risk to each capability to turn the map into a decision tool.
Application landscape / cooperation
ArchiMate layer: Application
What it shows
The portfolio of applications and how they cooperate — which systems exist, what they do, and the main information flows between them.
Core elements & relationships
Application component and application service elements, connected by serving and flow relationships to show who uses whom and what data moves. Optionally group components by business domain or capability for readability.
When to use it
To get a shared, honest inventory of the estate before any consolidation, integration or migration programme — and to spot duplication and tangled point-to-point links.
Build it in Archilu
Maintain the application inventory in Archilu and let the cooperation view stay in sync as components, owners and interfaces change.
Application-to-capability mapping
ArchiMate layer: Business + application
What it shows
Which applications support which business capabilities — the bridge between the business view and the IT estate. Often shaded as a heat map (coverage, cost, health or redundancy per capability).
Core elements & relationships
Capability elements on one axis, application components on the other, joined by serving relationships (an application serves a capability). Many-to-many links are normal — one capability may be supported by several apps, and one app may touch several capabilities.
When to use it
To find capabilities with too many overlapping applications (rationalisation candidates) or too few (gaps and risk), and to prioritise investment by business value.
Build it in Archilu
Create the mapping in Archilu and overlay cost and lifecycle so over-served and under-served capabilities surface automatically.
Technology / infrastructure
ArchiMate layer: Technology
What it shows
The technology that runs the applications — servers, platforms, system software, networks and the deployment of components onto nodes.
Core elements & relationships
Node, device, system-software and technology-service elements, with applications assigned to the nodes that host them, plus communication paths between nodes. Keep it at the level you actually manage rather than every cable.
When to use it
For data-centre and cloud migration, end-of-life and patch planning, resilience reviews, and tracing applications down to the infrastructure they depend on.
Build it in Archilu
Model nodes and platforms in Archilu and link applications to their hosting so technology lifecycle and risk roll up to the business view.
Application dependency / impact
ArchiMate layer: Application (cross-layer)
What it shows
What depends on what — so you can answer "if this changes or fails, what is affected?" both upstream and downstream of a chosen element.
Core elements & relationships
A focal application component with its serving, flow and dependency relationships traced outward to the applications, services and (optionally) capabilities and infrastructure it touches. Direction matters: separate "depends on" from "is depended on by".
When to use it
For change-impact and risk analysis, incident and resilience planning (including DORA-style scenarios), and decommissioning — knowing the blast radius before you act.
Build it in Archilu
In Archilu an impact view is a live query over the connected model — pick an element and see everything up- and downstream, kept current automatically.
Roadmap / transition
ArchiMate layer: Implementation & migration
What it shows
How the architecture moves from today (baseline) to the target over time, via a small number of intermediate plateaus, with the work packages that get you there.
Core elements & relationships
Plateau elements representing stable intermediate states on a timeline, gaps between them, and work-package and deliverable elements that close each gap. Often shown as a simple time-axis swimlane.
When to use it
To align stakeholders on sequencing, show what changes in each step, and link the architecture vision to an actual delivery plan and investment case.
Build it in Archilu
Capture baseline, plateaus and target in Archilu so the roadmap stays tied to the real model and updates as the architecture evolves.
How to use these templates
- 1Pick the view that answers the question you actually have right now — don't model everything at once.
- 2Reuse the same element types and naming every time so views stay comparable across teams and over time.
- 3Keep each view readable: if a diagram needs more than roughly 20–30 boxes, split it or raise the level of abstraction.
- 4Connect views through shared elements (the same application appears in the landscape, the dependency view and the capability mapping) so they stay consistent.
- 5Recreate the view in Archilu and attach real data — owners, cost, lifecycle, risk — so the picture drives decisions, not just documentation.
Go deeper on ArchiMate
Standard & attribution
ArchiMate is a registered standard of The Open Group. The layer, element and relationship names referenced here are paraphrased and used only to describe neutral, commonly-needed views; no copyrighted specification text is reproduced. For authoritative definitions and the full notation, consult the official ArchiMate specification from The Open Group. These templates are independent starting points to adapt and are not endorsed by or affiliated with The Open Group.
From a diagram to a living architecture model
Drawings go stale. In Archilu these views become a connected model — applications, capabilities, technology and risk linked together — so an impact analysis or a rationalisation case is a query, not a redraw. The EA Maturity Assessment is a fast way to see where to start.