The C4 Model: Visualizing Software Architecture

Simon Brown explains that the C4 Model started not as a grand design theory, but as a practical answer to an embarrassing problem: running a workshop on architecture diagramming, he realized he couldn't understand any of the diagrams being produced. The model formalized his own consulting practice of hierarchical handover documentation — context diagram at the top, containers below, components and code at the bottom — giving it a name and making it teachable. His core advice is to start with just the top two levels: context and container diagrams. These change infrequently, are quick to draw, and deliver immediate value. Levels three and four — components and code — are included for completeness but age rapidly with every commit, and in most cases aren't worth the maintenance overhead.

Two especially practical insights emerge from the conversation. First, how to handle microservices: if your team owns all the services inside a system boundary, each service is a collection of C4 containers; if you depend on another team's service that you can't see inside, model it as an opaque software system. This maps naturally to how domain boundaries and team ownership actually work in practice. Second, the surprisingly important distinction between modeling and diagramming: C4's real value is the shared vocabulary — systems, containers, components, code — not the visual notation itself. Teams using entirely different tooling can communicate clearly because they've agreed on what the words mean. Simon is firm that there will be no C4 v2; the model is intentionally lightweight, and adding more would risk turning it into the next UML — comprehensive, heavy, and largely abandoned.