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 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.
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.
Your key constraints, and the problem statement from chapters 1 and 2. You justify every decision from these. See Architectural Thinking.

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.
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.
You cannot decide yet. Defer the decision on purpose. Write down when you will decide. See Solution as Moving Target and Continuous Architecture Principles.

How to do it

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.
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, Architecture Principle Structure and Working with Principles.
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, Architectural Pattern, Architectural Pattern vs. Design Pattern and Conflicting Architecture Principles.
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, Security Tactic, Performance Tactic and Modifiability Tactic. See Choosing and Applying Tactics.
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.
Add organizational decisions. Include the development process and any work given to third parties. The Solution Strategy article lists them as part of the chapter.
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 and Incrementality.
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 and System Idea.

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).

Privacy and security of health data.
Availability during morning peaks.
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 and Microservices Architecture. 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 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 over several servers, with failed servers hidden from clients; Ping/Echo health checks	Several servers cost more than one
Availability: a slow SMS provider must not block booking	Timeouts, Retry for transient faults, a Circuit Breaker, and Graceful Degradation	Reminders may arrive late
Integration: adding a new vendor takes under two person-weeks	One wrapping interface per Design for Change, hiding vendor details (Information Hiding)	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.
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.
The top-level structure is named, with its constraints, costs and the reasons for choosing it. See Architecture Style.
Each tactic names the one quality attribute it serves, and its side effects are recorded. See Choosing and Applying Tactics.
Each principle has a name, statement, rationale and implications, and ties to a requirement. See Architecture Principle Structure.
Organizational decisions are included, and the chapter links to chapters 1 and 2. See Solution Strategy.
Hard-to-change decisions and deliberately open decisions are marked. See Solution as Moving Target.