Book ReviewProgramming

Book Review: Building Evolutionary Architectures

Recently, I finished the new and popular book Building Evolutionary Architectures by the three (former) Thoughtworkers Neil Ford, Rebecca Parsons and Patrick Kua. Overall I was underwhelmed by the book, but continue reading for the full review and my reasons.

Content

The first chapter introduces software architecture “-ilities” as the basis for decisions made by software architects. Every software architecture wants to ensure some of these “-ilities”. Obviously, you can’t have them all, since they are not necessarily independent, or their ensurance would result in inflated costs. I found the table of “-ilities” a great collection for reference, hence, I include them here at the end of the post.

Most importantly, though, this chapter offers the following definition of an evolutionary architecture:

An evolutionary architecture supports guided, incremental change across multiple dimensions.

Here’s the gist of the definition’s components:

  • guided: separates it from something like emerging architecture and emphasizes that it’s more than just the planning aspect.
  • incremental: it’s not an upfront architecture, but change is a first-class citizen of evolutionary architectures.
  • multiple dimensions: these refer to the “-ilities”, extended with dimensions like data, security or operations.

In terms of the multiple dimensions or “-ilities” every project needs to identify these individually, as they heavily depend on the software you want to develop and its stakeholders. Incremental change as such is pretty clear already from the term “evolutionary”. What’s most interesting, therefore, is the “guided” aspect.

Chapter 2 offers the authors’ proposition on how to approach this guidance: fitness functions. Surprisingly enough, “architectural fitness functions” make an appearance on the 17th Thoughtworks Tech Radar as well. The idea of a fitness function is to have one or more automated tests for ensuring the desired “-ilities”. Think of it like this: traditional unit tests ensure correctness of units. If you run a stress test, in which you measure the page load times, it ensures the responsiveness. A test for a fitness function can hence be pretty much any sort of automated test.

Fitness functions are one of these amazing ideas that are so evident in hindsight. Of course it makes sense to have automated tests to ensure the desired properties of your software – most of us just haven’t thought of consistently applying that idea to architecture. I personally encountered many projects with some form of a fitness functions here or there, but it takes architecture to a different level when you just combine these two simple ideas:

  1. Explicitly concentrate on and decide the “-ilities” your architecture should support
  2. Write automated tests to ensure all of these “-ilities” are present in your software

This concept of architectural fitness functions is at the core of the book, which degrades heavily after that second chapter. The rest of the book looks at different traditional architectures and how they relate to the above definition, incremental change for data (database, schema, etc.), ideas on how to build or progress towards evolutionary architectures at different stages of a software’s lifecycle and antipatterns. The final chapter discusses the organisational aspects, team culture and other soft factors when trying to put evolutionary architecture into practice.

The book finishes quite suddenly, without any big words or giving you a unified overall picture that would be any grander than “do use fitness functions”.

Target Audience

This book does little in terms of explanations of concepts not introduced by the authors. It is obviously directed at (aspiring) software architects, but it also wouldn’t be understandable for junior developers. You should already have a solid grasp and some experience of real-life software architectures, the different styles and problems that come with them in order to get the most out of the book.

Style

The book can be read fluently. Apart from numerous little grammar and spelling mistakes (not unique to this book only, are books even proof-read at all these days?), you can read through it in a rather short time. Unfortunately, most parts of the book essentially come down to feeling like a Thoughtworks marketing scam. The book made me feel like I actually bought myself spam – and not the edible kind. While I appreciate the first two chapters, I would probably have like the book much more if it was a small book with only those. After these initial chapters, the authors stay extremely superficial. Every once in a while you will find an example of a fictitious company applying something of what the book talks about, but more often than not, you are left with various synonyms of the typical consultant statement: “it depends”.

It certainly is very difficult to write about software architecture without having a single software project or product in mind, but trying to address potentially all software that’s being written. This generality, however, combined with the abstractness of the architecture concept, results in a style that barely scratches the surface of most topics. While never stated as such, as a reader I constantly read between the lines that architecture is really really difficult and that Thoughtworks has a lot of experience and awesome consultants that can help me with that.

Summary

I wholeheartedly agree with the authors on the importance of architectural fitness functions. The ones I’ve seen and created in the wild have brought tremendous value. As such, I still believe this is an important book as it is the most thorough information available on fitness functions. Names are important in software development and this book gives as “fitness function” as a new name for a concept we can now reason about. Unfortunately, as discussed above, the book falls short on everything else. I would suggest the title to be changed to more closely resemble this – but I’m aware that evolutionary architecture is a much easier sell. And I kind of got the impression that “selling” was a major reason for the book to exist.

However, given that most of the book somehow relates to fitness functions, the authors still shied away of giving you interesting practical examples for these. Considering the list of “-ilities” in the appendix, I’d wager that most software architects would consider it quite a challenge to define automated tests for each of these – I know I do! I’m really looking forward to someone developing a catalog of automation ideas for fitness functions for each of the “-ilities”. Once something like that is available, I’d suggest skipping this book entirely.

Appendix

List of software architecture “-ilities”

  • accessibility
  • accountability
  • accuracy
  • adaptability
  • administrability
  • affordability
  • agility
  • auditability
  • autonomy
  • availability
  • compatibility
  • composability
  • configurability
  • correctness
  • credibility
  • customizability
  • debugability
  • degradability
  • determinability
  • demonstrability
  • dependability
  • deployability
  • discoverability
  • distributability
  • durability
  • effectiveness
  • efficiency
  • usability
  • extensibility
  • failure transparency
  • fault tolerance
  • fidelity
  • flexibility
  • inspectability
  • installability
  • integrity
  • interoperability
  • learnability
  • maintainability
  • manageability
  • mobility
  • modifiability
  • modularity
  • operability
  • orthogonality
  • portability
  • precision
  • predictability
  • process capabilities
  • producibility
  • provability
  • recoverability
  • relevance
  • reliability
  • repeatability
  • reproducibility
  • resilience
  • responsiveness
  • reusability
  • robustness
  • safety
  • scalability
  • seamlessness
  • self-sustainability
  • serviceability
  • securability
  • simplicity
  • stability
  • standards compliance
  • survivability
  • sustainability
  • tailorability
  • testability
  • timeliness
  • traceability