Product Description

The foundation of any software system is its architecture. Using this book, you can evaluate every aspect of architecture in advance, at remarkably low cost -- identifying improvements that can dramatically improve any system's performance, security, reliability, and maintainability. As the practice of software architecture has matured, it has become possible to identify causal connections between architectural design decisions and the qualities and properties that result downstream in the systems that follow from them. This book shows how, offering step-by-step guidance, as well as detailed practical examples -- complete with sample artifacts reflective of those that evaluators will encounter. The techniques presented here are applicable not only to software architectures, but also to system architectures encompassing computing hardware, networking equipment, and other elements. For all software architects, software engineers, developers, IT managers, and others responsible for creating, evaluating, or implementing software architectures.

---

Product Details

• Amazon Sales Rank: #187172 in Books
• Published on: 2001-11-01
• Original language: English
• Binding: Hardcover
• 368 pages

Book Info
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 Inside Flap

The foundation of any software system is its architecture, that is, the way the software is constructed from separately developed components and the ways in which those components interact and relate to each other. If the system is going to be built by more than one person—and these days, what system isn't?—it is the architecture that lets them communicate and negotiate work assignments. If the requirements include goals for performance, security, reliability, or maintainability, then architecture is the design artifact that first expresses how the system will be built to achieve those goals. The architecture determines the structure of the development project. It is the basis for organizing the documentation. It is the first document given to new project members, and the first place a maintenance organization begins its work. Schedules, budgets, and workplans all revolve around it. And the senior, most talented designers are paid to create it.

A system's longevity—how viable it remains in the face of evolutionary pressure—is determined primarily by its architecture. Some architectures go on to become generic and adopted by the development community at large: three-tier client-server, layered, and pipe-and-filter architectures are well known beyond the scope of any single system. Today, organizations are recognizing the importance and value of architectures in helping them to meet corporate enterprise goals. An architecture can give an enterprise a competitive advantage and can be banked like any other capitalized asset.

The right architecture is the first step to success. The wrong architecture will lead to calamity. This leads to an important question: If your organization is betting its future—or at least a portion of it—on an architecture for a system or family of related systems, how can you be sure that you're building from the right architecture and not the wrong one?

The practice of creating an architecture is maturing. We can identify causal connections between design decisions made in the architecture and the qualities and properties that result downstream in the system or systems that follow from it. This means that it is possible to evaluate an architecture, to analyze architectural decisions, in the context of the goals and requirements that are levied on systems that will be built from it.

And yet even though architecture is regarded as an essential part of modern system development, architecture evaluation is almost never included as a standard part of any development process. We believe it should be, and this book is an attempt to help people fill that gap.

The time has come for architecture evaluation to become an accepted engineering practice for two reasons. First, architecture represents an enormous risk in a development project. As we've said, the wrong one leads to disaster. It makes good sense to perform an evaluation on such a pivotal artifact, just as you would plan risk-mitigation strategies for other sources of uncertainty. Second, architecture evaluation can be remarkably inexpensive. The methods described in this book add no more than a week to the project schedule, and some abridged forms require no more than a day or two. Architecture evaluation represents a very cheap insurance policy. Compared to the cost of a poor architecture, the modest expense of a software architecture evaluation makes all the sense in the world. What has been lacking up to this point is a practical method for carrying it out, which is where this book comes in.

This is a guidebook for practitioners (or those who wish to become practitioners) of architecture evaluation. We supply conceptual background where necessary, but the intent of the work is to provide step-by-step guidance in the practice of architecture evaluation and analysis. To help put the methods into practice, we have included sample artifacts that are put into play during an architecture evaluation: viewgraph presentation outlines, scenarios, after-action surveys, final report templates, and so forth. The goal is that after reading this book, you will feel confident enough to try out the methods on an architecture in your own organization. We have tried to help answer the question, during an evaluation, "What should I do now?"

While the book is written from the point of view of the evaluator, there are others involved in an evaluation—project managers, architects, other stakeholders—who will gain valuable insights by reading this book. They will come to understand how their products will be evaluated and thus can position themselves to make those products fare better with respect to the evaluation criteria. This is rather like scoring well on a test because you've seen an early copy of the test, but in this case it isn't cheating but rather sound management and engineering practice. But know that when we use the word you in the text, we are speaking to the evaluator.

The techniques in this book are based on actual practice in government and industry. Most of the methods were developed by ourselves and others at the Software Engineering Institute and applied by ourselves and others to our customers' and collaborators' systems. Other material was gleaned by holding industrial workshops whose participants were experts in the analysis and evaluation of architecture. In short, we have learned by doing, and we have learned from others' doing.

This book will not teach you how to become a good architect, nor does it help you become fluent in the issues of architecture. We assume that you already have a good grasp of architectural concepts that comes from practical experience. This book will not help you assess the job performance of any individual architect nor a project's architecture (or development) process. What it will do is show you how to evaluate an architecture with respect to a broad spectrum of important quality attributes having to do with the architecture and the future system(s) that will be built from it.

Finally, we should say a word about software versus system architecture—that is, the architecture of software-intensive systems. This is a book about the evaluation of software architectures, but we often hear the question, "Well, what about the architecture of the system, not just the software? It's just as vital." We couldn't agree more. System architectures embody the same kinds of structuring and decomposition decisions that drive software architectures. Moreover, they include hardware/software tradeoffs as well as the selection of computing and communication equipment, all of which are completely beyond the realm of software architecture. System architectures hold the key to success or failure of a system every bit as much as the software architecture does for the software. Hence, they deserve to be evaluated every bit as much and for exactly the same reasons.

The methods presented in this book will, we believe, apply equally well to system architectures as to software architectures. If modifiability is a concern, the methods can be used to gauge the expense of making changes over the system's lifetime; if performance is a concern, the methods can be used to spot bottlenecks and problem areas in the system as well as the software; and so forth.

Why, then, do we call it a book about software architecture evaluation? Because that is the realm in which the methods were invented, developed, tested, and matured. In the remainder of this book when we speak of architecture, you can always safely prefix it with software. You can prefix it with system depending on how applicable you feel the methods are to system architectures and how confident you are about our intuition in the matter.

As a final word, we invite you to share your experiences with us. We would be keenly interested in knowing what you discover works well and what doesn't work so well. Writing a book is an opportunity to share lessons, but more importantly to us, it is an opportunity to gather new ones.

—PCC, Austin, Texas—RK, Pittsburgh, Pennsylvania—MHK, Pittsburgh, Pennsylvania

020170482XP10082001

From the Back Cover

Praise for Evaluating Software Architectures

“The architecture of complex software or systems is a collection of hard decisions that are very expensive to change. Successful product development and evolution depend on making the right architectural choices. Can you afford not to identify and not to evaluate these choices? The authors of this book are experts in software architecture and its evaluation. They collected a wealth of ideas and experience in a well-organized and accessible form. If you are involved in the development of complex systems or software, you will find this book an invaluable guide for establishing and improving architecture evaluation practice in your organization.”

         —Alexander Ran, Principal Scientist of Software Architecture, Nokia

“Software engineers must own this book. It is a well-written guide to the steps for evaluating software architecture. It argues for the inclusion of architecture evaluation and review as a standard part of the software development lifecycle. It introduces some new and innovative methods for analyzing important architecture characteristics, like extensibility, portability, and reliability. I believe these methods will become new engineering cornerstones for creating good software systems.”

         —Joe Maranzano, AT&T Bell Labs Fellow in Software Architecture (1990), and former head of the Bell Labs Software Technology Center

“Experience and teamwork are the only approaches I know of to deliver products faster, cheaper, and yet to delight your customers. In their first book, Software Architecture in Practice, Paul and Rick (and Len Bass) helped me match my experience with theory. Their invaluable approaches and case studies changed my practice and the way I proceed to design systems and software architectures. This second book, with Mark, covers what I will look at before I feel good about an architecture. It is about how I can tap other people's experience to produce an improved outcome, using other people's feedback. I have used many of the concepts explained in this book for my customers' benefit. Using this book, you—architects, developers, and managers—will develop a common language and practice to team up and deliver more successful products.”

         —Bertrand Salle, lead architect with a major telecommunications company

“If architecture is the foundation of system construction, architectural evaluation is part of the foundation of getting to a ‘good’ architecture. In this book, the authors put their considerable expertise to one of the most pressing issues in systems development today: how to evaluate an architecture prior to system construction to ascertain its feasibility and suitability to the system of interest. The 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., and technical editor, IEEE Recommended Practice for Architectural Description of Software-Intensive Systems

“Too many systems have performance and other problems caused by an inappropriate architecture. Thus problems are introduced early, but are usually detected too late—when the deadline is near or, even worse, after the problem makes the headlines. Remedies lead to missed schedules, cost overruns, missed market windows, damaged customer relations, and many other difficulties. It is easy to prevent these problems by evaluating the architecture choices early, and selecting an appropriate one.”

         —Connie U. Smith, Ph.D., principal consultant, Performance Engineering Services Division, L&S Computer Technology, Inc., and coauthor of the new book, Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software

“The ATAM an evaluation method described in this book is the natural quality-gate through which a high-level design should pass before a detail design project is initiated. Why use the ATAM to evaluate an architecture? Mitigation of design risk is a major reason, but more importantly, the ATAM provides an interactive vehicle that can give key development and user stakeholders architectural visibility—visibility that can lead to an important ‘early buy-in.’”

         —Rich Zebrowski, Software Technology Manager, Motorola, Inc.

“Caterpillar's experience with architecture reviews includes SAAM, ATAM, ARID, and ADR evaluation methods described in this book, the first three in detail. These reviews ensured that the needs of the user community were being met, and they exposed the architecture to others in the organization helping with understanding and organizational buy-in. The SAAM- and ATAM-based evaluations worked well to expose the architecture early in the development cycle to a broad range of people. The ARID- and ADR-based evaluations facilitated the exposure of technical details of the architecture later in the development cycle. As the architect of the pilot project for ARID, I observed that this review even served as an architecture training session before the architecture was fully documented.”

         —Lee R. DenBraber, former Lead Software Architect, Caterpillar, Inc.

“We’ve heard all the management hype about harnessing the innovative creativity of our teams, establishing integrated customer-developer-product teams, and better targeting our systems to meet end user needs. The ATAM techniques described in this book give technical managers, system architects, and engineers proven tools for breaking down the communications barriers that impede our ability to realize these goals. We have successfully integrated the ATAM techniques throughout our lifecycle, including development and maintenance, and have found that they provide the strong technical basis we need to evaluate the many difficult trades required by a system as large as EOSDIS.”

         —Mike Moore, Deputy Manager, Science Systems Development Office, Earth Observing System Data Information System (EOSDIS) Project, NASA Goddard Space Flight Center

“If you know how difficult architecture reviews are, you will be amazed how effective ATAM evaluations can be. For example, an ATAM evaluation we conducted on an important software product line identified a major architectural risk, which we subsequently were able to avoid-a benefit we expect to continue seeing. Moreover, ATAM techniques have enabled us to explain such risks to stakeholders far more clearly than by any other review method.”

         —Stefan Ferber, Corporate Research, Robert Bosch GmbH

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.

---

Customer Reviews

Depends on what you want.
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.

Essential reading for practicing SW architects
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.