Evaluating Software Architectures: Methods and Case Studies (SEI Series in Software Engineering) (Hardcover)

by Paul Clements (Author), Rick Kazman (Author), Mark Klein (Author)

Editorial Reviews

Product Description
Detailed case studies demonstrate the value and practical application of the ATAM, SAAM and the ARID methods to real-world systems. A must have for software engineers.

From the Back Cover
"This book provides a practical guide to architecture evaluation using three contemporary evaluation methods. It should prove valuable to practitioners and as a basis for the evolution of architectural evaluation as an engineering practice." —Rich Hilliard, Chief Technical Officer, ConsentCache, Inc.

"Successful product development and evolution depends on making right architectural choices. Can you afford not to identify and not to evaluate these choices?" —Alexander Ran, Principal Scientist of Software Architecture, Nokia

"Software engineers must own this book." —Joe Maranzano, Former Head of the AT&T Bell Labs Software Technology Center

Drawing on clearly identified connections between architecture design decisions and resulting software properties, this book describes systematic methods for evaluating software architectures and applies them to real-life cases. It shows you how such evaluation can substantially reduce risk while adding remarkably little expense and time to the development effort (in most cases, no more than a few days). Evaluating Software Architectures introduces the conceptual background for architecture evaluation and provides a step-by-step guide to the process based on numerous evaluations performed in government and industry.

In particular, the book presents three important evaluation methods:

• Architecture Tradeoff Analysis Method (ATAM)
• Software Architecture Analysis Method (SAAM)
• Active Reviews for Intermediate Designs (ARID)

Detailed case studies demonstrate the value and practical application of these methods to real-world systems, and sidebars throughout the book provide interesting background and hands-on tips from the trenches.

All software engineers should know how to carry out software architecture evaluations. Evaluating Software Architectures is the chance to get up to speed quickly by learning from the experience of others.

020170482XB09252001

See all Editorial Reviews

Product Details

• Hardcover: 368 pages
• Publisher: Addison-Wesley Professional (November 1, 2001)
• Language: English
• ISBN-10: 020170482X
• ISBN-13: 978-0201704822
• Product Dimensions: 9.3 x 6.5 x 0.9 inches
• Shipping Weight: 1.4 pounds (View shipping rates and policies)
• Average Customer Review: 4.0 out of 5 stars See all reviews (4 customer reviews)
• Amazon.com Sales Rank: #139,125 in Books (See Bestsellers in Books)

  Popular in these categories: (What's this?)

  #20 in	Books > Computers & Internet > Computer Science > Software Engineering > Methodology
  #71 in	Books > Computers & Internet > Hardware > Microprocessors & System Design > Computer Design

• This item is part of The SEI Series.

Customer Reviews

Most Helpful Customer Reviews

50 of 53 people found the following review helpful:

5.0 out of 5 stars Essential reading for practicing SW architects, April 12, 2002

By	Mike Tarrani "www.tarrani.com" (Deltona, FL USA) - See all my reviews (TOP 500 REVIEWER)    (REAL NAME)    (COMMUNITY FORUM 04)

The authors provide an in-depth treatment of three methods for
evaluating software architectures, all of which were developed at the
Software Engineering Institute with involvement by the authors. The
methods examined are:
(1) ATAM (Architecture Tradeoff Analysis
Method)
(2) SAAM (Software Architecture Analysis Method)
(3)
ARID (Active Reviews for Intermediate Designs)

Each of the above
address software evaluations in increasing levels of detail, with the
book's main emphasis on ATAM.

What makes this book so valuable is
the fact that you can learn much about developing software
architectures from the criteria with which they are evaluated. For
example, the discussion on quality attributes is eye-opening because
what architects consider to be well formed quality attributes are
usually too vague to properly evaluate, resulting in ill defined
architectures in the first place. Knowing how to evaluate the
architecture will provide the keys for defining a solid architecture.
More important is the way the authors define the outputs of the
architecture evaluation, which gives the practicing architect a
framework for design that fully meets the evaluation criteria. The
net result is that a defined architecture will unambiguously
communicate the design to the development team, as well as to the QA
team.

I especially like the business oriented approach that
addresses the costs and benefits of evaluation, the three approaches
from which to choose that best meets technical and business goals, and
the case studies that support each of the approaches. Another strong
point about this book is architecture is also evaluated with
production in mind. Too many books only consider architecture from
the development point of view, or in rare cases, from development and
QA points of view. The evaluation techniques in this book extend to
support and maintenance. The authors make selection of the best
technique easy by comparing them in Chapter 9, and provide an approach
to implement evaluations in Chapter 10.

If you're an architect I also recommend augmenting the excellent
material in this book with Design and Use of Software Architectures by
Jan Bosch , which gives an alternate method to ATAM that is more
complete in many respects. Even if you espouse Bosch's approach,
however, the approach and techniques given in Evaluating Software
Architectures: Methods and Case Studies are complementary. I personally
recommend both books and assign equal value to them.

10 of 10 people found the following review helpful:

4.0 out of 5 stars Depends on what you want., July 1, 2004

By	wiredweird "wiredweird" (Earth, or somewhere nearby) - See all my reviews (TOP 100 REVIEWER)

What this book does, it does very well. It presents three techniques for reviewing the suitability of a software architecture. The presentation style is clear, complete, and reasonably frank about the problems an architecture evaluator is likely to encounter.

The oldest of the three techniques presented is SAAM, the Software Architecture Analysis Model. It's primary goal is to determine how well a system's structure addresses the technical requirements of the application, and its probable success at addressing future changes of requirements.

ATAM, the Architecture Tradeoff Analysis Method, descends from SAAM but is far more complete. It starts upstream of the requirements, at the business model behind the application, then moves forward methodically through the top-level design. At each step, reviewers update the list of technical risks and non-risks (relatively safe items). ATAM is open-ended, in the sense that the project's own goals define the specific measures of quality that apply - it doesn't force-fit every project onto one Procrustean axis of measure.

If ATAM is SAAM grown large, then ARID (Active Reviews for Intermediate Design) is SAAM scaled down. Where ATAM and SAAM address strategic issues about complete systems, ARID incorporates tactical information about specific design issues. It's not as narrow as standard design review techniques, but not as broad as an architecture review.

ATAM is the main focus of the book, with more pages than SAAM and ARID combined. All three are described in full detail, however. The authors identify the specific skill sets, roles, and responsibilities that must be involved at each step. They present checklists for eliciting the kinds of information needed, even specifics of meeting agendas and meeting room equipment.

That creates my second impression of this book: I was very disappointed. This book is for meeting organizers, and deals very little with technical specifics. That is not at all what I hoped for. It is not the fault of the book that it fails to meet my expectations. In my present work, however, the authors present just about nothing to enhance my project's technical content.

This is a process book. It seems to be a good one. It takes what works in other design review methodologies, then expands that to the highest level of the software project. It gives enough detail that you can tune specifics of the process to specifics of your project. Still, it's just a process book.

5 of 5 people found the following review helpful:

4.0 out of 5 stars Great on meeting details, but short on substantive examples, May 4, 2005

By	Lars Bergstrom "LarsBerg" (Chicago, IL) - See all my reviews (REAL NAME)

This book does a great job of diving into specific details on how to run meetings and the checklists of steps to follow for three different architecture review models that go into different depth (ATAM, SAAM, and ARID). I really liked the breadth of issues that the reviews covered as well as the concrete guidelines on how deep to go with the reviews.

I didn't particularly enjoy the checklist feel of the book. I felt like they had a series of meetings to have and attendees, but they didn't do a good job of explaining why which meetings had to happen in which order and what lengths were appropriate. It was hard to understand what was a critical constraint and not to be violated and what was guideline that would vary by project and is open to interpretation.

Additionally, the examples in the book were comprehensive in terms of what happened in the meetings, but weren't quite complete enough in terms of the documents generated. There were excerpts, but I almost would've liked to see larger pieces of them in the appendices. It was hard to get past the details of who was in what room when to what documents were actually generated, what the final results presentation looked like, and what the flavor of follow-up actions was.