Purpose
SAAM helps teams judge an architecture’s suitability for selected tasks and changes. It is particularly useful for examining modifiability and comparing architecture alternatives with clear reasoning.
Architecture Analysis method
SAAM (Software Architecture Analysis Method)
Uses concrete change tasks to examine how well an architecture supports future development.
SAAM shows which parts of a system would need to change for a planned requirement. It maps business functions to responsible components, assesses concrete changes, and supports comparison of architecture alternatives on the same basis.
What changes do our planned tasks require, and how do the architecture alternatives differ?
- Participants
- Architecture experts and stakeholders for scenarios and weighting
- Time
- Preparation, scenario analysis, and findings review; effort depends on scope
The five sections follow the original SAAM version. This guide uses modifiability as an example. Allow time for preparation, joint discussion and technical analysis.
Functions
Describe the functions the system performs
Describe what the system needs to do for its users and business. This functional partition provides a common basis for all architectures under review.
Allocation
Map functions to components
Show which components implement each function and how they are connected.
Qualities
Set quality goals and evaluation criteria
Choose properties that matter for using and developing the system. Modifiability is a particularly useful focus for this analysis.
Tasks
Describe representative changes as evaluation cases
Concrete scenario tasks make a quality goal examinable. For modifiability, an example is adding another shipping provider.
Evaluation
Examine change impacts for each architecture
Work through the agreed evaluation cases. Record the changes each architecture would require.
When requirements or the architecture change, update the evaluation cases and their mapping to components. Retain earlier assessments and their assumptions.
A good fit when
Useful for planned or existing architectures, especially questions about modifiability and moving software to other technical environments (portability). Comparing alternatives requires comparable architecture descriptions and the same evaluation cases.
Ideal for
- Modifiability of existing or planned architectures
- Comparing architecture alternatives using the same scenarios
- Dependencies between components revealed by changes
Not good for
- Evaluation without concrete scenarios or an architecture description
- Comprehensive analysis of trade-offs between many quality goals
Outputs
Functions and components
An overview shows which components implement the business functions and how they are connected. Alternatives are described at comparable depth.
Assessed change impacts
Each evaluation case records the expected changes and the basis of the assessment. Assumptions and open questions show where further investigation is needed. Additional analysis establishes costs and runtime behaviour.
Next steps with named owners
The next steps contain specific investigations and decisions with a responsible person and date.
SAAM analysis report
Fictional worked example
Document the business functions, affected components and assessed change impacts.
Question and business functions
Describe the analysis question, system boundary and goals for future development. List the business functions as a shared basis.
Add shipping providers; prepare order, book shipment, map status.
Functions and components
Describe components and connections for each alternative. Map business functions to them and record sources and information still needed.
A: The order module calls providers directly. B: Adapters handle communication and map status codes. The shared interface still needs checking.
Quality goals and criteria
Name the relevant quality goals. Explain the criteria you will use and which conclusions they support.
Modifiability: affected components and interfaces and required tests. Effort will be estimated later.
Concrete evaluation cases
Record concrete tasks, context, desired outcome, priority and selection rationale.
T1: add second parcel provider. T2: grouped shipments with multiple parcel IDs. Both from fictional growth plans.
Assessment and next steps
For each task and alternative, record the required changes, evidence, assumptions and assessment. Agree next steps and owners.
With a suitable interface, T1 in B affects the new adapter and status mapping. T2 requires further changes in both alternatives. Development examines the interface and tests.
The example is fictional. It illustrates possible change impacts; open assumptions and pending checks are marked.
First step
Clarify the analysis question and the business domain in scope. Gather architecture documents and agree relevant change tasks with people who know the system and how it is used.
Good to do first
Deep dive
How it works
Describe the system’s domain functions and map them to architecture components and connections. Select important quality attributes, such as modifiability. Define typical tasks as scenarios and examine how the architecture supports each task.
In detail
This guide follows the original five-step SAAM version. The team first describes domain functions and maps them to components and connections. This shared basis makes architectures comparable. Concrete tasks then show how well the architecture supports the selected quality attributes. These include modifiability and portability, meaning the ability to move to other technical environments. Experienced practitioners examine the affected structures and explain their judgments. The strength of the conclusions depends on the selected tasks, the precision of the architecture description, and the documented assumptions. Reliable implementation costs require additional evidence.
Facilitation
Agree which changes or alternatives to examine and prepare an architecture overview. Gather typical usage tasks and realistic changes with the participants. Ask experienced developers to explain the effects on the system and label estimates. One specialist can perform the analysis. Confirm the scenario selection and weighting together with the participants. Allow time for research, analysis, and a joint review of the findings.
The method guide walks execution through 5 phases, timing, 5 pitfalls, and clear stop criteria.
Open method guideYour perspective
Does this method help with your work?
Your feedback helps shape the next improvements to methodatlas.
Sources and topics
Sources
SEI: SAAM: A Method for Analyzing the Properties of Software Architecturessei.cmu.eduOriginal paper, section 1 and subsequent case analysis: common functional partition, allocation to structures, quality attributes, concrete tasks and evaluation of architectural support. This guide follows that five-step version; example and worksheet are original teaching additions.Original report PDFsei.cmu.eduFull text for deeper study of the steps and evaluation limits identified above.
Artifact templates
SAAM (Software Architecture Analysis Method): WorksheetPrepare the overall initiative or a selected analysis block with a concrete question, documents and participants.markdown
SAAM (Software Architecture Analysis Method): WorksheetPrepare the overall initiative or a selected analysis block with a concrete question, documents and participants.
markdownsaam-markdown.md
Prepare the overall initiative or a selected analysis block with a concrete question, documents and participants.
SAAM (Software Architecture Analysis Method): Worksheet
Question
To be confirmed
Desired outcome
To be confirmed
Scope
Whole analysis initiative Time: Multiple meetings and interim work, to be agreed according to scope
Complete this worksheet on paper or in your own document during the work.
Preparation for this scope
Method setup
- Materials: Versioned architecture documents, goals for future development, evaluation cases, findings log and sources used.
- Roles: An architecture analyst; developers familiar with the system; product and domain representatives to help select tasks. Add facilitation and note-taking as needed. A qualified person can prepare and conduct the analysis alone. Task selection, weighting and key assumptions are then checked with affected stakeholders; until then, findings are an initial assessment.
- Advance information: Clarify the analysis question and the business domain in scope. Gather architecture documents and agree relevant change tasks with people who know the system and how it is used.
- Overall time needed: Plan preparation, agreement on evaluation cases, one or more analysis blocks and a results discussion. The number and difficulty of tasks and the available documents determine the time needed. The time entered for one step applies to that selected work block.
- Setup: Set up a shared document with stable scenario and finding IDs. Label facts, assumptions, technical evidence and decisions separately.
Prepare for the work steps
Functions: Describe the functions the system performs
- Knowledge of the business domain and system use
- Bounded analysis question
Allocation: Map functions to components
- Functional partition
- Architecture description for each alternative
Qualities: Set quality goals and evaluation criteria
- Goals for use and future development
- Functions and responsible components
Tasks: Describe representative changes as evaluation cases
- Quality attributes and criteria
- Expected business or technical changes
Evaluation: Examine change impacts for each architecture
- Scenario tasks
- Mapping of functions to components
- Evaluation criteria
SAAM analysis report
Question and business functions
Describe the analysis question, system boundary and goals for future development. List the business functions as a shared basis.
...
Functions and components
Describe components and connections for each alternative. Map business functions to them and record sources and information still needed.
...
Quality goals and criteria
Name the relevant quality goals. Explain the criteria you will use and which conclusions they support.
...
Concrete evaluation cases
Record concrete tasks, context, desired outcome, priority and selection rationale.
...
Assessment and next steps
For each task and alternative, record the required changes, evidence, assumptions and assessment. Agree next steps and owners.
...
Enter your own information, sources and assumptions in the blank worksheet.
SEI: Software Architecture Analysis Method
Functions: Describe the functions the system performs
Expected artifact: Shared list of business functions
Functions describe responsibilities; components are mapped in the next step.
Entry:
...
- Do the functions describe business tasks independently of particular products?
- Is it understood consistently across alternatives?
Allocation: Map functions to components
Expected artifact: Functions and responsible components
Describe each component’s responsibility and connections so you can trace the effects of a change later.
Entry:
...
- Are all relevant functions mapped?
- Are alternatives described at comparable depth?
Qualities: Set quality goals and evaluation criteria
Expected artifact: Quality goals and evaluation criteria
The number of affected components shows how far a change reaches. An effort estimate also needs information about implementation and testing.
Entry:
...
- Do the criteria match the goals for use and future development?
- Are structural indicators distinguished from effort estimates?
Tasks: Describe representative changes as evaluation cases
Expected artifact: Evaluation cases with selection rationale
Start with the desired change. Record possible technical solutions as options for the subsequent analysis.
Entry:
...
- Are the tasks concrete enough to walk through the affected components step by step?
- Have people from the affected areas agreed on the selection?
Evaluation: Examine change impacts for each architecture
Expected artifact: Evaluation and change impact
The analysis shows which changes the architecture is expected to require. Further investigations establish code quality, precise effort and actual runtime behavior.
Entry:
...
- Can each assessment be traced to the affected components and its sources?
- Are assumptions and unexamined consequences visible?
Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/saam/run-sheet
Alternatives and neighbors
Fitting alternatives with decision guidance, followed by other related methods.
Architecture
ATAM (Architecture Tradeoff Analysis Method)
Choose ATAM to evaluate several competing quality goals and their trade-offs.
Architecture
LASR (Lightweight Approach for Software Reviews)
Helps a small team assess the main quality risks in its software and choose where to investigate further.
Architecture
Architecture Decision Record
Documents an architecture decision with context, alternatives, and consequences so later reviews remain traceable.
Architecture
Architecture Inception Canvas
Bundles problem, goals, stakeholders, and risks into a starting picture that sorts early architecture questions.
Architecture
ARID (Active Reviews for Intermediate Designs)
Developers try a preliminary technical design through typical tasks, showing what makes it easy or difficult to use.
Architecture
Quality Attribute Workshop
Gathers quality goals, prioritizes risks, and turns them into architecture topics evaluated together.
Constraints and origin
HighWorkshop + asyncPreparation, scenario analysis, and findings review; effort depends on scope
Profile
- Method form
- Analysis method
- Participants
- Architecture experts and stakeholders for scenarios and weighting
- Time
- Preparation, scenario analysis, and findings review; effort depends on scope
- Maturity
- Canonical
Next up: Experiment Canvas