Tooling

Every section so far has ended on the same quiet warning: diagrams go stale. We've now reached the section that does something about it. The C4 model tells you what to draw; this section is about how to draw it so your diagrams stay alive instead of rotting in a wiki. The short version: general-purpose drawing tools are where architecture diagrams go to die, and "Architecture as Code" is how you keep them breathing.

But before we get to how, one liberating fact.

C4 is notation- and tooling-independent

The C4 model does not mandate a specific tool, a specific notation, or a specific set of colors and shapes. It tells you what abstractions to use (people, systems, containers, components) and at what level of detail — and then it gets out of your way. You can draw a perfectly valid C4 diagram with:

• Sticky notes on a whiteboard during a design session.
• A generic diagramming tool like draw.io, Lucidchart, Miro, or PowerPoint.
• A diagrams-as-code tool like Structurizr, Mermaid, PlantUML, or Ikandi.

All of these can produce legitimate C4 diagrams. So this section isn't about which tool is "allowed" — it's about which approach keeps your diagrams accurate over time, because that's the battle most teams lose.

Why general drawing tools fail

Drawing tools — draw.io, Lucidchart, Visio, PowerPoint, and friends — are wonderful for a first sketch. Reach for a whiteboard or draw.io when you're brainstorming; nothing beats them for thinking out loud. The trouble starts when that sketch becomes your official documentation. Then three problems set in:

1. Manual maintenance guarantees staleness. Every drawing is hand-placed, box by box, arrow by arrow. When the architecture changes — a new service, a renamed container, a rerouted dependency — a human has to remember to open the tool, find the right file, and painstakingly update the picture. In practice, nobody does. The code ships; the diagram doesn't. Within weeks the "official" diagram is quietly lying to everyone who trusts it. This is the reason teams stop trusting diagrams, and it's baked into the drawing-tool workflow.

2. Inconsistency creeps in. Because each diagram is drawn by hand, the same container is a blue rectangle on one page and a grey rounded box on another. Levels get mixed. Naming drifts. Five diagrams of the same system look like five different systems — the exact chaos C4 set out to eliminate.

3. No single source of truth. Your System Context, Container, and Component diagrams are three separate image files with no connection to each other. Rename the "Backend API" and you must find and fix it in three places (and you'll miss one). Nothing enforces that the containers in your Container diagram are the same ones referenced in your Component diagram. The model exists only in the pictures, and the pictures don't agree.

Notice that all three problems have the same root cause: the diagram is a hand-made artifact, disconnected from any underlying model. Fix that, and all three problems dissolve at once.

The fix: Architecture as Code

"Architecture as Code" (or "diagrams as code") flips the workflow on its head. Instead of drawing diagrams, you describe your architecture once, in a text-based model, and let a tool render the diagrams from that model automatically.

You define your people, systems, containers, components, and the relationships between them — once — in a structured text file. The tool then generates every diagram (Context, Container, Component…) as a view onto that single model. The benefits fall straight out of this design:

• One source of truth. Define the "Backend API" once. It appears, consistently, in every diagram that references it. Rename it in one place and every view updates.
• Consistency for free. Every diagram uses the same elements, styles, and naming automatically, because they're all rendered from the same definitions by the same engine.
• Version control. Because the model is text, it lives in Git right alongside your code. You get diffs, history, code review, and blame. A change to the architecture becomes a reviewable pull request — "we added a caching container" shows up in the diff.
• Automation. You can regenerate diagrams in CI, publish them to a docs site automatically, and even keep them close to (or derived from) the codebase — so updating the architecture and updating its picture become the same act, not two.

This is the same philosophy we met at Level 4: generate, don't hand-maintain. Architecture as Code simply applies it to every level.

Structurizr: a tool built for C4

The flagship example — and the one most closely associated with the model — is Structurizr, created by Simon Brown, the author of the C4 model himself. It was purpose-built around exactly the ideas above.

The core idea of Structurizr is that you create a single model of your software architecture — the people, systems, containers, and components — and then define multiple views onto that model. Each view becomes one of your C4 diagrams. Because every diagram is a view of the same underlying model, they can never drift out of sync with one another: change the model, and every view that shows the changed element updates automatically.

A few things worth knowing about it:

• You can define the model using the Structurizr DSL, a clean, human-readable text format designed specifically for C4 — or programmatically via code (there are Java, .NET, and other language bindings).
• Because the model is code/text, it lives in version control, gets code-reviewed, and can be rendered in an automated pipeline.
• It handles the tedious parts for you — consistent styling, keeping elements in sync across views, and laying diagrams out — so you focus on describing the architecture rather than drawing it.

Structurizr isn't the only option (Mermaid — which we've used for the examples throughout this guide — and PlantUML with its C4-PlantUML extension are popular, lighter-weight, text-based choices too). But it's the most complete embodiment of the "one model, many views" philosophy, and it comes straight from the source.

Picking your approach

There's no single right answer — match the tool to the moment:

Situation	Best fit
Brainstorming, early design, workshops	Whiteboard, sticky notes, draw.io
A quick diagram embedded in a README or wiki	Mermaid or PlantUML (text, renders in-line)
Living documentation that must stay accurate over time	Structurizr (single model, many views, in version control)

A pragmatic path many teams take: sketch on a whiteboard to think, use Mermaid for lightweight diagrams that live next to the code, and graduate to Structurizr once the architecture is important enough that keeping the diagrams honest really matters.

The takeaway

The tool doesn't make your architecture good — but the wrong tool quietly guarantees your diagrams will be wrong, and a wrong diagram is worse than no diagram. Treat your architecture as a model you describe once and render many times, keep that model in version control next to your code, and the staleness problem that has haunted every previous section simply goes away.

With the model understood and the tooling sorted, there's only one question left: how does your team actually start doing this on Monday morning? That's the subject of our final section.

---

Previous: ← Supporting Diagrams · Next: Conclusion & Next Steps →