A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.
What needs to be finished first
Components, interfaces and dependencies are described for the system area in scope. For existing systems, the documents show which details have been checked against code or with people who know the system.
Product and domain representatives have agreed on the analysis question. Participants can identify typical usage and change requirements.
A qualified person can assess components, interfaces and change impacts. Developers familiar with the system and product and domain representatives are available to answer questions.
What needs to be ready before start
Versioned architecture documents, goals for future development, evaluation cases, findings log and sources used.
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.
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.
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.
Set up a shared document with stable scenario and finding IDs. Label facts, assumptions, technical evidence and decisions separately.
The one question this method answers
What changes do our planned tasks require, and how do the architecture alternatives differ?
Phases with goal, actions, output and pitfall
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.
Fictional worked example
Document the business functions, affected components and assessed change impacts.
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.
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.
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.
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.
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.
Functions
Goal
Establish a common basis for analysis.
Inputs for this step
Actions
Output
Shared list of business functions
Functions describe responsibilities; components are mapped in the next step.
Quality check
Do the functions describe business tasks independently of particular products? Is it understood consistently across alternatives?
Pitfall
Functions simply mirror modules in the favored solution. Describe the business tasks independently of the technical solution and agree them with domain experts.
Timing: Preparation and domain discussion; plan time based on the available documents.
Allocation
Goal
Understand architectures at the same level of description.
Inputs for this step
Actions
Output
Functions and responsible components
Describe each component’s responsibility and connections so you can trace the effects of a change later.
Quality check
Are all relevant functions mapped? Are alternatives described at comparable depth?
Pitfall
An alternative seems simpler because its details are missing. Describe alternatives at comparable depth and identify information still needed for the comparison.
Timing: Document analysis and architecture alignment; schedule necessary reconstruction separately.
Qualities
Goal
Ground evaluation in relevant criteria.
Inputs for this step
Actions
Output
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.
Quality check
Do the criteria match the goals for use and future development? Are structural indicators distinguished from effort estimates?
Pitfall
Quality is reduced to having as few components as possible. Also consider responsibilities, interfaces, required tests and confidence in the assessment.
Timing: Align criteria jointly before analyzing tasks.
Tasks
Goal
Explain which evaluation cases cover the important requirements.
Inputs for this step
Actions
Output
Evaluation cases with selection rationale
Start with the desired change. Record possible technical solutions as options for the subsequent analysis.
Quality check
Are the tasks concrete enough to walk through the affected components step by step? Have people from the affected areas agreed on the selection?
Pitfall
Only tasks that are easy to support are selected. Include likely and challenging changes and document the selection rationale.
Timing: Align tasks with affected people; conduct additional interviews where knowledge is missing.
Evaluation
Goal
Explain the architecture’s suitability through concrete change impacts.
Inputs for this step
Actions
Output
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.
Quality check
Can each assessment be traced to the affected components and its sources? Are assumptions and unexamined consequences visible?
Pitfall
A qualitative assessment is passed on as a firm implementation estimate. Label the estimation basis and have the implementers examine effort, tests and migration separately.
Timing: Analysis blocks and result alignment; schedule technical evidence gathering separately.
What comes out at the end
A versioned analysis report covering the question, architecture alternatives, evaluation cases, change impacts, evidence and next steps with owners.
Record the architecture version, date, participants and evidence used for each assessment. Mark superseded findings and retain earlier versions.
Prepare the overall initiative or a selected analysis block with a concrete question, documents and participants.
To be confirmed
To be confirmed
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.
Describe the analysis question, system boundary and goals for future development. List the business functions as a shared basis.
...
Describe components and connections for each alternative. Map business functions to them and record sources and information still needed.
...
Name the relevant quality goals. Explain the criteria you will use and which conclusions they support.
...
Record concrete tasks, context, desired outcome, priority and selection rationale.
...
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
Expected artifact: Shared list of business functions
Functions describe responsibilities; components are mapped in the next step.
Entry:
...
Expected artifact: Functions and responsible components
Describe each component’s responsibility and connections so you can trace the effects of a change later.
Entry:
...
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:
...
Expected artifact: Evaluation cases with selection rationale
Start with the desired change. Record possible technical solutions as options for the subsequent analysis.
Entry:
...
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:
...
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/saam/run-sheet
Concrete filled scenario, fictional example
Fictional example for orientation. Counts and timings describe this case and are not universal requirements.
Concrete filled scenario, fictional example
A retailer wants to add shipping providers. The software performs three business functions: preparing an order, booking shipment and mapping delivery status.
Alternative A: The order module calls providers directly and processes their status codes. Alternative B: An adapter handles communication with each provider. A mapping translates external status codes into internal delivery states.
Task T1: Add a second provider for standard parcels. A requires changes to the order module and status processing. B may need only a new adapter and an additional status mapping. This assumes the shared interface also fits the new provider, which still needs checking.
Task T2: Support grouped shipments with multiple parcel IDs. Both alternatives require changes to the order model and status mapping.
Assessment: For T1, alternative B may confine changes to the new adapter and status mapping. This assessment assumes the shared interface fits. T2 affects further components in both alternatives. The team investigates implementation effort and migration risks separately.
Next step: Development checks the shared interface against an example from the new provider and updates the architecture overview. The entire example, including its findings, is fictional.
Recognize symptoms and steer against them
Quick overview, the full text is in the matching phase in the flow
Functions simply mirror modules in the favored solution.
Describe the business tasks independently of the technical solution and agree them with domain experts.
An alternative seems simpler because its details are missing.
Describe alternatives at comparable depth and identify information still needed for the comparison.
Quality is reduced to having as few components as possible.
Also consider responsibilities, interfaces, required tests and confidence in the assessment.
Only tasks that are easy to support are selected.
Include likely and challenging changes and document the selection rationale.
A qualitative assessment is passed on as a firm implementation estimate.
Label the estimation basis and have the implementers examine effort, tests and migration separately.
When to pause, resolve prerequisites, or choose another approach
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.
