Book review: Fundamentals of Software Architecture by Mark Richards and Neal Ford

Verdict: A principle-centred guide for architects and non-architects

This book is an in-depth study about what constitutes software architecture and how it shapes software solutions. I picked up this book in preparation for a new job. I thought I should solidify my hitherto very basic knowledge of software architecture (I am not a developer or architect myself). My goal for reading this book was to be able to have a meaningful discussion with an architect during my next project and fully understand his or her architectural decisions, which will have an impact on me in my role as project manager or business analyst.

I could not have picked up a better book for this objective because the authors put a lot of emphasis on explaining the reasoning behind architecture (what it is, why you need it) and within architecture (the trade-offs of architectural decision-making). The first part of the book, called “Foundations” (which covers around a third of the pages), goes into great lengths in introducing fundamental concepts that you need to understand before the authors event present the first architecture style in Part 2. They start with “why” instead of diving right into what you would naively expect from a book about software architecture (to list all different architecture styles).

The journey into the “why” starts with a very clear definition of the authors’ understanding of software architecture. The main thing that has always annoyed me about other books and lectures that I have seen about the topic is that nobody dares to define software architecture in a practical way. Fluffy descriptions such as “the stuff that is difficult to change later” or “the stuff that matter, whatever that is” only help those who are already on the inside. Other definitions are too abstract. The Carnegie Mellon University’s Software Engineering Institute compiles a long list of existing software architecture definitions. Here is an example:

The set of structures needed to reason about the system, which comprises software elements, relations among them, and properties of both.

Clements et al., Documenting Software Architectures: Views and Beyond, Addison-Wesley, 2010.

In my professional life, I have always found these kind of abstract definitions very unsatisfying because they do not help me in my day-to-day discussions. Richards and Ford, on the other hand, define software architecture as the combination of four things that you have to keep in mind when building a software solution:

• The structure of a system: The architecture style such as micro services, layered, micro kernel.
• Architecture characteristics: The “-ilities” of the system such as scalability, maintainability, security, etc.
• Architecture decisions: The rules for how a system behaves (which component can access the database ? Is data shared or stored redundantly ?).
• Design principles: Guidelines for developers on how to best implement a particular part of the system (use asynchronous messaging between components where possible).

Yes, it is a list, not an easily quotable phrase. But it is useful.

They also open their book with two almost natural laws that govern software architecture:

1. Everything in software architecture is a trade-off.
2. Why is more important that how.

These two laws permeate through the whole book and are referred to time and again. From my indirect experience of working alongside architects, I can confirm that almost all the discussions I have participated in were about weighing off the pro’s and con’s of several solution options. These trade-off considerations are so important in software architecture that Richards and Ford are about to release another book focussing on this topic (which they aptly called “the hard parts” of software architecture).

Unfortunately, I have seldom witnessed that people think about the second law. In many cases the discussion dives directly into how we could build a certain solution rather than understanding why it should be done this way and not the other.

The rest of Part 1 explains in great lengths how to define and measure modularity (since you have to break down a system in its components), the different architecture characteristics that you typically have to deal with and how to define them based on domain concerns and requirements. The different ways to measure cohesion, coupling and connascence were too much for me as a non-developer but the part about extracting architecture characteristics from domain concerns and / or requirements seemed familiar for me as a business analyst / project manager.

Part 2: Eight fundamental architecture styles

After introducing some fundamental styles like the Big Ball of Mud, they present a list of considerations or fallacies in relation to the comparison between distributed and non-distributed styles. This is one of the main dimension along which they categorise the eight architecture styles in this book:

• Layered architecture style
• Pipeline architecture style
• Microkernel architecture style
• Service-based architecture style
• Event-driven architecture style
• Space-based architecture style
• Orchestration-driven service-oriented architecture
• Micro services architecture

Each chapter presents a style’s topology (using very clear diagrammes), the situations when you would use them, the pro’s and con’s and some more technical details for their implementation. At the end, the authors also rate each style against a list of architecture characteristics (how reliable is a certain style, how costly, how is its elasticity, etc.).

This was the part that I had been most afraid of as a non-developer but each chapter is easy to understand and well written. I am not quite sure to what extent each of these styles are standalone choices or whether and how your can mix them. Here and there the authors mention some ideas of mixing styles within the same software solution but they do so in passing and without going into more details. It would have been nice to better understand the interplay between different styles when you look at the global architecture of a system.

Another thing that I would have loved to see is a bit more history about each style. They do talk about the history of orchestrated SOA but none of the other chapters really looked at when a certain styles has been used first, in what domain they were/are being used most, etc. The historical context would not have been essential to better understand each style. Just a nice to have.

There are also some technical details that I have not been able to fully grasp. For example, why is the mediator pattern of event-driven architecture considered to be event-driven at all ? It seems to me to be based on commands (i.e. initiating events) rather than driven by events (i.e., reacting to something that has happened). Why is the orchestrated SOA style a separate style on its own, next to the “simple” (or maybe choreographed?) SOA ?

Part 3: The soft bits of software development

Part 3 was a little bit of a nice surprise to me. I had been expecting a book about the “hard bits” of software architecture, i.e., the fundamental styles presented in Part 2. In this last part of the book, Richards and Ford go beyond the technical elements of software architecture and look at some underlying skills of architects and some processes of an organisation that will help make software architecture effective. They present, for example, ways to document architecture decisions or analyse risk. Most importantly, though, they look at how an architect can build an effective collaborations with development teams and what types of leadership skills she might need in her relationships with developers, business stakeholders or other architects.

I especially appreciated the three different types of architect personalities that they use to classify a person’s behavioural style in his/her role as an architect: The control freak, the armchair architect and the effective architect. Their personality descriptions fit perfectly to the people I have worked with. Whereas Parts 1 and 2 were good reading material for non-architects and non-developers, Part 3 seems to most clearly oriented towards people who already wear the architect’s hat and want to become better at the people side of their job.

What I liked

• A practical definition of software architecture that I can work with on a daily basis.
• Clear and easy to understand presentations of the fundamental architecture styles.
• The laws of software architecture, which will be another useful idea to keep in mind in the office.
• The book’s focus on explaining the “why” of software architecture in general and of each of the architecture styles in particular.
• The book is very well written and not too long. The separation into three clearly distinct parts makes it easy to refresh your memory and read up on a topic later on.
• Great visualisations and examples throughout the entire book.
• The fact that they cover the “hard” parts as well as the “soft” side of being an architect.

What I did not like

• I would have been nice to find out a bit more about the historical context of each architecture style or even the history of architecture in general. I suppose it would have made the book too long in the end but maybe half a page per architecture style would have been enough.
• The bits about measuring modularity were too technical for me and I doubt that many architects use those formulas on a daily basis. The book also talks about software solutions that provide you KPIs with those measurements about the fitness of your solution. Maybe focussing on these solutions a bit more would have added more practical value to the book.