# Step 7: Choose a solution strategy

## What you get from this step

You get a short list of the fundamental decisions that shape your system. It has four parts:

- a few architecture principles,
- one top-level structure (an architecture style or pattern),
- tactics for each top quality goal,
- organizational decisions, such as how you work and what you hand to third parties.

This list is the content of the [Solution Strategy](https://arc.fuet.ch/concepts/documentation/arc42-solution-strategy.md) chapter (arc42 section 4). That chapter stays short and compact, for example as a keyword list. It points to other chapters for details. Section 8 of arc42 is one place for such details.

## What you need first

- Your top quality goals, ranked by stakeholder importance. A quality goal says how well the system must work, for example how available it must be. See [Quality Attribute Trade-off](https://arc.fuet.ch/concepts/quality-attributes/architectural-trade-off-thinking.md).
- A measurable scenario for each top goal. A scenario describes a concrete situation and a criterion you can check. See [Working with Tactics and Quality Attributes](https://arc.fuet.ch/concepts/tactics/working-with-tactics-and-quality-attributes.md).
- Your key constraints, and the problem statement from chapters 1 and 2. You justify every decision from these. See [Architectural Thinking](https://arc.fuet.ch/concepts/fundamentals/architectural-thinking.md).

## If something is missing

- **No ranking of goals.** Ask the stakeholders to rank them. Without a ranking, you cannot settle conflicts. See [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md).
- **A goal has no measurable criterion.** Write a scenario with a number you can check, and agree on it with the stakeholders.
- **A constraint or goal is unclear.** Record your assumption. Treat what you learn during design as feedback to the requirements. Requirements and architecture grow together, in rounds. See [Twin Peaks Model](https://arc.fuet.ch/concepts/forces-decisions/twin-peaks-model.md).
- **You cannot decide yet.** Defer the decision on purpose. Write down when you will decide. See [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md) and [Continuous Architecture Principles](https://arc.fuet.ch/concepts/principles/continuous-architecture-principles.md).

## How to do it

1. **Pick the top goals and constraints.** Reread chapters 1 and 2. Keep the few goals that matter most. Everything below serves them. See [Architectural Thinking](https://arc.fuet.ch/concepts/fundamentals/architectural-thinking.md).
2. **Write a few principles.** A principle is a short rule that narrows your options without dictating one answer. Give each a name, a statement, a rationale and implications. Tie each to a requirement. See [Architecture Principle](https://arc.fuet.ch/concepts/principles/architecture-principle.md), [Architecture Principle Structure](https://arc.fuet.ch/concepts/principles/structure-of-an-architecture-principle.md) and [Working with Principles](https://arc.fuet.ch/concepts/principles/working-with-principles.md).
3. **Choose the top-level structure.** Name the style or pattern for the whole system. State the constraints it imposes and the costs you accept. Base the choice on your goals, not on trends. Late changes to it are costly. See [Architecture Style](https://arc.fuet.ch/concepts/styles-patterns/architectural-style.md), [Architectural Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern.md), [Architectural Pattern vs. Design Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern-vs-design-pattern.md) and [Conflicting Architecture Principles](https://arc.fuet.ch/concepts/principles/conflicting-architecture-principles.md).
4. **Choose tactics for each top goal.** A tactic is one design decision aimed at one quality attribute. Name the attribute each tactic serves. Use the catalogs for your goal, for example [Availability Tactic Categories](https://arc.fuet.ch/concepts/tactics/availability-responses.md), [Security Tactic](https://arc.fuet.ch/concepts/tactics/security-tactics.md), [Performance Tactic](https://arc.fuet.ch/concepts/tactics/performance-tactics.md) and [Modifiability Tactic](https://arc.fuet.ch/concepts/tactics/modifiability-tactics.md). See [Choosing and Applying Tactics](https://arc.fuet.ch/concepts/tactics/choosing-and-applying-tactics.md).
5. **Check the side effects.** Each tactic can hurt another quality. Write down what it costs and which trade-off you accept. See [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md).
6. **Add organizational decisions.** Include the development process and any work given to third parties. The [Solution Strategy](https://arc.fuet.ch/concepts/documentation/arc42-solution-strategy.md) article lists them as part of the chapter.
7. **Separate firm decisions from open ones.** Take most care with decisions that are hard to change. Defer the others until facts exist, and build capabilities only when you need them. See [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md) and [Incrementality](https://arc.fuet.ch/concepts/principles/incrementality.md).
8. **Write the chapter.** Keep it short. Put a table next to it that links each goal to its approach. Link back to chapters 1 and 2. Record each important decision with its rationale, for example as a lightweight decision record. See [Working with Tactics and Quality Attributes](https://arc.fuet.ch/concepts/tactics/working-with-tactics-and-quality-attributes.md) and [System Idea](https://arc.fuet.ch/concepts/vision-stakeholders/system-idea.md).

## Example: ClinicBook

ClinicBook is an online appointment booking system for 40 small medical practices. Patients use the web and a mobile app. It must integrate with practice-management software from different vendors, send reminders by SMS and e-mail, and protect health data.

**Top goals and constraints (from chapters 1 and 2).**

1. Privacy and security of health data.
2. Availability during morning peaks.
3. Integration with legacy systems, which includes coping with change in them.

The constraints are a small team and a fixed launch date.

**Principles (two examples).**

- *Name:* Wrap every external system.
  *Statement:* Code reaches a practice's software only through one interface that we own.
  *Rationale:* Vendors differ, and new practices will bring new ones.
  *Implications:* We write one adapter per vendor. Domain code never calls a vendor directly.
- *Name:* Health data is protected by default.
  *Statement:* We store and send health data only in encrypted form.
  *Rationale:* Privacy is the top goal.
  *Implications:* We need key management, and we accept some extra effort and runtime cost.

**Top-level structure.** The team builds one system, split into layers by kind of work and into components by function, such as booking, calendars and reminders. It does not build microservices. Microservices add network, data and operations costs, and a small team on a fixed date would carry them. See [Layers and Components Decomposition](https://arc.fuet.ch/concepts/styles-patterns/layers-and-components-decomposition.md) and [Microservices Architecture](https://arc.fuet.ch/concepts/styles-patterns/microservices-architecture.md). The accepted cost: the whole system deploys together, and its parts scale together. The team will validate this choice after launch, because changing it later is costly.

**Tactics per goal (example values; stakeholders must set real numbers).**

| Goal and scenario | Approach | Side effect accepted |
|---|---|---|
| Security: stored and transmitted patient data is unreadable without a key | [Encrypt Data](https://arc.fuet.ch/concepts/tactics/encrypt-data.md) at rest and in transit, with keys in a key management service | Key management effort, some runtime cost |
| Availability: at 8:00 on a Monday, bookings still work when one server fails | [Load Balancer](https://arc.fuet.ch/concepts/tactics/load-balancer.md) over several servers, with failed servers hidden from clients; [Ping/Echo](https://arc.fuet.ch/concepts/tactics/ping-echo.md) health checks | Several servers cost more than one |
| Availability: a slow SMS provider must not block booking | Timeouts, [Retry](https://arc.fuet.ch/concepts/tactics/retry.md) for transient faults, a [Circuit Breaker](https://arc.fuet.ch/concepts/tactics/circuit-breaker.md), and [Graceful Degradation](https://arc.fuet.ch/concepts/tactics/graceful-degradation.md) | Reminders may arrive late |
| Integration: adding a new vendor takes under two person-weeks | One wrapping interface per [Design for Change](https://arc.fuet.ch/concepts/principles/design-for-change.md), hiding vendor details ([Information Hiding](https://arc.fuet.ch/concepts/principles/information-hiding.md)) | One more layer of indirection |

Graceful degradation needs a business decision on what is core. Here, booking and cancelling are core, and reminders can pause. When a practice's own software does not answer, the circuit breaker rejects calls at once. Patients see a notice. Other practices keep working. Retries apply only to safe-to-repeat operations, such as sending a reminder with a unique ID.

**Organizational decisions.**

- The team builds the core booking flow first and adds vendor adapters one by one. See [Incrementality](https://arc.fuet.ch/concepts/principles/incrementality.md).
- SMS and e-mail delivery go to external providers.

**Deferred decisions.** The team defers extra spare servers for the database until it sees real morning-peak data. It records this as an open decision. It treats the layered structure and the storage of health data as hard to change, so it decides them now.

**Writing it down.** Section 4 holds a short keyword list, the table above and links to chapters 1 and 2. Each tactic decision gets a short decision record with its alternatives and consequences.

## Done when

- Each top quality goal has a measurable scenario and a named approach, ideally in one table. See [Working with Tactics and Quality Attributes](https://arc.fuet.ch/concepts/tactics/working-with-tactics-and-quality-attributes.md).
- The top-level structure is named, with its constraints, costs and the reasons for choosing it. See [Architecture Style](https://arc.fuet.ch/concepts/styles-patterns/architectural-style.md).
- Each tactic names the one quality attribute it serves, and its side effects are recorded. See [Choosing and Applying Tactics](https://arc.fuet.ch/concepts/tactics/choosing-and-applying-tactics.md).
- Each principle has a name, statement, rationale and implications, and ties to a requirement. See [Architecture Principle Structure](https://arc.fuet.ch/concepts/principles/structure-of-an-architecture-principle.md).
- Organizational decisions are included, and the chapter links to chapters 1 and 2. See [Solution Strategy](https://arc.fuet.ch/concepts/documentation/arc42-solution-strategy.md).
- Hard-to-change decisions and deliberately open decisions are marked. See [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md).

## Learn more

- [Solution Strategy](https://arc.fuet.ch/concepts/documentation/arc42-solution-strategy.md)
- [System Idea](https://arc.fuet.ch/concepts/vision-stakeholders/system-idea.md)
- [Architecture Means](https://arc.fuet.ch/concepts/fundamentals/architecture-means.md)
- [Architecture Principle](https://arc.fuet.ch/concepts/principles/architecture-principle.md)
- [Architecture Principle Structure](https://arc.fuet.ch/concepts/principles/structure-of-an-architecture-principle.md)
- [Working with Principles](https://arc.fuet.ch/concepts/principles/working-with-principles.md)
- [Conflicting Architecture Principles](https://arc.fuet.ch/concepts/principles/conflicting-architecture-principles.md)
- [Architecture Style](https://arc.fuet.ch/concepts/styles-patterns/architectural-style.md)
- [Architectural Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern.md)
- [Architectural Pattern vs. Design Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern-vs-design-pattern.md)
- [Layers and Components Decomposition](https://arc.fuet.ch/concepts/styles-patterns/layers-and-components-decomposition.md)
- [Microservices Architecture](https://arc.fuet.ch/concepts/styles-patterns/microservices-architecture.md)
- [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md)
- [Relationship between Tactics and Architectural Styles/Patterns](https://arc.fuet.ch/concepts/tactics/tactics-vs-architectural-styles-and-patterns.md)
- [Choosing and Applying Tactics](https://arc.fuet.ch/concepts/tactics/choosing-and-applying-tactics.md)
- [Working with Tactics and Quality Attributes](https://arc.fuet.ch/concepts/tactics/working-with-tactics-and-quality-attributes.md)
- [Tactic Trade-off Balancing](https://arc.fuet.ch/concepts/tactics/tactic-trade-off-balancing.md)
- [Quality Attribute Trade-off](https://arc.fuet.ch/concepts/quality-attributes/architectural-trade-off-thinking.md)
- [Availability Tactic Categories](https://arc.fuet.ch/concepts/tactics/availability-responses.md)
- [Security Tactic](https://arc.fuet.ch/concepts/tactics/security-tactics.md)
- [Design for Change](https://arc.fuet.ch/concepts/principles/design-for-change.md)
- [Twin Peaks Model](https://arc.fuet.ch/concepts/forces-decisions/twin-peaks-model.md)
- [Incrementality](https://arc.fuet.ch/concepts/principles/incrementality.md)
- [Solution as Moving Target](https://arc.fuet.ch/concepts/forces-decisions/solution-as-moving-target.md)