When I was at university, we were taught about the Waterfall Model for developing software. Strangely enough, upon entering the workforce a few years later, it was nowhere in sight. Instead, feedback and change requests arrived well after development had started, and often conflicted with or even contradicted what was there initially. I was lucky enough to mostly work on projects that accommodated such changes fairly well, with the occasional refactoring. Of course, it wasn’t only luck: whoever created the architecture for those projects (at the time, not me) knew that change is inevitable, and built the system to prepare for it. If you are interested in creating an architecture that embraces future changes instead of resisting them, then this new book, Building Evolutionary Architectures, is for you.

The book starts with a definition of what software architecture actually is:

… analyzing business and domain requirements along with other important factors to find a solution that balances all concerns optimally.

There are a ton of these “important factors”: e.g. accessibility, adaptability, configurability, and others. The authors refer to it as the long list of -ilities. They present a table with 52 -ilities, but there could easily be more.

Chapter 2 talks about fitness functions: these things evaluate how well your project caters to the “important factors”.

Chapter 3 is about making incremental changes. In order for an architecture to respond to changes favorably, these changes must be small.

Chapter 4 describes architectural coupling. It describes a variety of architectural styles, ranging from the infamous “big ball of mud” to full-blown microservices. I found this spectrum particularly interesting, as showed me where I am in terms of my own journey to architectural evolvability (for the record, most of the applications I’ve made are “modular monoliths”). It’s reassuring to know that I’m not at the bottom of the architectural barrel, but inspiring to see that I still have a long way to go.

Chapter 5 talks about the role of data in architecture, and how different approaches to data can help or hinder the evolvability of your architecture.

Chapter 6 describes building evolutionary architectures. Of course, it’s easier to start from scratch, but in the real world, we don’t always have this luxury. Often, we’ll be in the middle of an existing project that wasn’t necessarily architected with evolvability as a priority. This chapter deals with the challenge of working on such projects and offers options to make their architectures more evolvable.

Chapter 7 introduces architecture pitfalls and antipatterns: examples of what not to do.

Finally, Chapter 8 talks about the challenges of pursuing evolutionary architectures in practice, for example dealing with factors specific to your particular organization or team.