Architecture tradeoff analysis method (ATAM) | Concise Software

Architecture tradeoff analysis method (ATAM)

The Architecture Tradeoff Analysis Method (ATAM) is a method for evaluating software architectures relative to quality attribute goals. Method evaluations expose architectural risks that potentially inhibit the achievement of an organization’s business goals.

Why Architectural Analysis?

The earlier you find a problem in a software project, the better off you are.
An unsuitable architecture will bring disaster on a project.
Architecture evaluation is a cheap way to avoid disaster

Participants in ATAM:

  • The evaluation team:
    • team leader,
    • evolution leader,
    • scenario and processing scribe,
    • timekeeper,
    • process observe.
  • Project decision makers.
  • Architecture stakeholders:
    • developers,
    • testers,
    • users,
    • builders of systems.

Read also: Native app vs. hybrid app. Which one you should choose?

The method consists of nine steps:

  1. Present the ATAM.
  2. Present business drivers.
  3. Present architecture.
  4. Identify architectural approaches.
  5. Generate quality attribute utility tree.
  6. Analyze architectural approaches.
  7. Brainstorm and prioritize scenarios.
  8. Analyze architectural approaches.
  9. Present results.

Conceptual flow of ATAM

conceptual flow of ATAM

Phases of the ATAM

Phase 0

  • activity: preparation
  • participants: evaluation team leadership and key project decision makers
  • typical duration: proceeds informally as required, perhaps over a few weeks

Phase 1

  • activity: evaluation (steps 1-6)
  • participants: evaluation team and project decision makers
  • typical duration: 1 day followed by a hiatus of 2 to 3 weeks

Phase 2

  • activity: evaluation (steps 7-9)
  • participants: evaluation team, project decision makers and stakeholders
  • typical duration: 2 days

Phase 3

  • activity: follow-up
  • participants: evaluation team and evaluation client
  • typical duration: 1 week

Outputs of ATAM

  • A concise presentation of the architecture.
  • Articulation of business goals.
  • The quality requirement in terms of a collection of scenarios.
  • Mapping of architectural decisions to quality requirements.
  • A set of identified sensitivity and tradeoff points.
  • A set of risks and non-risks.
  • A set of risk themes.

Read also: How to estimate product backlog effectively?

Conclusions

If a software architecture is a key business asset for an organization, then architectural analysis must also be a key practice for that organization. Why? Because architectures are complex and involve many design tradeoffs. Without undertaking a formal analysis process, the organization cannot ensure that the architectural decisions made—particularly those which affect the achievement of quality attributes such as performance, availability, security, and modifiability—are advisable ones that appropriately mitigate risks.

Bibliography

Contact Us