Rating: 
Summary: Some good advice on 'ilities' trade-offs, but not much else
Review: This book will be useful for people looking for tactics for architecting particular 'ilities' into a system, deciding whether or not product lines are relevant, and many of the management / business aspects to maintaining architectural conformance. I particularly enjoyed the breakdown of concrete architectural tactics to achieve the most important 'ilities' and the tradeoffs involved in implenting them. There were even nice tie-ins later to the cost of implementing them and what the ROI is for making a decision to support, say, a certain level of modifiability, through the CBAM process they present. The less impressive points in the book were some of the case studies and the software reconstruction chapter. A couple of the case studies discussed projects that failed to produce a real product that deployed and was successful in the real world. While I agree with the authors that there was still research value in them and that good lessons were learned, I question their relevance in a book that contains the words "in Practice" in its title. It would've been nice to instead see more real stories around the tactics and how people really traded off the various architectural decisions, how it affected what they built, and how those decisions impacted the products in subsequent versions. I also didn't find the architecture reconstruction chapter very compelling. There were a lot of good ideas, but they were interspersed with a lot of confusing diagrams, counts of clusterings of classes and relationships, and talk about manual hypothesis generation and validation. It would've been better for me to see a few scenarios around reconstruction (i.e. "validation of implementation architecture" and "code dropped in your lap") and then some discussions of where there are good tools in place and where the state of the art isn't yet good enough. I didn't get a good sense of whether anything was useable in practice yet and, if it was, what value I could actually get.
Rating: 
Summary: We took the "In Practice" part of our title seriously.
Review: We wrote our book for the practicing software architect. I think there are three things that set our book apart from others. First, we thought it important to show real live architectures solving absolutely authentic real-world problems with hard-to-meet behavioral and quality requirements. Our book includes seven case studies in software architecture. You want to see an architecture for an ultra-high-reliability air traffic control system? It's in Chapter 11. You want to see an architecture for an avionics system designed for extension and modifiability? It's in Chapter 3. And so forth. Second, we included a practical method for evaluating an architecture for its ability to meet the quality requirements of the system it will be used to build. Architecture evaluation is a critical activity in system development, but there are precious few practical methods for carrying it out. The one we describe is relatively cheap and, experience shows, effective. Third, we show how architecture can form the essential basis for developing a family a related systems as a product line. Software product lines are emerging as a new and vital paradigm for software system development, and architecture is at its core.
Rating: 
Summary: Comprehensive and structured review of software architecture
Review: What I liked: =>Coverage of architectural qualities was insightful, differentiating between runtime attributes and non-runtime attributes =>Thorough explanation of key points in analyzing software architectures using a structured method (SAAM) =>Concept of Architecture Business Cycle (ABC) was useful What was missing: =>Good examples from the business world
| 
