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.
Document control
| 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
1. Executive summary
[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
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
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
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
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
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] |
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
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
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.
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
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
10.1 ROI ranking
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
- Remove strategies with negative total benefit.
- Fund mandatory strategies first and deduct their cost.
- Rank the remaining strategies by ROI, highest first.
- Walk down the list. Fund a strategy if it fits the remaining budget
and schedule and does not conflict with one already funded.
- When a strategy does not fit, check whether a cheaper one further
down fits the remainder before stopping.
- Record every skipped strategy with its reason.
11. Step 9: Confirm results with intuition
| 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
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
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
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.