The shape of an architectural artefact
EOModeller blog · post 002
The previous post argued that architects model for at least seven distinct reasons, and that most tools serve only one or two of them. The tool that is excellent for documentation is hostile to thinking. The tool that is excellent for thinking cannot be promoted into reference material. Architects compensate by switching between tools — Excalidraw for the meeting, Bizzdesign for the repository, PowerPoint for the executive summary — and every switch costs work, because each new tool demands the artefact be re-authored from scratch.
This post is about why that happens, and about a frame for thinking about it that I've found unreasonably useful. Once the frame is visible, it becomes obvious why existing tools fight the architect, and what a tool that didn't fight the architect would look like.
The frame
Every architectural artefact can be located on two axes.
The first is formality. At one end, a hand-drawn whiteboard sketch with free-text labels, arrows drawn with whatever style felt right, no notation discipline. At the other end, an ArchiMate diagram that passes model validation, with typed elements, conformant relationships, populated attributes. Low formality accepts whatever the architect puts down. High formality enforces the rules of a specific notation.
The second is detail. At one end, three boxes and two arrows — the minimum required to make a point. At the other end, every relevant element, every attribute, every relationship, every exception path. Low detail is selective; high detail is complete.
These two dimensions are independent. You can have a strict ArchiMate diagram with only four elements on it — high formality, low detail. You can have a richly annotated whiteboard diagram with fifty things on it — low formality, high detail. They are different dimensions of how fully the artefact is specified, measuring different things.
Together, they describe a two-dimensional space. Philippe Kruchten, in a 2009 chapter on architectural representation, described architectural knowledge as evolving along both dimensions: from intuitive and informal toward structured and abstract; from simple diagrams toward specific languages. The two-dimensional space he described is the space every architect's working life inhabits, whether they can articulate it or not.
Four quadrants, all real
The space divides naturally into four quadrants, and each is a legitimate place for an artefact to live.
The sketch — low formality, low detail. Three wobbly boxes in a Tuesday-morning meeting. The purpose is to communicate an idea quickly, with no commitment beyond "approximately this shape." The sketchiness of the aesthetic is not a limitation; it is a social signal that says this is thinking, do not over-interpret. If the audience begins debating the exact position of the arrow, the signal has failed.
The whiteboard explosion — low formality, high detail. The whiteboard after an hour of brainstorming. Many elements, many annotations, much captured thinking, but still no discipline about notation. Free-text labels everywhere. This is the richest form of informal thinking, a dense capture of a design conversation. It represents significant work and would embarrass anyone if filed as a reference artefact.
The overview — high formality, low detail. A carefully-composed ArchiMate Application Layer view showing the five key applications and their high-level relationships, omitting the dozens of others that would clutter the view. Every element is typed. Every relationship conforms to ArchiMate's rules. But the view is deliberately sparse — it exists to show shape, not to document everything. Executive summary diagrams live here. Reference architecture overviews live here. Good ones are hard to produce and disproportionately valuable.
The reference artefact — high formality, high detail. The HLSD. The full specification. Every element present, every attribute populated, every relationship typed and specified. The artefact that the implementation team reads, the governance body approves, and the auditor checks.
All four quadrants are real, and architects work in all of them. The proportions vary by role — a solution architect probably spends more time in the top-right than an enterprise architect does — but no architect works in only one quadrant for long. A senior enterprise architect in a healthy practice might move through all four quadrants in a single Tuesday.
Movement is the point
If the quadrants were all we had to talk about, the frame would be mildly interesting but not especially useful. Every experienced architect already knows, implicitly, that different kinds of diagrams serve different purposes, even if they've never drawn a 2×2 about it.
What makes the frame useful is what happens between the quadrants. An architectural idea, in a healthy practice, moves across the space as it matures. It starts in the low-formality, low-detail corner — a sketch capturing an early thought. As conversations refine the idea, detail accumulates, and the artefact drifts toward the top of the space. As the notation tightens and the elements become recognisable, formality increases, and the artefact drifts toward the right. Sometimes the movement is along one axis and then the other; sometimes diagonal; occasionally backwards — a reference artefact gets demoted to draft when a major redesign invalidates it.
This movement is the architect's actual work, and it is precisely what existing modelling tools make impossible.
The reason architects reach for Excalidraw in meetings is not that Excalidraw is better than their organisation's enterprise tool. It is that the movement from the bottom-left quadrant to anywhere else is broken in the enterprise tool. The enterprise tool refuses to serve the sketch phase at all — it demands typed elements, validated relationships, populated attributes before it will do anything — so the sketch phase has to happen somewhere else. Whatever is produced somewhere else cannot be promoted into the enterprise tool without being re-authored from scratch, which is expensive, so the promotion mostly does not happen. The sketch is lost after the meeting. The idea that it captured survives only in the architect's head, and in whatever re-drawing they eventually do in the formal tool — a re-drawing that is less faithful than the original, because some of the original's subtlety evaporated in the gap.
Every existing tool has this problem, in a different direction.
Anti-patterns
Each tool category sits at a specific position in the quadrant, and has no mechanism for movement.
The enterprise repositories — Bizzdesign, LeanIX, Sparx in its default configuration — implicitly assume the top-right quadrant is where work lives. Every diagram demands typed elements. Every relationship must be valid. The tool is, in effect, refusing to serve the other three quadrants. The result is that architects do not use it for the other three quadrants, which is most of the work.
The casual diagramming tools — Excalidraw, drawio, PlantUML, Mermaid — occupy the low-formality half of the space, but have no mechanism to move out of it. An Excalidraw diagram cannot be promoted to formality; it is fundamentally a collection of visual primitives with no semantic backbone. These tools are good at what they do, but their output is disposable by design. The sketch that captured a critical architectural insight is still just boxes and arrows, with no way to become anything more.
The interesting exception is Balsamiq. Balsamiq chose the low-formality, moderate-detail quadrant and defended it aggressively for more than fifteen years. Their sketchy aesthetic is not a limitation; it is a product thesis. Wireframes should look provisional, because otherwise stakeholders start arguing about button colours during the concept phase, when the concepts themselves have not yet settled. Balsamiq's refusal to allow diagrams to become polished is exactly what makes it useful. Balsamiq is honest about its position in the quadrant, and treats that position as a strategic commitment rather than a feature gap.
Balsamiq works because it named its corner. The formal tools do not work for daily architectural practice because they assume their corner is the only real corner. The casual tools cannot produce durable artefacts because they have no corner at all, just an aversion to formality. None of them accommodate the movement that architectural work actually requires.
What a quadrant-native tool would look like
What would a tool that served the whole space look like?
It would treat formality and detail as first-class properties of every diagram, not as decorative options buried in menus. An architect opening the tool would see, for any given diagram, where in the quadrant it currently lives. The axes would be continuous rather than binary, because the phases of architectural work are not discrete — a diagram progressing from sketch to draft to reference moves smoothly through many intermediate positions.
The artefact's visual rendering would follow from its position. A diagram at low formality would render with hand-drawn aesthetics, signalling thinking in progress the same way Excalidraw does. A diagram at high formality would render with clean geometric precision, signalling reference material. Positions in between would render in between — slightly loose at the edges, mostly clean, or fully loose and sketchy. The visual would be a continuous function of the position, and the architect would control the position directly.
Validation would also follow from the position. A diagram at low formality accepts any label, any relationship, any element type. At high formality, the same diagram is checked against the notation's full rules, with violations flagged as errors. Between the extremes, warnings or informational messages indicate departures from strict conformance without preventing the work. The point is that the tool does not impose rigour the architect has not asked for, and does not withhold validation the architect wants.
Most importantly, movement across the quadrant would be a property change, not a redraw. The architect who drew a sketch in a meeting, and whose sketch captured the essential structure of a design, could promote it to draft or reference by adjusting its position. The underlying elements and relationships persist. The visual rendering and the validation behaviour adapt to the new position. New detail can be added; missing attributes can be populated; element types can be tightened. The artefact matures in place, on the same substrate it was born on, without being re-authored.
No existing commercial tool works this way. Sparx has a hand-drawn rendering mode and a whiteboard diagram style, both buried in menus and unconnected to each other — decorative options that do not express anything about what the artefact is for. Bizzdesign, LeanIX, and Ardoq assume the high-formality quadrant and offer no mechanism to retreat from it. Excalidraw and drawio offer no mechanism to leave the low-formality quadrant. The ideas behind a quadrant-native tool are not new — Kruchten was describing the arc fifteen years ago — but no one has implemented formality and detail as structural properties of the artefact rather than as styling choices. Retrofitting them into an existing tool requires rethinking rendering, validation, and UX at once, and no incumbent with an installed base can afford to do that.
What this changes about practice
Once the quadrant is visible, several things about architectural practice become easier to see and easier to do.
It becomes possible to say where a given artefact should live, and to notice when an artefact is being asked to live in a quadrant it was not designed for. The one-page executive summary does not need to be a high-detail reference artefact; it needs to be a high-formality low-detail overview, and demanding more will make it worse. The Tuesday-morning sketch does not need to be promoted to reference; it needs to remain a sketch, because its value was in the conversation it served.
It becomes possible to plan the movement of an artefact through the space as part of the design process, rather than treating the movement as a re-drawing tax. The initial sketch captures an idea; the draft adds detail and begins applying notation; the reference locks in rigour and completes specification. Each phase has its own acceptance criteria — not "is this diagram correct" but "is this diagram correct for its position."
And it becomes possible to have honest conversations about what each artefact in the organisation's architecture repository is for. The classic trap of enterprise EA — assuming every diagram is a reference artefact — dissolves once the quadrant is available. Some artefacts are reference, and belong in the repository. Some are drafts, and belong wherever design conversations are happening. Some are sketches, and belong in the meeting notes they came from. Storing them all in the same place at the same formality level is what makes enterprise EA repositories feel hostile to real work. It is not that the repositories are wrong to want formality; it is that they are wrong to treat formality as binary.
Where this is going
EOModeller is being built around the frame in this post. Formality and detail are first-class properties of every diagram. The visual rendering follows from the position. The validation follows from the position. Movement across the quadrant is a property change, not a redraw. You pick the position; the tool adapts.
The next post will be about what that looks like in practice — the UI for setting position, the behaviour when you move across quadrants, the consequences for how a single architectural idea lives and grows on a single substrate.
For now, though, the frame itself is what I wanted to get on the page. Architectural work is not uniform; artefacts live at different positions, and move between them, and the tools we have refuse to accommodate the movement. The quadrant is not a clever model someone imposed on the discipline. It is the shape of the work, visible as soon as anyone looks.
EOModeller is in pre-release development. If you want to hear when it's ready, request early access. The book that accompanies the tool, Models That Matter, is in draft; the chapter this post is based on will appear there in longer form.