Simon Brown is the creator of the C4 model for Visualising Software Architecture and the founder of Structurizr, the original developer-friendly “diagrams as code” tooling for version-controlled architecture documentation. An independent consultant based in Jersey, he has spent 15+ years helping hundreds of organizations across roughly 40 countries communicate their software architecture more clearly. His new book, “The C4 Model: Visualizing Software Architecture”, arrived from O’Reilly this month.
Episode Overview
Why have software architects, declared dead a decade ago, suddenly turned up again on client org charts? And how did a set of plain block diagrams Simon Brown used to sketch for his own day job become a whiteboard standard you can spot everywhere from Miami to London to Mumbai?
Simon tells the origin of C4 with characteristic modesty (he calls it “really boring”). It started in mid-2000s London, where he ran architecture workshops, looked at the diagrams people drew, and realized he couldn’t understand any of them. With UML on its way out and no appetite to bring it back, he taught people the block diagrams he already used at the office. That became C4: four levels of abstraction, one at a time, with a Google Maps-style zoom from a broad system context into containers, components, and code.
From there the conversation ranges across the architecture revival and what’s driving it (compliance gaps, lost water-cooler knowledge, and a flood of AI-generated code nobody understands), why Simon refused to build a drag-and-drop editor and made a text-based DSL instead, the deployment diagram he thinks is the most slept-on view in the whole model, and a candid comparison of how developer cultures differ on either side of the Atlantic. It’s a clear-eyed, plain-spoken look at the craft of drawing software so other people can actually read it.
Links & Resources
Guest Links
Structurizr and the Structurizr docs
The C4 Model: Visualizing Software Architecture by Simon Brown (O’Reilly, 2026) — the rewritten and expanded successor to his self-published LeanPub C4 book; first six chapters are in early access
Software Architecture for Developers by Simon Brown (Leanpub)
Books & Articles Mentioned
The Culture Map: Breaking Through the Invisible Boundaries of Global Business by Erin Meyer — the book Dave references on cross-cultural communication and negotiation styles, which maps how different cultures approach meetings and deals (best guess at the title Dave couldn’t recall in the moment; worth confirming before publishing)
Tools, Frameworks & Concepts
Structurizr DSL — a lightweight, text-based domain-specific language for defining a C4 model as code; a wrapper over the original Structurizr for Java library, built during COVID lockdown
Model Context Protocol (MCP) — Simon added MCP tooling that runs validation and parsing so an LLM can read the error messages and fix its own invalid DSL
PlantUML — text-based diagramming tool; Structurizr can export views to it
Mermaid — diagrams-as-code tool with a C4-style syntax that doesn’t enforce C4 semantics or view rules
UML — the OG modeling notation that fell out of favor after the Agile Manifesto, leaving the gap C4 filled
The C4 abstractions — system context, container, component, and code, plus the supporting system landscape, dynamic, and deployment diagrams
Topics & Key Points
The "Boring Origin Story of C4
Simon traces C4 back to the architecture workshops he ran in mid-2000s London, where he discovered he couldn’t make sense of the diagrams participants drew. With UML already on the way out, he simply taught the block diagrams he used in his own day job.
Key points:
The work grew out of consulting: growing a consultancy meant creating more tech leads and architects, so Simon started teaching people how to move into those roles
C4 is “a formalization of the block diagrams” he drew in a post-UML world, shaped over years of feedback rather than designed as an invention
The name stuck even though most teams use only the top two levels; Simon jokes it could just as well be called “C2 plus two optional levels”
One Level at a Time
The main move with C4 is to stop putting everything on one page and instead focus on a single level of abstraction at a time, zooming in Google Maps style from the system context down toward the code.
Key points:
The “everything on one page” everything-diagram puts almost everyone off: non-technical stakeholders, infrastructure folks, and product owners all tune out
Slicing the picture into levels invites more people to the party: business and UX people engage with the context diagram because they’re thinking about how users reach their goals, and infrastructure and DevOps people gravitate to the container diagram
The container diagram closes the gap between dev and ops who want to collaborate but speak different languages; network engineers have told Simon that the diagram finally let them understand what the developers actually hand over to run and monitor
Code-level diagrams are almost never drawn (Simon has done it once), and even component diagrams are niche, most useful when planning a service extraction from a monolith or arranging a new small-to-medium monolith
The Architecture Revival
Dave notes that architect roles are reappearing among clients in 2026 after years of backlash against “ivory tower” architects. Simon offers two theories for why.
Key points:
Theory one: organizations that swung from heavy upfront design all the way to “working software over comprehensive documentation” overcorrected, and now fail compliance audits, hold critical knowledge in tribal silos, and don’t fully understand the software running their business; COVID made it worse by erasing water-cooler knowledge transfer
Theory two: AI and vibe coding produce thousands of lines of code nobody understands, can review, or knows how to fit into existing systems, nudging teams back toward some planning, not months of it, but enough to bring structure
Dave frames the shift as planning and feedback loops moving left up the value stream, now reaching into architecture and product conversations
A good plan plus small, reviewable slices (build a slice, then pause and review) is producing strong results in Dave’s own workflow
Diagrams as Code with Structurizr
Simon explains why he turned down a WYSIWYG editor for C4 and instead built a text-based DSL, and why that choice has aged well in the AI era.
Key points:
He’s a developer. He likes text, version control, and diffs. Drag-and-drop canvases give a low barrier and quick wins but become unmanageable at scale (picture adding one system that connects to forty others by ticking boxes in a GUI)
The earliest Structurizr tooling required writing Java, which few people wanted, so during lockdown Simon built the lightweight Structurizr DSL as a wrapper over the Java library; the first version took about a week
The DSL is model-based: one text file can drive multiple views with consistent styling, and relationships defined at lower levels bubble up automatically to reduce what you have to write
All this turns out to be AI/LLM-readable too; Simon added MCP tooling so an LLM can run validation and parsing, read the error messages, and fix its own invalid output
Unlike Mermaid, which offers a C4-style syntax without understanding C4’s semantics or view rules, the Structurizr DSL bakes the rules in and won’t let you mix abstraction levels; you can still export to PlantUML or Mermaid when your toolchain needs them
The Slept-On Diagrams
Beyond the four static levels, Simon walks through the supporting views people tend to overlook, and names his favorite underrated one.
Key points:
The system landscape diagram is essentially a context diagram without a single-system focus, a wider view of the world around you
The dynamic diagram shows how one feature works at runtime as a set of collaborations; it’s genuinely useful but underused, and the trick is to document recurring patterns rather than drawing one per feature
Simon’s pick for most slept-on is the deployment diagram; the common mistake is superimposing the production cloud environment onto the container diagram, when the container diagram should stay deployment-environment-agnostic with a separate deployment diagram per environment
Simon’s static-content example makes it concrete: the same set of files is mounted into an NGINX Docker container in development and pushed to an S3 bucket served via Cloudflare in production
On representing change over time, the options range from current and future-state copies, to additive DSL extensions, to a future-state tagging mechanism that drives separate views, to color-coding (with a caution to watch for red-green color deficiency)
Two Sides of the Atlantic
The episode closes on a frank comparison of developer cultures, with Dave offering the American read and Simon the European one.
Key points:
Dave’s take: US teams feel practical, results-driven, and money-focused, while the European and UK scenes lean more intellectual and ideas-driven
Simon, who has run the large majority of his workshops in and around Europe, sees more friction, overhead, and bureaucracy in the typical US enterprise, and a stronger learning culture inside European organizations
He caveats the comparison heavily, noting he has never run a workshop in California or Silicon Valley and is deliberately carving that out
Dave mentioned a book on cross-cultural communication and negotiation styles, “When Cultures Collide: Leading Across Cultures (4th Edition)” by Richard D. Lewis. It contains some interesting visualizations about how different cultures run meetings, negotiations, and other business events.
Hard Boiled Software is hosted by Dave Laribee.
