[Book Review] Software Architecture in Practice

Having stumbled onto some of the SEI’s material on software quality attributes, I decided I had to know more.  That was the motivation that drove me to read Software Architecture in Practice.  It didn’t hurt when the book was shortly thereafter recommended to me by Arnon.

On the Amazon scale of rankings, I’d give this book 5 stars (of 5).  Not only did it contain a wealth of information on software quality attributes, but it also contained a goldmine of other information as well.

Here’s a very short list:

• Software Quality Attributes – a through introduction to software qualities (often referred to as nonfunctional requirements)  In particular, the book has a strong focus on a particular core set: availability, modifiability, performance, security, testability, and usability.  You might wonder why some other obvious qualities weren’t on that list, and that’s covered in the book as well (ie..scalability falls under the combination of performance and modifiability).
• Tactics – a tactic is an approach you can use to tweak a particular software quality attribute.  Localize Changes is an example of a tactic that’s described for increasing modifiability.  Generally speaking, tactics involve compromise.  As an example, using a security tactic often involves a negative tradeoff in performance (actually, almost everything involves a negative tradeoff in performance).
• Case Studies – the book is not short on case studies, and it has some really interesting ones at that.  If you’ve ever wondered what the architecture of a group of networked flight simulators (military grade) might look like, a good case study is included.  Others include a study of the US air traffic control system and a software product line used to build submarines.
• Architecture evaluation – the book serves as an introduction to the topic of architecture evaluation (through the lens of quality attributes and scenarios).  It introduces two formal frameworks for evaluation, the ATAM (the Architectural Tradeoff Analysis Method) and the CBAM (the Cost-Based Analysis Method).  While the two formal methods are too heavy for me to use practically, they serve as a good background for learning LAAAM (the Lightweight Architecture Alternatives Analysis Method).  While I’m sure several people are snickering at the thought of doing architecture evaluations, I’ll just point out two facts: 1) they are practiced by ThoughtWorks (they are not anti-agile) 2) when applied appropriately, they have been known to save large amounts of money (Figures from AT&T were roughly $1M per 100k LOC – IEEE Software Apr-May 2005).
• Real-Time Systems – This is a bit of a double edged sword.  I really like the fact that the book had quiet a bit to say about real-time systems, but in practice, most of us don’t build real-time systems.  This was due to the fact that the SEI is funded by the DoD and deals heavily with military systems.
• Software Product Lines – the book briefly introduces the concepts (there’s another volume dedicated to SPLs) and provides a very nice case study.  Software Product Lines is definitely a topic I’m interested in and I hope to expand myself in this area in the future.

Overall, I would highly recommend this book to developers who have honed their OO design skills and are looking to expand their horizons.  This book sticks to fundamentals and covers quite a bit of breadth.  I will warn you though, it’s quite thick (almost 500 pages) and can be dense in spots.