I went to see a talk by Simon Brown organized by the Amsterdam Java Users Group (JUG) in the (quite awesome, to be honest) facilities of Miro in Amsterdam. (Facilities tour on YouTube)
Simon has a new book out, The C4 Model, published by O'Reilly. It will be available for purchase in the next few days. Simon said that when O'Reilly contacted him about writing a book he told them that he did not have much material, so it would necessarily be a small book. O'Reilly replied that it's okay, times have changed, people do not actually like big books nowadays, they prefer small books. (I guess this is one more way, in the already long list of ways, in which we are witnessing the demise of humankind.) Anyway, the animal on the cover is a Western Tree Hyrax, and no, Simon did not choose it, O'Reilly always chooses the animal.
Since I do not often travel to Amsterdam, I suffered from a bit of anxiety to be there on time, and as a result I arrived there very early. So, I had the opportunity to have a chat with the very friendly organizer Geertjan Wielenga, who then introduced me to Simon, so I had the chance to have a chat with him too, one-on-one, for a decent length of time, which is something that I was completely unprepared for.
I admire Simon Brown for caring about the same things that I care about, and for having skill and charisma in talking about those things, but the truth is that we disagree in just about everything. (-:=
Simon believes that software architecture should be strictly descriptive (suggestive), whereas I believe it should be prescriptive (authoritative). I said to him that as things stand today, there is nothing to guarantee to me, the architect, that the programmers and the operations folk have implemented the system exactly as I designed it. Furthermore, as the system evolves, there is nothing to guarantee that the design still matches the implementation.
Simon agreed that this is a bit of an issue, but went on to speak of existing verification tools that somehow compare systems against their intended designs. I told him that I find this to be way too roundabout and clunky. I brought electronic design as an example of what we should ideally have, where a schematic diagram, being an authoritative design document, can be sent to a manufacturing shop that will turn it into a functioning electronic board with close to zero human intervention.
Simon indicated that he was fully familiar with the paradigm, but went on to say that some people would argue that in software we do not need authoritative architecture because we have the code. I indicated that I am well aware of this proposition, and counter-argued that this is equivalent to saying that the design of a one-million-line-of-source-code software system is the million lines of source code that make up that system, which is as preposterous as saying that the design of the Great Wall of China is a listing of all the bricks that make up the Great Wall of China.
Simon indicated that he saw my point but went on to say that model driven architecture was tried in the early 2000s and it was not a success. He mentioned that the failed attempts invariably involved code generation. I think we both agreed that code generation as a central feature of a software architecture toolset is a bad idea. I told him I believe I have a recipe that will make model driven architecture work, but I do not know what to do with it because it is too much work for a single person like me. He told me that I should try my luck with the academia, they tend to like such things.
There are many other ways in which me and Simon disagree.
For example, Simon does not mind UML at all, whereas I abhor UML, as I have explained in my post On UML.
As another example, Simon believes that code is one of the concerns of software architecture. That's what the fourth "C" stands for in his C4 model. In contrast, I believe that architecture need not, and should not, be concerned with code.
Besides the layer of code, Simon is quite insistent in his C4 model that we need exactly three more layers, with fixed responsibilities: Components, Containers, and Context. In his talk he mentioned that people have objected to him that this is quite unmanageable when we have dozens or even hundreds of components inside a container, and his answer is that in this case, we should visualize the components as little circles instead of boxes, which is essentially saying "well, draw them smaller!". In contrast, I favor the notion of Hierarchical System Composition, which means that any component can in turn be a container, encapsulating other components, to an arbitrary level of nesting. Also, a container can act as context for its constituent components, so we do not need context as a separate layer, either. This fundamentally opposes the C4 model which, in a (noble, but amiss) attempt to bring order and simplicity to our discipline, prescribes exactly four layers; no more, no less.
So, when I wrote that we disagree in just about everything, I did really mean it. (-:= Nonetheless, I like the guy. I do not want to sound like I am dissing him.
Among other take-aways from Simon's talk, A.I. does not seem to (currently?) fare particularly well with:
- creating C4 designs from source code
- writing source code from C4 designs.
I postulate that an authoritative software design mechanism would fare much better in these regards, because the results of the conversion would be verifiable in an automated fashion.
Cover photo: Simon Brown at Miro Amsterdam, photo by michael.gr, 2026-07-01.