The C4 Model: Visualizing Software Architecture • Simon Brown & Susanne Kaiser • GOTO 2026
Simon Brown, creator of the C4 Model, discusses its origin as a practical solution to clarify messy software diagrams. He explains the four hierarchical levels (context, container, component, code), emphasizing that most teams only need the top two for significant value. The discussion highlights the importance of including technology in diagrams, C4's collaborative nature, and practical advice on modeling microservices and bounded contexts, all while advocating for a lightweight, accessible approach to architectural visualization.
The interview with Simon Brown, creator of the C4 Model, delves into the model’s origins, principles, and practical application in visualizing software architecture. Brown emphasizes the C4 Model as a practical solution to “messy boxes and arrows” diagrams, aiming to bring structure and shared understanding to software architecture communication in a post-UML world.
Origin and Purpose of the C4 Model
Simon Brown explains that the C4 Model was born from a practical problem he encountered while teaching architecture diagramming. He realized attendees’ diagrams were unintelligible. Rather than adopting heavyweight notations like UML, which was in decline, he formalized his own consulting practice of hierarchical handover documentation. This method involved starting with a high-level context diagram, followed by container diagrams, and then component and code diagrams, providing a clear, traceable path from code to system boundary and vice-versa. The core value of C4 lies not just in its visual notation but in establishing a shared vocabulary of “systems, containers, components, and code,” enabling clear communication even with diverse tooling.
The Four Levels: Context, Container, Component, Code
The C4 Model defines four levels of abstraction:
- System Context Diagram: Shows the software system in scope and its relationships with users and other external software systems.
- Container Diagram: Zooms into the system to show the containers (applications and data stores) that make up the system, their responsibilities, and the technology choices.
- Component Diagram: Focuses on the internal structure of a single container, detailing its components.
- Code Diagram: The lowest level, showing the implementation details of a component (e.g., classes, interfaces).
Brown strongly advises teams to primarily focus on the top two levels (System Context and Container diagrams). These diagrams are quicker to create, change less frequently, and provide significant value by illustrating the system’s external environment and internal structure. Levels three and four (components and code) are included for completeness but are highly volatile, changing with almost every code commit, making their maintenance overhead generally not worth the effort for most teams.
Importance of Technology in Diagrams
A key aspect of the C4 Model is its insistence on including technology choices directly on the diagrams. Brown argues that technology selections (e.g., Java, Spring Boot, MySQL) are inherently architectural decisions, impacting team skills, frameworks, and operational concerns. Including them on diagrams makes the representations more “real world,” fosters ownership among developers, and completes the architectural picture.
Getting Started and Collaborative Nature
To adopt C4, Brown recommends starting small:
- Draft a System Context Diagram: A 30-minute whiteboard session can define the system, its users, and key integration points.
- Proceed to Container Diagram: If the context diagram proves valuable, detail the applications and data stores within the system.
C4 is notation and tooling agnostic, allowing teams to start with whiteboards before moving to tools like Structurizr for version control. Brown emphasizes that the model’s true benefit comes from its collaborative development. Engaging a team to sketch ideas fosters shared understanding, which he notes is superior to AI-generated diagrams alone. Creators typically include software architects, tech leads, and engineers, while a wide range of consumers like operations, security, compliance, and even product owners find these diagrams invaluable for their respective functions.
Modeling Microservices and Domain-Driven Design (DDD)
Brown provides specific guidance for modern architectures:
- DDD Bounded Contexts / Feature Teams: These should not be modeled as single C4 software systems. Instead, individual software systems (e.g., microservices, distinct applications) each maintain their own C4 diagrams. Feature teams or stream-aligned teams working across multiple services would modify the respective diagrams for each affected service.
- Microservices:
- If your team owns a collection of microservices within a system boundary, each microservice is modeled as a collection of C4 containers (e.g., a Spring Boot API + MySQL schema).
- If you depend on another team’s microservice, and cannot see its internal implementation, model it as an opaque C4 software system. This approach aligns with Conway’s Law and team ownership boundaries.
Scope and Future of C4
The C4 Model is best suited for bespoke enterprise software (e.g., Java, C#, Ruby applications). It is less effective for embedded systems, integration-heavy applications (Salesforce, SAP), or low-code/no-code platforms, as these are outside its core design philosophy.
Regarding the future, Brown does not foresee a “C4 v2.” The model has been stable since around 2017-2018, with continuous refinement rather than major overhauls. He believes the current lightweight nature is crucial to its success, distinguishing it from heavyweight, often abandoned, alternatives like UML. The focus remains on helping teams effectively adopt and apply the existing model.