C4 Model in Practice: Communicating Architecture to Every Stakeholder

Architecture diagrams fail for one of two reasons: too much detail for the audience, or too little. Simon Brown's C4 model solves this by providing a hierarchy of perspectives — Context, Containers, Components, Code — each calibrated for a different stakeholder and level of concern.

We've standardised on C4 across all our architecture engagements. This article is our field guide: how we use each level, which tools we've settled on, and how we integrate C4 diagrams with the Architecture Decision Records that give them meaning.

Level 1 — System Context: For Business Stakeholders

The System Context diagram shows one system in the centre, the people who use it, and the external systems it interacts with. Nothing about technology. Nothing about implementation. Just: what is this thing, who uses it, and what does it depend on?

We use Level 1 diagrams in executive briefings, steering committees, and vendor discussions. They're the starting point for every architecture review — before we discuss solutions, we agree on what the system boundary is and who it serves. This sounds obvious but is frequently skipped, leading to architecture conversations that conflate different concerns from the start.

Level 2 — Containers: For Technical Decision-Makers

The Container diagram zooms into the system to show the deployable units: web applications, APIs, databases, message queues, mobile apps, file systems. This is the level where technology choices become visible — "we use PostgreSQL here, a Symfony API here, a Redis cache here."

Level 2 is our most frequently used diagram. It's the right level for Architecture Review Board submissions, security reviews, integration planning, and onboarding senior developers to a new system. It answers "what are the moving parts and how do they communicate?" without requiring knowledge of the internal implementation.

Tooling: Structurizr DSL Over Draw.io

We moved from draw.io to Structurizr DSL for all C4 work two years ago and haven't looked back. The advantages are significant: diagrams are defined as code (version controlled, diffable, reviewable), the model is single-source (change a container once and all diagrams that reference it update), and the output is consistent without manual alignment work.

Integrating C4 with Architecture Decision Records

A diagram without context is decoration. We link every significant architectural choice visible in a C4 diagram to an ADR that explains why that choice was made. The container diagram for a system becomes an index: every technology label links to the ADR that justifies its selection.

This practice dramatically reduces the "why did we do it this way?" questions that consume senior architect time. The answer is always in the linked ADR — including the alternatives considered and the trade-offs accepted.