Book Review: Fundamentals of Software Architecture

Categories: Architecture

Overview

I’ve recently finished reading Fundamentals of Software Architecture by Mark Richards and Neal Ford (O’Reilly 2020, isbn: 978-1-492-04345-4).

This is an interesting and useful book for anyone working the field of software architecture, or wanting to. It is a little bit unstructured; a big bag of different ideas at different levels of abstraction and sometimes the book feels like a long rambling interview or “brain dump” with/of experienced architects. But that’s useful in itself; after all, the role of software architect is also a rather fuzzy thing, as the authors state in the first few paragraphs. And overall, each of the presented topics is useful, though which are most relevant will depend upon exactly what aspect of architecture the reader is working in.

First the book addresses: what is software architecture, ie what does a software architect do? And their conclusion is: software principles are still evolving at such a rapid pace that an architect is a “change manager”. We need to be able to evaluate options and objectively weigh trade-offs. In addition, software architects are now responsible for far more “soft topics” related to processes, team and personal interaction, and communication than was historically the case. No established rules or guidelines should be considered “axioms”; everything can be challenged and reassessed.

In general, this book does not offer rules or plans. It does offer some patterns, but also emphasises an analytical approach to dealing with software - ie emphasises the ability to measure/evaluate options whatever they may be. They emphasis the importance of dealing with tradeoffs and state that the answer to many architecture-related questions is “it depends”.

The book also goes into details regarding a set of specific architectural styles (eg event-driven). I personally would disagree with many of the statements made about these architectural styles - and thereby probably prove the author’s thesis that architecture is all about “it depends”.

One nice quote from the book is: architecture is the stuff you can’t google. Everything in architecture is a tradeoff, so the right answer depends very much on context - something that doesn’t fit into a query.

I don’t see this book as a “definitive work” but it is useful as an overview of the current state of software architecture. I would recommend that every architect or aspiring architect read it, but it’s probably not a book to re-read regularly or use as a reference. It could also be somewhat confusing for those with less experience - a huge firehose of information. My suggestion: don’t get too bogged down in the details, just soak in the general philosophies and breadth of topics.

Specific Topics of Interest

Below are some of the recommendations from the book and rough notes on the topics addressed, to give you an idea of whether the book might be relevant for you..

Expectations of an architect:

  • continually analyze architecture - is the current state still the best solution (evolution)?
  • keep up with latest trends
  • ensure compliance - ideally via automation
  • have a solid body of IT knowledge
  • have business domain knowledge
  • posess interpersonal skills - decisions need to persuasive, leadership is needed - arch decisions affect many people
  • understand and navigate politics, do negotiation
  • identify architecture characteristics implicit in business requirements
  • make architecture decisions and set design principles

An architectural decision is a rule that software must follow; any exceptions (“variances”) must be explicitly approved. A principle is a guideline that software should follow where possible, but no explicit approval required for alternatives.

Architecture characteristics (the -ilities) include:

  • operational: availability/reliability/scalability/elasticity/recoverability/performance/deployability
  • developmental: agility/testability/maintainability/learnability/portability
  • other: security/confidentiality/supportability/usability

There are often tradeoffs between characteristics; not every characteristic is equally important in each project - and sometimes items are not relevant at all.

An interesting concept related to architecture characteristics is architecture quanta. When different sets of features within the requirements have different sets of architecture characteristics (eg different requirements related to security or scalability) then this suggests that the corresponding code may need to be in a distinct component in order to fulfil those requirements. Identifying the quanta can reveal the appropriate set of system components to be built.

Architects must often guide the IT rather than specify it, ie define tech requirements that solutions must fulfill. Actual solutions can then be delegated, eg choosing appropriate frameworks.

Given the large range of responsibilities, architects often need to focus on “broad knowledge” rather than “deep knowledge”. Knowing that 10 tools exist, and roughly which tradeoffs exist for each, is better than knowing one tool in depth.

An architect is also often responsible for the engineering processes, eg agile, ci/cd, and other practices.

Any chosen architecture will need to survive both the “unknown unknowns” that appear during development, and changes in requirements and the ecosystem. What is needed is an evolutionary architecture, ie guide software development into paths that are flexible enough to support later modifications. Use architecture fitness functions to measure the fit between existing software and what is important to you - eg page load times, test coverage percentage, change fail rates.

The old concept of doing architecture “up front” is dead; architecture has become an iterative process just like development. It also is a two-way partnership between the architects and the implementers. There is no longer a hard line between architecture and design; they have different levels of abstraction but overlap in the middle.

First law of software architecture: everything in software architecture is a trade-off

Second law: why is more important than how - particularly important in code-comments and ADRs!

Quote: We believe every architect should code and .. maintain a reasonable level of technical depth. Options (paraphrased) for maintaining that technical depth include:

  • being part of development teams part-time - but not “owning” code on the critical path.
  • building proof-of-concepts
  • work on technical debt tickets or low-priority bugfixes
  • building tools (automating repetitive tasks, monitoring/metrics)

Further recommended reading includes the books Building Evolutionary Architectures and Continuous Delivery (sorry, not sure which of the many books with similar names is meant here). Also, the collection of architecture katas from author Neal Ford is recommended.