A Look at the Architecture Tradeoff Analysis Method (ATAM)

by Paul Williams

“He who doesn’t lay his foundations before hand, may by great abilities do so afterward, although with great trouble to the architect and danger.” – Machiavelli

Machiavelli’s prescient quote applies equally as well to the software development process today as it did regarding building architecture in 16th Century Italy. Getting software architecture right up front is vital for ensuring that the unforeseen cost of scope-creep doesn’t kill a project before its successful completion.

The brilliant minds at the Software Engineering Institute at Carnegie Mellon University developed the Architecture Tradeoff Analysis Method (ATAM) as an iterative process to help mitigate risk when a software project is in its initial stages. The process involves up-front analysis from a group of project architects and stakeholders to determine the ultimate business goals of a project, attach a quality score to each goal, and then the tradeoff of a collection of scenarios for each goal detailing the architectural approach to accomplish each task.

The ability to analyze how potentially differing project goals interact and ultimately tradeoff against each other is vital for determining the quality of the project’s desired architecture. The overall ATAM process takes about from about three days to a week to fully accomplish an evaluation – provided the ATAM time can fully dedicate the time for the task.

Robert Abate, the Director of Enterprise Information Architecture at Walmart, gave a presentation on the ATAM at this year’s Enterprise Data World. Abate feels the ATAM is perfect for organizations aspiring towards continuous improvement in their software development process: “ATAM provides the framework for continuous improvement that is lacking in many architectural risk analysis processes due to its iterative nature”

Following the ATAM Leads to Robust Software Architecture

Use of the ATAM during the beginning phases of a software project leads to a host of tangible benefits. Some of these include: improved requirements, more complete architectural documentation, and earlier identification of risk factors.

The Software Engineering Institute concurs: “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.”

Another derived benefit is an important requirement to make the ATAM process work — communication. Improved and focused communication is vital with any form of interpersonal iterative process, and the ATAM is no exception. Abate also feels the proper application of use case analysis enhances the communication process when determining the business and architectural drivers during a project’s initial stages.

Determining Business Drivers and Architectural Approaches

An architect or business expert knowledgeable in the ATAM is vital for streamlining the entire process. Abate concurs with this sentiment: “ATAM works best when facilitated by an expert who knows how to lead the discussion, capture the artifacts and follows through with the analysis.”

Assuming the project stakeholders are already familiar with the ATAM and its techniques, the project manager or the customer herself kicks off the ATAM process by describing the business goals for the task at hand in addition to any architectural drivers. These drivers could involve any number of factors, including system availability, security, or the competitive environment within the project’s sector.

The enterprise or system architect then presents the overall design of the system. This includes describing the individual architectural approaches and detailing how they handle the project’s business and architectural drivers. Further analysis of these approaches does not happen at this point.

Defining a Quality Attribute Utility Tree

One of the most important deliverables from the ATAM process is the Quality Attribute Utility Tree. This details the factors that comprise overall system quality, including performance, availability, security, usability, modifiability, and more. Ultimately it aims to provide a hierarchical model of the architectural requirements of the entire project.

These quality factors are then drilled-down to the individual scenario level, get notated with potential stimuli and the associated responses, and undergo prioritization. The output of this task drives further analysis of the system architecture presented earlier.

The assembled team then performs a detailed analysis of the architectural approaches that address the highest priority quality factors from the previous step. Each type of analysis reflects the nature of the quality factor. For example, the approach handling a security quality factor undergoes a detailed security analysis.

In addition to the analytical work, the identification of risks, as well as sensitivity and tradeoff points also occurs. This information helps the team to transverse the upcoming iterative steps in the overall process.

Prioritize, Rinse, and Repeat

A new set of less vital scenarios are now elicited from the larger team of project stakeholders. Each scenario comes up for vote, helping to prioritize them amongst the larger view of the project.

The earlier analysis of the architectural approaches then gets repeated on the higher priority items from the new set of scenarios, deriving a new collection of risks and tradeoff points. The new scenarios also collectively serve as a test-case for the analytical work performed to date.

The results are then presented by the ATAM team to entire group of project stakeholders. This includes all the documented architectural approaches and scenarios, the tradeoff points, the quality attribute tree, as well as any specific questions generated by the overall process.

The ATAM: Outputs and Benefits

The SEI defines the most important deliverables from the ATAM process as follows:

  • A set of identified architectural approaches
  • The Quality Attribute Utility Tree
  • The full set of project scenarios, with a subset mapped to the architecture
  • A set of questions and answers regarding quality attributes applied to the architecture
  • A set each of identified risks and non-risks
  • A synthesis of risks into themes threatening to undermine the business goals of the system
  • A “Quality Attribute Roadmap” documenting risks vs. tradeoffs

Software projects also derive measurable benefits from the use of the ATAM. These include more clearly stated quality attribute requirements, improved documentation of the project’s architecture — including documented basis for architectural decisions, an earlier identification of project risks, and ultimately, more communication between project stakeholders.

It deserves mentioning again that the latter benefit — improved communication — might be the most important artifact of following the ATAM process. This author encountered many instances on development projects in the past where the dearth of quality communication led to mistaken assumptions and ultimately missed project goals.

The SEI is looking for ATAM Candidates

The Software Engineering Institute is actively looking for organizations interested in adding the ATAM to their arsenal of software development methodologies. They are also able to use the tool to evaluate the architecture systems currently in production.

Individuals wanting to take part in the ATAM process at their own organizations have two options. The SEI currently offers a Software Architecture Certificate Program that earns the graduate an ATAM Evaluator Certificate. Before being admitted to the program, candidates are required to pass a SEI administered test on software architecture principles and practices.

Additionally, an interested party can earn the ATAM Leader Certificate, qualifying that person to lead an ATAM evaluation at their own organization. Prerequisites include an ATAM Evaluator Certificate as well as superior oral and written communication skills along with five years of experience in a software engineering environment.

There are also additional training requirements, and within 18 months of the completion of the training, the candidate must be observed leading the ATAM process by someone qualified by the SEI. A review board at the SEI then analyzes the candidate’s performance during training and the notes from the observer before issuing the leader certificate.

Large enterprises with robust investments in software systems and architecture need to look closely at implementing the ATAM process if they are not already following the practice. From the U.S. Government to corporations as disparate as Boeing, Nationwide, and KPMG all follow the ATAM, reaping its benefits to engineer high-quality software architectures and thus deliver high-quality software applications.

Machiavelli would be impressed.

Related Posts Plugin for WordPress, Blogger...
photo by: joshua_schnable

  1 comment for “A Look at the Architecture Tradeoff Analysis Method (ATAM)

Leave a Reply

Your email address will not be published. Required fields are marked *