Skip to content
Software Architecture Guide

ATAM Application Phases

Explanation

Section titled “Explanation”

The Architecture Tradeoff Analysis Method (ATAM) is explained in the article “Architecture Tradeoff Analysis Method (ATAM)”. This article covers when in a system’s life it pays off.

Early, before the system is built

Checking an architecture before the system exists is cost-effective. You learn whether the system will reach its desired qualities before you invest in building it. ATAM is positioned as a method that reduces risk and can be applied early in the development life cycle. A common guideline says the same: evaluate the architecture before major investment in implementation.

When stakeholders disagree

ATAM is also suggested when stakeholders have conflicting quality requirements. Performance against security is a typical pair.

Legacy systems

Older systems also need architecture analysis. Their architecture is often undocumented, or the documents are wrong because the system drifted and eroded over time. The team must first recover the architecture. Only then can it analyze it.

Example

Section titled “Example”

A team plans a new order system. It has written no code yet. Two stakeholders want very fast responses and strict data protection, and those goals pull against each other. The team runs an ATAM evaluation now, while changes are still cheap.

Later, the same company wants to analyze an old billing system. Nobody trusts the old diagrams. The team first reconstructs how the system is really built. Then it analyzes that recovered architecture.

Trade-offs

Section titled “Trade-offs”

For legacy systems, the analysis cannot start right away. The team must first spend effort recovering an architecture that is undocumented or inaccurately documented.

Checks

Section titled “Checks”
  • The architecture was evaluated before major investment in implementation.
  • For a legacy system, the architecture was recovered before the analysis, and the documentation was not simply trusted.
  • Conflicting stakeholder quality requirements, such as performance versus security, are named as a reason for the evaluation.
Section titled “Related”

Sources

Section titled “Sources”