The Architecture Tradeoff Analysis Method (ATAM) is a method for evaluating software architectures relative to quality attribute goals. ATAM evaluations expose architectural risks that potentially inhibit the achievement of an organization's business goals. The ATAM gets its name because it not only reveals how well an architecture satisfies particular quality goals, but it also provides insight into how those quality goals interact with each other—how they trade off against each other.
The ATAM is the leading method in the area of software architecture evaluation. 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.
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
A Conceptual Flow of the ATAM
Business drivers and the software architecture are elicited from project decision makers. These are refined into scenarios and the architectural decisions made in support of each one. Analysis of scenarios and decisions results in identification of risks, non-risks, sensitivity points, and tradeoff points in the architecture. Risks are synthesized into a set of risk themes, showing how each one threatens a business driver.
The ATAM consists of nine steps:
The most important results are improved architectures. The output of an ATAM is an outbrief presentation and/or a written report that includes the major findings of the evaluation. These are typically
The most important results are improved architectures. The ATAM aids in eliciting sets of quality requirements along multiple dimensions, analyzing the effects of each requirement in isolation, and then understanding the interactions of these requirements.
Many people have a stake in a system's architecture, and all of them exert whatever influence they can on the architect(s) to make sure that their goals are addressed. For example, the users want a system that is easy to use and has rich functionality. The maintenance organization wants a system that is easy to modify. The developing organization (as represented by management) wants a system that is easy to build and that will employ the existing work force to good advantage. The customer (who pays the bill) wants the system to be built on time and within budget. All of these stakeholders will benefit from applying the ATAM. And needless to say, the architect is also a primary beneficiary.
The SEI has used this method to evaluate the software architectures of systems from many different application domains. The SEI is currently looking for organizations that would like to incorporate the ATAM as one of their routine software development practices.
The SEI can evaluate your architecture using the ATAM or qualify individuals to
An SEI-authorized ATAM evaluation is one that is led by an SEI-certified ATAM Leader and whose team is made up of individuals who have received the SEI ATAM Evaluator certificate.
For additional details or to arrange an ATAM evaluation for your organization, contact us at email@example.com.
Direct technical questions about ATAM to us using the link in the For more information box at the bottom of this page.
To see a list of SEI-Certified ATAM Leaders, visit Find an SEI Partner Sponsored Individual and select "ATAM Leader (Certified)" from the drop-down list. You can also become certified to lead your own ATAM evaluations. For more information on becoming an SEI-Certified ATAM Leader, visit our certification page.
Progress Toward an Organic Software Architecture Capability in the U.S. Army, Stephen Blanchette, Jr. & John K. Bergey
Categorizing Business Goals for Software Architectures
Rick Kazman & Len Bass
Evaluating Software Architectures: Methods and Case Studies
Paul Clements, Rick Kazman, & Mark Klein
Risk Themes Discovered Through Architecture Evaluations
Len Bass, Robert Nord, William Wood, & David Zubrow