# Architecture Cost-Benefit Analysis (CBAM): [System name]

> Report of an economic analysis of architectural strategies following
> the Cost Benefit Analysis Method (CBAM) developed at the Software
> Engineering Institute (SEI), Carnegie Mellon University, by Rick
> Kazman, Jai Asundi and Mark Klein (SEI technical reports
> CMU/SEI-2001-TR-035, December 2001, and CMU/SEI-2002-TR-035,
> September 2002). It records the scenarios carried over from an
> architecture evaluation, their response levels and utility curves,
> stakeholder votes and weights, the candidate architectural strategies
> with their expected responses, benefit, cost, return on investment
> (ROI), a sensitivity analysis and the investment decision. Replace
> every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Run the CBAM after an architecture evaluation such as the ATAM
  (`architecture/atam-evaluation`), when the team must choose which
  architectural strategies to fund from a limited budget. The ATAM tells
  you where the risks are; the CBAM tells you which fixes pay back best.
- Work through sections 3 to 11 in step order. Each section maps to one
  CBAM step. Do not skip step 9 (confirm with intuition): a ranking that
  nobody believes is a sign of a wrong utility curve or a missing cost.
- Utility is a stakeholder judgement on a 0 to 100 scale, not a
  measurement. Record who gave each value so the numbers can be
  challenged and revisited.
- Recompute every derived number (weights, interpolated utilities,
  benefit, ROI) whenever an input changes. The worked example in this
  template is internally consistent: use it to check your spreadsheet.
- Related documents: Quality attribute scenarios
  (`requirements/quality-attributes`), NFR catalogue
  (`requirements/nfr-catalogue`), Fitness functions
  (`architecture/fitness-functions`), Technical debt register
  (`architecture/tech-debt-register`), TCO analysis
  (`architecture/tco-analysis`), Solution options analysis
  (`architecture/solution-options-analysis`), Architecture roadmap
  (`architecture/architecture-roadmap-transition`), Business case
  (`business/business-case`).
-->

## Document control

<!-- Guidance: Identify the system, the evaluation this analysis builds on and the budget envelope being allocated. A change to the scenario set, weights or budget is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [CBA-001] |
| System | [System name and version] |
| Preceding evaluation | [ATAM report ID or QAW report ID, date] |
| Budget envelope analysed | [USD amount, period] |
| Planning horizon | [Releases or quarters covered] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@lead-architect] |
| Approvers/reviewers | [@product-owner], [@engineering-manager], [@finance-partner], [@architecture-board] |
| Facilitator | [@facilitator] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Product or business owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Lead architect | [@name] | [Decision] | YYYY-MM-DD |
| Finance partner | [@name] | [Decision] | YYYY-MM-DD |
| Architecture board | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft after scenario workshop |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; three strategies funded for the next two quarters |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Second iteration after cost estimates for AS-02 were refined |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Executive summary](#1-executive-summary)
2. [Context, scope and participants](#2-context-scope-and-participants)
3. [Step 1: Collate scenarios](#3-step-1-collate-scenarios)
4. [Step 2: Refine scenarios](#4-step-2-refine-scenarios)
5. [Step 3: Prioritise scenarios](#5-step-3-prioritise-scenarios)
6. [Step 4: Assign utility](#6-step-4-assign-utility)
7. [Step 5: Develop architectural strategies](#7-step-5-develop-architectural-strategies)
8. [Step 6: Determine expected utility](#8-step-6-determine-expected-utility)
9. [Step 7: Calculate total benefit](#9-step-7-calculate-total-benefit)
10. [Step 8: Choose strategies by ROI](#10-step-8-choose-strategies-by-roi)
11. [Step 9: Confirm results with intuition](#11-step-9-confirm-results-with-intuition)
12. [Uncertainty and sensitivity analysis](#12-uncertainty-and-sensitivity-analysis)
13. [Decision, follow-up and traceability](#13-decision-follow-up-and-traceability)
14. [Glossary and references](#14-glossary-and-references)

## 1. Executive summary

<!-- Guidance: Write this last. State the budget, the strategies funded, the total benefit bought and the main uncertainty. A reader who stops here should know what was decided and why. -->

[Two or three paragraphs: the decision being supported, the budget, the
recommended strategies in ROI order, what they buy in quality terms and
the main caveats.]

*Example:* The payments platform team had USD 500,000 for architecture
work in the next two quarters and five candidate strategies addressing
the four highest-priority scenarios from the ATAM held on YYYY-MM-DD.
The CBAM recommends funding AS-01 (read cache and asynchronous
confirmation), AS-04 (payment provider adapter layer) and AS-02 (warm
standby region), in that ROI order. Together they cost exactly the
budget and deliver 101.3 weighted utility points. AS-03 (active-active
multi-region) delivers the largest single benefit (54.2 points) but
costs USD 900,000 and has the lowest ROI; it is rejected for this
horizon and recorded as a future option. The ranking is stable under a
plus or minus 30 percent cost range for AS-02; it is most sensitive to
the latency AS-01 actually achieves, which a two-week spike will test
before the full build, and to the weight of the fraud scenario, which
will be re-voted at the next quarterly review.

| Item | Value |
|---|---|
| Strategies analysed | [n] |
| Strategies funded | [IDs] |
| Total cost of funded strategies | [USD amount] |
| Total benefit of funded strategies | [weighted utility points] |
| Strategies deferred or rejected | [IDs and reason] |
| Main uncertainty | [Input whose change would alter the ranking] |

## 2. Context, scope and participants

<!-- Guidance: Say what decision the analysis supports and what is out of scope. CBAM needs both technical and business stakeholders in the room: architects estimate responses and costs, business stakeholders set utility and votes. Without the latter the result is a technical opinion, not an investment case. -->

### 2.1 Decision and scope

| Field | Value |
|---|---|
| Decision supported | [Which architectural strategies to fund in the horizon] |
| Systems in scope | [Components, services, platforms] |
| Out of scope | [Feature work, operating budget, unrelated systems] |
| Cost basis | [Engineering effort at blended rate, licences, infrastructure for n months] |
| Cost unit used in ROI | [USD 1,000] |
| Iteration | [1 / 2 / n] |

The CBAM can run in more than one iteration. A first iteration
narrows the field using rough estimates; a second iteration refines
costs, response estimates and utility curves for the remaining
strategies. Record which iteration this report covers and what
changed since the previous one.

### 2.2 Participants

| Name | Role | Group | Contribution |
|---|---|---|---|
| [@name] | Facilitator | Evaluation team | Runs the steps, keeps time, challenges numbers |
| [@name] | Lead architect | Architecture | Strategies, expected responses, side effects |
| [@name] | Product owner | Business | Votes, utility, business goals |
| [@name] | Engineering manager | Delivery | Cost and schedule estimates |
| [@name] | Operations lead | Operations | Operability side effects, run costs |
| [@name] | Finance partner | Finance | Cost basis, budget constraint |
| [@name] | Scribe | Evaluation team | Records rationale for every number |

### 2.3 Inputs

| Input | Reference | Version or date |
|---|---|---|
| Architecture evaluation report | [ATAM or ISO/IEC/IEEE 42030 evaluation ID] | [Date] |
| Quality attribute scenarios | [`requirements/quality-attributes` document ID] | [Version] |
| Architecture description | [Document ID] | [Version] |
| Risk themes and technical debt | [Tech debt register ID] | [Date] |
| Budget and schedule constraints | [Finance reference] | [Period] |

## 3. Step 1: Collate scenarios

<!-- Guidance: Gather the scenarios from the earlier evaluation and let stakeholders add new ones. Keep the set small: CBAM effort grows with every scenario carried forward. A common pitfall is importing every ATAM scenario; select by contribution to business goals. -->

Collect the scenarios elicited in the preceding evaluation, invite
stakeholders to add scenarios that reflect business goals not yet
covered, and shortlist roughly the top third by contribution to those
goals. Each scenario keeps its original ID where one exists so it can
be traced back. *Example:* 24 scenarios (19 from the ATAM, 5 new) were
reviewed; the eight below form the shortlisted top third.

| ID | Source ID | Scenario (stimulus, environment, response) | Business goal | Shortlisted |
|---|---|---|---|---|
| SCN-01 | *Example:* U-03 | Checkout requests at peak load (400 per second) complete end to end | BG-1 conversion | Yes |
| SCN-02 | *Example:* U-02 | Primary cloud region becomes unavailable; payment processing resumes | BG-2 availability commitment | Yes |
| SCN-03 | *Example:* U-04 | A new payment provider is added to the platform | BG-3 market expansion | Yes |
| SCN-04 | *Example:* New | Fraud team changes a detection rule in response to an attack pattern | BG-4 fraud loss | Yes |
| SCN-05 | *Example:* S-03 | Auditor requests a full transaction trail for one merchant | BG-5 compliance | Yes |
| SCN-06 | *Example:* New | Reporting queries run during business hours | BG-1 conversion | Yes |
| SCN-07 | *Example:* New | Developer onboards and ships a first change | BG-6 engineering velocity | Yes |
| SCN-08 | *Example:* S-04 | Workload is moved to a second cloud provider | BG-2 availability commitment | Yes |
| [SCN-nn] | [ID] | [Scenario] | [BG-n] | [Yes / No] |

## 4. Step 2: Refine scenarios

<!-- Guidance: For each shortlisted scenario, fix the response measure and elicit four response levels: worst case, current, desired and best case. Use the same unit for all four. Pitfall: a "desired" level that is cheaper to state than to reach; ask what the business would actually pay for. -->

Each scenario is refined to a single response measure with four
response levels. The worst case is the level at which the scenario
becomes worthless to the business; the best case is the level beyond
which further improvement adds no value.

| ID | Response measure | Worst | Current | Desired | Best |
|---|---|---|---|---|---|
| SCN-01 | *Example:* p99 checkout latency (ms) | 4,000 | 1,800 | 800 | 400 |
| SCN-02 | *Example:* Recovery time after region loss (minutes) | 240 | 120 | 15 | 5 |
| SCN-03 | *Example:* Effort to add a provider (person-weeks) | 20 | 12 | 4 | 2 |
| SCN-04 | *Example:* Time to deploy a new fraud rule (days) | 30 | 10 | 1 | 0.04 (1 hour) |
| SCN-05 | *Example:* Time to produce a merchant trail (hours) | 72 | 24 | 4 | 1 |
| SCN-06 | *Example:* Reporting impact on p99 OLTP latency (percent) | 50 | 20 | 5 | 0 |
| SCN-07 | *Example:* Days from laptop to first production change | 20 | 10 | 3 | 1 |
| SCN-08 | *Example:* Months to run on a second provider | 36 | 24 | 9 | 6 |
| [SCN-nn] | [Measure and unit] | [Value] | [Value] | [Value] | [Value] |

Check every row: the four levels must be ordered (worst, current,
desired, best) in the direction that the business prefers, and the
current level must come from measurement or monitoring, not memory.
Record the source of each current level in the evidence column of the
appendix table in section 13.3.

## 5. Step 3: Prioritise scenarios

<!-- Guidance: Give each stakeholder the same number of votes (100 is common) and ask them to distribute votes across scenarios based on the value of reaching the desired level. Keep roughly the top half. The highest-voted scenario gets weight 1.0; the others get votes divided by the top score. Record individual votes so outliers can be discussed. -->

Each of the [n] voting stakeholders received 100 votes. Scenarios were
ranked by total votes and the top half retained. Weights are
normalised so that the highest-ranked scenario has weight 1.00.

| ID | Votes | Rank | Retained | Weight (votes / top votes) |
|---|---|---|---|---|
| SCN-01 | *Example:* 300 | 1 | Yes | 1.00 |
| SCN-02 | *Example:* 240 | 2 | Yes | 0.80 |
| SCN-03 | *Example:* 150 | 3 | Yes | 0.50 |
| SCN-04 | *Example:* 90 | 4 | Yes | 0.30 |
| SCN-05 | *Example:* 12 | 5 | No | n/a |
| SCN-06 | *Example:* 5 | 6 | No | n/a |
| SCN-07 | *Example:* 3 | 7 | No | n/a |
| SCN-08 | *Example:* 0 | 8 | No | n/a |
| Total | *Example:* 800 (8 stakeholders x 100) | | | |

Scenarios not retained are not discarded: list them in section 13.2 as
candidates for a later iteration or for the technical debt register.
*Example:* SCN-05 (audit trail) received few votes because a manual
workaround exists; the compliance lead asked for it to be re-examined
if the audit frequency rises.

## 6. Step 4: Assign utility

<!-- Guidance: For each retained scenario, stakeholders assign a utility from 0 to 100 to each response level. Worst is normally 0 and best is normally 100, but stakeholders set the current and desired values. Draw the curve: it shows where improvement stops paying. Pitfall: assuming a straight line; most curves flatten near the best case. -->

Utility expresses how much a response level is worth to the
stakeholders on a scale from 0 (worthless) to 100 (no further value).
The four points per scenario define a utility-response curve; values
between points are obtained by linear interpolation in step 6.

| ID | U(worst) | U(current) | U(desired) | U(best) | Curve shape and rationale |
|---|---|---|---|---|---|
| SCN-01 | *Example:* 0 | 40 | 85 | 100 | Steep gain to 800 ms (abandonment drops), flat below |
| SCN-02 | *Example:* 0 | 30 | 90 | 100 | Contract penalty clause starts at 30 minutes |
| SCN-03 | *Example:* 0 | 35 | 80 | 100 | Two new markets need providers within the year |
| SCN-04 | *Example:* 0 | 50 | 90 | 100 | Same-day rule change stops most attack waves |
| [SCN-nn] | [0] | [n] | [n] | [100] | [Rationale] |

```mermaid
flowchart LR
  W["Worst: utility 0"] --> C["Current: stakeholder value"]
  C --> D["Desired: stakeholder value"]
  D --> B["Best: utility 100"]
```

Record, for each curve, who proposed the values and whether the group
reached consensus or the product owner decided. Utility values carry
more weight than any other input, so they must be defensible.

## 7. Step 5: Develop architectural strategies

<!-- Guidance: For each retained scenario, the architects propose strategies and estimate the response level each would achieve, for every retained scenario it affects (including negative side effects). Estimate cost and schedule at the same time. Pitfall: ignoring side effects; a strategy that helps availability often costs latency or modifiability. -->

### 7.1 Strategy catalogue

| ID | Strategy | Scenarios affected | Cost (USD 1,000) | Schedule | Mutually exclusive with |
|---|---|---|---|---|---|
| AS-01 | *Example:* Read-through cache for catalogue and price data plus asynchronous order confirmation | SCN-01 | 120 | 6 weeks | None |
| AS-02 | *Example:* Warm standby in a second region with asynchronous database replication and scripted failover | SCN-02 | 300 | 12 weeks | AS-03 |
| AS-03 | *Example:* Active-active deployment across two regions with conflict-free payment partitioning | SCN-02, SCN-01 | 900 | 30 weeks | AS-02 |
| AS-04 | *Example:* Provider adapter layer (port and adapter) with a contract test kit | SCN-03 | 80 | 5 weeks | None |
| AS-05 | *Example:* Externalised fraud rules engine with a rule deployment pipeline | SCN-04 | 150 | 10 weeks | None |
| [AS-nn] | [Strategy] | [SCN IDs] | [Cost] | [Duration] | [IDs] |

### 7.2 Cost basis

| Cost element | Basis | Applies to |
|---|---|---|
| Engineering effort | *Example:* Person-weeks x blended rate of USD 4,000 | All strategies |
| Infrastructure | *Example:* Additional run cost for 12 months | AS-02, AS-03 |
| Licences and services | *Example:* Rules engine subscription for 12 months | AS-05 |
| Contingency | *Example:* 20 percent on estimates rated low confidence | AS-03 |
| [Element] | [Basis] | [AS IDs] |

Use one cost basis for every strategy. If one strategy includes twelve
months of run cost and another does not, the ROI ranking is
meaningless. For lifetime cost comparisons, reference the TCO analysis
(`architecture/tco-analysis`) and bring a single figure into this
table.

### 7.3 Expected response levels

| Strategy | Scenario | Current response | Expected response | Estimate confidence | Basis of estimate |
|---|---|---|---|---|---|
| AS-01 | SCN-01 | *Example:* 1,800 ms | 900 ms | Medium | Load test of cache prototype on 10 percent traffic |
| AS-02 | SCN-02 | *Example:* 120 min | 30 min | High | Failover rehearsal in staging |
| AS-03 | SCN-02 | *Example:* 120 min | 5 min | Medium | Vendor reference architecture and spike |
| AS-03 | SCN-01 | *Example:* 1,800 ms | 1,900 ms | Medium | Added cross-region consistency check on write path |
| AS-04 | SCN-03 | *Example:* 12 pw | 5 pw | Medium | Last two provider integrations re-estimated against adapter |
| AS-05 | SCN-04 | *Example:* 10 days | 1 day | High | Rules engine pilot in fraud team |
| [AS-nn] | [SCN-nn] | [Value] | [Value] | [High / Medium / Low] | [Evidence] |

## 8. Step 6: Determine expected utility

<!-- Guidance: Read the utility of each expected response level from the curve in step 4, interpolating linearly between the two nearest points. Show the calculation so reviewers can check it. -->

For an expected response x that lies between two known points
(x0, u0) and (x1, u1) on the utility curve, the expected utility is
obtained by linear interpolation.

```text
U(x) = u0 + (x0 - x) / (x0 - x1) * (u1 - u0)
```

| Strategy | Scenario | Bracketing points | Calculation | U(expected) | U(current) |
|---|---|---|---|---|---|
| AS-01 | SCN-01 | *Example:* current (1,800; 40), desired (800; 85) | 40 + (900 / 1,000) x 45 | 80.5 | 40 |
| AS-02 | SCN-02 | *Example:* current (120; 30), desired (15; 90) | 30 + (90 / 105) x 60 | 81.4 | 30 |
| AS-03 | SCN-02 | *Example:* equals best (5; 100) | Read directly | 100.0 | 30 |
| AS-03 | SCN-01 | *Example:* worst (4,000; 0), current (1,800; 40) | 0 + (2,100 / 2,200) x 40 | 38.2 | 40 |
| AS-04 | SCN-03 | *Example:* current (12; 35), desired (4; 80) | 35 + (7 / 8) x 45 | 74.4 | 35 |
| AS-05 | SCN-04 | *Example:* equals desired (1; 90) | Read directly | 90.0 | 50 |
| [AS-nn] | [SCN-nn] | [Points] | [Formula] | [Value] | [Value] |

Keep unrounded values in the working spreadsheet and round only when
reporting. The worked example rounds to one decimal place in this
table but uses the unrounded values in section 9.

## 9. Step 7: Calculate total benefit

<!-- Guidance: The benefit of a strategy for one scenario is the change in utility from current to expected. Multiply by the scenario weight and add across all scenarios the strategy affects. Negative side effects reduce the total. -->

```text
b(i, j) = U_expected(i, j) - U_current(j)
B(i)    = sum over j of b(i, j) x W(j)
```

Here i is the strategy, j is the scenario and W(j) is the weight from
step 3.

| Strategy | Scenario | Utility change b | Weight W | Weighted benefit | Total benefit B |
|---|---|---|---|---|---|
| AS-01 | SCN-01 | *Example:* +40.5 | 1.00 | +40.5 | 40.5 |
| AS-02 | SCN-02 | *Example:* +51.4 | 0.80 | +41.1 | 41.1 |
| AS-03 | SCN-02 | *Example:* +70.0 | 0.80 | +56.0 | |
| AS-03 | SCN-01 | *Example:* -1.8 | 1.00 | -1.8 | 54.2 |
| AS-04 | SCN-03 | *Example:* +39.4 | 0.50 | +19.7 | 19.7 |
| AS-05 | SCN-04 | *Example:* +40.0 | 0.30 | +12.0 | 12.0 |
| [AS-nn] | [SCN-nn] | [Value] | [Value] | [Value] | [Sum] |

A strategy with a negative total benefit is never funded on CBAM
grounds, whatever its cost. If such a strategy is mandatory (for
example to meet a regulation), record it as a constraint in section
10.2 and deduct its cost from the budget before ranking the rest.

## 10. Step 8: Choose strategies by ROI

<!-- Guidance: Divide total benefit by cost to get ROI, rank strategies and fund from the top until the budget or schedule constraint is reached. Respect mutual exclusions and mandatory items. Pitfall: funding the strategy with the largest benefit instead of the best ratio. -->

### 10.1 ROI ranking

```text
ROI(i) = B(i) / C(i)
```

ROI in this report is expressed in weighted utility points per
USD 1,000. Some presentations multiply the ratio by 100; the ranking is
the same either way.

| Rank | Strategy | Benefit B | Cost C (USD 1,000) | ROI (B / C) | Cumulative cost | Decision |
|---|---|---|---|---|---|---|
| 1 | AS-01 | *Example:* 40.5 | 120 | 0.338 | 120 | Fund |
| 2 | AS-04 | *Example:* 19.7 | 80 | 0.246 | 200 | Fund |
| 3 | AS-02 | *Example:* 41.1 | 300 | 0.137 | 500 | Fund |
| 4 | AS-05 | *Example:* 12.0 | 150 | 0.080 | 650 | Defer: over budget |
| 5 | AS-03 | *Example:* 54.2 | 900 | 0.060 | n/a | Reject: excluded by AS-02, lowest ROI |
| [n] | [AS-nn] | [B] | [C] | [ROI] | [Sum] | [Fund / Defer / Reject] |

*Example:* The funded set costs USD 500,000, equal to the budget, and
delivers 40.5 + 19.7 + 41.1 = 101.3 weighted utility points (101.33
unrounded). Replacing AS-02 with AS-03 would raise the availability
benefit but the set would cost USD 1,100,000, more than twice the
budget.

### 10.2 Constraints applied

| Constraint | Type | Effect on selection |
|---|---|---|
| *Example:* Total budget USD 500,000 for two quarters | Budget | Funding stops after AS-02 |
| *Example:* AS-02 and AS-03 cannot both be built | Mutual exclusion | AS-03 removed once AS-02 is selected |
| *Example:* Availability improvement live before the peak season in month 5 | Schedule | AS-02 (12 weeks) must start in month 1 |
| [Constraint] | [Budget / Schedule / Exclusion / Mandatory / Dependency] | [Effect] |

### 10.3 Selection procedure

1. Remove strategies with negative total benefit.
2. Fund mandatory strategies first and deduct their cost.
3. Rank the remaining strategies by ROI, highest first.
4. Walk down the list. Fund a strategy if it fits the remaining budget
   and schedule and does not conflict with one already funded.
5. When a strategy does not fit, check whether a cheaper one further
   down fits the remainder before stopping.
6. Record every skipped strategy with its reason.

## 11. Step 9: Confirm results with intuition

<!-- Guidance: Present the ranking to the stakeholders and ask whether it makes sense. Disagreement is useful: trace it to a specific input (a utility value, a weight, a cost, a response estimate), correct that input and recompute. Never adjust the result directly. -->

| Question | Answer | Action if no |
|---|---|---|
| Do the funded strategies address the business goals stakeholders care most about? | [Yes / No, explanation] | Revisit votes in step 3 |
| Is any strategy ranked surprisingly high or low? | [Strategy and reason] | Check its response estimate and cost |
| Has any strategy a side effect nobody priced? | [Yes / No] | Add the affected scenario to step 7 |
| Do the costs include run cost and the cost of change to operations? | [Yes / No] | Correct the cost basis in section 7.2 |
| Would stakeholders accept the risk left by deferred strategies? | [Yes / No] | Record residual risk in section 13 |
| Is there a strategy nobody proposed that would dominate these? | [Yes / No] | Add it and run a second iteration |

*Example:* Stakeholders questioned why AS-05 (fraud rules) ranked
below AS-02. Tracing the result showed that the fraud scenario's low
weight (0.30) came from a vote held before the most recent fraud
incident. The product owner chose to keep the weight for this
iteration and to rerun the vote at the next quarterly review; the
decision is recorded in section 13.

## 12. Uncertainty and sensitivity analysis

<!-- Guidance: Every CBAM input is an estimate. Identify which inputs, if wrong, would change the ranking. Test them with low and high values. Spend analysis effort, spikes or prototypes on the inputs that matter, not on the ones that do not. -->

### 12.1 Input confidence

| Input | Strategy or scenario | Confidence | Range tested |
|---|---|---|---|
| Cost | *Example:* AS-02 | Medium | USD 210,000 to 390,000 (plus or minus 30 percent) |
| Expected response | *Example:* AS-01 on SCN-01 | Medium | 900 ms to 1,200 ms |
| Weight | *Example:* SCN-04 | Low | 0.30 to 0.60 |
| Utility | *Example:* SCN-02 desired level | High | 85 to 95 |
| [Input] | [ID] | [High / Medium / Low] | [Range] |

### 12.2 Sensitivity results

| Variation | Effect on ROI | Ranking changes? | Conclusion |
|---|---|---|---|
| *Example:* AS-02 cost at USD 210,000 | ROI 41.1 / 210 = 0.196 | No | AS-02 stays third |
| *Example:* AS-02 cost at USD 390,000 | ROI 41.1 / 390 = 0.105 | No, still above AS-05 (0.080) | Funded set would exceed the budget by USD 90,000: cut scope or seek extra funding |
| *Example:* AS-01 achieves 1,200 ms, not 900 ms | U = 40 + (600 / 1,000) x 45 = 67.0; B = 27.0; ROI 27.0 / 120 = 0.225 | Yes: AS-04 (0.246) moves to first | Funded set unchanged; validate AS-01 with a spike before full build |
| *Example:* SCN-04 weight at 0.60 | B = 40 x 0.60 = 24.0; ROI 24.0 / 150 = 0.160 | Yes: AS-05 overtakes AS-02 (0.137) | Rerun the vote; compare feasible sets (table below) before switching |
| [Variation] | [Calculation] | [Yes / No] | [Conclusion] |

The last row shows why the weights matter, and why a pure ROI walk is
not the whole answer. With the fraud weight at 0.60, ranking by ROI
funds AS-01, AS-04 and AS-05 (USD 350,000, benefit 40.5 + 19.7 + 24.0
= 84.2 points) and then stops, because AS-02 (USD 300,000) no longer
fits the remaining USD 150,000. The original set AS-01, AS-04 and AS-02
still fits the budget exactly and delivers 101.3 points. When the
budget is tight, compare the total benefit of every feasible set of
strategies, not only the order of the ratios, and present such
breakpoints to decision makers explicitly.

| Feasible set (weight of SCN-04 = 0.60) | Cost (USD 1,000) | Total benefit | Unspent budget |
|---|---|---|---|
| *Example:* AS-01, AS-04, AS-02 | 500 | 101.3 | 0 |
| *Example:* AS-01, AS-04, AS-05 | 350 | 84.2 | 150 |
| *Example:* AS-01, AS-02, AS-05 | 570 | Over budget | n/a |
| [Set] | [Cost] | [Benefit] | [Remainder] |

### 12.3 Risk to the decision

| ID | Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|---|
| CBR-01 | *Example:* AS-01 latency gain lower than estimated | Medium | ROI ranking changes | Two-week spike with production-like data before committing |
| CBR-02 | *Example:* Replication lag makes AS-02 failover lose recent payments | Low | Scenario SCN-02 fails acceptance | Measure lag in rehearsal; add reconciliation step |
| CBR-03 | *Example:* Fraud weight out of date | Medium | Wrong strategy funded | Re-vote at the next quarterly review |
| [CBR-nn] | [Risk] | [H / M / L] | [Impact] | [Mitigation] |

## 13. Decision, follow-up and traceability

<!-- Guidance: Record the decision as a budget commitment and as architecture decisions. Each funded strategy gets an ADR, a measurable acceptance criterion taken from its scenario and, where possible, a fitness function that keeps the gain from eroding. -->

### 13.1 Decision record

| Field | Value |
|---|---|
| Decision | [Fund AS-nn, AS-nn; defer AS-nn; reject AS-nn] |
| Budget committed | [USD amount] |
| Decision maker | [@name, forum] |
| Date | YYYY-MM-DD |
| ADRs raised | [ADR IDs, see `architecture/adr-full` or `architecture/architecture-decision-log`] |
| Next review | [Date or trigger, for example after the AS-01 spike] |

### 13.2 Deferred items and residual risk

| Item | Type | Owner | Where tracked |
|---|---|---|---|
| *Example:* AS-05 fraud rules engine | Deferred strategy | [@fraud-lead] | Architecture runway backlog (`architecture/architecture-runway-plan`) |
| *Example:* AS-03 active-active | Rejected option | [@lead-architect] | Architecture roadmap (`architecture/architecture-roadmap-transition`) |
| *Example:* SCN-05 audit trail | Scenario not retained | [@compliance-lead] | Technical debt register (`architecture/tech-debt-register`) |
| [Item] | [Type] | [@owner] | [Location] |

### 13.3 Traceability matrix

| Business goal | Scenario | Strategy | Acceptance criterion | Fitness function | Evidence for current level |
|---|---|---|---|---|---|
| *Example:* BG-1 conversion | SCN-01 | AS-01 | p99 checkout latency at or below 900 ms at 400 requests per second | FF-03 latency budget check in performance pipeline | APM dashboard, last 30 days |
| *Example:* BG-2 availability | SCN-02 | AS-02 | Region failover completes in 30 minutes or less in a quarterly rehearsal | FF-08 failover drill result | Last DR test report |
| *Example:* BG-3 market expansion | SCN-03 | AS-04 | Next provider integrated in 5 person-weeks or less | FF-04 dependency rule: providers only behind the adapter port | Effort records of last two integrations |
| [BG-n] | [SCN-nn] | [AS-nn] | [Measurable criterion] | [FF ID in `architecture/fitness-functions`] | [Source] |

### 13.4 Benefit realisation

After delivery, measure the actual response level for each funded
strategy and compare it with the expected level. Feed the difference
back into future estimates: a team that overestimates gains by 30
percent should know it before the next CBAM.

| Strategy | Expected response | Actual response | Date measured | Actual utility | Lesson |
|---|---|---|---|---|---|
| [AS-nn] | [Value] | [Value] | YYYY-MM-DD | [Value] | [Lesson] |

## 14. Glossary and references

<!-- Guidance: Define the CBAM terms as used in this report and list the sources consulted with the date you checked them. -->

### 14.1 Glossary

| Term | Meaning in this report |
|---|---|
| Architectural strategy | A design change or investment that alters one or more quality attribute responses |
| Scenario | A quality attribute requirement stated as stimulus, environment and measurable response |
| Response level | A value of the scenario's response measure: worst, current, desired or best |
| Utility | Stakeholder-assigned value of a response level on a 0 to 100 scale |
| Weight | Relative importance of a scenario, derived from votes, with the top scenario at 1.0 |
| Benefit | Weighted sum of the utility changes a strategy produces across scenarios |
| ROI | Benefit divided by cost, used to rank strategies |
| Side effect | A change, positive or negative, that a strategy causes in a scenario it does not target |
| Iteration | One pass through the CBAM steps; later iterations refine estimates |

### 14.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Kazman, R., Asundi, J., Klein, M. *Making Architecture Design Decisions: An Economic Approach*. CMU/SEI-2002-TR-035, Software Engineering Institute, sei.cmu.edu | September 2002, checked YYYY-MM-DD | CBAM steps and case study structure |
| Asundi, J., Kazman, R., Klein, M. *Using Economic Considerations to Choose Among Architecture Design Alternatives*. CMU/SEI-2001-TR-035, sei.cmu.edu | December 2001 | Original CBAM description |
| Software Engineering Institute. *Cost Benefit Analysis Method (CBAM)*, brochure, sei.cmu.edu | February 2018 as listed when written; confirm the date in the SEI digital library | Method overview |
| Bass, L., Clements, P., Kazman, R. *Software Architecture in Practice*, Addison-Wesley | Edition used: [n] | Background reading (inspiration only) |
| Architecture evaluation (ATAM) template (`architecture/atam-evaluation`) | This collection | Source of scenarios |
| [Internal cost model] | [Version] | [Use] |

## Standard and licence note

Based on the Cost Benefit Analysis Method (CBAM) published by the
Software Engineering Institute, Carnegie Mellon University, in
technical reports CMU/SEI-2001-TR-035 and CMU/SEI-2002-TR-035: the
nine steps (collate, refine and prioritise scenarios, assign utility,
develop strategies, determine expected utility, calculate benefit,
choose by ROI, confirm with intuition), response levels, utility
curves, weights and the benefit-to-cost ratio. This template is
original text written for this collection and reproduces no text,
tables or figures from SEI publications or from books on the method;
the worked example is invented and marked *Example*. Check the SEI
digital library for the current versions of the reports before use.
Carnegie Mellon, SEI and ATAM may be trademarks or service marks of
Carnegie Mellon University; this template is not affiliated with or
endorsed by the SEI. Template licence: MIT.