Skip to content

Book Review: Continuous Architecture in Practice

Continuous Architecture in Practice

Software Architecture in the age of agility and devops

Buy Now

Why I read this book

Over the past few months I have been focusing on reading books related to Software Architecture and Product Management and exploring how these too disciplines in software development intertwine. This exploration has primarily been driven by the fact that over the years I have often witness software development projects experience real issues which ultimately stem from some, often at times, poor decisions from these areas. I have to caveat this statement with the fact that often these decisions turn out to be poor but at the time they were made they were often with the best of intentions and often based on the best of the knowledge that was known at the time.

One of the biggest issues with software projects, is that quite often requirements, needs, desires, regulations and businesses change radically over the course of project, which will often incur major shifts in application functionality. I've witnessed first hand on numerous projects this happening and have heard countless stories of friends and colleagues of this happening elsewhere in the wild.

I enjoyed reading and learned quite a bit from Principles of Web API Design: Delivering Value with APIs and Microservices  and noticed this book within the same series and thought I'd give a try.

Principles of Web API

Delivering Value with APIs and Microservices

Principles of Web API Design brings together principles and processes to help you succeed across the entire API design lifecycle.

What I like about this book

In my opinion, this book clearly distils a lot of wisdom gained through some difficult experiences on software projects. In a number of case, I've witnessed some of the issues and use cases highlighted. Its one of the rare software development books where you can find valuable insights for all levels.

I have read books like Fundamentals of Software Architecture and Software Architecture: The hard parts which provide great background and real in depth aspects of software architecture and its related best practices and standards. Which I learned a lot from and in my opinion this book provides a great guide on how you can implement a lot of the knowledge gained in more Agile and Devops approaches, by explaining how architecture starts, adapts and continues to evolve during the course of a software project.

The book offers pragmatic and concise approaches to applying Software Architecture principles to more modern or emerging technologies in an agile environment, providing a considerable range of references that point to important but now well understood topics, helping to connect the dots into a coherent philosophy and key principles.

Fundamentals of Software Architecture

An Engineering Approach

provides the first comprehensive overview of software architecture's many aspects. Aspiring and existing architects alike will examine architectural characteristics, architectural patterns, component determination, diagramming and presenting architecture, evolutionary architecture, and many other topics.

What I learned from this book

Software Architecture is evolving from being an upfront effort at the start of a project, to being an activity that evolves constantly throughout a project. It is gradually becoming less of 1 person or team activity having oversight, to an activity that the whole team are constantly engaged in throughout a projects lifespan and constantly evolves.

.... architecture emrges from code building and refactoring activities, hence the term emergent architecture

Continuous Architecture in Practice

Software Architecture is difficult discipline, and this book does a good job of exploring this complexity, unabashedly highlight there is no magic elixir nor fairy dust, and provide realistic suggestions.

The 6 Principles of Continuous Architecture are a good thing to keep in mind when working on systems and developing software.

  1. Architect products; evolve from projects to products. 
  2. Focus on quality attributes, not on functional requirements. 
  3. Delay design decisions until they are absolutely necessary.
  4. Architect for change, leverage the “power of small”. 
  5. Architect for build, test, deploy and operate. 
  6. Model the organisation of your teams after the design of the system you are working on.

The real key takeaways I ultimately took from this is book are:

  • Software architecture is a series of decisions and trade-offs that should be recorded and made transparent. This is not entirely something new that I learned from this book, but it does strongly corroborate with Software Architecture: The Hard parts
  • Decisions should be made by observing the realised or live architecture, and not a paper based exercise.
  • Defining quality attributes or system qualities is key to being able to evaluate and supporting decisions.

Why I recommend this book

If you are curious about how architecture can be applied in an agile environment, the first two chapters distill this very well. 

Gary Woodfine
Latest posts by Gary Woodfine (see all)
Tags: