# Architecture Evaluation

> ATAM, scenario-based and lightweight evaluation methods, risks, non-risks, sensitivity points, trade-off points, technical debt.

## Concepts

- [Advantages and Drawbacks of ATAM](https://arc.fuet.ch/concepts/evaluation/advantages-and-drawbacks-of-atam.md): ATAM brings early risk detection, clearer quality requirements, better documentation and more stakeholder discussion. The price is effort: a full evaluation takes days and many people, so lighter variants exist.
- [Architectural Approach Identification](https://arc.fuet.ch/concepts/evaluation/architectural-approach-identification.md): Architectural approach identification is Step 4 of ATAM. The architect names the approaches used in the system. The team only lists them here and analyzes them later.
- [Architectural Decision Records as Evaluation Prerequisite](https://arc.fuet.ch/concepts/evaluation/architectural-decision-records-as-evaluation-prerequisite.md): Writing down key architectural decisions, with the reasons for each choice, gives an evaluation something concrete to check against the quality goals. Reviewers can then see which decisions support which goals.
- [Architecture Tradeoff Analysis Method (ATAM)](https://arc.fuet.ch/concepts/evaluation/architecture-tradeoff-analysis-method-atam.md): ATAM is a method for checking a software architecture against its quality goals. It shows how those goals pull against each other and exposes risks that could block business goals.
- [ATAM Application Phases](https://arc.fuet.ch/concepts/evaluation/atam-application-phases.md): ATAM works best early, before major implementation spending, because it shows whether an architecture can meet its quality goals. It also applies to legacy systems, once their real architecture has been recovered.
- [ATAM Evaluation Team and Stakeholder Selection](https://arc.fuet.ch/concepts/evaluation/atam-evaluation-team-and-stakeholder-selection.md): An ATAM evaluation needs an external evaluation team and a group of stakeholders. Both are chosen and briefed before analysis starts. The stakeholders supply the scenarios that drive the analysis.
- [ATAM Findings: Risks, Non-Risks, Sensitivity Points and Trade-off Points](https://arc.fuet.ch/concepts/evaluation/atam-findings-risks-non-risks-sensitivity-points-and-trade-offs.md): An ATAM review produces findings: risks, non-risks, sensitivity points and trade-off points. They come from analyzing architectural approaches against the highest-priority scenarios. Risks are then grouped into themes tied to business drivers.
- [ATAM Non-Risk](https://arc.fuet.ch/concepts/evaluation/atam-non-risk.md): A non-risk is a decision that an ATAM evaluation team analyzed and found sound for a specific quality goal. The team records it with its reasoning, next to the risks it finds.
- [ATAM Phase 1 and 2 Activities](https://arc.fuet.ch/concepts/evaluation/atam-phase-1-and-2-activities.md): An ATAM evaluation is a short series of steps, usually three to four days. Participants present the method and the architecture, analyze it against scenarios, and end with a report of findings.
- [ATAM Phase 1: Architecture-centric Analysis](https://arc.fuet.ch/concepts/evaluation/atam-phase-1-architecture-centric-analysis.md): Phase 1 of ATAM opens an architecture evaluation. The evaluation team, the architects and other participants start by learning how the method works. Phase 2 then widens the input to a larger stakeholder group.
- [ATAM Results](https://arc.fuet.ch/concepts/evaluation/atam-results.md): ATAM results are what an evaluation team hands to stakeholders at the end: documented architecture risks, plus risk themes showing which business goals those risks threaten.
- [ATAM Roles](https://arc.fuet.ch/concepts/evaluation/atam-roles.md): An ATAM evaluation involves three groups: a small external evaluation team, project decision-makers who can mandate architectural changes, and broader stakeholders who join only in the second phase.
- [Battlefield Control System ATAM Case Study](https://arc.fuet.ch/concepts/evaluation/battlefield-control-system-atam-case-study.md): The Battlefield Control System is the first worked case study of the ATAM, an architecture evaluation method, in the book Evaluating Software Architectures. It shows how risks, sensitivity points and trade-off points are found.
- [Code Smell](https://arc.fuet.ch/concepts/evaluation/code-smell.md): A code smell is a surface sign in code that often points to a deeper design problem. Smells such as long methods or large classes show where refactoring may be needed.
- [Comparing Architectural Alternatives with ATAM](https://arc.fuet.ch/concepts/evaluation/comparing-architectural-alternatives-with-atam.md): To compare candidate architectures with ATAM, judge each against the same requirements and scenarios. Tally the risks, sensitivity points and trade-off points per draft. Then weigh them by business impact, not by count alone.
- [Fitness for Purpose](https://arc.fuet.ch/concepts/evaluation/fitness-for-purpose.md): An architecture is rarely good or bad on its own. It is fit or unfit for a purpose, and that purpose comes mostly from the context where the system will live.
- [Insufficient ATAM Application](https://arc.fuet.ch/concepts/evaluation/insufficient-atam-application.md): An ATAM review is weak when its findings are not tied to specific architectural decisions, quality attributes and scenarios. Vague risks and unproven non-risks cannot be acted on or trusted.
- [Lightweight Approach for Software Reviews (LASR)](https://arc.fuet.ch/concepts/evaluation/lightweight-approach-for-software-reviews-lasr.md): LASR is a lightweight way to review a software system. A small team runs a short, game-like workshop. It checks the system against quantified quality goals and gives first results within hours.
- [Lightweight ATAM](https://arc.fuet.ch/concepts/evaluation/lightweight-atam.md): A lightweight ATAM is a shortened form of the full Architecture Tradeoff Analysis Method. It uses fewer people and simpler steps to deliver results in about a day, but it finds fewer risks.
- [Placing ATAM Evaluation in arc42](https://arc.fuet.ch/concepts/evaluation/placing-atam-evaluation-in-arc42.md): arc42 section 11 normally lists risks and technical debt. An ATAM-based variant replaces it with an evaluation section that records the risks, sensitivity points and trade-off points found during an ATAM evaluation.
- [Risk Storming](https://arc.fuet.ch/concepts/evaluation/risk-storming.md): Risk storming is a quick, collaborative way to find and show risks in an architecture. The team rates each risk by probability and impact, then tackles the highest-priority ones first.
- [Scenario Weight Assignment and Prioritization](https://arc.fuet.ch/concepts/evaluation/scenario-weight-assignment.md): Stakeholders brainstorm many scenarios, then vote to rank them. In ATAM and the Quality Attribute Workshop, the voting involves the stakeholder group.
- [Sensitivity Point](https://arc.fuet.ch/concepts/evaluation/sensitivity-point.md): A sensitivity point is a property of a system that one quality, such as speed or confidentiality, depends on strongly. Teams flag these points during evaluation so they know which decisions carry the most leverage.
- [Software Architecture Analysis Method (SAAM)](https://arc.fuet.ch/concepts/evaluation/software-architecture-analysis-method-saam.md): SAAM is the first documented method for analyzing a software architecture. It uses scenarios to test how well a design handles change, and it came before ATAM.
- [Software Architecture Evaluation](https://arc.fuet.ch/concepts/evaluation/software-architecture-evaluation.md): Architecture evaluation examines a design for problems and risks before teams build on it. Its findings are qualitative, and it works best when done early.
- [Technical Debt](https://arc.fuet.ch/concepts/evaluation/technical-debt.md): Technical debt means shortcuts in design or code that help in the short term but make later change more costly. A little deliberate debt can speed work if the team repays it promptly.
- [Trade-off Point](https://arc.fuet.ch/concepts/evaluation/trade-off-point.md): A trade-off point is a property of the architecture that affects several quality attributes at once. Improving one attribute through it costs another. ATAM reports these points so teams can decide on a compromise knowingly.