Building the Business Case

An architecture nobody funds does not ship. The professional architect is expected to put numbers to a Claude solution: what it costs to build and run, what it returns, when, and how confident anyone should be. The exam tests whether you can do this honestly, including the costs that enthusiasm tends to omit and the benefits that are easy to claim and hard to measure.

Start from the job and its baseline

A business case rests on a baseline: how the work is done today, what it costs, how long it takes, how often it goes wrong. Measure before you propose. For a document-processing case: documents per month, minutes per document, fully loaded hourly cost, error rate and the cost of an error. For a developer-productivity case: cycle time, review time, defect rates. Without a baseline, every claimed benefit is an assertion.

Decompose the job into tasks and identify which tasks the system will take over, which it will assist, and which stay human. Benefits accrue only to the first two, and differently.

Benefit categories

Category	Typical measure	Caution
Cost reduction	Hours saved multiplied by loaded cost; vendor spend avoided	Hours saved are real only if capacity is redeployed or not hired
Revenue	Conversion, throughput, new offerings	Attribution is hard; use controlled rollouts
Risk reduction	Fewer errors, faster compliance, better audit trails	Quantify with incident cost and frequency
Speed	Cycle time, time to answer, time to market	Translate into cost or revenue where possible
Quality and experience	Satisfaction scores, rework rates	Lead indicators; pair with a lagging financial measure

Be explicit about which benefits are hard (recognised by finance) and which are soft. Lead with the hard ones.

Total cost of ownership

The token bill is usually a minority of the real cost. Enumerate:

• Model usage: tokens by route at expected volume, with caching assumptions stated; tool and server-tool fees; batch versus interactive mix.
• Platform: cloud platform premiums, gateway infrastructure, observability, sandboxes for agents.
• Engineering: build, integration with legacy systems, evaluation suite construction, security review.
• Evaluation and quality: ongoing eval runs, human labelling, grader calibration.
• Oversight: reviewer time for in-the-loop actions; this is often the largest recurring cost and the most often forgotten.
• Governance: privacy assessments, policy review, audits, documentation.
• Change: training, support, process redesign, communication.
• Lifecycle: model migrations, prompt maintenance, deprecation handling, re-evaluation.

Present usage cost as a range with the assumptions visible, and show sensitivity to the two variables that move it most: volume and caching efficiency. A sensitivity table does more for credibility than a precise point estimate.

Unit economics

Express the case per unit of work: cost per processed document, per resolved ticket, per pull request reviewed, compared with the baseline per unit. Include retries, human review and failed tasks in the numerator; the honest unit is cost per completed task. If the per-unit case does not work at realistic quality, no amount of volume will fix it.

Risk adjustment

Discount benefits by the probability the system reaches the quality bar, and show the evidence that informs that probability: prototype eval results, comparable deployments, known limitations. State the risks that could eliminate the benefit: policy or regulatory constraints, data access that may not be granted, legacy integration difficulty, adoption resistance. Give each a mitigation and an owner. A case that admits risk is trusted more than one that does not.

Design the pilot to produce evidence

The pilot is not a demo; it is the experiment that converts the business case from estimate to measurement. Define up front: the metrics (quality against the eval set, cost per task, time saved), the success thresholds, the sample size, the duration, and the decision that follows (scale, iterate, stop). Run it on real data with real users under real governance, so the measurements transfer to production. The pilot-to-production lesson covers execution.

Build, buy or wait

Compare with alternatives honestly: a vendor product with Claude embedded, a non-AI process improvement, or waiting for capability or price changes. Model prices and capabilities have historically moved quickly; a case that is marginal today may be clear in a year, and a case that depends on heavy engineering may be overtaken by a platform feature. Note the option value of waiting and the cost of delay.

Presenting the case

Lead with the decision requested and the headline numbers. Then the baseline, the benefits with their evidence quality, the full cost, the sensitivity, the risks, and the pilot plan with its exit criteria. Keep the architecture in an appendix; the decision makers are buying an outcome. Commit to reporting actuals against the case at defined checkpoints; that commitment is what distinguishes a business case from a pitch.

Exam focus

• Measure the baseline first; benefits are differences from it, not absolute claims.
• Separate hard benefits (cost, revenue) from soft ones and lead with hard.
• Total cost of ownership includes engineering, evaluation, human oversight, governance, change and lifecycle costs, not only tokens.
• Express the case in cost per completed task, including retries and review, against the baseline per unit.
• Show sensitivity to volume and caching efficiency; risk-adjust benefits with stated evidence.
• Design the pilot as the experiment that measures the case, with thresholds and a decision rule defined in advance.