Software Architecture in Practice (SEI Series in Software Engineering) [Hardcover]

The author start by describing software architecture as:

"The Software Architecture of a program or computing system is the structure or structures of the system, which compromise software elements, the externally visible properties of those elements, and the relationships between them."

Throughout the book, the author used this definition to describe various aspects of architecture. One of the methods/techniques that the author uses is called the Architecture Business Cycle (ABC). ABC is method of realizing the "things" that influence the architect and in-turn the architecture - known as the circle of influences. This concept, ABC, is used for all the case studies mentioned in this book:

· A case study on a system that have extreme safety requirements - the Air traffic control.
· A case study on a system with high level of distribution of its subsystems - A flight simulator
· A case study in which it was essential for the organization to be able to share documents instantaneously.
· A case study on an organization where one architecture lead to a product line of applications
· A case study on the need to standardization of architectural approaches across organizations and the community - J2EE and the EJB.

For each case study, the authors depict its ABC and give the reader the reason, business reason, that this project got started to begin with. The reader then walks thru a series of decision-making steps that led to the architecture that was finally chosen. The drivers of the project, the business reason, the architect[s], and the organization are all linked and the authors go into a GREAT DETAIL on how this link can influence the final design.

Architecture Tradeoff Analysis Method or ATAM is a new topic that is added to the second edition of the book. ATAM is a structured method of evaluating architectures.

"It results in a list of risks that the architecture will not meet its business goals"

The authors start by describing the roles and responsibilities of people involved in ATAM, and the output artifacts that ATAM will produce when completed:

· A Concise presentation of the Architecture
· Articulation of the business goals
· Quality requirements in terms of collection of scenarios
· Mapping of architectural decisions to quality requirements
· A set of identified sensitivity and tradeoff points
· A set of risks and non-risks
· A set of risk themes.

The process of ATAM is depicted next in which there are a total of 4 phases:

1) Partnership and preparation: the key project decision makers informally meet to work out the details of the ATAM process.
2) Evaluation phase - the long evaluation process of the architecture with the same project decision makers as in previous phase
3) Evaluation phase, continued - this time the stakeholders are present
4) Follow up - the stakeholders and the evaluation team meets again to follow up.

The process is described very well and examples forms are shown in the book that can be used for your evaluation process. The great thing about this chapter and how it's written is the way that the ATAM process is presented. It is almost like a checklist that the architects need to follow. Very easy to read and follow. The inputs of every phase are clearly identified, and the description of the output is depicted rather clearly. The chapter ends with yet another case study that shows the "theory" just presented. The authors close the chapters by having the following comments about this book:
· ATAM is not an evaluation of Requirements, but only the architecture
· ATAM is not a code evaluation
· ATAM does not actually involved system testing
· ATAM is not a practice instrument, but identifies possible areas of risk within the architecture.
The ATAM is followed by another very well written topic on CBAM (Cost Benefit Analysis Method). This chapter is also new in this edition, but I will leave the details of this chapter for the reader. I like the ATAM method more than the CBAM, because it seems simpler to me.
All and all, the authors in this book did a fantastic job in writing this book. This book is packed with useful information for architects, project leads, and even technical managers.

I used the first edition, along with SEI technical papers in a graduate-level software architecture introductory course. After reading the first edition, I still wasn't sure what a software architect should do. The second edition makes it clear. I think a lot of the technical papers that I read are now chapters in the book. Some new chapters are simply great: Understanding Quality Attributes, Achieving Qualities, Designing the Architecture, Documenting Software Architectures, the ATAM, and the CBAM.

I really liked the replacement of ADL with UML, the de facto standard, with all of its warts and blemishes.

For criticism, this book was history as soon as it hit the presses. You'd still need to read SEI technical papers to be current. One of the chapters discusses the performance problems with remote entity beans and makes no reference to EJB 2.0 spec local entity beans with no performance hit on every cross-bean call. Likewise, the final chapter on "The Future" wasn't so bold as to prognosticate on OMG's current work on MDA, but they may be alluding to it with "Moving from architecture to code."

Still more fun to read than a harlequin romance novel and readable in four days.