Conclusion

We began with a nightmare: forty-seven boxes, unlabelled arrows, and a diagram nobody understood or trusted. We're ending somewhere much calmer — with a simple, shared, zoomable way to map any software system. Let's tie it together and, more importantly, turn it into something your team can start doing tomorrow.

The whole model in one breath

Strip C4 down to its essence and it's just this: don't try to show everything on one diagram — zoom.

• Level 1 — System Context 🌍 The country view. Your system as one box, its users, and the external systems it talks to. For everyone.
• Level 2 — Container 🏙️ The city view. The deployable building blocks — apps, APIs, databases — and their technologies. For technical folks. (Not Docker containers!)
• Level 3 — Component 🛣️ The street view. The major pieces inside one container and how they collaborate. For developers of that container.
• Level 4 — Code 🚪 The rooms inside a building. Classes and interfaces — usually skipped, generated from the IDE when needed.
• Supporting diagrams Different lenses: System Landscape (the whole org), Dynamic (runtime, step by step), Deployment (where it runs).

Two habits make it all work: one level of abstraction per diagram, and every box stands on its own — a name, a type, and a one-line description, with labelled, directional arrows.

How to start tomorrow

You don't need a tool, a budget, or a committee. You need a whiteboard and thirty minutes. Here's a concrete path:

1. Draw your System Context diagram first — today. Grab a whiteboard or open draw.io. Put your system in the middle. Add the people who use it and the external systems it talks to. Label every arrow with a plain-English sentence. That's it — you've just produced the single highest-value architecture diagram most teams will ever have, and it took half an hour.

2. Then draw the Container diagram. Open up that middle box. What are the deployable units — the web app, the mobile app, the API, the database, the queue? What's each built with? How do they talk (protocols included)? For most teams, Levels 1 and 2 together are 80% of the value of the entire model. If you only ever maintain two diagrams, maintain these.

3. Add Component diagrams only where they earn it. Don't draw one for every container. Pick the one or two containers that are genuinely complex or high-risk and map their internals. Skip the thin CRUD services.

4. Skip Level 4 — on purpose. Let your IDE generate a class diagram on the rare day you need one. You're following the model correctly by not hand-drawing code diagrams.

5. Reach for supporting diagrams on demand. When a stakeholder asks "how does checkout actually work?" draw a Dynamic diagram. When ops asks "what runs where?" draw a Deployment diagram. Not before.

6. Graduate to Architecture as Code when the diagrams matter. Once these diagrams are genuinely useful, stop letting them rot in a drawing tool. Move to a text-based model — Mermaid for lightweight diagrams that live in your README, or Structurizr for a single model with many synchronized views — and put it in version control right next to your code. Now the diagram changes when the code does, in the same pull request.

A quick self-check

Before you call a diagram "done," run it past this short checklist:

• Does every box have a name, a type, and a one-line description?
• Is every arrow labelled and pointing in a direction?
• Is the whole diagram at a single level of abstraction (no stray class-level detail on a Container diagram)?
• Could someone outside the team understand it without a verbal walkthrough?
• Is it stored somewhere it will actually be kept up to date (ideally next to the code)?

If you can answer yes to all five, you've got a diagram worth trusting.

The mindset shift

The deepest lesson of C4 isn't the four levels — it's a change in attitude. Architecture diagrams aren't a one-time deliverable you produce for a review and then abandon. They're a living map of a system that's always changing. C4 gives you the shared vocabulary and the zoom levels; tooling like Structurizr keeps the map honest. Together they turn diagramming from a dreaded chore into one of the highest-leverage things a team can do — onboarding new engineers in hours, grounding design debates in a shared picture, and surfacing risky dependencies before they surface themselves at 2 a.m.

Start small. Draw your Context diagram this week. Everything else follows from there.

Resources to go deeper

• The official C4 model website — the canonical reference, by Simon Brown.
• Interactive example — click through a real set of C4 diagrams.
• Structurizr — the diagrams-as-code tool built for C4 by the model's creator.
• Mermaid C4 syntax — the lightweight, text-based approach used for the examples in this guide.
• The C4 model (book) and the talk on video — Simon Brown explaining it in his own words.

---

Previous: ← Tooling · Back to Introduction