Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

Standalone conceptMethodChapter III · Evolution · Building block 6 of 15

ATAM

One architecture decision can affect several quality goals at once.

By Michael Meierhoff · Meierhoff Systems

  1. Quality scenariosQuality scenarios: Stakeholders make quality goals concrete.
  2. DecisionsDecisions: Relevant architecture decisions become visible.
  3. RisksRisks: Trade-offs and sensitivity points are documented.

Context

Why this is important

Evaluate quality goals and architecture decisions together.

Evaluate quality goals and architecture decisions together.

Shop example · Mapping

ATAM: inspect the decision

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. For the shop, order confirmations should remain timely during a campaign, and payment failures must not create duplicate charges. An ATAM team collects measurable scenarios, maps them to decisions about the database, broker, and payment call, and examines which decisions affect several goals at once. It documents open risks and assigned follow-up as workshop outcomes.

This is how you read the picture

  1. Quality scenarios Quality scenarios
  2. Decisions Decisions
  3. Risks Risks
ATAM: inspect the decision
ConceptMeaningReview question
Quality scenariosStakeholders make quality goals concrete.What does the ATAM team connect in the shop review?
DecisionsRelevant architecture decisions become visible.How does a quality trade-off become visible?
RisksTrade-offs and sensitivity points are documented.Which prerequisite limits reliable ATAM results?
Die Methode sucht Risiken, Nicht-Risiken, Sensitivitätspunkte und Trade-off-Punkte. Sie liefert eine strukturierte Analyse für ein bestimmtes System und dessen Stakeholder; sie zertifiziert keine Architektur und ersetzt keine Umsetzungsmessung. Use the questions in the second column to test this scenario.

Benefits & limitations

Helps if:

  • Evaluate quality goals and architecture decisions together.
  • Plan participants, scenarios, and architecture decision makers for the evaluation.

Boundaries

  • Results depend on realistic scenarios and available decision makers.
  • ATAM requires stakeholder participation and substantive scenarios; an architecture walkthrough alone is not that evaluation.

In practice

  1. Write one measurable scenario each for product, operations, and development covering order availability, response time, and payment integrity; then mark which scenarios compete.
  2. Map each relevant architectural decision to the affected scenarios and identify sensitivity points, tradeoff points, and risks with likelihood and impact.
  3. Ask stakeholders to validate the ranking against agreed business goals and record a concrete analysis or an open decision with an owner for every prioritized risk.
Read the detailed explanation

ATAM evaluates how architectural decisions support multiple quality goals under concrete scenarios. Participants develop a quality tree and scenarios, then connect them to decisions that shape outcomes.

The method identifies risks, non-risks, sensitivity points, and trade-off points. It provides a structured analysis for a specific system and its stakeholders; it neither certifies an architecture nor replaces measurement of an implementation.

The shop example uses the existing shared database and seven modules. Any added service or deployment model is a hypothetical extension. For the shop, order confirmations should remain timely during a campaign, and payment failures must not create duplicate charges. An ATAM team collects measurable scenarios, maps them to decisions about the database, broker, and payment call, and examines which decisions affect several goals at once. It documents open risks and assigned follow-up as workshop outcomes. review and saam help compare this decision with adjacent concerns.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    What does the ATAM team connect in the shop review?

    View the solution with justification

    Quality scenarios with decisions about the database, broker, and payment.

  2. ApplyingTransferred to a new situation

    How does a quality trade-off become visible?

    View the solution with justification

    Examine the scenario, architecture decision, and resulting risks together.

  3. EvaluateWeighing an alternative

    Which prerequisite limits reliable ATAM results?

    View the solution with justification

    Representative stakeholders and realistic quality scenarios must participate.

Explore further

These building blocks continue the thoughts of this page.

EvolutionArchitecture reviewContext and comparisonOpening EvolutionSAAMConceptual connectionOpening EvolutionARIDConceptual connectionOpening EvolutionLASRConceptual connectionOpening RequirementsQuality scenarioQuality scenarios structure the investigation.Opening

References

Continue on the learning path

Next in Evolution & assessment: Technical debt.

15 Building blocks

Continue withTechnical debt