A Technical History of the SEI

Architecture Tradeoff Analysis Method
The Challenge: Determining the Best Architectural Design for Defense
Systems
Most complex software systems are required to be modifiable and have good performance. They
may also need to be secure, interoperable, portable, and reliable. But for any particular system,
what precisely do these quality attributes mean—modifiability, security, performance, reliability?
The achievement of quality attributes such as these in a software system depends more on the
software architecture than on code-related issues: language choice, fine-grained design, algorithms,
data structures, testing, and so forth. Software architectures are complex and involve many
design tradeoffs. Without undertaking a formal analysis process, an organization developing a
system cannot ensure that the architectural decisions made—particularly those that affect the
achievement of particular quality attributes—are advisable ones that appropriately mitigate risks.
In the early 1990s, there was not a structured and repeatable way of analyzing tradeoffs among
quality attributes. Analysis of tradeoffs in quality attributes was ad hoc and intuitive, and there
was not a way for architects to explain to other stakeholders in their organizations why they
thought their proposed architectures were appropriate or superior to other possible architectures.
A Solution: The Architecture Tradeoff Analysis Method
In an earlier effort, the SEI developed the Software Architecture Analysis Method (SAAM) as a
way of looking at modifiability [Kazman 1994, 1996]. In considering modifiability, SEI researchers
realized that there were other quality attributes that were important, and that there are tradeoffs
among them. The Architecture Tradeoff Analysis Method (ATAM) emerged from the SAAM as a
way of analyzing these other quality attributes [Kazman 2000].
The purpose of the ATAM is to assess the consequences of architectural decisions in light of quality
attribute requirements and business goals. An ATAM is an early lifecycle analysis method that
is designed to discover risks in decisions that might create future problems in some quality attribute
and to discover tradeoffs in decisions affecting more than one quality attribute. Discovered
risks can then be made the focus of mitigation activities (further design, further analysis, or prototyping),
and surfaced tradeoffs can be explicitly identified and documented.
An evaluation using the ATAM typically takes three to four days and gathers together a trained
evaluation team, architects, and representatives of the architecture’s various stakeholders. The
ATAM consists of nine steps, which include a discussion of business drivers and architecture, and
architectural approaches, among other topics. The output of an ATAM is a presentation and/or a
written report that includes the major findings of the evaluation. These are typically a set of architectural
approaches identified; a “utility tree”—a hierarchic model of the driving architectural requirements;
the set of scenarios generated and the subset that were mapped onto the architecture;
quality-attribute-specific questions that were applied to the architecture and the responses to these
questions; a set of identified risks; a set of identified non-risks; and synthesis of the risks into risk
themes that threaten to undermine the business goals for the system. The most important results
are improved architectures.
CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 258
Distribution Statement A: Approved for Public Release; Distribution is Unlimited.