PPassTheCertExam

Study guides / CCAR-P / Domain 2

Solution Design & Architecture · Lesson 6 of 6

2.6 - Aligning a Design to Business-Value Pillars and SLAs

Map design choices to efficiency, productivity, cost, transformation and performance/SLA targets, pick a primary pillar per use case, and state each trade-off in measurable terms.

Architecture is only persuasive when it is tied to a claim a sponsor can hold you to. The task statement names five value pillars: efficiency, transformation, productivity, cost and performance SLAs. Every design choice in this domain, from pattern (lesson 2.3) to fan-out (lesson 2.4) to step boundaries (lesson 2.5), moves at least one of them and usually trades against another. The skill tested is to name the pillar a choice serves, say what it costs on the others, and express both as measurable targets. Success-criteria mechanics are in lesson 2.1, metrics in 3.1, cost tuning in 3.5, and SLA conversations with stakeholders in 5.3.

The pillars as design targets

The definitions below are working definitions for this guide; adapt the wording to your organisation but keep each pillar's metric distinct.

PillarWhat it meansTypical metricsDesign levers
EfficiencyThe same outcome with less time, effort or waste in a processCycle time, throughput, touch rate (share of cases needing a human)Workflow automation of known steps, parallel sections, batching non-urgent work, fewer handoffs
ProductivityMore or better output per person (augmentation)Tasks per person-hour, draft acceptance rate, edit effort, time to first draftAssistive patterns, review UX, context integration; count review time honestly (lesson 7.2)
CostLower total cost per outcomeCost per completed task including human review and reworkCaching, batching, model tier and effort, routing, output length, avoiding unjustified multi-agent
TransformationA capability, product or operating model that was not feasible beforeLeading indicators against a stated hypothesis: adoption, new-use volume, experiment outcomesStaged pilots with explicit hypotheses and kill criteria; accept higher uncertainty
Performance and SLAsMeeting latency, throughput, availability and quality targetsp95 end-to-end latency, time to first token, error rate, availability, quality SLOStreaming, model and effort choice, caching, timeouts, fallbacks, bounded loops, capacity planning

Two conflations cause wrong answers. Efficiency is not productivity: the first is about a process, the second about the people using it, and they can move in opposite directions (a faster pipeline whose output needs heavy human editing). And transformation does not obey the same ROI arithmetic as efficiency: judging a new-capability bet by short-term handle-time savings will kill it, so run it as staged options with leading indicators.

Make each pillar measurable

Use a value hypothesis for each pillar you claim: for [user] doing [task], this design moves [metric] from [baseline] to [target], measured by [method] over [period], while [guardrail metric] does not degrade. The guardrail is what keeps a win on one pillar from hiding a loss on another. Anthropic's guidance on success criteria makes the same point: most use cases need multidimensional criteria, and latency and price are named alongside task fidelity.

For cost, measure per completed task, not per token. Anthropic's cost guidance says to compare on cost per completed task, and gives an example where a higher-capability model at lower effort was cheaper per solved task than a cheaper-per-token tier because it failed less. The documented levers each carry a trade-off you must name:

Common exam distractor

Three tempting answers: cut cost with the Batch API when the requirement is an interactive latency target; choose the cheapest per-token model without measuring cost per completed task, including reviewer time and rework; and optimise every pillar at once. A defensible design names a primary pillar, treats the others as constraints with thresholds, and shows the trade-off explicitly. Also watch for measuring productivity by usage volume or tokens processed, which shows activity rather than value.

Performance targets and SLAs

Keep three terms apart: an SLI is a measurement (for example p95 latency), an SLO is your internal target for it, and an SLA is an external commitment with consequences. Your SLA can only be as strong as what you control and can verify. On the platform side, Anthropic's service-tiers documentation describes the standard tier as the default with best-effort availability, and Batch as a tier for asynchronous work. It describes Priority Tier as prioritised capacity with an uptime target, but notes that new Priority Tier capacity commitments are no longer available for purchase and directs guaranteed-capacity needs to sales. So do not promise customers an availability figure that assumes capacity you have not secured; check the current service-tiers page and your contract, and if you deploy through a cloud provider, that provider's terms.

Design for the tail, not the average. Latency is driven by input size, output length, model and effort, every tool round trip, retrieval, validation-and-repair loops and retries, so a p95 target must be met by bounding each of these:

Key concept: one primary pillar, the rest as constraints

For each use case, choose the pillar that justifies the investment and write the others as thresholds the design must not breach. Then state each trade-off in a fixed form: we accept [cost, latency or complexity] to gain [benefit], because [pillar priority], measured by [metric], and we will revisit if [trigger]. A design that cannot be written in that form has an unexamined trade-off.

Worked example: call summaries within a latency SLA

A contact-centre tool must show a summary within a few seconds of a call ending at p95. Each request carries a long, unchanging policy and instruction block plus the transcript. The primary pillar is performance, with a quality threshold and a cost guardrail. Chosen design: cache the stable prefix (lower latency and cost on reuse within the lifetime), stream the output, pick model tier and effort by eval against the quality rubric, set a timeout with a templated fallback summary, and report p95 rather than the mean. Rejected, with reasons: batching (violates the latency target), a multi-agent split (token multiple and coordination latency for a single-step task) and the highest-capability model by default (only justified if the eval shows the rubric cannot be met otherwise, and it costs latency and money).

Exam traps

Practice question

A contact-centre product must display a summary to the agent within 3 seconds of the call ending (95th percentile). Each request contains a large, unchanging policy and instruction block plus the call transcript. Volume is steady all day. Summaries must meet a quality rubric; cost matters but is secondary to the latency target. Which design best aligns with these priorities?

  • A Send all summaries through the Message Batches API to obtain the 50% cost reduction on every request, since volume is steady all day

    Batch results are asynchronous, typically within an hour and up to 24 hours, which breaks a 3-second target. It optimises the secondary pillar at the expense of the primary one.

  • B Split summarisation across several parallel agents, each summarising part of the transcript, with a coordinator merging the results to cut wall-clock time

    A single-step summary gains little from parallel agents, while the token multiple, coordination and aggregation add cost and latency and create new failure modes.

  • C Always use the highest-capability model available, because quality is the first requirement and cost is secondary to getting the summaries right

    Latency is the primary constraint, and the rubric is what defines quality. The model tier should be chosen by evaluation against both, not assumed; the most capable option may exceed the latency budget.

  • D Cache the stable policy prefix, stream the response, select model tier and effort by eval against the quality rubric, and add a timeout with a templated fallback; track p95 Correct

    Caching cuts processing time and cost on the repeated prefix, streaming improves perceived latency, eval-driven tier and effort choices meet the rubric without over-spending, and the timeout fallback protects the tail.

Build exercise: Trace value to design and measure the trade-offs

Intermediate · 90 minutes

You'll practice:

  1. Pick a use case (for example the call-summary feature). Choose one primary pillar and write the other four as constraints with numeric thresholds you would defend.

    A design cannot maximise every pillar. Naming the primary and constraining the rest is the core judgement this task statement tests.

    You should see: A table with five rows: the primary pillar marked, and each other pillar with a threshold, such as p95 latency under [n] seconds or cost per summary at or below [x].

    Hints 
    1. If two pillars conflict, which one would the sponsor sacrifice last?
    2. Ask the sponsor which failure is worse: slow, expensive or poor quality, and rank the pillars accordingly.
    3. Example: primary is performance (p95 under [n] s). Constraints: quality rubric average at or above [target]; cost per summary at or below baseline; productivity measured as agent edit rate under [x]%; transformation not claimed for this release.

  2. Write a value hypothesis for each pillar you claim, in the form: for user, task, metric moves from baseline to target, measured how, guardrail metric.

    The guardrail stops a win on one pillar from hiding a loss on another, and the baseline makes the claim falsifiable.

    You should see: Two to four hypotheses, each with all five parts filled and no adjective standing in for a number.

    Hints 
    1. Which existing metric could you get a baseline for this week?
    2. Prefer metrics the business already tracks (handle time, reopen rate) and add a guardrail that the improvement could plausibly damage.
    3. Example: For contact-centre agents writing call notes, the summary feature moves after-call work time from [baseline] to [target], measured from the telephony system over four weeks, while reopened-ticket rate does not increase.

  3. Build a measurement harness that runs 20 summarisation calls twice, once without and once with a cache breakpoint on a long system prompt, recording latency, input and output tokens and cache tokens for each call.

    Trade-offs need evidence. This gives you latency percentiles and token accounting for a lever whose benefit depends on reuse and prefix length.

    You should see: Two result sets. In the cached run, calls after the first should show non-zero cache_read_input_tokens, provided the prefix meets your model's minimum cacheable length (shorter prompts are silently not cached).

    Hints 
    1. How will you know whether the cache was actually used?
    2. Read usage.cache_read_input_tokens and usage.cache_creation_input_tokens from each response and time each call.
    3. import time, anthropic
client = anthropic.Anthropic()
MODEL = 'claude-sonnet-5'  # check the models overview page for current IDs
POLICY = open('policy.txt').read()  # make it long enough for your model's minimum cacheable length
def call(transcript, cached):
    block = {'type': 'text', 'text': POLICY}
    if cached:
        block['cache_control'] = {'type': 'ephemeral'}
    t0 = time.time()
    r = client.messages.create(model=MODEL, max_tokens=300, system=[block], messages=[{'role': 'user', 'content': 'Summarise this call:\n' + transcript}])
    u = r.usage
    return {'s': time.time() - t0, 'in': u.input_tokens, 'out': u.output_tokens, 'cache_read': u.cache_read_input_tokens, 'cache_write': u.cache_creation_input_tokens}

  4. Compute p50 and p95 latency and an estimated cost per call for both runs. Fill in the price per million tokens from the current models page, and use the documented cache multipliers for reads and writes.

    Percentiles, not means, drive SLAs, and cost per call must include cache-read and cache-write pricing to be honest.

    You should see: A comparison table of p50, p95 and cost per call, with a note on the sample size and the fact that 20 calls is a coarse estimate of p95.

    Hints 
    1. Why might the first cached call cost more than an uncached one?
    2. Sort the latencies and index into the list for percentiles; cost = base-priced input + cache reads at the read multiplier + cache writes at the write multiplier + output at the output price.
    3. PRICE_IN, PRICE_OUT = 0.0, 0.0  # per million tokens, copy from the current models page
def cost(r):
    return (r['in'] * PRICE_IN + r['cache_read'] * PRICE_IN * 0.1 + r['cache_write'] * PRICE_IN * 1.25 + r['out'] * PRICE_OUT) / 1e6  # multipliers per the prompt caching docs (5-minute lifetime); verify
lat = sorted(x['s'] for x in results)
p50, p95 = lat[len(lat) // 2], lat[int(0.95 * len(lat)) - 1]

  5. Write the SLI, SLO and SLA proposal: which SLIs you will measure, the internal SLO, what you would commit externally and why, and the degraded modes for timeout, rate limiting and a persistent 429.

    This separates what you measure, what you aim for and what you promise. The external commitment must rest on controls and contracts you can verify.

    You should see: A short table: SLI, SLO, external commitment (deliberately weaker than the SLO), fallback per failure type, and the alert that triggers a human.

    Hints 
    1. What could go wrong that is outside your control, and what will the user see when it does?
    2. Set the external commitment below the internal SLO, define a fallback for transient overload versus a persistent spend-cap failure, and note that you must confirm capacity terms with your provider.
    3. Example: SLI p95 end-to-end latency. SLO under [n] s. SLA commitment [weaker] on a monthly basis. Timeout at [t] s returns a templated summary. Transient 529: SDK backoff then queue. Persistent 429 without retry-after: alert, switch to manual note entry, do not retry.

  6. Write two trade-off statements in the fixed form (we accept X to gain Y because pillar Z, measured by M, revisit if T), including one option you rejected and why.

    A recorded, revisitable trade-off is what stakeholders can audit later. It also shows you compared options rather than defaulting to one.

    You should see: Two statements that each name a cost, a benefit, a metric and a revisit trigger, one of which rejects batching or multi-agent with a reason tied to your measurements.

    Hints 
    1. What number in your measurements supports each statement?
    2. Reuse your harness results as the evidence and name a concrete trigger such as a change in volume, prompt length or quality score.
    3. Example: We accept a cached prefix whose write costs [x] times a normal input in exchange for lower p95 on repeated calls, because performance is the primary pillar, measured by p95 in the harness, and will revisit if traffic drops below one call per cache lifetime. We reject batching because results are asynchronous and cannot meet the latency target.

Sources