NEWS AT SEI
This article was originally published in News at SEI on: June 1, 2001
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-modifiability, security, performance, reliability-mean? Can a system be analyzed to determine these desired qualities?
A system's quality attributes are largely permitted or precluded by its architecture. So why should an organization analyze a software or system architecture? Quite simply, because it is a cost-effective way of mitigating the substantial risks associated with this highly important artifact. With its Architecture Tradeoff Analysis Method (ATAM), the SEI is providing a way to perform this task.
A software architecture is a representation of a software system in terms of its components, their externally visible properties, and their relationships. It serves as a blueprint of the system and the basis for communicating, analyzing, and reusing key design decisions. Architectures allow or preclude nearly all of the system's quality attributes such as performance, modifiability, usability, and availability.
The ATAM evaluates architectural decisions in light of quality attributes requirements and reveals how quality attributes interact with each other. It also highlights the relationship between quality attributes and the business drivers (for example, affordability, time to market) that motivate them.
The ATAM elicits sensitivity points, tradeoff points, and risks. Sensitivity points are architectural decisions that dramatically affect a quality attribute. Tradeoff points are architectural decisions that dramatically affect more than one quality attribute. Risks are a subset of sensitivity points that potentially can inhibit the system from achieving its quality attribute goals. The ATAM consolidates risks into risk themes and then examines the impact of risk themes on the organization's business drivers. By identifying sensitivity points, tradeoff points, and risks, software developers can examine the consequences of architectural decisions before committing resources to implementing them.
The ATAM offers a number of additional benefits. It helps software developers and other stakeholders clarify quality attribute requirements, leads to improved architecture documentation, and provides the reasoning for architectural decisions. It also enhances communication among stakeholders.
Experience with ATAM
Over the past several years, SEI technical staff members have performed about 20 architecture evaluations for defense, non-defense government, and commercial organizations using the ATAM. For example, SEI staff members recently conducted a successful ATAM-based evaluation for the Joint National Test Facility (JNTF), Shriever Air Force Base, Colorado. The JNTF provides modeling and simulation support to military and defense industrial customers. The SEI applied the ATAM to Wargame 2000, its centerpiece simulation tool. According to JTNF personnel, the ATAM-based evaluation produced several architecture-related benefits; but more importantly, it empowered the participants. In particular, it enabled the project manager to identify and address a key design tradeoff that would not have surfaced until much later, when its impact would have been significant. In addition, several participants expressed "amazement" about how the process fostered open and frank communication among the government and support contractors.
In a non-defense government application, the SEI is helping to integrate the ATAM into the maintenance and evolution process for a NASA satellite data acquisition and processing system. NASA engineers are using the ATAM to develop a list of quality attribute requirements. Before the ATAM evaluation, the justifications for key architectural decisions were not well documented. Also, stakeholders (other than development staff) viewed all changes as equally plausible. After the ATAM, the architect, development personnel, and operations stakeholders reached consensus on priorities for quality attribute requirements. They identified and documented 50 key architectural decisions and more than 100 associated risks, sensitivity points, and tradeoffs. And they prioritized and compared the technical merits of more than 60 proposed changes.
In the commercial area, the SEI and one of its technology adoption partners, Robert Bosch Gmbh, recently evaluated the architecture of an embedded automotive system. During the evaluation, the ATAM team uncovered 40 risks, 3 sensitivity points, and 5 tradeoff points. Bosch managers responsible for the embedded automotive system were very satisfied with these results. A key manager remarked that "this is the first time that business and technical perspectives were discussed at the same time." Knowing that a risk may jeopardize a business goal can motivate both managers and engineers. In this instance, the knowledge gave the architecture group a clear and focused agenda and the manager's statement gave them the authority to act.
Currently, the SEI is looking for additional technology adoption partners to further the use of the ATAM. Under this arrangement, the SEI will work closely with the organization. SEI technical staff members typically perform an initial evaluation using the ATAM to demonstrate its potential. Next, the organization's potential ATAM evaluators will take the ATAM evaluator training. The SEI will then perform a joint evaluation with the technology adoption partner. Finally, they will observe the partner independently performing an evaluation and provide additional recommendations, if necessary. The SEI is also planning to license third-party organizations to use the ATAM.
In addition, Paul Clements, Rick Kazman, and Mark Klein have authored Evaluating Software Architectures: Methods and Case Studies, which will be published in the fall of 2001 as part of the Addison-Wesley SEI Series in Software Engineering. The book is designed for anyone who is, or will be, involved in software architecture evaluation. While it is written from the evaluator's perspective, project managers, architects, and other stakeholders can gain valuable insights into the purpose and the process of architecture evaluation.
The ATAM has proven to be an effective means to evaluate the impact of architectural decisions on the achievement of quality attributes requirements. The ATAM has been "road-tested" over the last several years on many systems in different domains and is now ready for widespread adoption.