arc42 section 4: Solution Strategy

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