Claude Certified Engineers logoCCE

CCAR-P · Study Guide

← Domain 1: Solution Design & Architecture

1.6 · Lesson 6 of 6

Align solutions to business value pillars (efficiency, transformation, productivity, cost, performance SLAs)

What You Need to Know

Business value pillars — efficiency, transformation, productivity, cost, and performance SLAs — are how architects justify Claude solutions to stakeholders. Every material choice (model tier, toolkit size, caching, human gates, multi-agent) should name the pillar it serves and how you will measure it. When pillars conflict, document the priority order and the rejected alternative instead of pretending all five improve forever.

Trade latency and cost against accuracy explicitly against an agreed floor. SLAs belong in the architecture decision — model selection, timeouts, capacity — not only in ops runbooks. Do not call low-volume automation "transformation" when the real win is efficiency or productivity. Mislabeling pillars is an exam distractor as common as ignoring cost.

The five pillars

  • Efficiency — same outcomes with less waste (time, tokens, steps)
  • Transformation — operating-model change at meaningful scope, not a small script
  • Productivity — humans complete more valuable work per unit time
  • Cost — unit economics stakeholders accepted ($/task, infra, review load)
  • Performance SLAs — latency, availability, and related budgets in the design

Decision rules

  • State which pillar each design choice serves and how you will measure it.
  • Trade latency and cost against accuracy explicitly against an agreed floor.
  • Put SLAs in architecture decisions, not only in runbooks.
  • Do not label incremental automation as transformation without matching scope.
  • When pillars conflict, document priority order and the rejected alternative.

Why pillar language matters on the exam

Stems often set cost and hard p95 above marginal accuracy. The keyed answer picks the smaller/faster model that still clears the accuracy floor and records the trade-off. Distractors chase maximum accuracy, drop monitoring to "save money," or rebrand efficiency as transformation.

Review checklist

  • Can you name the top pillar in one stakeholder sentence?
  • Is there an accuracy (or quality) floor written down?
  • Are p95 / cost KPIs attached to model and caching choices?
  • Did you reject a tempting larger-model or broader-toolkit option in writing?
  • Would removing monitoring break your ability to prove the SLA pillar?

Prefer answers that name the pillar, the metric, and the trade-off. Vague quality maximalism without cost or SLA context usually fails.

Exam application

Cost + hard p95 with accuracy already at floor → smaller/faster model. Reject always-largest, ignore-SLA, mislabeled transformation, and cut-monitoring-to-save-cost distractors.

Exam traps

  • Always choosing the largest model

    Largest is not a pillar. When cost and latency dominate above an accuracy floor, a smaller model can be the aligned choice.

  • Ignoring SLAs until runbooks

    Performance SLAs belong in architecture decisions — model tier, caching, and timeouts — not only in ops after launch.

  • Mislabeling efficiency as transformation

    Low-volume automation that saves minutes is efficiency or productivity. Transformation requires matching scope and change to the operating model.

  • Dropping monitoring to save cost

    Cutting observability to shave spend undermines SLA proof and usually fails exam items that pair cost with performance pillars.

Practice scenario

Leadership prioritizes cost control and a hard p95 latency SLA for a customer-facing assistant. A larger model would add only marginal accuracy above an already agreed floor. Which architecture choice best aligns to the stated pillars?

Choose one answer

Build exercise

Map a support-copilot design to pillars with KPIs

35 minutes

What you'll learn

  • Name and prioritize business value pillars
  • Attach KPIs to each design choice
  • Trade cost/latency against an accuracy floor
  • Document one rejected trade-off and keep SLAs in architecture

  1. Step 1

    Name pillars for the support-copilot initiative

    List which of efficiency, transformation, productivity, cost, and performance SLAs this design must serve. Rank them when they conflict.

    Why: Exam answers that name the pillar and the trade-off beat vague "better AI" claims.

    You should see: A priority-ordered pillar list with one sentence of stakeholder wording each.

  2. Step 2

    Map each design choice to a pillar and a KPI

    For model tier, tool scope, caching, and HITL gates, state the pillar served and a measurable KPI (p95 ms, $/resolution, handle-time delta, accuracy floor).

    Why: Unmeasured pillars are slogans. Architects attach numbers stakeholders accepted.

    You should see: A table: choice → pillar → KPI → owner.

  3. Step 3

    Trade latency/cost against accuracy explicitly

    Record the accuracy floor. If a smaller/faster model clears it, prefer that when cost and SLA lead. Do not quietly optimize accuracy past the agreed floor at SLA expense.

    Why: Professional stems reward explicit floors and rejected larger-model options.

    You should see: A written accuracy floor, measured candidate models, and the selected tier with rationale.

  4. Step 4

    Document one rejected trade-off and keep SLAs in the architecture

    Capture the option you did not take (e.g., largest model) and why. Encode timeouts, budgets, and monitoring as design requirements — not afterthoughts.

    Why: Pillar conflicts without a rejected alternative are incomplete ADRs. SLAs outside architecture are theater.

    You should see: A short ADR snippet plus latency/cost monitors tied to the chosen design.

Sources