I have just finished reading Software Architecture for Developers by Simon Brown. It is a very nice and well-structured book. Any aspiring or experienced architect should find something useful in it. In this post I would like to summarize what I have found especially interesting and reference some other great sources on this topic.

A few words about the author

If you have not met Mr Simon Brown yet, he has done a lot of work on preaching gospel about software architecture. Aside from this great book he made tons of presentations on multiple conferences. To just link one of his cool presentation checkout this one. In the above video Brown describes succinctly his approach to software architecture.

So what really is software architecture?

Simon provides a lot of views on what different people think software architecture is. His definition says that it is anything related to the significant elements of a software system. I like the explanation that it is everything that is hard to change, everything that will cost us a lot of money and time to change. Grady Booch quote fits here perfectly:

Architecture represents the significant design decisions that shape a system, where significance is measured by cost of change.

Do we really need it?

As Brown highlights many people think that when incorporating agile in their project then architecture and documentation are no longer needed. They want to avoid big design upfront, but actually go to the other extreme. There is also a problem in thinking that code is the documentation. This approach is somewhat true, however there are a lot of questions that the code itself cannot answer (like ‘why these technologies have been chosen’, ‘how scalability is achieved’, ‘how security is ensured’, etc.). We should bear in mind that too much documentation is bad, but too little is also not any good. I like Brown’s clarification on this topic:

Just enough up front architecture and design

Benefits

So what can be accomplished with software architecture? You get a fair amount of benefits:

• express goals of the system (requirements and constraints)
• create a clear vision and roadmap
• identify and avoid risks
• ignite discussions across the team about how software should work (architecture as a platform for conversation)
• introduce standards and guidelines

The C4 model

With the strong decline of UML use in modern IT projects the model suggested by Brown seems to be a lighter and more sensible solution.

C4 stands for:

• context - a birds-eye view of the system with its dependencies and actors (systems/users) that even non-technical people should understand
• containers - a more-detailed diagram showing technology choices and distribution of responsibilites accross the system; this diagram is meant for technical people that are trying to grasp what containers are in the system (by container you should understand web server, database, file system, etc.); mentioning protocols used by the system (HTTP, JMS, etc.) can be very beneficial here
• components - a diagram explaining the components/services: how the system is structured and what are the containers consisting of?
• classes - optional diagram of classes in the system (usually code is enough at this point)

Software architecture guide book

Simon published a free guide book on how you can introduce the C4 model to your projects. Beneath are some diagrams presented in the book. I would be more than grateful, if I could receive such documentation for a system I am taking over.

Context

Containers

Components

Structurizr

In order to incorporate C4 model Simon is recommending Structurizr. It is not free, but still worth considering. You can check here how the techtribes.je project is visualised in Structurizr.

Software architecture checklist

Brown provides a great checklist that can be run against the C4 model.

Some more stuff to ponder on…

O’Reilly has a very cool set of videos on software architecture presented by Neal Ford and Mark Richards - two fantastic architecture masters. I would recommend to start with “Understanding the Basics” and then move on to “Beyond the Basics”. After that your brain will be filled with a lot of concepts around software architecture.