# Solution Options Analysis: [Decision or initiative name]

> Structured comparison of two to five solution approaches (not products) for one business problem:
> the decision required, drivers and critical success factors, constraints, a long list filtered
> by dimension, a short list with a business-as-usual baseline and a do-minimum option, an
> architecture sketch per option, quality attribute fit, cost and TCO, delivery risk and time to
> value, weighted scoring, sensitivity and switching values, and a recommendation with conditions.
> Option generation follows the long-list and short-list method of the HM Treasury Green Book
> (2026); the decision and its rationale are recorded in the way ISO/IEC/IEEE 42010:2022 expects of
> an architecture description; quality attributes follow ISO/IEC 25010:2023. In TOGAF terms the
> analysis supports Phase E, Opportunities and Solutions. Replace every `[bracketed]` value and
> every row marked *Example*; the worked example compares approaches to modernising a retailer's
> order management.

<!--
Guidance: How to use this template
- Use this document to choose an approach (retain, wrap, refactor, replace with SaaS, rebuild,
  phase by capability). Once the approach is chosen, choose products with Technology Selection
  (`architecture/technology-selection`) or Build vs Buy Analysis (`architecture/build-vs-buy-analysis`).
- Write sections 1 to 3 and agree the criteria and weights in section 7 before anyone scores. Weights
  changed after scoring are the most common way an analysis is bent towards a favourite.
- Always keep business as usual on the short list as the benchmark, even when it fails the
  objectives, and include a do-minimum option to expose gold plating.
- The weighted score supports judgement; it does not replace it. Section 12 shows how robust the
  ranking is, and section 13 states the conditions under which the recommendation holds.
- Related: Current State Assessment (`architecture/current-state-assessment`), TCO Analysis
  (`architecture/tco-analysis`), Business Case (`business/business-case`), Proof of Concept
  (`architecture/proof-of-concept`), ADR (`architecture/adr-full`), Architecture Decision Log
  (`architecture/architecture-decision-log`), Architecture Roadmap and Transition Architectures
  (`architecture/architecture-roadmap-transition`).
-->

## Document control

<!-- Guidance: Identify the decision, who makes it and by when. A new option, a change of weights or new cost evidence is a new version. -->

| Field | Value |
|---|---|
| Document ID | [SOA-001] |
| Decision | [One sentence: what must be decided] |
| Decision owner | [@sponsor or @architecture-board] |
| Decision needed by | YYYY-MM-DD |
| Version | [0.1] |
| Status | [Draft / In review / Recommended / Decided / Superseded] |
| Owner | [@solution-architect] |
| Approvers/reviewers | [@enterprise-architect], [@product-owner], [@finance-partner], [@security-architect], [@delivery-lead] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Related documents | [Business case], [Current state assessment], [ADR-NNN] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Decision owner | [@name] | [Accept recommendation / Choose another option / Defer] | YYYY-MM-DD |
| Architecture board | [@name] | [Endorse / Endorse with conditions / Reject] | YYYY-MM-DD |
| Finance | [@name] | [Costs reviewed] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | Decision framed; long list drafted |
| 0.5 | YYYY-MM-DD | [@name] | *Example:* Criteria and weights agreed in workshop before scoring |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Recommendation endorsed by the architecture board |

## Contents

1. [Decision required and context](#1-decision-required-and-context)
2. [Drivers, objectives and critical success factors](#2-drivers-objectives-and-critical-success-factors)
3. [Constraints, assumptions and dependencies](#3-constraints-assumptions-and-dependencies)
4. [Long list and options filter](#4-long-list-and-options-filter)
5. [Short-listed options](#5-short-listed-options)
6. [Architecture sketches](#6-architecture-sketches)
7. [Evaluation criteria and scoring scales](#7-evaluation-criteria-and-scoring-scales)
8. [Quality attribute fit](#8-quality-attribute-fit)
9. [Cost and TCO comparison](#9-cost-and-tco-comparison)
10. [Delivery risk and time to value](#10-delivery-risk-and-time-to-value)
11. [Weighted scoring results](#11-weighted-scoring-results)
12. [Sensitivity and switching values](#12-sensitivity-and-switching-values)
13. [Recommendation and conditions](#13-recommendation-and-conditions)
14. [Decision record and next steps](#14-decision-record-and-next-steps)
15. [Glossary and references](#15-glossary-and-references)

## 1. Decision required and context

<!-- Guidance: State the decision in one sentence and the problem behind it without naming a solution. Questions: what is broken or missing, what does it cost, why decide now, and what happens if nothing is decided? Pitfall: framing the decision so that only one option fits ("decide how to move to SaaS"). -->

### 1.1 Decision statement

[Decide which approach the organisation will take to [problem] by [date], within [budget envelope]
and [time horizon].] *Example:* Decide how to modernise order management so that the business can
handle three times today's peak order volume and launch new fulfilment options without six-month
release cycles, within a five-year horizon.

### 1.2 Context

[Summarise the current state, its pain and the trigger. Link the detailed assessment.] *Example:* The
order management system is a twelve-year-old monolith on one database. During the last peak season
it slowed to 40 orders per minute against a demand of 120, and order capture was throttled for six
hours. Every change needs a full regression cycle, so releases ship twice a year. Detail is in
Current State Assessment (`architecture/current-state-assessment`).

### 1.3 Scope of the decision

| In scope | Out of scope |
|---|---|
| *Example:* Order capture, order orchestration, fulfilment routing, returns | Payment processing (recently replaced) |
| *Example:* Integration with web shop, stores, warehouse management | Product information management |
| [Item] | [Item] |

## 2. Drivers, objectives and critical success factors

<!-- Guidance: Objectives must be measurable; critical success factors are the tests every option must pass to stay on the list. Questions: what outcome does the sponsor expect, how will we know, and which conditions are non-negotiable? Pitfall: objectives that are really solution features ("use microservices"). -->

### 2.1 Objectives

| ID | Objective | Measure | Target *(Example)* |
|---|---|---|---|
| OBJ-001 | *Example:* Handle seasonal peak without throttling | Sustained order capture rate | 360 orders per minute (three times today's demand of 120) |
| OBJ-002 | *Example:* Shorten time to launch a fulfilment option | Lead time from approval to live | Under 6 weeks |
| OBJ-003 | *Example:* Reduce order failures | Orders needing manual repair | Under 0.5% |
| [OBJ-NNN] | [Objective] | [Measure] | [Target] |

### 2.2 Critical success factors

Every short-listed option must satisfy all critical success factors, with two exceptions: business
as usual, which stays as the benchmark, and, where no cheaper option meets every factor, a
do-minimum option kept to expose gold plating. Record which factors such an option fails.

| ID | Critical success factor | Test applied to each option |
|---|---|---|
| CSF-001 | *Example:* Strategic fit | Meets OBJ-001 and OBJ-002 within the horizon |
| CSF-002 | *Example:* Affordability | Five-year TCO within the envelope of USD 6.5 million |
| CSF-003 | *Example:* Achievability | Deliverable by the team and partners we can realistically secure |
| CSF-004 | *Example:* Peak-season safety | No cutover of order capture between October and January |
| CSF-005 | *Example:* Supplier market | At least two credible suppliers or a viable in-house path |
| [CSF-NNN] | [Factor] | [Test] |

## 3. Constraints, assumptions and dependencies

<!-- Guidance: List what limits the options and what you assumed to compare them. Questions: what is fixed (budget, dates, policies, contracts, skills), and which assumptions would change the ranking if wrong? Pitfall: hidden assumptions that favour one option, such as assuming the in-house team will grow on time. -->

| ID | Type | Statement | Effect on options |
|---|---|---|---|
| CON-001 *(Example)* | Constraint | Cloud provider already contracted; landing zone in place | Favours managed services on that provider |
| CON-002 *(Example)* | Constraint | Warehouse management system stays for at least five years | All options integrate with it |
| ASM-001 *(Example)* | Assumption | Two senior engineers can be hired within four months | Critical for OPT-2; tested in section 12 |
| ASM-002 *(Example)* | Assumption | SaaS subscription price rises at most 5% per year | Affects OPT-3 cost |
| DEP-001 *(Example)* | Dependency | Web shop team can adopt a new order API by month 6 | Affects OPT-1 and OPT-2 time to value |
| [ID] | [Type] | [Statement] | [Effect] |

## 4. Long list and options filter

<!-- Guidance: Generate the long list by working through dimensions of choice, not by naming favourite solutions. Rate each choice against the critical success factors: green (meets them best), amber (meets them less well), red (fails and is discarded). Record why. Pitfall: a long list of three options that were decided before the workshop. -->

The filter takes one dimension at a time. For each dimension, list the possible choices, rate them
against the critical success factors, carry green and amber choices forward, and confirm that each
carried-forward choice still meets the objectives in 2.1. The short list is built by combining
carried-forward choices into coherent options.

| Dimension | Choice | Rating | Reason |
|---|---|---|---|
| Scope | *Example:* Order capture only | Amber | Fixes the peak but not fulfilment agility (OBJ-002) |
| Scope | *Example:* Order capture, orchestration and fulfilment routing | Green | Meets all objectives |
| Scope | *Example:* Full order-to-cash including finance | Red | Outside the decision scope; payment and finance recently replaced |
| Solution | *Example:* Retain and tune | Amber | Only useful as the benchmark and the do-minimum base |
| Solution | *Example:* Wrap with an API layer and scale the database | Amber | Partial peak relief; little agility |
| Solution | *Example:* Replace incrementally with domain services | Green | Meets objectives; risk spread over time |
| Solution | *Example:* Replace with a SaaS order management product | Green | Meets objectives if integration fits |
| Solution | *Example:* Rebuild from scratch in one go | Red | Fails CSF-003 and CSF-004: one cutover, no peak-season window |
| Delivery | *Example:* In-house team with a partner for peak capacity | Green | Keeps knowledge in-house |
| Delivery | *Example:* Fully outsourced build | Amber | Weak on knowledge retention unless a handover is contracted |
| Implementation | *Example:* Big bang | Red | Fails CSF-004 |
| Implementation | *Example:* Phased by capability between peak seasons | Green | Each phase lands outside the peak window |
| Funding | *Example:* Capital project | Amber | Allowed, but finance prefers operating expenditure |
| Funding | *Example:* Product team with an annual budget | Green | Matches the operating model |
| [Dimension] | [Choice] | [Green / Amber / Red] | [Reason] |

## 5. Short-listed options

<!-- Guidance: Describe each option as an approach with enough detail to cost and sketch it. Keep business as usual and a do-minimum option. Questions: what would we actually build, buy, change and retire, and in what order? Pitfall: a straw-man option that nobody would choose, included to make the preferred one look good. -->

| ID | Option | Role on the short list | Summary *(Example)* |
|---|---|---|---|
| OPT-0 | Business as usual | Benchmark | Keep the monolith; add hardware before each peak; two releases a year |
| OPT-1 | Wrap and scale | Do minimum | API layer in front of the monolith, read replicas, queue for order capture; core logic unchanged |
| OPT-2 | Incremental replacement | Preferred candidate | Replace order capture, then orchestration, then fulfilment routing with domain services on managed cloud services, one capability between each peak season, retiring the monolith in year 3 |
| OPT-3 | SaaS order management | Alternative way forward (different solution choice) | Configure a SaaS order management product; integrate with web shop, stores and warehouse; retire the monolith at the end of year 2 |
| [OPT-N] | [Option] | [Role] | [Summary] |

*Example:* OPT-1 fails CSF-001 (OBJ-001 is only partly met and OBJ-002 is not met, section 8). In
Green Book terms a true do-minimum just meets the objectives; no cheaper option does here, so OPT-1
is kept as the nearest floor and as the interim measure named in section 13, with the failed factor
recorded.

For each option, add a short narrative: what changes, what stays, what is retired, who delivers it,
how it is funded and what the end state looks like at the horizon.

*Example:* **OPT-2 Incremental replacement.** Year 1 builds an order capture service with its own
store and an event stream; the monolith receives orders from the stream, and change data capture
publishes the monolith's order updates back to the stream for the new services. Year 2 moves
orchestration and returns. Year 3 moves fulfilment routing and switches the monolith off. An
in-house product team of eight, with a partner adding four engineers in year 1, delivers it.

## 6. Architecture sketches

<!-- Guidance: One sketch per option at the same level of abstraction, so that options can be compared fairly. Show what is new, what is reused and what is retired. Pitfall: a detailed diagram for the favourite and a box labelled "legacy" for the others. -->

```mermaid
flowchart TB
  subgraph OPT0[OPT-0 Business as usual]
    w0[Web shop and stores] --> m0[Order monolith] --> wh0[Warehouse system]
  end
  subgraph OPT1[OPT-1 Wrap and scale]
    w1[Web shop and stores] --> api1[API layer and queue] --> m1[Order monolith with read replicas] --> wh1[Warehouse system]
  end
  subgraph OPT2[OPT-2 Incremental replacement]
    w2[Web shop and stores] --> oc2[Order capture service] --> ev2[(Order event stream)]
    ev2 --> or2[Orchestration service]
    ev2 --> m2[Monolith until year 3]
    or2 --> wh2[Warehouse system]
  end
  subgraph OPT3[OPT-3 SaaS order management]
    w3[Web shop and stores] --> ip3[Integration platform] --> s3[SaaS order management] --> wh3[Warehouse system]
  end
```

| Option | New components | Reused | Retired by the horizon |
|---|---|---|---|
| OPT-0 | None | Monolith, database | Nothing |
| OPT-1 | API layer, queue, read replicas | Monolith core logic | Nothing |
| OPT-2 | Domain services, event stream, per-service stores | Warehouse integration, identity, landing zone | Monolith (year 3) |
| OPT-3 | SaaS tenant, integration flows | Integration platform, warehouse integration | Monolith (end of year 2) |

## 7. Evaluation criteria and scoring scales

<!-- Guidance: Use five to eight criteria that follow from the objectives and critical success factors. Define what each score means before scoring, with numbers where possible. Weights add up to 1.00. Pitfall: criteria that overlap (cost and affordability scored twice) or scales that are never written down. -->

| ID | Criterion | Weight | Score 5 | Score 3 | Score 1 |
|---|---|---|---|---|---|
| C1 | Business outcome fit (OBJ-001 to OBJ-003) | 0.25 | Meets every objective with margin | Meets most objectives | Meets none |
| C2 | Quality attribute fit (section 8) | 0.20 | Meets every target, with evidence | Critical targets only partly met | Meets no target |
| C3 | Five-year TCO (section 9) | 0.20 | At most USD 4.0 million | USD 5.0 to 6.0 million | Over USD 7.0 million |
| C4 | Delivery risk (section 10) | 0.15 | Low on every risk factor | Medium overall | High overall |
| C5 | Time to first measurable value | 0.10 | 3 months or less | 7 to 9 months | Over 12 months or never |
| C6 | Strategic flexibility and exit | 0.10 | Easy to change direction or supplier | Possible at moderate cost | Locked in |
| | **Total** | **1.00** | | | |

Intermediate scores: C3 scores 4 for USD 4.0 to 5.0 million and 2 for USD 6.0 to 7.0 million; C5
scores 4 for 4 to 6 months and 2 for 10 to 12 months. Bands include their upper bound. C2 scores 4
when every critical target is met but evidence is incomplete or one other target is partly met, and
2 when critical targets are missed but other targets are met.

## 8. Quality attribute fit

<!-- Guidance: Compare options against the quality targets that matter, using the ISO/IEC 25010:2023 characteristics as a checklist. Questions: which option meets which target, with what evidence, and which targets need a proof of concept? Pitfall: rating every option "meets" because nobody tested the claims. -->

| Characteristic | Target *(Example)* | OPT-0 | OPT-1 | OPT-2 | OPT-3 |
|---|---|---|---|---|---|
| Performance efficiency (critical) | 360 orders per minute sustained | Not met | Partly met: queue absorbs bursts, core limit stays | Met: capture scales on its own | Met per vendor benchmark; to verify |
| Reliability (critical) | 99.95% order capture availability | Not met | Partly met | Met | Met per vendor SLA |
| Maintainability | Weekly releases of order logic | Not met | Not met | Met | Met for configuration; vendor controls core releases |
| Flexibility | New fulfilment option in under 6 weeks | Not met | Not met | Met | Partly met: depends on product features |
| Security | Meets the security baseline | Met | Met | Met | Met, subject to supplier assessment |
| Compatibility | Integrates with warehouse system | Met | Met | Met | Met through integration platform |
| **C2 score** | | **2** | **3** | **4** | **4** |

Targets that rest on a vendor claim or on an untested design go to a proof of concept before the
decision is final (Proof of Concept, `architecture/proof-of-concept`). *Example:* OPT-3 peak
throughput and OPT-2 event stream latency.

OPT-2 scores 4, not 5, because the event stream design is unproven at the target rate in this
organisation; OPT-3 scores 4 because two targets rest on vendor claims and one is partly met.

## 9. Cost and TCO comparison

<!-- Guidance: Use the same horizon, cost categories and price basis for every option. Include the cost of running the old system until it is retired, migration, dual running and exit. Questions: what is one-off, what recurs, and how confident is each number? Pitfall: comparing a SaaS subscription with only the build cost of the alternative. -->

All values in USD thousand, undiscounted, *Example*. Apply your organisation's discount rate if
required and state it; detailed models go in TCO Analysis (`architecture/tco-analysis`).

| Cost item | OPT-0 | OPT-1 | OPT-2 | OPT-3 |
|---|---|---|---|---|
| One-off: build, configure, migrate, train | 0 | 600 | 2,400 | 1,500 |
| Run year 1 | 900 | 820 | 900 | 900 |
| Run year 2 | 900 | 820 | 750 | 900 |
| Run year 3 | 900 | 820 | 600 | 900 |
| Run year 4 | 900 | 820 | 550 | 900 |
| Run year 5 | 900 | 820 | 550 | 900 |
| **Five-year TCO** | **4,500** | **4,700** | **5,750** | **6,000** |
| C3 score (section 7 bands) | 4 | 4 | 3 | 3 |
| Confidence | High | Medium | Medium | Medium: subscription quote valid 90 days |

Check: OPT-1 is 600 + 5 x 820 = 4,700; OPT-2 is 2,400 + 900 + 750 + 600 + 550 + 550 = 5,750;
OPT-3 is 1,500 + 5 x 900 = 6,000. All options stay within the CSF-002 envelope of 6,500.

Costs that are not in the TCO but matter to the decision: *Example:* OPT-0 carries the risk of
another throttled peak, estimated by the business at USD 1.2 million of lost orders per event. That
belongs to the benefit side and is reflected in C1, not added to C3, so it is not counted twice.

## 10. Delivery risk and time to value

<!-- Guidance: Rate delivery risk on named factors, not as a single feeling. Questions: how new is the technology to us, how many teams and suppliers must coordinate, how reversible is each step, and when does the first benefit arrive? Pitfall: ignoring the risk of the do-nothing option. -->

### 10.1 Delivery risk factors

| Factor | OPT-0 | OPT-1 | OPT-2 | OPT-3 |
|---|---|---|---|---|
| Technology novelty for the team | Low | Low | Medium | Medium |
| Number of teams and suppliers | Low | Low | Medium | Medium: vendor, integrator, in-house |
| Reversibility of each step | High | High | High: each capability can stop | Low after data migration |
| Data migration complexity | None | None | Medium, phased | High, one migration |
| Dependency on hiring (ASM-001) | None | Low | High | Low |
| **Overall and C4 score** | **Low: 5** | **Low to medium: 4** | **Medium: 3** | **Medium: 3** |

### 10.2 Time to value

| Option | First measurable value | Months *(Example)* | C5 score |
|---|---|---|---|
| OPT-0 | None | Never | 1 |
| OPT-1 | Queue absorbs the next peak's bursts | 4 | 4 |
| OPT-2 | New order capture live before the next peak | 7 | 3 |
| OPT-3 | First channel live on the SaaS product | 9 | 3 |
| [Option] | [Value] | [Months] | [Score] |

## 11. Weighted scoring results

<!-- Guidance: Show the full matrix and the arithmetic so anyone can check it. Put the evidence reference next to each contested score. Pitfall: presenting only the totals. -->

| Criterion | Weight | OPT-0 | OPT-1 | OPT-2 | OPT-3 |
|---|---|---|---|---|---|
| C1 Business outcome fit | 0.25 | 1 | 2 | 5 | 4 |
| C2 Quality attribute fit | 0.20 | 2 | 3 | 4 | 4 |
| C3 Five-year TCO | 0.20 | 4 | 4 | 3 | 3 |
| C4 Delivery risk | 0.15 | 5 | 4 | 3 | 3 |
| C5 Time to value | 0.10 | 1 | 4 | 3 | 3 |
| C6 Strategic flexibility and exit | 0.10 | 2 | 2 | 4 | 2 |
| **Weighted score (maximum 5.00)** | **1.00** | **2.50** | **3.10** | **3.80** | **3.35** |
| Rank | | 4 | 3 | 1 | 2 |

*Example* arithmetic, weight times score summed over criteria:

- OPT-0: 0.25 + 0.40 + 0.80 + 0.75 + 0.10 + 0.20 = 2.50
- OPT-1: 0.50 + 0.60 + 0.80 + 0.60 + 0.40 + 0.20 = 3.10
- OPT-2: 1.25 + 0.80 + 0.60 + 0.45 + 0.30 + 0.40 = 3.80
- OPT-3: 1.00 + 0.80 + 0.60 + 0.45 + 0.30 + 0.20 = 3.35

Score evidence: C1 for OPT-3 is 4 because product configuration limits the fulfilment rules the
business listed (fit-gap workshop notes, Appendix [A]); C6 for OPT-3 is 2 because the data export
terms in the draft subscription contract allow one full export per year only.

## 12. Sensitivity and switching values

<!-- Guidance: Test whether the ranking survives plausible changes in weights and in the most uncertain scores. A switching value is the change needed to make another option win. Pitfall: declaring a winner when the gap is inside scoring noise; a gap under about 0.25 on a five-point scale needs another look. -->

### 12.1 Weight scenarios

| Scenario | Weight change | OPT-0 | OPT-1 | OPT-2 | OPT-3 | Leader |
|---|---|---|---|---|---|---|
| Baseline | As in section 7 | 2.50 | 3.10 | 3.80 | 3.35 | OPT-2 |
| *Example:* Cost matters more | C3 0.30, C1 0.15 | 2.80 | 3.30 | 3.60 | 3.25 | OPT-2 |
| *Example:* Risk aversion | C4 0.25, C5 0.05, C6 0.05 | 2.85 | 3.20 | 3.75 | 3.40 | OPT-2 |
| [Scenario] | [Change] | [ ] | [ ] | [ ] | [ ] | [ ] |

Arithmetic for the cost scenario, moving 0.10 of weight from C1 to C3: OPT-2 is 3.80 - 0.10(5) +
0.10(3) = 3.60; OPT-1 is 3.10 - 0.10(2) + 0.10(4) = 3.30. For the risk scenario, adding 0.10 to C4
and removing 0.05 from each of C5 and C6: OPT-2 is 3.80 + 0.10(3) - 0.05(3) - 0.05(4) = 3.75; OPT-3
is 3.35 + 0.10(3) - 0.05(3) - 0.05(2) = 3.40.

### 12.2 Score scenarios and switching values

| Uncertain input | Change tested | Effect | Leader |
|---|---|---|---|
| *Example:* ASM-001 hiring fails | OPT-2 C4 from 3 to 2 | OPT-2 falls to 3.80 - 0.15 = 3.65 | OPT-2 |
| *Example:* SaaS fit better than expected | OPT-3 C1 from 4 to 5 | OPT-3 rises to 3.35 + 0.25 = 3.60 | OPT-2 |
| *Example:* Both of the above | Both changes | OPT-2 3.65, OPT-3 3.60 | Near tie: decide on conditions in section 13 |

Switching value for C1: the gap between OPT-2 and OPT-3 is 0.45, so OPT-2's outcome score would
have to fall by 0.45 / 0.25 = 1.8 points (from 5 to 3.2) before OPT-3 leads. Cost alone cannot
switch the ranking inside the envelope: if OPT-2's TCO rose to the CSF-002 limit of USD 6.5
million, its C3 score would fall to 2 and its total to 3.80 - 0.20 = 3.60, still ahead of OPT-3.

## 13. Recommendation and conditions

<!-- Guidance: Recommend one option, say why in two or three sentences, and state the conditions that must hold. Questions: what would make us revisit the choice, and what is the fallback? Pitfall: a recommendation without conditions, so nobody notices when its premises fail. -->

**Recommended option:** [OPT-N]. *Example:* OPT-2 Incremental replacement. It is the only option
that meets every objective with margin, it keeps each step reversible, and it stays the leader
under every weight scenario tested. Its main weakness is dependence on hiring (ASM-001).

| ID | Condition | Check point | Fallback if the condition fails |
|---|---|---|---|
| CND-001 *(Example)* | Two senior engineers hired or contracted by month 4 | Steering group, month 4 | Partner supplies the roles for year 1 at the cost already in the TCO |
| CND-002 *(Example)* | Proof of concept shows the event stream meets the latency target | PoC report, month 2 | Re-score C2; reconsider OPT-3 for orchestration |
| CND-003 *(Example)* | Order capture service live before the peak-season freeze | Go-live gate, month 7 | Run OPT-1 queue measures for that peak |
| [CND-NNN] | [Condition] | [Check point] | [Fallback] |

Options not recommended and why: *Example:* OPT-3 is credible but scores lower on outcome fit and
exit; it remains the fallback for the orchestration capability. OPT-1 is the right interim measure
if the first condition fails. OPT-0 fails the strategic fit test and is kept only as the benchmark.

## 14. Decision record and next steps

<!-- Guidance: Record the decision and its rationale where architecture decisions live, then plan the next steps. Questions: who decided, what was decided, which alternatives were rejected and why, and what follows? Pitfall: leaving the rationale in a slide deck that nobody can find a year later. -->

| Field | Value |
|---|---|
| Decision | [Option chosen and scope] |
| Decided by and date | [@name], YYYY-MM-DD |
| Rationale | [Two or three sentences, matching section 13] |
| Alternatives rejected | [Options and the reason for each] |
| Conditions | [CND IDs] |
| ADR | [ADR-NNN] in the Architecture Decision Log (`architecture/architecture-decision-log`) |
| Review date | [Date or trigger to revisit] |

| Next step | Owner | Due |
|---|---|---|
| *Example:* Run the proof of concept for event stream latency | [@solution-architect] | Month 2 |
| *Example:* Update the business case with the chosen option (Business Case, `business/business-case`) | [@product-owner] | Month 1 |
| *Example:* Add the transition steps to the architecture roadmap | [@enterprise-architect] | Month 2 |
| [Step] | [Owner] | [Date] |

## 15. Glossary and references

<!-- Guidance: Define the terms readers may confuse and list the sources used for costs, scores and method. -->

### 15.1 Glossary

| Term | Meaning |
|---|---|
| Option | A complete approach to the problem, combining choices of scope, solution, delivery, implementation and funding |
| Long list | All options generated before filtering |
| Short list | The options analysed in detail, always including business as usual and a do-minimum option |
| Business as usual | Continuing the current arrangement; the benchmark every option is compared with |
| Do minimum | The option that just achieves the objectives and goes no further (Green Book); where none exists below the preferred option, the nearest floor, with its failed factors recorded |
| Critical success factor | A condition an option must meet to stay on the short list |
| Switching value | The change in an input needed to make a different option rank first |
| TCO | Total cost of ownership over the stated horizon, one-off plus recurring |
| [Term] | [Meaning] |

### 15.2 References

| ID | Reference | Version / date |
|---|---|---|
| REF-01 | HM Treasury, The Green Book (2026): long-list appraisal, options framework filter, short-list composition | Updated 2026-02-05, gov.uk |
| REF-02 | ISO/IEC/IEEE 42010:2022, Software, systems and enterprise: Architecture description | Edition 2, 2022-11 |
| REF-03 | ISO/IEC 25010:2023, SQuaRE: Product quality model | Edition 2, 2023-11 |
| REF-04 | The TOGAF Standard, 10th Edition (The Open Group), Phase E Opportunities and Solutions | 2025 release (C220, 19 May 2025) with Technical Corrigendum 1 |
| REF-05 | Current State Assessment (`architecture/current-state-assessment`) | [x.y] |
| REF-06 | TCO Analysis (`architecture/tco-analysis`) | [x.y] |
| REF-07 | [Vendor quotes, benchmark reports, workshop notes] | [Date] |

## Standard and licence note

Based on the option generation and short-listing method of HM Treasury's The Green Book (2026
edition, updated 5 February 2026), Crown copyright, reusable under the Open Government Licence v3.0;
the method is described here in original words and no text is reproduced. Structure also aligned
with ISO/IEC/IEEE 42010:2022 (recording architecture decisions and their rationale) and ISO/IEC
25010:2023 (quality characteristics), which are copyrighted: only clause concepts and
characteristic names are used. TOGAF is a registered trademark of The Open Group. This template uses
only the name of ADM Phase E; all text is original. Check the current editions at gov.uk, iso.org
and opengroup.org. Template licence: MIT.