The design · 5 min read
An A3 sheet for a fifteen-minute reader
Why is the overview one printed sheet, what does the A3 method force on it, and what do the two sheets drawn so far show?
Roar Elias Georgsen, 27 August 2026
Part 8 of 13 in Federating a systems model, written for release v0.3.0.
The story so far
The demo publishes a SysML v2 model, a capacity analysis and a requirements document as three GraphQL services. A router serves them as one graph, with two web apps in front, all in one container. Part 7 introduced the architecture, drawn as five views with twenty-six decisions behind it. This part is about the opposite problem, getting the essentials onto a single sheet of paper.
The reader I have in mind is an engineering manager, or a systems engineer new to federation, deciding in a quarter of an hour whether the approach deserves a closer look. That reader isn’t going to open an architecture description with five views and twenty-six decision records. What they need fits on one sheet of paper.
So the design phase made the Markdown description and the decision records the record of the architecture, and the sheets its overview (the architecture record decision). When the design changes, the record changes first and a sheet follows at its next re-issue. So a sheet can lag behind, and its status says so.
Why A3
Key term A3 architecture overview
A way of summarising one aspect of a system’s architecture on a single sheet of A3 paper, from Borches and Bonnema, developed at Philips Healthcare. The sheet carries simple models of the system, such as what it does, the numbers that matter and how it’s built, with a short text summary.
I adopted A3 for what it forces more than for its rituals. Four things make it worth the effort.
It gets read. Borches found that people came to meetings having read the A3, when they hadn’t read the equivalent document (the 2010 paper). A 2025 study at a Norwegian company, by Bergtun and Engen, found readers spending ten to fifteen minutes on a sheet. Over 90 per cent of them said they understood the system better for it.
It forces a choice. Each sheet takes one aspect, and nothing that doesn’t fit. Borches’ cookbook for the method puts it bluntly: “you can’t put everything you know about this topic in this A3! So do not try to do it.” Anything else goes on another sheet, or stays in the record.
It keeps notation out. The sheet carries no formal modelling notation, because in Borches’ own experiments with SysML “most of the meetings with experts was spent discussing the notation itself rather than the content”. That’s a dry thing to find in the literature behind a project about SysML, and a fair warning to me.
It layers. Practice settled on a small hierarchy: an L0 sheet for context, an L1 for the technical overview, and L2 sheets for topics. A reader starts at the top and goes only as deep as they need.
I took the rest of what the method offers as guidance, and used it where it helped.
Four sheets, two drawn
Each sheet has one goal question its reader should be able to answer afterwards:
| Sheet | Goal question |
|---|---|
| L0, Federating a systems model | What does this demo claim, what is in the box, and what would I keep or replace if I adopted it? |
| L1, Three subgraphs, one graph | What do the three services agree on, and what happens when a number changes? |
| L2a, Adapter: projecting SysML v2 | How does a model file become a subgraph, and where does the adapter stop? |
| L2b, Pipeline example: capacity and verdicts | Why does raising one server change nothing and raising another change everything? |
I drew L0 and L2b first, because they carry the argument and the memorable moment. L1 and L2a were to follow once the schemas stopped moving. At release v0.3.0 neither has been drawn, and the sheet index says so.
L0, the argument on one page
The L0 sheet: the argument as eight numbered boxes on the left, what the services agree on and what’s in the box top right, the container bottom right. The whole sheet is L0, Federating a systems model.
The reading path is the argument for federating a systems model in eight boxes:
- Author the model as text, in Git.
- Publish a projection of it, plain types and no metamodel.
- Attach an analysis that knows nothing about SysML.
- Attach editorial structure that knows nothing about it either.
- Compose the three into one graph, checked before deployment.
- Serve two apps from the one graph.
- Change a number in either app.
- Watch the verdict and the document follow.
Beside the reading path sit the numbers a manager asks about: one image, one command, one port, and how little the services have to agree on. The container view marks what an adopter would keep (the adapter, the compose step, the supervisor) and what they’d replace (the model, the example services, the apps and the document tree).
I first drew L0 with the numbers the design could only estimate, and re-issued it on 29 August once the build had measured them. It now shows the image at 45 MB for amd64 and 41 MB for arm64, against an 80 MB ceiling. It also shows the two-second bound on an edit as met.
L2b, how the number is made
The L2b sheet: seven numbered boxes, the wiring in three states beside them, the arithmetic and its table top right. The whole sheet is L2b, Pipeline example: capacity and verdicts.
L2b is for anyone who has run the demo and wants to know why the bottleneck moved. Its seven boxes go from reading the five servers and their wiring, through the flow and the cut, to the verdicts. They end on the two lessons. Raise a server outside the cut and nothing moves. Raise one inside it and the cut migrates. Its table is the worked example from From use cases to requirements, row for row. A note under the boxes spells out the limits of the idealised capacity model the sheet rests on.
The next part leaves the design behind, and plans the build.
Previous: Five views and twenty-six decisions · Index: Federating a systems model · Next: Planning the build