# arc42 section 9: Architecture Decisions

Checks for section 9 (Architecture Decisions) of an arc42 document.

Important, expensive, risky decisions with rationale

- Storage choices such as partitioning and tablespaces are documented. → [Physical Data Model](https://arc.fuet.ch/concepts/data-architecture/physical-data-model.md)
- Temporary transition components are identified, and a plan exists to remove them once the target is reached. → [AS-IS and TO-BE View](https://arc.fuet.ch/concepts/documentation/as-is-and-to-be-view.md)
- The business context shows the system as a black box apart from its communication partners. → [Architecture Canvas](https://arc.fuet.ch/concepts/documentation/architecture-canvas.md)
- The document covers what cannot be read from the code. → [Motivation for Architecture Documentation](https://arc.fuet.ch/concepts/documentation/motivation-for-architecture-documentation.md)
- Documents are built and published by a toolchain, not assembled by hand. → [Self-Documentation](https://arc.fuet.ch/concepts/documentation/self-documentation.md)
- Each entry in section 9 states the decision together with its rationale. → [arc42 Architecture Decisions](https://arc.fuet.ch/concepts/documentation/arc42-architecture-decisions.md)
- Decisions in section 4 are short but give reasons. → [arc42 Architecture Decisions](https://arc.fuet.ch/concepts/documentation/arc42-architecture-decisions.md)
- Business, data, and technology architecture are described as separate levels. → [Common Features of Architecture Frameworks](https://arc.fuet.ch/concepts/enterprise-architecture/common-features-of-architecture-frameworks.md)
- Topics near the peak are treated with caution, since publicity there can create unrealistic expectations. → [Gartner Hype Cycle for Enterprise Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/gartner-hype-cycle-for-enterprise-architecture.md)
- Responsibility for concerns that affect several applications is assigned between EA and the application. → [Relationship between Enterprise Architecture and Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/relationship-between-enterprise-architecture-and-application-architecture.md)
- Reference models, if used, are named and their constraining role on design is clear. → [TOGAF](https://arc.fuet.ch/concepts/enterprise-architecture/togaf.md)
- The document shows that data architecture and application architecture are developed together in Phase C. → [TOGAF Architecture Development Method](https://arc.fuet.ch/concepts/enterprise-architecture/togaf-architecture-development-method.md)
- Conflicting stakeholder quality requirements, such as performance versus security, are named as a reason for the evaluation. → [ATAM Application Phases](https://arc.fuet.ch/concepts/evaluation/atam-application-phases.md)
- Each documented non-risk names a quality attribute or scenario, a specific architectural decision, and a justification. → [ATAM Non-Risk](https://arc.fuet.ch/concepts/evaluation/atam-non-risk.md)
- The architecture evaluation produced a written report or out-brief that lists risks and non-risks. → [Advantages and Drawbacks of ATAM](https://arc.fuet.ch/concepts/evaluation/advantages-and-drawbacks-of-atam.md)
- The approaches are listed without risk or trade-off findings attached; those appear in the later analysis step. → [Architectural Approach Identification](https://arc.fuet.ch/concepts/evaluation/architectural-approach-identification.md)
- Important, expensive, large-scale or risky decisions are documented with their rationales. → [Architectural Decision Records as Evaluation Prerequisite](https://arc.fuet.ch/concepts/evaluation/architectural-decision-records-as-evaluation-prerequisite.md)
- Risks, sensitivity points and trade-off points are listed separately for each alternative. → [Comparing Architectural Alternatives with ATAM](https://arc.fuet.ch/concepts/evaluation/comparing-architectural-alternatives-with-atam.md)
- The document judges the style's benefits against its challenges for the specific context. → [Fitness for Purpose](https://arc.fuet.ch/concepts/evaluation/fitness-for-purpose.md)
- Each risk names a specific architectural decision and a specific scenario it could make fail. → [Insufficient ATAM Application](https://arc.fuet.ch/concepts/evaluation/insufficient-atam-application.md)
- The evaluation report lists sensitivity points and states which quality attribute response each one affects. → [Sensitivity Point](https://arc.fuet.ch/concepts/evaluation/sensitivity-point.md)
- The evaluation does not rely on metrics alone to judge whether quality goals are met. → [Software Architecture Evaluation](https://arc.fuet.ch/concepts/evaluation/software-architecture-evaluation.md)
- Each trade-off decision is recorded in arc42 section 9 with its rationale. → [Trade-off Point](https://arc.fuet.ch/concepts/evaluation/trade-off-point.md)
- Accepted trade-off consequences are tracked in the prioritized risk and technical debt list in section 11. → [Trade-off Point](https://arc.fuet.ch/concepts/evaluation/trade-off-point.md)
- The criteria in the ADR come from the context and requirements, not from the properties of the preferred option. → [ADR Common Mistakes and Review Checklist](https://arc.fuet.ch/concepts/forces-decisions/adr-common-mistakes-and-remediations.md)
- The ADR lists the considered options and justifies the rejection of each alternative. → [ADR Common Mistakes and Review Checklist](https://arc.fuet.ch/concepts/forces-decisions/adr-common-mistakes-and-remediations.md)
- The decision section explains why the option was chosen and does not just repeat the ADR title. → [ADR Common Mistakes and Review Checklist](https://arc.fuet.ch/concepts/forces-decisions/adr-common-mistakes-and-remediations.md)
- The consequences of each constraint, such as extra cost or effort, are described. → [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md)
- Each decision states the alternatives considered and the criteria used to choose among them. → [Architectural Decision](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision.md)
- Each decision records its rationale, answering why this option was chosen. → [Architectural Decision](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision.md)
- The context of each decision covers technical, political, social, and project aspects. → [Architectural Decision](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision.md)
- The record shows that the stakeholders of the decision were identified, for example in a RACI matrix. → [Architectural Decision Definition of Ready](https://arc.fuet.ch/concepts/forces-decisions/definition-of-ready-for-architectural-decisions.md)
- The decision requirements and drivers are at least identified and drafted, ideally in SMART form. → [Architectural Decision Definition of Ready](https://arc.fuet.ch/concepts/forces-decisions/definition-of-ready-for-architectural-decisions.md)
- An ADR template was chosen and validated before the decision was recorded. → [Architectural Decision Definition of Ready](https://arc.fuet.ch/concepts/forces-decisions/definition-of-ready-for-architectural-decisions.md)
- Context and requirements are stated explicitly, so decisions can be compared with earlier projects. → [Architectural Decision Making Fallacies](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-making-fallacies.md)
- Each decision record states its scope and does not mix system-wide and local arguments. → [Architectural Decision Making Fallacies](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-making-fallacies.md)
- The ADR log contains only architecturally significant decisions, those affecting structure, quality characteristics or important dependencies. → [Architectural Decision Management](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-practices.md)
- Each ADR logs the resolution of at least one architecturally significant requirement. → [Architectural Decision Management Cycle](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-cycle.md)
- Each ADR names its decision makers. → [Architectural Decision Management Cycle](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-cycle.md)
- Each decision lists at least two options and the criteria (decision drivers) used to compare them. → [Architectural Decision Management Cycle](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-cycle.md)
- The ADR title conveys both the problem solved and the solution chosen. → [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md)
- The ADR evaluates more than one real option, not dummy alternatives. → [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md)
- The decision is traced to requirements. → [Architectural Decision Record](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-record.md)
- The record names the problem and links it to at least one quality goal or significant requirement. → [Architectural Decision Record Example](https://arc.fuet.ch/concepts/forces-decisions/middleware-architectural-decision-example.md)
- Rejected options are listed and evaluated, not only the chosen one. → [Architectural Decision Record Example](https://arc.fuet.ch/concepts/forces-decisions/middleware-architectural-decision-example.md)
- Pros, cons and trade-offs of the chosen option are balanced, with a stated judgment. → [Architectural Decision Record Example](https://arc.fuet.ch/concepts/forces-decisions/middleware-architectural-decision-example.md)
- Each recorded decision shows at least two options that were compared. → [Architectural Decision-Making Process](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-making-in-project-development.md)
- Decisions state when they will be reviewed or which context changes trigger re-evaluation. → [Architectural Decision-Making Process](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-making-in-project-development.md)
- The document describes how the system keeps its most critical functions working when elements fail. → [Architectural Decisions for Availability](https://arc.fuet.ch/concepts/forces-decisions/architectural-decisions-for-availability.md)
- Each design issue is phrased as a concise question. → [Architectural Design Issue](https://arc.fuet.ch/concepts/forces-decisions/formulation-of-decision-issues.md)
- Rejected options are evaluated too, not only the chosen one. → [Architectural Design Issue](https://arc.fuet.ch/concepts/forces-decisions/formulation-of-decision-issues.md)
- The document separates constraints (which must be handled, though some are negotiable) from forces (which are weighed). → [Architectural Force](https://arc.fuet.ch/concepts/forces-decisions/architectural-forces.md)
- The architecture decisions section lists only important, expensive, large-scale or risky decisions, each with its rationale. → [Architecturally Significant Decision](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-decision.md)
- Each ASR is linked to business value or risk, or to a key stakeholder's concern. → [Architecturally Significant Requirement](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-requirement.md)
- Essential architectural decisions are recorded, for example as ADRs, using one consistent template. → [Architecture Challenges at Project Start](https://arc.fuet.ch/concepts/forces-decisions/architecture-challenges-at-project-start.md)
- Each decision lists all consequences, including negative ones. → [Architecture Decision Documentation and Requirements Management](https://arc.fuet.ch/concepts/forces-decisions/decision-documentation-and-requirements-management.md)
- Each recorded decision names the chosen alternative and the criteria or requirement behind the choice. → [Architecture Decision Rationale](https://arc.fuet.ch/concepts/forces-decisions/architecture-decision-rationale.md)
- Each ADR covers exactly one decision together with its rationale. → [Architecture Decision Rationale](https://arc.fuet.ch/concepts/forces-decisions/architecture-decision-rationale.md)
- Consequences list all effects of the decision, not only the positive ones. → [Architecture Decision Rationale](https://arc.fuet.ch/concepts/forces-decisions/architecture-decision-rationale.md)
- The architecture documentation lists the important, expensive, large-scale or risky decisions together with their reasons. → [Architecture as Set of Design Decisions](https://arc.fuet.ch/concepts/forces-decisions/architecture-as-set-of-design-decisions.md)
- Each documented decision is tied to an architecturally significant requirement. → [Architecture as Set of Design Decisions](https://arc.fuet.ch/concepts/forces-decisions/architecture-as-set-of-design-decisions.md)
- The reasoning behind resolving concern conflicts is recorded in Architecture Decision Records. → [Concern](https://arc.fuet.ch/concepts/forces-decisions/concern.md)
- Decisions with many or unclear outgoing dependencies are flagged as big or early decisions. → [Decision Dependencies](https://arc.fuet.ch/concepts/forces-decisions/decision-dependencies.md)
- The decision record shows at least two alternatives that were investigated and compared. → [Definition of Done for Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/definition-of-done-for-architectural-decisions.md)
- The decision is captured and shared in a lean template. → [Definition of Done for Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/definition-of-done-for-architectural-decisions.md)
- The record states who challenged the decision and that the team accepts outcome and rationale. → [Definition of Done for Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/definition-of-done-for-architectural-decisions.md)
- AI-generated ADRs show evidence of human review before being accepted. → [GenAI Support for Architectural Decision Records](https://arc.fuet.ch/concepts/forces-decisions/genai-support-for-architectural-decision-records.md)
- References in AI-drafted ADRs (APIs, web pages, product features) were checked to exist. → [GenAI Support for Architectural Decision Records](https://arc.fuet.ch/concepts/forces-decisions/genai-support-for-architectural-decision-records.md)
- Pros and cons suggested by an AI were validated for incorrect or exaggerated details. → [GenAI Support for Architectural Decision Records](https://arc.fuet.ch/concepts/forces-decisions/genai-support-for-architectural-decision-records.md)
- Each open decision states whether its most responsible moment has come. → [Last Responsible Moment](https://arc.fuet.ch/concepts/forces-decisions/last-responsible-moment.md)
- Big architectural decisions with an early most responsible moment are identified and not postponed. → [Last Responsible Moment](https://arc.fuet.ch/concepts/forces-decisions/last-responsible-moment.md)
- Architectural decisions made by teams are recorded, for example in ADRs, after seeking advice from affected parties. → [Levels of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/levels-of-architectural-decisions.md)
- Higher-level bodies provide guidelines or principles rather than deciding everything themselves. → [Levels of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/levels-of-architectural-decisions.md)
- Decision files sit in docs/decisions and follow the NNNN-title-with-dashes.md naming pattern. → [Markdown Architectural Decision Records](https://arc.fuet.ch/concepts/forces-decisions/markdown-architectural-decision-records-madr.md)
- Each decision lists its consequences, both good and bad. → [Markdown Architectural Decision Records](https://arc.fuet.ch/concepts/forces-decisions/markdown-architectural-decision-records-madr.md)
- Each decision says how compliance with it will be confirmed. → [Markdown Architectural Decision Records](https://arc.fuet.ch/concepts/forces-decisions/markdown-architectural-decision-records-madr.md)
- Each architectural decision names its decision makers, consulted stakeholders and affected people. → [RACI Matrix](https://arc.fuet.ch/concepts/forces-decisions/raci-matrix.md)
- Each task or decision has exactly one Accountable party. → [RACI Matrix](https://arc.fuet.ch/concepts/forces-decisions/raci-matrix.md)
- Non-functional requirements are explicitly linked to the architectural decisions that address them. → [Requirements-Decision Modeling for Cyber-Physical Systems of Systems](https://arc.fuet.ch/concepts/forces-decisions/requirements-decision-modeling-for-cyber-physical-systems-of-systems.md)
- Buy-versus-build decisions state their total-cost-of-ownership consequences. → [Seven Types of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/seven-types-of-architectural-decisions.md)
- The solution strategy is described as able to evolve, with iterative and incremental building. → [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md)
- Technical limits or goal conflicts found during architecture work are recorded as feedback to the requirements. → [Twin Peaks Model](https://arc.fuet.ch/concepts/forces-decisions/twin-peaks-model.md)
- Each decision statement names its context, concern, chosen option, neglected options, desired qualities and accepted downside. → [Y-Statement](https://arc.fuet.ch/concepts/forces-decisions/y-statement.md)
- The downside clause ('accepting that...') states a concrete cost, not a generic remark. → [Y-Statement](https://arc.fuet.ch/concepts/forces-decisions/y-statement.md)
- The decision is written as one sentence, kept lean. → [Y-Statement](https://arc.fuet.ch/concepts/forces-decisions/y-statement.md)
- The team has recorded architectural decisions, so the structure traces back to deliberate choices. → [Accidental Architecture](https://arc.fuet.ch/concepts/fundamentals/unsystematic-accidental-architecture.md)
- Models or viewpoints are chosen to answer stated questions, such as a throughput model for a throughput concern. → [Agile Architecture](https://arc.fuet.ch/concepts/fundamentals/agile-architecture.md)
- Conflicting goals are recorded together with how the relevant stakeholders resolved them. → [Architectural Thinking](https://arc.fuet.ch/concepts/fundamentals/architectural-thinking.md)
- For each chosen style, the document states the constraints it imposes and the trade-offs accepted. → [Architecture Means](https://arc.fuet.ch/concepts/fundamentals/architecture-means.md)
- Changes are made in small steps and integrated often, rather than in one late big-bang integration. → [Keep It Working](https://arc.fuet.ch/concepts/fundamentals/keep-it-working.md)
- The architecture is described in views that address stakeholder concerns. → [Role of the Software Architect](https://arc.fuet.ch/concepts/fundamentals/architect-knowledge-and-tasks.md)
- The consequences of key trade-offs are made visible to stakeholders at several organizational levels. → [Software Architect](https://arc.fuet.ch/concepts/fundamentals/software-architect-role.md)
- The canonical model is independent of any specific application. → [Canonical Data Model](https://arc.fuet.ch/concepts/integration/canonical-data-model.md)
- Platform and protocol constraints of a chosen messaging product, such as proprietary protocols, are stated. → [Integration Pattern vs. Middleware Technology](https://arc.fuet.ch/concepts/integration/integration-patterns-vs-middleware-technology.md)
- If a shared database is used, the document explains how one schema serves all applications and how changes are controlled. → [Integration Style](https://arc.fuet.ch/concepts/integration/integration-pattern.md)
- The document states which AMQP version is meant, since 1.0 and 0-9-1 differ on the wire. → [Messaging Protocol Support in Message Brokers](https://arc.fuet.ch/concepts/integration/messaging-systems-and-protocols.md)
- The document states how long clients can rely on a published API version. → [Patterns for API Design](https://arc.fuet.ch/concepts/integration/patterns-for-api-design.md)
- Any shared database between applications is justified, including the risk it adds when applications change. → [Principles Influencing EAI Pattern Selection](https://arc.fuet.ch/concepts/integration/principles-influencing-eai-pattern-selection.md)
- If a relay publishes outbox messages, the document states that duplicates are possible and how receivers handle them. → [Transactional Client](https://arc.fuet.ch/concepts/integration/transactional-client.md)
- If models are published straight from the tool to an environment, the document names that environment. → [BPMN Modeling Tool](https://arc.fuet.ch/concepts/modeling-bpmn/bpmn-modeling-tools.md)
- RPA bots run as normal process steps with shared error handling, retries, and audit. → [Degrees of BPM Maturity](https://arc.fuet.ch/concepts/modeling-bpmn/degrees-of-bpm-maturity.md)
- Principles narrow the options instead of dictating a single answer. → [Architecture Principle](https://arc.fuet.ch/concepts/principles/architecture-principle.md)
- Choices such as microservices are justified by fit to context, not by trend. → [Conflicting Architecture Principles](https://arc.fuet.ch/concepts/principles/conflicting-architecture-principles.md)
- Decisions are based on facts rather than guesses, so unused capabilities are not built. → [Continuous Architecture Principles](https://arc.fuet.ch/concepts/principles/continuous-architecture-principles.md)
- The document shows how user and stakeholder feedback is collected and fed back into the design. → [Incrementality](https://arc.fuet.ch/concepts/principles/incrementality.md)
- Widely deployed, hard-to-change elements, such as enterprise database schemas, are identified, with the cost of changing them noted. → [Shearing Layers](https://arc.fuet.ch/concepts/principles/shearing-layers.md)
- Important architecture decisions name the requirements behind them. → [Traceability](https://arc.fuet.ch/concepts/principles/traceability.md)
- Each principle gives a rationale in business terms. → [Working with Principles](https://arc.fuet.ch/concepts/principles/working-with-principles.md)
- Each major decision names the quality it improves and the quality it may harm. → [Quality Attribute Trade-off](https://arc.fuet.ch/concepts/quality-attributes/architectural-trade-off-thinking.md)
- The standby type (hot, warm, or cold) is named, and the state the standby holds at takeover is described. → [Quantifying Recovery and Availability Trade-offs](https://arc.fuet.ch/concepts/quality-attributes/quantifying-recovery-and-availability-trade-offs.md)
- Reused assets are checked as fit for purpose, or designed for reuse. → [Reusability](https://arc.fuet.ch/concepts/quality-attributes/reusability.md)
- The document states the topology constraints of each pattern, such as what elements may know about each other. → [Architectural Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern.md)
- The trade-offs of the chosen style or patterns are stated. → [Architectural Pattern vs. Design Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern-vs-design-pattern.md)
- The style choice is traced to business drivers and prioritized architecture characteristics, with stakeholder input. → [Architecture Style](https://arc.fuet.ch/concepts/styles-patterns/architectural-style.md)
- The document explains how the serving layer combines batch views with speed-layer updates for queries. → [Lambda Architecture](https://arc.fuet.ch/concepts/styles-patterns/lambda-architecture.md)
- Where a pattern is used, the tactics it is built from are identified. → [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md)
- The document describes which essential functions stay available in a degraded mode when components fail. → [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics.md)
- Side effects of each tactic on other quality attributes are documented along with the trade-offs accepted. → [Choosing and Applying Tactics](https://arc.fuet.ch/concepts/tactics/choosing-and-applying-tactics.md)
- Runtime overhead from added structure, such as layer crossings, is acknowledged. → [Increase Cohesion](https://arc.fuet.ch/concepts/tactics/increase-cohesion.md)
- Key modules expose an explicit interface that hides implementation details. → [Modifiability Tactic](https://arc.fuet.ch/concepts/tactics/modifiability-tactics.md)
- Queue sizes and execution time per event are bounded, or the document explains why not. → [Performance Tactic](https://arc.fuet.ch/concepts/tactics/performance-tactics.md)
- Design decisions are tied to a stated quality attribute objective. → [Reasons for Architectural Tactics](https://arc.fuet.ch/concepts/tactics/reasons-for-architectural-tactics.md)
- The document says how each chosen tactic is realized, for example through a pattern, framework or code. → [Relationship between Tactics and Architectural Styles/Patterns](https://arc.fuet.ch/concepts/tactics/tactics-vs-architectural-styles-and-patterns.md)
- The document records that stakeholders took part in selecting the security tactics. → [Security Tactic](https://arc.fuet.ch/concepts/tactics/security-tactics.md)
- The decision to split or join is based on overall complexity, not size. → [Split Module](https://arc.fuet.ch/concepts/tactics/split-module.md)
- Trade-off points and sensitivity points found in the analysis are identified. → [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md)
- Each tactic decision is recorded as an ADR that traces back to a requirement. → [Working with Tactics and Quality Attributes](https://arc.fuet.ch/concepts/tactics/working-with-tactics-and-quality-attributes.md)
- Each strategic decision is tied to the problem statement, quality goals or key constraints. → [System Idea](https://arc.fuet.ch/concepts/vision-stakeholders/system-idea.md)