Software Architecture for Developers

By Simon Brown (LeanPub or website)

The version of this book I read was a bit older, recently he split the content in 2 separate volumes. Also, important parts of the book were presented in various conferences like the ones in the links above, or this YouTube video.

Simon Brown is the author of C4 Model for software architecture, described in the books but also on C4Model.com. His model is easy to understand, splitting the architecture visualizations at 4 different levels of abstraction: context, containers, components and classes (C4):

1. Context: A high-level diagram that sets the scene; including key system dependencies and actors.

2. Container: A container diagram shows the high-level technology choices, how responsibilities are distributed across them and how the containers communicate.

3. Component: For each container, a component diagram lets you see the key logical components and their relationships.

4. Classes

A better approach is to create a number of diagrams at varying levels of abstraction. A number of simpler diagrams can describe software in a much more effective way than a single complex diagram that tries to describe everything.

Sketching is a fantastic way to communicate a lot of information in a relatively short amount of time

I jumped in the middle of the book, with C4 model / diagram, but if I would have started properly, with the beginning, I should have quoted these:

This collection of essays knocks down traditional ivory towers, blurring the line between software development and software architecture in the process. It will teach you about software architecture, technical leadership and the balance with agility.

This book isn’t about creating a new approach to software development, but it does seek to find a happy mid-point between the excessive up front thinking typical of traditional methods and the lack of any architecture thinking that often happens in software teams who are new to agile approaches. 

Architecture, regardless of the domain, is about structure and vision.

As you can see the book is mainly addressed to developers, especially to those who want to switch roles to software architecture, in an agile environment. It's very easy to read, at beginner level, I'd say, but nonetheless informative by listing and discussing many options and sticky points of architecture role. After a quick introduction of what architecture means, it asks questions like: Should software architects code? Should software architects be master builders? Should they be external contractors or internal to organization? Is everybody an architect? And so on.

But then, one of the most meaty part is about architectural drivers, quality attributes, principles, constraints and collaboration.

Despite people’s aspirations to be agile, collective code ownership and a distribution of the architecture role are likely to hinder chaotic teams rather than help them. Chaotic teams need a more direct leadership approach and they will benefit from a single point of responsibility for the technical aspects of the software project. In other words, they will benefit from a single person looking after the software architecture role. Ideally this person will coach others so that they too can help with this role. [...] Agile or not, the software architecture role exists.

A good working knowledge of the business domain is essential. [...] A deep knowledge of the business domain only comes from working within that domain for an extended period of time

The software architecture role is about technical leadership 

Technology isn’t just an “implementation detail” and the technology decisions that you make are as important as the way that you decompose, structure and design your software system. Defer technology decisions at your peril.

Software architecture is a platform for conversation

Then it describes in details an often missing part of agile architecture: documentation. It has a list of topics documentation should have, with many examples and options.

“Working software over comprehensive documentation” is what the Manifesto for Agile Software Development says and it’s incredible to see how many software teams have interpreted those five words as “don’t write any documentation”. 

He also has a part about risks and quantifying them, as well as a very touchy part of how much is just enough up front design?

I liked a lot his saying, repeated couple time throughout the book that "technology isn't just an implementation detail", which is very true.