Solution Options Analysis Template

Approach options: decision, objectives and CSFs, long-list filter, short list with BAU and do minimum, sketches, NFR fit, TCO, risk, scores, sensitivity

Kiến trúcĐầy đủHM Treasury Green Book (2026) options framework; ISO/IEC/IEEE 42010:2022; ISO/IEC 25010:2023; TOGAF 10 Phase Esolution options analysisCập nhật 22 thg 10, 2026

Mở trong editorTải .md

Cách dùng: Use it when you must choose an approach (retain, wrap, replace incrementally, SaaS, rebuild) before choosing products. Fill the decision statement, objectives, critical success factors and the weighted criteria before anyone scores. The main pitfall is changing weights after scoring or dropping business as usual and the do-minimum option from the short list.

Xem trước

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.

Document control

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

Decision required and context
Drivers, objectives and critical success factors
Constraints, assumptions and dependencies
Long list and options filter
Short-listed options
Architecture sketches
Evaluation criteria and scoring scales
Quality attribute fit
Cost and TCO comparison
Delivery risk and time to value
Weighted scoring results
Sensitivity and switching values
Recommendation and conditions
Decision record and next steps
Glossary and references

1. Decision required and context

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Template liên quan

Kiến trúc