Building Evolutionary Architectures: Support Constant Change

by Neal Ford, Rebecca Parsons, Patrick Kua

The software development ecosystem is constantly changing, providing a constant stream of new tools, frameworks, techniques, and paradigms. Over the past few years, incremental developments in core engineering practices for software development have created the foundations for rethinking how architecture changes over time, along with ways to protect important architectural characteristics as it evolves. This practical guide ties those parts together with a new way to think about architecture and time.

Genres: Technology, Programming, Architecture, Software, Computer Science, Technical, Nonfiction

190 pages, Paperback

Published October 13, 2017

About the author

Neal Ford is Software Architect and Meme Wrangler at ThoughtWorks, a global IT consultancy with an exclusive focus on end-to-end software development and delivery. He is also the designer and developer of applications, instructional materials, magazine articles, courseware, video/DVD presentations, and author and/or editor of 5 books spanning a variety of technologies. He focuses on designing and building of large-scale enterprise applications. He is also an internationally acclaimed speaker, speaking at over 100 developer conferences worldwide, delivering more than 600 talks. Check out his web site at http://www.nealford.com. He welcomes feedback and can be reached at nford@thoughtworks.com.

Reviews

[Jared Davis · Rating 1 out of 5]

I do not enjoy writing bad reviews, and less so for a book that I've only partially read, but I believe it's warranted in this case. Lots of people will encounter Building Evolutionary Architectures in their professional life -- either as current or as aspiring software architects and/or team leads -- and they'll make decisions based on what they learn ( or misunderstand ). So I think it's fair to pan the book with the understanding that I just want people building software and managing projects do a great job and don't create more confusion than already exists out there.

I have a simple complaint: the author does not seem to know much about evolutionary theories. I am not an expert either, but I do understand three things:

1. an evolutionary theory explains (with predictive power) the effect of reproduction on a species' population
2. an evolutionary theory explains (with predictive power) the effect of survival of an individual has on a species' population
3. an evolutionary theory explains (with predictive power) the effect of mutation (or adaptation) on a species' population

A "fitness function" basically encapsulates some interpretation of those three aspects of evolutionary theories. The output basically predicts growth or decline of a species population given adjustable parameters.

So what's an evolutionary theory of software architecture? What's a "species" in terms of software architecture? What does it mean for an architecture to "reproduce", or "survive", or "mutate"? The book does a woeful job settling these terminological points.

One might defend the book's approach by suggesting that evolutionary theories serve only as a metaphor, and that a reader should not look for a close correspondence between the practices the authors describe and the theories that inspire those descriptions. But I am not so sure.... why reach for a highly technical ( and not-at-all-unified-yet ), deeply researched collection of biological theories as the basis for a business-process metaphor if you're not going to be precise? It's too easy to be mistaken about the science in such a way that the business-practices become pathological... hence, one star.

[Emre Sevinç · Rating 3 out of 5]

This book is a very high-level overview of the current thinking and challenges in modern software architecture and design. If you can stand the overuse and overstretching of terms from physics and biology such as "quantum", "quanta", "fitness function", etc. you can have a general idea about what it means to design for changeability.

If you subscribe to the idea that the software architecture means "the parts that are difficult to change", you already know how important to it is to design for relatively easy change, because change is one thing that will certainly happen to any software-intensive system that can survive at least a few months.

Some parts of the book is like time travel where the authors compare the architectural patterns from the end of 1990s and beginning of 2000s, and how things changed as of 2018: within the space of few pages they compare and contrast enterprise service bus based architectures with microservices.

The downside of the book: if you aren't already familiar with most of the concepts and techniques, it'll be difficult to understand what the book is all about. And if you're already familiar, then you know that for many of the topics mentioned, there are dedicated and well-written books.

If you want a very broad and high level overview, this book might serve you for a short period of time. If you want to go into more detail, you'll have to dive into titles such as Infrastructure as Code: Managing Servers in the Cloud and Architecting for Scale: High Availability for Your Growing Applications.

[Mihnea · Rating 4 out of 5]

Revolves around fitness functions, the evolvability of systems, and other "-ilities" across multiple dimensions of architecture layers, company political layers, and also time layers, referring to having fast time-to-market for cost optimization.
An interesting note is the mention of Conway's law: "Organizations design systems that mirror their own communication structure.", which is more and more evident by the examples and use cases presented in the book.

[npacenop · Rating 2 out of 5]

Let me first say that I've still got a deep respect for the authors, even though I didn't particularly enjoy this book.

I've been tracking the work of the authors (and their peers) for some time now and am somewhat invested in the field of evolutionary architecture myself. That being said, I was somewhat disappointed that there were rather only a few new ideas in there for me. The whole book felt more like a unstructured taxonomy on current buzzwords.

[Ricardo Cavalcanti · Rating 4 out of 5]

The book builds on top of ideas from Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation and Building Microservices: Designing Fine-Grained Systems, feeling almost like a continuation.

This book is an agile take on classic software architecture work. The idea of fitness functions as a way to evaluate the architecture as it is being built is very interesting.

It feels a bit short. I'm looking forward to a "Building Evolutionary Architectures: Fieldbook" with more real life examples.

[Avraam Mavridis · Rating 1 out of 5]

What a waste of paper... the only outstanding about this book is how the authors managed to expand in 174 pages the simple "All software evolve over time, plan for changes"... Thank god I read it because of my subscription to Oreily and I didnt had to pay for it... 40 euros for 174 pages of buzzword driven nothingness. The book is the perfect example "lets take something that exist over years, wrap it in a new buzzword and re-sell it"

[Franck Chauvel · Rating 3 out of 5]

Neil explains how to use continuous delivery and other modern engineering practices to build architectures that better sustain time and avoid rotting.

I think this text explains well how various practices and tools fit together (DDD, CD, testing, etc.) but does not dive into any. I don’t know if the analogy with evolutionary computing and its fitness functions really helps those unfamiliar with it. What I found less clear is how to decouple those fitness functions from the code so as to enable evolution.

[João Paiva · Rating 4 out of 5]

First book I read that has "architecture" in the title. Very easy read. Good overview of the concepts, and with tons of pointers to more material. Maybe a bit shallow, and I didn't fully buy the main thesis (the few and far between parallels with biology seem more of a marketing move than an actual valuable addition). It also seemed to have the underlying stance of "architects vs developers" which I solemnly hate, but ignoring that it has some pretty good content.

[Steve Fenton · Rating 4 out of 5]

Firstly, this is an interesting read and there are several concrete ideas that I know I'm going to use. The writing style makes it easy to read (see below) and the concepts are supported by clear diagrams and descriptions.

I recommend this book to any developer interested in the bigger picture.

I can't end this review without mention of the disastrous proof reading in this, the first edition (October 2017). It is practically impossible to catch every mistake when preparing a book for release, but the number of basic mistakes is truly exceptional. Having to re-read so many sentences to "make them work" drove me to distraction.

I still recommend this book, but be aware that there are a goodly number of sentences you'll need to rewrite mentally as you go.

Please fix this in the second edition!

[Gabriel Santos · Rating 5 out of 5]

This is a great resource for technologists of all kind, specially for solutions and enterprise architects.

In the book not only do the authors introduce the fitness function concept but they also talk rather deeply about evolutionary architecture, degrees of coupling and cohesion of architectures thoroughly.

I would also highlight chapter 7 whereas they present several anti patterns to evolvability.

I rate this book 5 stars specially because, despite some subjects are not new to me, the way the authors present the matters bring them to the surface on a new perspective shedding light on the very core aspects of architecture.

[Tbueno · Rating 3 out of 5]

The book contains good content, but it feels much more like a compendium that a book with new ideas.

This book is basically a summary of https://www.goodreads.com/book/show/1... and https://www.goodreads.com/book/show/8.... If you have read both these books, "Building Evolutionary Architecture" will bring no novelty to your knowledge about modern software architecture.

The premise of "Evolvability " as one of the "ities" (scalability, security, etc..) we should be concerned with in an architecture is interesting, though.

[Adam Sipos · Rating 3 out of 5]

A couple of good ideas but I was expecting more.

[Geert · Rating 2 out of 5]

Metaphors aside, the basic message of the book is good, though not new. It just scratches the surface. If you want in depth stuff, read other books.
I found the examples redundant.

[Osvaldo Santana Neto · Rating 4 out of 5]

The beginning of this book is barely boring and repetitive. They try to explain the concept of fitness functions in several ways but it's a simple concept: automated testing for for architectural aspects of your systems. You define the main aspects of your system and create automated tests to ensure this characteristics. After 40% of the reading the things becomes more "practical" and authors propose some strategies to implement this kind of tests.

[Robson Castilho · Rating 4 out of 5]

Livro bem sucinto e 100% teórico, com foco maior em estratégia para adoção de arquiteturas evolutivas. Dedicado a arquitetos/líderes técnicos, traz importantes conselhos e serve como boa referência para consultas. Recomendo.

[Muhammad Khan · Rating 5 out of 5]

A great attempt at packaging the latest state of the art, software engineering practices with a focus on building "agile" architectures.
A must read for anyone working in software, at any level.

[Vlad Romanenko · Rating 3 out of 5]

The first half of the book is very high-level and hard to read. It talks a lot about fitness functions but I'm afraid even after reading the entire book I still don't have as clear understanding about fitness functions as I'd like.

However chapters 4, 6 and 7 have some practical advice and offer comparison of different architectural approaches. I found it very useful to learn about the evolution of architectural approaches over time. I see myself going back to these chapters for some useful thoughts on

[Victor · Rating 3 out of 5]

This book gives a high level overview of building evolutionary architectures. An evolutionary architecture supports guided, incremental change across multiple dimensions.

Changes are guided by fitness functions that check if the most important architectural characteristics are on target. Examples vary from coding standards to performance, security.

Incremental changes cover both building and deploying software. The authors emphasize the importance of a deployment pipeline if you want to make incremental changes.

Some of the dimensions that are affect the evolvability of the system are: technical (languages, tools, frameworks), data, security.

All in all, this is an interesting book, but it only scratches the surface. If you want to find out more, you'll probably need to have a look at other books, like Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation, Domain-Driven Design: Tackling Complexity in the Heart of Software, Building Microservices: Designing Fine-Grained Systems

[Manu Pk · Rating 4 out of 5]

The book speaks about fitness functions, to solve this concern. An architectural fitness function provides an objective integrity assessment of some architectural characteristics. So, in a system there may be many characteristics that we want to measure, so you would write separate fitness functions for each of them. In the book, a fitness function is not defined in a concrete way but rather in an abstract form of graphs, tests or any other methods by which we know that our system is doing good with the change. This means you would still need to use your intellect not only to write the fitness function but also to make sense of them.

For me, the best thing about the book is, it provides software architects with a rich vocabulary to communicate their intentions behind their choices to a variety of audiences, including business stakeholders, teams, and engineering leadership. The book also gives you it's a survey of various architectural approaches. It also talks about some of the practical ideas on how do we implement evolutionary architectures I particularly like the focus on the organizational factors and how does it apply to the software architectures.

In conclusion, I would recommend this book to any software architect. Use it as your communication guide, use it to improve your vocabulary, use it to get a sense of what is happening across the industry, so that you could choose what best for your situation.

http://blog.manupk.com/2020/03/buildi...

[Sten Vesterli · Rating 4 out of 5]

Even though the main idea of this book is fatally flawed, it is still a good book on IT architecture.

The flawed concept is the idea of a "fitness function" that automatically calculates the quality of an IT architecture. If it were possible to build such a function, it could be included in your build pipeline, you would notice and could prevent your architecture from degrading. The authors present the idea and benefits, but fail to argue convincingly how this can be done in practice.

The good part is a well-argued discussion of architectural coupling and what causes architecture to atrophy. The chapter on how to build evolvable architecture contains many good guidelines and there is a lot of knowledge in the architecture antipatterns chapter. Finally, the chapter on putting evolutionary architecture into practice is also full of actionable advice, even though implementing the book's main idea of a "fitness function" is not practicable.

[Maria · Rating 3 out of 5]

I'm not 100% who the target audience is for this book. I was also very disappointed by some of the terrible scientific analogies, in particular when they use quanta!

But anyway, aside from that I appreciated the writing. There was a lot of spelling mistakes but I noticed that an effort had been made to use gender neutral language. I also though that including examples at the end of each chapter was a good idea.

On the whole though, aside from giving concepts new names I'm not sure how much I learned from this book.

[David · Rating 5 out of 5]

This is an excellent book that crystalizes definitions and approaches to designing software systems that are amenable to change. Many of the concepts captured in this book have been practiced by experienced software engineers for many decades, but the discipline of evolvable software architecture has been lost since the explosion of the Internet ushered in fast and furious development. The authors do a great job of steering clear of discussing technology and instead focus on the essence of architecture and articulating the tradeoffs that come with the decisions we make.

[Hildeberto · Rating 2 out of 5]

It's a tedious read, with subjects thrown in the reader's face with not enough ground. You basically have to trust author's professional experience to believe what they say. The book alone doesn't do the job. They invented a new term - fitness function - that is hard to digest. They are basically talking about tests, different types of tests, just to make sure changes don't break things. To prove that they don't need to come up with a new term. By using existing terms they would simplify a lot the understanding of their approach.

[Nadim Rafehi · Rating 4 out of 5]

Well written with a lot of useful and insightful information, however it's somewhat lacking in exploring concrete examples of fitness functions.

[Francois D’Agostini · Rating 5 out of 5]

Great book, really putting the emphasis on the capability of architectures rather than end state.

I think I liked the book because it confirms a lot of personal insights and brings me confidence when delivering these to customers

And on top of it, as it is a "generic" book, it is good that it's not too long as it could get a bit abstract
Really enjoyed it.

[Balhau · Rating 3 out of 5]

This is an high level overview of the principles you should take care when building an evolutionary architecture. The book is an easy read. I like it in overall. My only criticism is regarding the level of abstraction regarding fitness functions. I would like to see some more concrete examples of this metrics and how to implement them in the real world. But it was a nice read overall

[Frederic · Rating 4 out of 5]

by far the most useful tool out of this book is the idea of automated fitness functions that yield metrics on each effective and desired property of the architecture, running with the rest of the tests.

[Tom · Rating 4 out of 5]

Nice compilation of best practices and a few new concepts, mixed with practical experiences to illustrate. It is a good read, not terribly long, and I found it useful. Interested in looking into architectural fitness functions and consumer driven contracts for microservices!

[Remo Biagioni · Rating 1 out of 5]

This was a hugely disappointing book. The concept of evolutionary architecture is not new: transition architectures are baked into TOGAF. The one piece of brilliance in this book is to identify 'fitness functions' from the architecture and make those testable - indeed introducing those tests into the automated test suite. This idea is covered well in chapters one and two - though perhaps with a bit tighter editing in could have fitted in a single chapter. The remainder of the book purports to be an explanation of how the idea fits with different architecture styles.

The author has a strong bias towards micro architectures and 'the developer as king' neither of which idea is argued particularly well generally using sweeping statements with no evidence: "most commercial software falls woefully short of industry standards for automation and testing".

"Many companies view software as overhead, like the heating system" and rightly so. If a company's strategy is to install heating systems at the lowest cost then it's hard to imagine a scenario where software would not be an overhead.

"Business people ... have priorities that drive inappropriate decisions from an architectural point of view". Surely the the point of the architecture is to support the business? It's hard to imagine a scenario where a business would invest in an architecture that did not support the business goals. Fundamentally architects and software engineers are part of the business - we are business people ourselves - our role is to work with our colleagues in sales, marketing, finance and operations to create and maintain products that implement the business strategy.

Nor does IT Operations escape the author's sweeping generalisations: "New capabilities come slow to some companies and the operations group is a common victim of lack of innovation". Most IT Operations people I've spoken to wouldn't think that they lack innovation but they would claim poor development as the root cause of many of their problems.

The author relies a lot on Conway's principle (organisations design systems that mirror their communications structure). Though posited in 1967, the principle remains a useful lens to analyse a system - software or otherwise. Fifty years later it is hardly revolutionary and is one of the basic tools of organisational design.

If you support the view that today's engineering practices and micro architectures can solve any problem, you just need business people to leave you alone, you'll enjoy this book. The author's rhetoric will give you much ammunition to use in your next holy war. If, on the other hand, you want something to challenge your point of view and bring in new ideas, keep browsing the bookshelf.

[Vinayak Hegde · Rating 3 out of 5]

This is quite a good book written by someone who has deep experience in building several systems. Many of the ideas as well the experiences in building systems resonated with me. The idea of fitness functions was good. Also liked the transpose of different types of architecture and their pros and cons.

Also one important idea that is not expressed in software enough is the coupling of architecture, culture and team structure. This is dealt at length here. However some of the prose felt repetitive and there were not enough examples of change management (the few examples that were there were good, but the book could have done with more of the same). IMHO the fictional made-up example of widgets was the Achilles heel of otherwise good book.

Also it is one of those books that are relevant at a point in time. If you are more experience, many of the ideas seem obvious. If you are less experienced then there is not enough context to appreciate the ideas in the book. Overall a decent read and would rate it 3.25 stars.