Aligning Architecture Decisions to Business Value Pillars
AdvancedAlign architectural decisions to business value pillars · Difficulty 3/5
Explanation
An architect justifies the design in the language of the business. Anthropic frames value across pillars the design should map to.
The Five Value Pillars
| Value pillar | What the design optimizes for |
|---|---|
| Efficiency | Automating manual work; reducing handle time |
| Transformation | Enabling capabilities that weren't feasible before |
| Productivity | Amplifying what a person or team can do |
| Cost | Meeting the outcome within a budget (model tier, caching, batching) |
| Performance / SLAs | Meeting latency and reliability commitments |
Every Tradeoff Should Be Traceable to a Pillar
"Use a smaller model with prompt caching" is a *cost and performance* decision; "add a Human-in-the-Loop review" is a *risk and quality* decision. Being able to state which pillar a decision serves is exactly what Domain 6 (stakeholder communication) then asks you to articulate. If you cannot name the pillar a proposed change serves, that change is not yet justified.
Common Exam Trap
> Trap: Optimizing a metric the business didn't ask for (e.g., squeezing latency the SLA doesn't require) at the expense of one it did (cost, quality). Anchor every tradeoff on the stated business value.
A classic version of this trap: a scenario states the job is high-volume and latency-tolerant, but asks to cut cost. The tempting wrong answer swaps in the largest, most capable model "for reliability" -- which optimizes a performance dimension nobody asked to improve, at the direct expense of the cost goal that was actually stated. The correct move is to route the job to a smaller model tier and/or batch it, directly serving the cost pillar the business named.
Applying the Pillars
- Identify which pillar (or pillars) the stakeholder's stated goal maps to.
- Propose the architectural lever that most directly serves that pillar (model tier and batching for cost; caching and async processing for performance; human review for quality/risk; new workflows or agents for transformation/productivity).
- Resist adding levers that serve a *different* pillar than the one requested, even if they seem like general improvements.
Key Takeaways
- Five business value pillars: efficiency, transformation, productivity, cost, performance/SLAs
- Every architectural tradeoff should be traceable to one of the five pillars
- "Smaller model + prompt caching" serves cost/performance; "human-in-the-loop review" serves risk/quality
- Trap: optimizing an unrequested metric (e.g., latency) at the expense of a requested one (e.g., cost) is wrong even if it looks like an improvement
- For a high-volume, latency-tolerant job where the goal is cost, the right move is a smaller model tier and/or batching -- not the largest model
Glossary Terms
A design pattern that interrupts the agentic loop at defined checkpoints to request human review or approval before proceeding. Used for high-stakes decisions, irreversible actions, or cases where confidence is below threshold. Balances automation with oversight.
A Claude API feature that caches frequently-used prompt content (system prompts, large documents, tool definitions) to reduce cost and latency on repeated API calls. Cached tokens are billed at a discounted rate. Cache has a TTL that resets on each use. Must be enabled by marking content with cache_control.
The five categories -- efficiency, transformation, productivity, cost, and performance/SLAs -- that an architect maps every architectural tradeoff to when justifying a design decision in the language of the business. A decision the architect cannot trace back to one of these pillars is not yet justified.
Related Concepts