CCA-P Domain 4: Stakeholder Engagement, Lifecycle & GTM

Domain 4 of the Claude Certified Architect – Professional exam. Covers structured discovery, presenting tradeoffs and running demos, building feedback loops and SLAs, documentation for handoff and audit, and entry-point selection with outcome measurement — the full discovery → design → handoff → monitoring → iteration lifecycle.

TL;DR

• Discovery is a structured elicitation, not a conversation — stakeholders speak in preferences (“seamless,” “fast,” “simple”), and the architect’s job is translating each preference into a testable, bounded constraint via listen → translate → write down.
• Four questions turn discovery into requirements: what must the system do (capabilities as outcomes), not do (boundaries — stakeholders rarely volunteer these), cost (budget in the stakeholder’s terms), and prove (evidence/proof obligations — far cheaper to surface in discovery than during legal review).
• A requirement traces to something the stakeholder actually said; an assumption is something the design takes for granted that was never stated — an unsourced assumption is the most dangerous kind because nobody remembers deciding it.
• Every tradeoff presentation names three elements (four when regulated): what we gain, what we give up, and the reversal cost — the element most people skip, and the one that most often turns a technical discussion into the right business decision.
• A scenario-specific demo (answers “what does this do with MY problem”) creates confidence; a capabilities demo (answers “what can this do”) only creates interest. Name 1-2 limitations upfront as intentional scope boundaries — a buyer who discovers one mid-demo loses confidence.
• A feedback loop is the decision layer above observability: signals → triage → decide → act → review. Monitoring collects signals; a feedback loop decides which ones matter, to whom, and what happens next. Regulated checkpoints (periodic output audits, residency confirmations) must run on a schedule regardless of whether metrics look fine.
• Documentation passes the completeness test when a competent architect who wasn’t in the room can make a safe change after reading it — which means recording the decision, the rejected alternatives, the tradeoff resolved, the owner, and the evidence artifact, not just the final architecture diagram.
• An outcome document needs six fields (use case with scope boundary, metric before, metric after, control in place, measurement owner, reuse potential) — technical metrics like latency and error rate tell a sponsor the system runs, not what it’s worth to the business.

Core Concepts

Discovery — Structured Elicitation

The translation table is discovery’s output: one row per item, capturing the stakeholder statement, the implied constraint, the required architectural decision, and the assumption to confirm. Treat any “it’s just a quick check” or “it’s just a review” statement as a constraint to chase down — in one hospital-network case, “clinicians will review the output anyway” turned out to be a mandatory licensed-clinician authorization gate, not a convenience feature.

Tradeoffs, Demos, and GTM

Three technical objection categories in a sales cycle: capability (“can it do this at all?” → demonstrate), governance/compliance (“can it be trusted and evidenced?” → show controls and artifacts), design-choice (“why this instead of that?” → explain the tradeoff and what the alternative would have cost). Four demo design decisions: scenario selection (a workflow the buyer recognizes), limit placement (name 1-2 limitations early), sales-team collaboration (shape the narrative together before building), and data preparation (structure/volume resembling the buyer’s own, anonymized if regulated).

Feedback Loops, SLAs, and Governance

An SLA names three things: what’s being measured, what counts as a breach, and what happens on breach — thresholds must trace to a real source (latency → UX expectation, availability → business criticality, quality → eval results); an untraceable number is probably arbitrary. Cost is the expectation that breaks most often, since production volume routinely runs 1-2 orders of magnitude above pilot — pre-empt it with a production-volume consumption forecast and a named spend-control posture before the first invoice. A governance table (signal type → review trigger → architect action → regulated checkpoint) must exist before launch; regulated deployments need scheduled reviews (periodic output audits, residency confirmations) that fire on a calendar, independent of whether any metric has crossed a threshold.

Documentation for Handoff and Audit

Completeness test: can a competent architect who wasn’t in the room make a safe change after reading this document? If no, it’s incomplete. A design without its rejected alternatives can’t be understood by a successor — they’ll reverse the right decision for the wrong reason, or defend the wrong one because they can’t tell which tradeoff it resolved. Assumptions must be explicitly labeled as assumptions, not embedded as facts, with an owner and resolution criteria.

Entry Point Selection and Outcomes

Cross-platform deployments expose problems a single entry point never shows: model identifier strings differ across routes, feature availability lags on CSP-mediated routes, and regional availability requires explicit configuration — defaulting to a global endpoint is the common pattern that silently breaks a data-residency requirement. An entry-point-responsibility map, written before integration begins, prevents the most common multi-entry-point failure: an entry point chosen for one task gradually absorbing another because routing logic was never documented.

The deployment lifecycle runs discovery → design → handoff → monitoring → iteration; identifying which phase a decision belongs to is what lets you judge when one phase is ready to move to the next.

Common Pitfalls

• Pitfall: Proposing a solution sketch immediately after hearing a stakeholder’s first statement. Why: plausibility is what makes this dangerous — a stakeholder who sees a confident architecture assumes the hard questions were already answered, and constraints (authorization gates, retention rules) surface weeks later during compliance review instead. Fix: finish the four-category question set (do, not-do, cost, prove) before proposing anything.
• Pitfall: Presenting a tradeoff without naming the reversal cost. Why: a stakeholder who approves a per-call cost figure is not the same as one who approved the resulting monthly bill or the cost of undoing the decision later — the gap surfaces at the first invoice, not in the room. Fix: name gain, give-up, and reversal cost every time, especially when a design feels obviously simpler.
• Pitfall: Treating a healthy dashboard as proof the feedback loop is working. Why: monitoring collects signals, but a slow quality drift that never crosses a hard error-rate threshold stays invisible until someone notices manually. Fix: build a governance table that maps signals — including gradual drifts — to triggers, owners, and actions, not just threshold alerts.
• Pitfall: Shipping an architecture diagram without the rejected alternatives. Why: a successor inherits WHAT was built but not WHY, and a later “obvious” fix can reverse a load-bearing decision (like a residency-driven context strategy) for a reasonable but wrong cause. Fix: record each decision, the alternatives rejected, and the tradeoff resolved while the reasoning is still fresh.
• Pitfall: Writing an outcome document from easy-to-export technical metrics. Why: request volume, average latency, and error rate tell a sponsor the system runs — they don’t tell a CFO what it’s worth, and the expansion case fails when a business-metric before/after was never captured. Fix: capture a business-unit baseline before deployment and the same metric after, plus an auditable control and a reuse note.

Interview Questions

Q — Why is “listen → translate → write down” described as a filter rather than a conversation, and what’s the cost of skipping the filter? A conversation produces impressions that fade or get reinterpreted; a filter produces a written record of requirements, assumptions, and unresolved constraints before the discussion moves on. Skipping it means the design inherits the architect’s assumptions instead of the stakeholder’s actual constraints, and the gap typically surfaces during the most expensive moment to fix it — a legal or compliance review after the system is already built.

Q — What’s the difference between a capabilities demo and a scenario-specific demo, and why can a weak demo actively undo trust discovery already built? A capabilities demo shows generic, polished functionality and answers “what can this do” — it creates interest. A scenario-specific demo uses the buyer’s own workflow shape and data volume to answer “what does this do with my problem” — it creates confidence. A capabilities-only demo after strong discovery can make the buyer question whether the team actually understood their problem, undoing credibility that discovery had already established.

Q — Why does the architect need a governance table before launch, not after the first incident? A governance table maps each production signal (output quality, latency, cost, data-residency config) to a review trigger, an owner, and an action — including regulated checkpoints that must fire on a schedule regardless of metric state. Building it after an incident means the drift that should have triggered a review already ran unnoticed for weeks; building it before launch turns policy into an operating routine instead of a reactive scramble.

Q — In the regional healthcare cumulative exercise, why does the outcome document’s “control in place” field matter as much as the before/after metric itself? The before/after metric (e.g., average time from dictation to clinician-authorized note) shows the deployment moved a number, but without an auditable control — like a timestamped clinician-authorization log tying clinician, note, and interaction together — the comparison is merely asserted, not provable. A CFO or compliance reviewer needs evidence the before/after wasn’t just measured differently or selectively; the control is what makes the comparison stand up to scrutiny.