Design and Use of Software Architectures: Adopting and Evolving a Product-Line Approach (ACM Press) [Englisch] [Taschenbuch]

The author's treatment of quality attributes provides a good foundation for the design process. The author's method of linking quality attributes to quality requirements is plain good practice and bears careful reading. Traceability in any engineering or design effort is essential and the approach proposed needs to be included early in the life cycle.

There are major four evaluation techniques covered in the book: Scenario-based that examines software qualities within the context of scenarios; simulation techniques that model the architecture in a simulation environment; mathematical modeling that uses statistics, probability and other techniques to predict qualities such as reliability, etc.; and experienced-based reasoning (see Brooks' Mythical Man Month for a good explanation of that!).

Among the most powerful concepts presented is dimensional views, which decompose the architecture into component and system views; business, organization, process and technology views; and development, usage and evolution views. This approach ensures that an architecture's design proceeds in accordance with findings from a thorough analysis, and that all factors be considered and incorporated into the design. If you are a proponent of SEI's Architecture Trade-off Analysis Method (ATAM) you will see some similarities. However, if you carefully examine the author's approach you will see some gaps: the focus is not on trade-off points (although the dimensional views will certainly uncover trade-offs that have to be made), and ATAM does not address the evolution of the architecture. The product line approach proposed by the author does. Applying product line concepts to design and development promotes reusability, as well as providing a set of guidelines for evolving or changing the architecture.

Overall this is an excellent book that balances theory with a practical approach that is supported by case studies and real examples. I view it as a philosophy on architecture design instead of a methodology. It is a refreshing change from some of the architecture books I have read that are filled with dogmatic methods and "design in a vacuum". The approach proposed will link design to requirements, and will ensure that the architecture meets standards that are defined by quality attributes and not arbitrary design criteria.

A few things early on left me skeptical. Section I.4.1, for example, discusses quality factors of an architecture. The approach is completely retrospective, though. It only looks backwards at what emerged in a system, not forwards into how a system should be designed. I agree with section I.5.5 that some quality requirement X will be implemented across some set of system modules. Summing that quality's presence across all modules to add up to X is a positively dangerous mis-statement. The strength of a chain is in all of its links, but is not the sum of the link strengths - the strength of a system's security is not increased by adding yet more insecure modules.

The treatment of "software science" metrics is deplorably shallow. If you must use that approach, it's best to use a wide variety of indicators with different sensitivities, ideally indicators that don't depend on the programming language. The author stops with one metric, a graph-theoretic number that would be nearly impossible to apply to XSLT, Prolog, UI specification systems, database schemata, and so on. "Experience-based assessment" proposes the use of external assessment teams, without suggesting any way of guaging that team's ability. The discussion of processes vs. threads, with respect to program reliability misses the most critical point: that processes normally have hardware memory protection and threads don't. Unwittingly or maliciously shared memory is the biggest threat to reliability, and is a threat in process systems without memory protection.

The same shallow approach appears elsewhere in the "Transformation of architecture" section, in the dicussion of design patterns. The failure to distinguish strategic from tactical design issues is disappointing. A facade pattern is a useful tool, at the level of a few modules or minor subsystem. It is not a fundamental organizational principle capable of guiding the system's future structure - it doesn't work at the architectural level.

Bosch's emphasis is on analysis of successful systems and on retrofit of older systems under active development. Good stuff - that really describes the large majority of software effort. The discussion never gets started, however, because it scarcely mentions any way of determining which existing subsystems demand the most immediate attention.

There are lots more problems with this book, but I hope the pattern is clear: shallow discussion, weak specifics, and sparse mention of commercially critical issues.