Skip to content
Software Architecture Guide

Software Architecture Analysis Method (SAAM)

Explanation

Section titled “Explanation”

SAAM stands for Software Architecture Analysis Method. It was the first documented method for analyzing software architecture. It was developed in the mid-1990s. Its goal was to analyze modifiability, meaning how easily a system can be changed (see the article Modifiability).

The method works with scenarios. A scenario is a short description of a situation. Here it is usually a change someone might want to make. SAAM uses scenarios to check how well an architecture supports change and modification. The original paper presents a structured, scenario-based method for analyzing architectures against quality attributes (see Quality Attribute).

Scenarios are prioritized. One secondary source says this is done by likelihood and criticality: how probable a change is and how much it matters. That way, the evaluation spends its effort on the changes that count most.

SAAM is described as a precursor to the Architecture Tradeoff Analysis Method (ATAM). So ATAM can be seen as the later method, and SAAM as its earlier ancestor.

The main benefit is insight into how architectural choices affect the system’s ability to change.

Example

Section titled “Example”

A team runs a web shop. They list likely changes: add a new payment provider, change the tax rules, and support a second language. They rank these by how likely and how important each one is. Then they walk through the architecture and ask how well it handles each change, starting with the top-ranked ones. The result shows which design choices make change easy and which make it hard.

Trade-offs

Section titled “Trade-offs”
  • Results can be subjective. They depend on the experience and bias of the evaluators.
  • Building a comprehensive scenario set and evaluating it takes time and resources.
  • The gain is a clearer view of how design choices affect the ability to change.

Checks

Section titled “Checks”
  • The architecture document lists the change scenarios used to evaluate the design.
  • Scenarios are prioritized, for example by likelihood and criticality.
  • The document notes that the assessment depends on the evaluators’ experience and possible bias.
Section titled “Related”

Sources

Section titled “Sources”