Reading: Software Architecture in Practice
One of my goals for 2025 was to read this hefty tome and share my thoughts about it. So here I am sharing the review of Software Architecture in Practice 4th Edition
tldr; it’s probably not worth reading this book cover to cover.
First, I’ll briefly describe the contents of the book, and then I’ll share my impressions. The book consists of five parts.
- What architecture is and why it matters. From the things I noted down from this chapter:
- Architecture defines the structure of an organization, and vice versa.
- Architecture should be the result of the work of a single architect or a small group with a clearly defined leader.
- Every architectural description is a constraint for the implementer.
- Quality attributes: various tactics and patterns for fulfilling these requirements are presented. The most interesting chapters for me were:
- Chapter 4: Availability. It explains fault detection tactics (monitoring, heartbeats, timestamps), state recovery (graceful degradation), and availability patterns (triple modular redundancy, circuit breaker, and redundant standby components).
- Chapter 9: Performance. Patterns such as service mesh, sidecars, rate limiting, and map-reduce.
- Many other chapters that were less interesting to me, listing tactics and patterns for things like deployability, integrability, testability, etc.
- Architectural solutions: the least interesting section. If I were to read the book again, I would skip it entirely. It mostly explains obvious things, such as API design (versioning), containerization, orchestration, and the idea of cloud computing.
- Practices for ensuring architectural scalability
- Architecture and organization
- These two sections explain the scope of an architect’s responsibilities and work: from gathering requirements, designing and evaluating architecture, to documenting it and managing architectural debt. Later, the collaboration between the architect and the Project Manager is described, as well as the skills architects need and how to develop as an architect.
My opinion:
I probably won’t read this book a second time. There’s a lot of filler, and at times I felt like I was reading boilerplate. Maybe that’s because the book has three authors and they agreed on a rigid chapter structure that they stuck to strictly?
I don’t think this book is even particularly useful as a vademecum of architectural patterns, because there are better sources, for example the Azure Architecture Center or Google Cloud Architecture Center
I don’t recommend reading this book in its entirety. If you do want to read it, I suggest skimming a chapter first and deciding whether there’s anything interesting in it. A large part of the book is filler or obvious statements.
But overall, I won’t complain too much. The tome looks cool on the shelf, and I bought it on sale.