# arc42 section 4: Solution Strategy

Checks for section 4 (Solution Strategy) of an arc42 document.

Fundamental decisions and solution approaches

- The document states which bounded contexts use CQRS rather than applying it to the whole system. → [Command Query Responsibility Segregation](https://arc.fuet.ch/concepts/data-architecture/command-query-responsibility-segregation.md)
- The diagram shows building blocks inside the system, not only its external dependencies. → [Architectural Overview Diagram](https://arc.fuet.ch/concepts/documentation/architectural-overview-diagram.md)
- Building blocks name the crosscutting concepts they apply, for example through a stereotype tag. → [Crosscutting Concept](https://arc.fuet.ch/concepts/documentation/arc42-crosscutting-concepts.md)
- The section is short and compact, for example a keyword list, and refers onward instead of giving details. → [Solution Strategy](https://arc.fuet.ch/concepts/documentation/arc42-solution-strategy.md)
- The section states the top-level decomposition decision, such as an architectural or design pattern. → [Solution Strategy](https://arc.fuet.ch/concepts/documentation/arc42-solution-strategy.md)
- Each key quality goal has a solution approach described in the context of that goal. → [Solution Strategy](https://arc.fuet.ch/concepts/documentation/arc42-solution-strategy.md)
- Section 9 refers to section 4 instead of repeating the fundamental decisions. → [arc42 Architecture Decisions](https://arc.fuet.ch/concepts/documentation/arc42-architecture-decisions.md)
- Each entity in the domain model has a unique identity, and its validation and state transitions live in the entity itself. → [DDD Building Blocks (Tactical Patterns)](https://arc.fuet.ch/concepts/domain-driven-design/ddd-modeling-elements.md)
- The document states which aspects of the domain the model covers. → [Domain Model](https://arc.fuet.ch/concepts/domain-driven-design/domain-model.md)
- The document names the domain experts' terms and uses them consistently. → [Domain-Driven Design](https://arc.fuet.ch/concepts/domain-driven-design/domain-driven-design.md)
- The documentation states that the domain model evolves as the team's understanding grows, rather than being fixed up front. → [Iterative Domain Modeling](https://arc.fuet.ch/concepts/domain-driven-design/evolutionary-domain-modeling.md)
- Names of building blocks and terms in the documentation use the vocabulary of the business domain, and domain experts have reviewed them. → [Reflecting the Business Domain in the Architecture](https://arc.fuet.ch/concepts/domain-driven-design/reflecting-the-business-domain-in-the-architecture.md)
- The chosen strategy per application (retire, replace, rehost, refactor, retain) is stated with its reason. → [Application Landscape Evolution Drivers](https://arc.fuet.ch/concepts/enterprise-architecture/patterns-for-the-evolution-of-application-landscapes.md)
- Lifecycle phases such as Plan, Pilot, Production, Sunset and Retired are shown where a lifecycle is defined. → [Application Lifecycle Diagram](https://arc.fuet.ch/concepts/enterprise-architecture/application-lifecycle-diagram.md)
- Capabilities are kept distinct from organization units, and level-one capabilities are mapped to major organization units. → [Business Capability](https://arc.fuet.ch/concepts/enterprise-architecture/business-capability.md)
- The map was drafted from strategic documents such as annual goals, roadmaps or investment themes. → [Business Capability Map](https://arc.fuet.ch/concepts/enterprise-architecture/business-capability-map.md)
- Each heat map states its purpose, scoring method, audience and how to interpret it. → [Capability Heat Map](https://arc.fuet.ch/concepts/enterprise-architecture/capability-heat-map.md)
- Assessment data records dates, reviewers and sources. → [Capability Heat Map](https://arc.fuet.ch/concepts/enterprise-architecture/capability-heat-map.md)
- Gap analysis compares current and future capabilities, including missing ones. → [Capability Map Use Cases](https://arc.fuet.ch/concepts/enterprise-architecture/capability-map-use-cases.md)
- The document states which enterprise architecture framework is used and whether it was tailored to the organization. → [Common Features of Architecture Frameworks](https://arc.fuet.ch/concepts/enterprise-architecture/common-features-of-architecture-frameworks.md)
- Artifacts are linked through a content metamodel, with a repository for storing them. → [Common Features of Architecture Frameworks](https://arc.fuet.ch/concepts/enterprise-architecture/common-features-of-architecture-frameworks.md)
- The target data architecture is stated to support the Business Architecture and the Architecture Vision. → [Data Architecture Inputs](https://arc.fuet.ch/concepts/enterprise-architecture/data-architecture-inputs.md)
- Quality control measures exist to keep data accurate and current. → [Data Architecture Principle](https://arc.fuet.ch/concepts/enterprise-architecture/data-architecture-principle.md)
- The scope of the EA work is limited to the areas that matter most, not the entire organization. → [Enterprise Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-management.md)
- The architecture description is based on the company's choices for process integration and standardization. → [Enterprise Architecture (Ross/Weill/Robertson definition)](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-ross-weill-robertson-definition.md)
- Maturity is tied to value realized by the organization, not only to a level label. → [Enterprise Architecture Maturity Level](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-maturity-levels.md)
- The document links the architecture to the operating model's integration and standardization needs. → [Enterprise Architecture Maturity Stages](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-maturity-stages.md)
- The document records the current state of the architecture and the desired future architecture. → [Enterprise Architecture Strategy](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-strategy.md)
- The strategy treats transformation as ongoing, not as a one-off event. → [Enterprise Architecture Strategy](https://arc.fuet.ch/concepts/enterprise-architecture/enterprise-architecture-strategy.md)
- A governance mechanism makes project decisions follow the enterprise architecture. → [Foundation for Execution](https://arc.fuet.ch/concepts/enterprise-architecture/foundation-for-execution.md)
- Any investment in a new technology is judged against its position in a hype cycle or similar timing view, not only against press interest. → [Gartner Hype Cycle for Enterprise Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/gartner-hype-cycle-for-enterprise-architecture.md)
- Critical IT and business process capabilities are derived from the operating model, not from strategy alone. → [Operating Model](https://arc.fuet.ch/concepts/enterprise-architecture/operating-model.md)
- For each organizational constraint, the document states whether it is fixed or negotiable. → [Relationship between Enterprise Architecture and Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/relationship-between-enterprise-architecture-and-application-architecture.md)
- The customer perspective states what customers want from the business, not what the business wants from them. → [Strategy Map](https://arc.fuet.ch/concepts/enterprise-architecture/strategy-map.md)
- The document names which of the four domains (Business, Application, Data, Technology) each architecture description covers. → [TOGAF](https://arc.fuet.ch/concepts/enterprise-architecture/togaf.md)
- The document states how the ADM was tailored to the organization's needs. → [TOGAF Architecture Development Method](https://arc.fuet.ch/concepts/enterprise-architecture/togaf-architecture-development-method.md)
- The document explains whether and how teams return to earlier phases or repeat activities within a phase. → [TOGAF Architecture Development Method](https://arc.fuet.ch/concepts/enterprise-architecture/togaf-architecture-development-method.md)
- Candidate roadmap components are derived from the gaps and feed a prioritized application roadmap. → [TOGAF Phase C: Application Architecture](https://arc.fuet.ch/concepts/enterprise-architecture/togaf-phase-c-application-architecture.md)
- The evaluation record lists the architectural approaches the architect named. → [Architectural Approach Identification](https://arc.fuet.ch/concepts/evaluation/architectural-approach-identification.md)
- Every candidate architecture is evaluated against the same utility tree. → [Comparing Architectural Alternatives with ATAM](https://arc.fuet.ch/concepts/evaluation/comparing-architectural-alternatives-with-atam.md)
- The document explains why the style was chosen and what trade-offs it accepts. → [Fitness for Purpose](https://arc.fuet.ch/concepts/evaluation/fitness-for-purpose.md)
- Each constraint states who wants it and why. → [Architectural Constraint](https://arc.fuet.ch/concepts/forces-decisions/requirements-versus-constraints.md)
- Decision records justify choices with SMART quality criteria, not single anecdotes. → [Architectural Decision Making Fallacies](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-making-fallacies.md)
- Each ADR justification refers to requirements, gathered information, evidence, criteria and agreement. → [Architectural Decision Management](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-management-practices.md)
- Each decision record states the problem and the trade-offs considered. → [Architectural Decision-Making Process](https://arc.fuet.ch/concepts/forces-decisions/architectural-decision-making-in-project-development.md)
- The document states which components must be highly available and why, for example servers that are single points of failure. → [Architectural Decisions for Availability](https://arc.fuet.ch/concepts/forces-decisions/architectural-decisions-for-availability.md)
- Each issue lists its criteria (drivers) and its options. → [Architectural Design Issue](https://arc.fuet.ch/concepts/forces-decisions/formulation-of-decision-issues.md)
- The decision log is kept small enough to maintain and does not record every decision. → [Architecturally Significant Decision](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-decision.md)
- Each significant quality scenario is specific and measurable. → [Architecturally Significant Requirement](https://arc.fuet.ch/concepts/forces-decisions/architecturally-significant-requirement.md)
- Only a few important decisions are documented, each with its motivation, instead of every choice. → [Architecture as Set of Design Decisions](https://arc.fuet.ch/concepts/forces-decisions/architecture-as-set-of-design-decisions.md)
- Conflicting concerns, such as time-to-market versus maintainability, are named, and the chosen trade-off is explicit. → [Concern](https://arc.fuet.ch/concepts/forces-decisions/concern.md)
- Decisions that trigger follow-on decisions (for example a principle leading to technology choices) are identified. → [Decision Dependencies](https://arc.fuet.ch/concepts/forces-decisions/decision-dependencies.md)
- A superseded decision points to its replacement. → [Decision Dependencies](https://arc.fuet.ch/concepts/forces-decisions/decision-dependencies.md)
- Decisions are checked for being useful and needed now before they are made. → [Last Responsible Moment](https://arc.fuet.ch/concepts/forces-decisions/last-responsible-moment.md)
- Decisions are visible to all organizational levels, not only to the team that made them. → [Levels of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/levels-of-architectural-decisions.md)
- Architectural decisions and requirements are collected in a shared knowledge base. → [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)
- Each decision with far-reaching, hard-to-change effects is recorded as an architectural decision. → [Seven Types of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/seven-types-of-architectural-decisions.md)
- The rationale for risky decisions is documented, with effort matched to risk. → [Seven Types of Architectural Decisions](https://arc.fuet.ch/concepts/forces-decisions/seven-types-of-architectural-decisions.md)
- The document states which decisions were deliberately deferred instead of pretending everything was decided up front. → [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md)
- Requirements and architecture are described at a level of detail that grew through iteration, starting from a rough version. → [Twin Peaks Model](https://arc.fuet.ch/concepts/forces-decisions/twin-peaks-model.md)
- Features have one or more functional acceptance tests. → [Agile Enterprise Backlog Model](https://arc.fuet.ch/concepts/functional-requirements/agile-enterprise-backlog-model.md)
- Each architectural backlog item has a measurable criterion, such as a response measure. → [INVEST Applied to Architectural Work](https://arc.fuet.ch/concepts/functional-requirements/invest-applied-to-architectural-work.md)
- Responsibilities are named explicitly, and public ones (offered as services) are distinguished from private ones. → [Responsibility Allocation](https://arc.fuet.ch/concepts/functional-requirements/responsibility-allocation.md)
- Tactics or patterns used to shape the decomposition are named, with their trade-offs. → [Responsibility Allocation](https://arc.fuet.ch/concepts/functional-requirements/responsibility-allocation.md)
- Stories using the word "manage" were examined and split by operation. → [Story Splitting](https://arc.fuet.ch/concepts/functional-requirements/story-splitting.md)
- The document names the chosen architecture explicitly and does not leave it implied by the code. → [Accidental Architecture](https://arc.fuet.ch/concepts/fundamentals/unsystematic-accidental-architecture.md)
- The document names the main project risks and ties architecture effort to them. → [Agile Architecture](https://arc.fuet.ch/concepts/fundamentals/agile-architecture.md)
- The document lists the functional requirements, quality requirements and constraints that the design started from. → [Architectural Thinking](https://arc.fuet.ch/concepts/fundamentals/architectural-thinking.md)
- Known technical debt that may erode the architecture is listed. → [Architecture Decay](https://arc.fuet.ch/concepts/fundamentals/architecture-decay.md)
- Specialist disciplines used for the solution, such as network design, are named. → [Architecture Disciplines](https://arc.fuet.ch/concepts/fundamentals/architecture-disciplines.md)
- The solution strategy records the fundamental decisions, including which styles, patterns or tactics were chosen. → [Architecture Means](https://arc.fuet.ch/concepts/fundamentals/architecture-means.md)
- The document states how the team alternates expansion with consolidation, refactoring and repair. → [Big Ball of Mud](https://arc.fuet.ch/concepts/fundamentals/big-ball-of-mud.md)
- The document or team process describes delivering features as complete pieces and gathering feedback after each one. → [Iterative and Incremental Development](https://arc.fuet.ch/concepts/fundamentals/iterative-and-incremental-development.md)
- The team relies on self-testing code so refactoring stays safe and the code stays malleable. → [Iterative and Incremental Development](https://arc.fuet.ch/concepts/fundamentals/iterative-and-incremental-development.md)
- The document says the system must stay available while it is modernized, because the business depends on it and its data. → [Keep It Working](https://arc.fuet.ch/concepts/fundamentals/keep-it-working.md)
- The document states that refactoring must not change observable behavior. → [Refactoring](https://arc.fuet.ch/concepts/fundamentals/refactoring.md)
- Each constraint is marked as fixed or negotiable. → [Requirements and Means Influence Architecture](https://arc.fuet.ch/concepts/fundamentals/requirements-and-means-influence-architecture.md)
- The architect's scope of decision authority is defined. → [Role of the Software Architect](https://arc.fuet.ch/concepts/fundamentals/architect-knowledge-and-tasks.md)
- The document separates the architecture itself from the description that documents it. → [Software Architecture](https://arc.fuet.ch/concepts/fundamentals/software-architecture.md)
- The document describes the system's components, connectors, constraints and rationale. → [Software Architecture Definition](https://arc.fuet.ch/concepts/fundamentals/implications-of-the-architecture-definition.md)
- The ID record and the business effect are saved in the same database transaction. → [Idempotent Receiver](https://arc.fuet.ch/concepts/integration/idempotent-receiver.md)
- The integration style (file transfer, shared database, remote procedure invocation, or messaging) is named in product-neutral terms. → [Integration Pattern vs. Middleware Technology](https://arc.fuet.ch/concepts/integration/integration-patterns-vs-middleware-technology.md)
- The document records which integration style was chosen, the alternatives considered, and the reason for the choice. → [Integration Style](https://arc.fuet.ch/concepts/integration/integration-pattern.md)
- API design choices, such as pagination or rate limiting, are recorded as decisions with options and criteria. → [Patterns for API Design](https://arc.fuet.ch/concepts/integration/patterns-for-api-design.md)
- The document names which integration style (file transfer, shared database, remote procedure invocation or messaging) connects each pair of applications. → [Principles Influencing EAI Pattern Selection](https://arc.fuet.ch/concepts/integration/principles-influencing-eai-pattern-selection.md)
- Each synchronous call chain is identified, and its composite availability is calculated as the product of the components' availabilities. → [Synchronous vs Asynchronous Connector](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-connector.md)
- The document states how each remote call handles an unavailable supplier. → [Synchronous vs. Asynchronous Communication](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-communication.md)
- The document states, for each process, how far it is automated, and whether partial automation is accepted. → [Degrees of BPM Maturity](https://arc.fuet.ch/concepts/modeling-bpmn/degrees-of-bpm-maturity.md)
- Each principle has a statement, a rationale tied to stakeholder goals, consequences, exceptions and relations. → [Architecture Principle](https://arc.fuet.ch/concepts/principles/architecture-principle.md)
- The Statement is short and states one fundamental rule without ambiguity. → [Architecture Principle Structure](https://arc.fuet.ch/concepts/principles/structure-of-an-architecture-principle.md)
- The document separates complexity that comes from the problem from complexity the team introduced. → [Complexity Reduction](https://arc.fuet.ch/concepts/principles/complexity-reduction.md)
- Modules are defined around design decisions that are difficult or likely to change, and each module hides such a decision. → [Component Design Principles](https://arc.fuet.ch/concepts/principles/component-design-principles.md)
- Design decisions are justified by a business requirement, not by a principle alone. → [Conflicting Architecture Principles](https://arc.fuet.ch/concepts/principles/conflicting-architecture-principles.md)
- Dependencies between building blocks are explicit and kept narrow, not hidden. → [Connect or Disconnect](https://arc.fuet.ch/concepts/principles/connect-or-disconnect.md)
- Quality attribute requirements, not only functional ones, are named as drivers of the architecture. → [Continuous Architecture Principles](https://arc.fuet.ch/concepts/principles/continuous-architecture-principles.md)
- Likely changes are written down as change scenarios, such as a new external provider. → [Design for Change](https://arc.fuet.ch/concepts/principles/design-for-change.md)
- Splits of modules are checked so they do not create anemic modules with heavy coupling between them. → [High Cohesion](https://arc.fuet.ch/concepts/principles/high-cohesion.md)
- The document describes how first versions are released early and how functionality is added step by step. → [Incrementality](https://arc.fuet.ch/concepts/principles/incrementality.md)
- Modules are derived from a list of difficult or change-prone design decisions, not only from processing steps. → [Information Hiding](https://arc.fuet.ch/concepts/principles/information-hiding.md)
- The document states where tight coupling is accepted and why, for example because the same team owns both endpoints. → [Loose Coupling](https://arc.fuet.ch/concepts/principles/loose-coupling.md)
- Building blocks map to the modularization constructs of the programming language. → [Modularity](https://arc.fuet.ch/concepts/principles/modularity.md)
- Components that are expected to change expose a stable, well-defined interface that other components use. → [Open-Closed Principle](https://arc.fuet.ch/concepts/principles/open-closed-principle.md)
- Superfluous steps were removed and roles clarified before automation was planned. → [Process Automation Magnifies Efficiency](https://arc.fuet.ch/concepts/principles/process-automation-magnifies-efficiency.md)
- The documentation states that coupling between building blocks is loose but still functionally sufficient. → [Relationships Between Architecture Principles](https://arc.fuet.ch/concepts/principles/relationships-between-architecture-principles.md)
- Elements are cohesive, and the document links this to low coupling. → [Relationships Between Architecture Principles](https://arc.fuet.ch/concepts/principles/relationships-between-architecture-principles.md)
- The building block view divides the system by responsibility, such as UI, business logic and data access. → [Separation of Concerns](https://arc.fuet.ch/concepts/principles/separation-of-concerns.md)
- The document states which parts of the system change at similar rates and groups them together. → [Shearing Layers](https://arc.fuet.ch/concepts/principles/shearing-layers.md)
- Each principle can be traced to a requirement it supports. → [Working with Principles](https://arc.fuet.ch/concepts/principles/working-with-principles.md)
- The document says whether multifactor authentication is used and why. → [Authenticity](https://arc.fuet.ch/concepts/quality-attributes/authenticity.md)
- Public APIs use a versioning scheme in which a major bump signals incompatible changes. → [Compatibility](https://arc.fuet.ch/concepts/quality-attributes/compatibility.md)
- Calls to unreliable dependencies are protected by a circuit breaker or bulkhead. → [Fault Tolerance](https://arc.fuet.ch/concepts/quality-attributes/fault-tolerance.md)
- Scalability requirements say whether the workload is expected to grow, shrink, or both. → [Flexibility](https://arc.fuet.ch/concepts/quality-attributes/flexibility.md)
- The document explains how the impact of a planned change can be assessed and how failure causes can be diagnosed. → [Maintainability](https://arc.fuet.ch/concepts/quality-attributes/maintainability.md)
- The document names coupling, cohesion, and cost as the parameters it uses to reason about modifiability. → [Modifiability](https://arc.fuet.ch/concepts/quality-attributes/modifiability.md)
- Patterns used for modifiability are described in terms of the tactics they apply. → [Modifiability](https://arc.fuet.ch/concepts/quality-attributes/modifiability.md)
- The document says how performance is measured and how the acceptable threshold was agreed. → [Performance Efficiency](https://arc.fuet.ch/concepts/quality-attributes/performance-efficiency.md)
- Quality requirements are ranked by stakeholder importance, with top goals separated from lesser ones. → [Quality Attribute Trade-off](https://arc.fuet.ch/concepts/quality-attributes/architectural-trade-off-thinking.md)
- Any redundancy-based availability figure states its assumptions, such as independence, and says whether failover and sync costs are included. → [Quantifying Recovery and Availability Trade-offs](https://arc.fuet.ch/concepts/quality-attributes/quantifying-recovery-and-availability-trade-offs.md)
- The document states whether each reused asset is copied or pulled in as a dependency. → [Reusability](https://arc.fuet.ch/concepts/quality-attributes/reusability.md)
- Bottlenecks, especially stateful parts like the database, are identified before scale-out is chosen. → [Scalability](https://arc.fuet.ch/concepts/quality-attributes/scalability.md)
- Testability is treated under maintainability and also considered under reliability. → [Testability](https://arc.fuet.ch/concepts/quality-attributes/testability.md)
- Each pattern used is described with its context, the problem and the consequences. → [Architectural Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern.md)
- The document names the architecture style or patterns chosen for the whole system. → [Architectural Pattern vs. Design Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern-vs-design-pattern.md)
- The document names the chosen architecture style and states the constraints it imposes on elements and their relationships. → [Architecture Style](https://arc.fuet.ch/concepts/styles-patterns/architectural-style.md)
- The document identifies the blackboard as the shared, structured memory that holds the partial solution. → [Blackboard Pattern](https://arc.fuet.ch/concepts/styles-patterns/blackboard-architecture.md)
- The document names the broker component and states that it coordinates communication, forwards requests, and returns results and exceptions. → [Broker Pattern](https://arc.fuet.ch/concepts/styles-patterns/broker-pattern.md)
- The document states that source code dependencies point only inward. → [Clean Architecture](https://arc.fuet.ch/concepts/styles-patterns/clean-architecture.md)
- The document states which data goes through the batch (cold) path and which through the speed (hot) path. → [Lambda Architecture](https://arc.fuet.ch/concepts/styles-patterns/lambda-architecture.md)
- The document states that each layer has a defined responsibility and that dependencies run only from higher to lower layers. → [Layered Architecture](https://arc.fuet.ch/concepts/styles-patterns/layered-architecture.md)
- Each layer has a stated responsibility, and the document says which layers may use which. → [Layers Pattern](https://arc.fuet.ch/concepts/styles-patterns/layers-pattern.md)
- The document states which basic mechanisms the core provides and which services run outside it. → [Microkernel Pattern](https://arc.fuet.ch/concepts/styles-patterns/microkernel-pattern.md)
- Each service implements a single business capability within a bounded context. → [Microservices Architecture](https://arc.fuet.ch/concepts/styles-patterns/microservices-architecture.md)
- The document keeps presentation (views and controllers) separate from the domain model. → [Model-View-Controller Pattern](https://arc.fuet.ch/concepts/styles-patterns/model-view-controller-pattern.md)
- Each filter in the pipeline has a single, documented task. → [Pipe-and-Filter](https://arc.fuet.ch/concepts/styles-patterns/pipe-and-filter-pattern.md)
- Each filter's input and output formats are documented, and adjacent filters have matching formats. → [Pipes and Filters](https://arc.fuet.ch/concepts/styles-patterns/pipes-and-filters.md)
- Each service has a documented interface that is separate from its implementation. → [Service-Oriented Architecture](https://arc.fuet.ch/concepts/styles-patterns/service-oriented-architecture.md)
- The document states which spare type (hot, warm or cold) protects each critical component. → [Active Redundancy](https://arc.fuet.ch/concepts/tactics/active-redundancy.md)
- Where a service offers bulk operations, the API bundles several independent requests into one message to reduce round trips. → [Aggregate Tactic](https://arc.fuet.ch/concepts/tactics/aggregate-tactic.md)
- Each documented tactic names the quality attribute it is meant to improve. → [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md)
- The document names which availability tactics it uses and groups them as detecting, recovering from or preventing faults. → [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactic.md)
- The document names which recovery tactics protect each critical component, such as retry, redundancy or checkpointing. → [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics.md)
- The document names which tactics cover each of the three categories: detect, recover and prevent. → [Availability Tactic Categories](https://arc.fuet.ch/concepts/tactics/availability-responses.md)
- Each chosen tactic traces back to a documented quality requirement. → [Choosing and Applying Tactics](https://arc.fuet.ch/concepts/tactics/choosing-and-applying-tactics.md)
- The document states how energy consumption is monitored for the workloads being optimized. → [Energy Efficiency Tactic](https://arc.fuet.ch/concepts/tactics/energy-efficiency-tactics.md)
- The document names which detection techniques are used (for example ping/echo, heartbeat, monitor, voting). → [Fault Detection Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-detection.md)
- The document states which prevention tactics (removal from service, transactions, predictive models, exception prevention, increasing the competence set) the system uses. → [Fault Prevention Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-prevention.md)
- The document states which recovery tactics are used, such as retry, redundant spares, or graceful degradation. → [Fault Recovery Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-recovery.md)
- Features are ranked by criticality, with a core set that must stay up and optional features that can pause. → [Graceful Degradation](https://arc.fuet.ch/concepts/tactics/graceful-degradation.md)
- Modules that mix unrelated responsibilities are identified, and splitting them is considered. → [Increase Cohesion](https://arc.fuet.ch/concepts/tactics/increase-cohesion.md)
- The architecture documents which mechanisms, such as feature toggles and backward-compatible interfaces, support rollback. → [Integrability, Deployability, Testability and Reliability Tactics](https://arc.fuet.ch/concepts/tactics/integrability-deployability-and-testability-tactics.md)
- The document names which modifiability tactic categories (increase cohesion, reduce coupling, defer binding) the design uses. → [Modifiability Tactic](https://arc.fuet.ch/concepts/tactics/modifiability-tactics.md)
- Applications that exchange messages connect through a shared set of interfaces, so applications can be added or removed without affecting others. → [Modifiability Tactics in SOA](https://arc.fuet.ch/concepts/tactics/modifiability-tactics-in-soa.md)
- Performance decisions are identified as either controlling resource demand or managing resources. → [Performance Tactic](https://arc.fuet.ch/concepts/tactics/performance-tactics.md)
- When a catalog pattern is used, the document shows how it was adapted to the specific problem and design context. → [Reasons for Architectural Tactics](https://arc.fuet.ch/concepts/tactics/reasons-for-architectural-tactics.md)
- The document explains which modules depend on a module that is expected to change often. → [Reduce Coupling](https://arc.fuet.ch/concepts/tactics/reduce-coupling.md)
- The document states which spare type (hot, warm, or cold) each critical component uses and why. → [Redundant Spare](https://arc.fuet.ch/concepts/tactics/redundant-spare.md)
- Each tactic named in the document is described as a design decision aimed at a quality attribute response. → [Relationship between Tactics and Architectural Styles/Patterns](https://arc.fuet.ch/concepts/tactics/tactics-vs-architectural-styles-and-patterns.md)
- Side effects of a tactic on other quality attributes are noted. → [Relationship between Tactics and Architectural Styles/Patterns](https://arc.fuet.ch/concepts/tactics/tactics-vs-architectural-styles-and-patterns.md)
- Operations that are retried are idempotent, or the document explains how duplicate execution is handled. → [Retry](https://arc.fuet.ch/concepts/tactics/retry.md)
- Each watchdog monitor runs in a separate failure domain from the component it supervises. → [Safety Tactic](https://arc.fuet.ch/concepts/tactics/safety-tactics.md)
- Where ATAM is used, each scenario is linked to the design decisions (sensitivity points) that affect it. → [Scenario-based Questions from Tactics](https://arc.fuet.ch/concepts/tactics/scenario-based-questions-from-tactics.md)
- The document states which security tactics were chosen, rather than only naming security patterns. → [Security Tactic](https://arc.fuet.ch/concepts/tactics/security-tactics.md)
- Each module split is justified by responsibilities that change for different reasons. → [Split Module](https://arc.fuet.ch/concepts/tactics/split-module.md)
- The document states which ISO 25010 edition (2011 or 2023) its quality terms come from. → [Tactic Coverage of ISO 25010 Quality Categories](https://arc.fuet.ch/concepts/tactics/tactic-sources-by-iso-25010-quality-category.md)
- The document says where testability is placed (maintainability, reliability or both). → [Tactic Coverage of ISO 25010 Quality Categories](https://arc.fuet.ch/concepts/tactics/tactic-sources-by-iso-25010-quality-category.md)
- Quality goals are ranked, for example in a utility tree, so conflicts can be settled by priority. → [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md)
- The document names which usability features, such as cancel, undo or progress bars, the architecture must support, and plans them early. → [Usability Tactic](https://arc.fuet.ch/concepts/tactics/usability-tactics.md)
- The document states how the voter forwards a majority result or flags a mismatch. → [Voting](https://arc.fuet.ch/concepts/tactics/voting.md)
- A table in the solution strategy links each quality goal and scenario to its tactics or approaches. → [Working with Tactics and Quality Attributes](https://arc.fuet.ch/concepts/tactics/working-with-tactics-and-quality-attributes.md)
- The solution strategy summarizes the fundamental decisions that shape the architecture. → [System Idea](https://arc.fuet.ch/concepts/vision-stakeholders/system-idea.md)