Blog

iSAQB Software Architecture Gathering

Independent Consultant
Published on October 23, 2026

When Good-Looking Diagrams Aren’t Good Enough: Simon Brown on C4, AI, and Software Architecture

 

In preparation for his SAG 2026 session “The C4 Model, Structurizr vNext, and AI,” Simon Brown talks about the current state of the C4 model, how architecture diagrams can capture systems as they evolve, and why AI-generated diagrams may look convincing without actually being good architecture documentation.

 

1. Is C4 already part of the "establishment" or do you still meet people in the trade that haven't heard of it?

This has always been a tricky question to answer, and remains so today given the hype around AI. After all, even despite their importance, diagrams and documentation are always seen as “nice to have”. I don’t have any empirical evidence, but I suspect that most software engineering teams are still not creating software architecture diagrams, or they are creating ad hoc “boxes and lines” diagrams that don’t use a specific approach/notation. A growing number of teams are certainly using the C4 model, or at least are aware of It, but I wouldn’t say that it’s part of the “establishment”. I know plenty of organisations that have adopted the C4 model as their de facto approach to software architecture diagramming, but I’m also regularly running workshops to introduce the topic to teams that are looking to adopt it.

2. C4 covers static structure and deployment modeling (+ visualization), will it ever reach into behaviour description?

The C4 model does define a “dynamic diagram”, which allows you to show the interaction between static structure elements at runtime to implement a given use case, feature, etc. The visual format of this diagram borrows from UML’s collaboration and sequence diagrams. So, to some extent, the C4 model can be used to cover the behavioural aspects of software at runtime. Other behavioural aspects can be modelled with existing UML activity diagrams, state charts, etc alongside the C4 model. 

3. What do you think about modelling the evolution of architecture, i.e. showing old, deprecated, or future elements of a system? Can I use C4 for modelling modernisation strategies?

Yes, you can use the C4 model to cover the evolution of an architecture over time. The general approach is to create a collection of C4 model diagrams that model the current state, and create variations of these to signify elements/relationships that are being modified, added, or removed at various points in time. The way you achieve this will vary based upon the tooling that you are using, the simplest being to use a colour coding for modified/added/removed elements, or to use “layers” on top of a base diagram to highlight the differences. A more sophisticated modelling tool may provide a way to add metadata to elements and relationships (e.g. via properties, tags, etc) and allow you to define views based upon that metadata, showing and hiding the elements/relationships applicable for that stage in the evolution. With my Structurizr tooling, you could define a single architecture model, tag items as “current” or “future”, and define separate views onto the model that target those specific tags. 

4. Using LLMs, it has become very easy to create tons of (plausibly sounding) architecture documentation, including diagrams (Structurizr, Mermaid, PlantUML) — is that an improvement? What effects do you see when people generate diagrams? Should they not?

This is one of my biggest sources of frustration at the moment! I’ve seen dozens of new tools introduced since the start of 2026, many of which claim to automatically generate C4 model diagrams just by connecting the tool to your git repo. I’ve also seen a large number of architecture diagramming skills for AI agents. These tools do tend to create very plausible looking diagrams, but the majority of them are terrible. In short, they exhibit the exact same problems as ad hoc “boxes and lines” diagrams created by humans – exactly the same problems I highlight in chapter 1 of my new O’Reilly book. People who truly understand the art of good software architecture diagrams will see these issues instantly. Those without that knowledge won’t though, and are, of course, unable to usefully review or critique them either. Tooling plays a part here too. Mermaid and PlantUML are diagramming tools, and don’t enforce the rules of the C4 model in any meaningful way. The Structurizr DSL has the rules of the C4 model built into it, which immediately avoids a whole category of common problems associated with misusing the C4 model, irrespective of whether humans or LLMs are generating the DSL. Even if you don’t want to use my Structurizr tooling, I’d still recommend asking your LLM to generate Structurizr DSL (in conjunction with the free Structurizr MCP server), which you can then export to Mermaid or PlantUML if required.

5. How long does it take to learn C4 modelling? Should I take a class? Where do I start?

The c4model.com website is reasonably small, and my new O’Reilly book is in the region of 150 pages. There are also several of my conference talks available on YouTube. So you can learn the basics of the C4 model in a couple of hours. The issue, as ever, is applying that knowledge. My recommendation for starting with the C4 model is to read the book, grab some colleagues, and sit down for an hour or two with the task of creating a system context diagram and a container diagram for whatever is it you’re building as a team. These two diagrams give you a lot of “bang for your buck”, they are reasonably easy to create, and likely won’t age rapidly when the code changes. The absolute best approach is to join one of my 1-day workshops, where we cover all of the theory behind software architecture diagramming and the C4 model, with a couple of practical exercises that provide a way put the ideas into practice in order to solidify the knowledge.

 

Many thanks to Simon for the great interview!