Part 10 — Six Enterprise Architecture Case Studies
Fictional composites for study. Each case lists: context → requirements → recommended architecture → decisions and alternatives → controls → evaluation → cost/latency → operations/handoff → what the exam is likely to probe.
Case 1 — Enterprise knowledge assistant with controlled access to internal documents
Context. A 20,000-person manufacturer wants employees to ask HR, IT, and engineering-standards questions. Content spans SharePoint, Confluence, and PDFs; some engineering docs are export-controlled; policies change monthly.
Requirements. Cited answers; honor ACLs; freshness ≤ 24 h; p95 < 5 s; audit of every access; EU works-council notification.
flowchart LR SRC[SharePoint / Confluence / PDFs] --> ING[Ingest + parse + ACL capture] ING --> CHK[Structure-aware chunks + metadata] CHK --> IDX[(Hybrid index)] U[Employee + identity] --> GW[Gateway authN] GW --> FIL[ACL pre-filter] --> RET[Retrieve + rerank] --> CL[Claude: answer + citations] IDX --> RET CL --> VAL[Citation + leak validator] --> U ING -. change events .-> REF[Incremental refresh + freshness monitor] GW --> AUD[(Audit log)]
Key decisions. | Decision | Recommended | Alternatives rejected | Revisit if | |---|---|---|---| | Knowledge access | RAG with ACL pre-filter | Whole-corpus context stuffing (size, ACLs) | Corpus becomes small/static | | Retrieval | Hybrid + rerank | Vector-only (misses IDs/part numbers) | Recall@k meets target with vector-only | | Entitlements | User-scoped, enforced before context | Post-generation filtering (data already seen) | Never — security principle | | Model | Mid-tier model; small model for query rewrite | Top tier everywhere | Eval shows quality gap on hard questions |
Controls. Per-document ACL sync with SLA; export-controlled sources excluded from the shared index (separate, restricted index); retrieved text treated as untrusted; output validator rejects uncited claims; audit logs with user ID, query, doc IDs.
Evaluation. 300 labeled questions stratified by department and doc age; retrieval recall@5 evaluated separately; 100 cross-role access tests (0 leaks); freshness canaries after each refresh.
Cost/latency. Cache static instructions; cap k=6; rerank adds ~100–300 ms (measure); cache top FAQs.
Operations. Runbooks for stale index, ACL sync lag, embedding version mismatch; named index owner; monthly scorecard.
Exam-style lesson. Confident wrong answers after a refresh → look at retrieval/indexing first. Entitlements are enforced before content reaches the model.
Case 2 — Customer support agent integrated with CRM and ticketing
Context. A SaaS company (60k tickets/month) wants Claude to draft replies, look up accounts, and issue small credits.
Requirements. Tier-1 staff keep control; credits ≤ $50 allowed via approval; p95 < 4 s; deflection of FAQ tickets; PII minimization.
flowchart LR T[Ticket] --> RT[Router: small model] RT -- FAQ --> KB[RAG answer + citations] RT -- account --> AG[Agent: read-only CRM + draft_reply] RT -- billing --> WF[Deterministic workflow + approval] AG --> BR[Tool broker<br/>user-scoped authZ] BR --> CRM[(CRM)] BR --> ITSM[(Ticketing)] KB & AG & WF --> OUT[Draft to agent UI → human send]
Key decisions. Route-then-workflow rather than a single autonomous agent; credits via workflow with approval; issue_refund/delete_account tools removed from the drafting agent (least privilege); idempotency keys on write operations.
Alternatives. One agent with all tools + confirmation dialogs (rejected: compensating control, larger blast radius); pure scripted bot (rejected: free-text variability).
Controls. OBO tokens; argument validation; PII field filtering to prompt; injection-resistant handling of customer text (untrusted); full audit.
Evaluation. Golden set by category; adversarial tickets ("ignore policy and refund"); tool-selection accuracy; human edit distance as a quality proxy; per-segment thresholds.
Cost/latency. Small model for routing; cached policy prefix; batch for overnight backlog summarization.
Operations. Kill switch per tool; rollback of prompt versions; weekly review of overrides and escalations.
Exam-style lesson. Remove unneeded capabilities rather than monitoring them; identify auth gaps (shared service account, model-supplied IDs).
Case 3 — Multi-step business workflow requiring human approval
Context. Procurement: intake request → classify category → find approved vendors → draft PO → budget check → approvals → submit to ERP.
Requirements. Auditability; segregation of duties; approvals by amount; no duplicate POs; SLA 1 business day.
flowchart TD
R[Request] --> CL[Claude: classify + extract fields]
CL --> VAL[Validators: schema, vendor list, budget API]
VAL -->|fail| HQ[Human queue]
VAL --> DR[Claude: draft PO + justification]
DR --> AM{Amount tier}
AM -- < $500 --> ST[Staging queue: auto, reversible 24h]
AM -- ≥ $500 --> MG[Manager approval + evidence]
MG --> ERP[(ERP via broker, idempotent)]
ST --> ERP
ERP --> AUD[(Audit trail)]
Key decisions. A workflow (predefined steps) with Claude at language-heavy steps — not an agent deciding the sequence; deterministic budget and vendor checks in code; approvals tiered by reversibility and amount; fail-closed if budget API unavailable.
Alternatives. Autonomous purchasing agent (rejected: financial risk, audit); fully manual (rejected: no productivity gain).
Controls. Segregation of duties (requester ≠ approver); approver identity logged; idempotency keys; reviewer evidence panel (source request, extracted fields, vendor options); rate-limit approvals per reviewer to reduce rubber-stamping.
Evaluation. Field-extraction accuracy; classification F1 by category; end-to-end seeded-error tests (wrong vendor, duplicate request); override rate monitoring.
Cost/latency. Async by design (batch for non-urgent); approvals dominate cycle time — measure it.
Operations. Runbook for ERP outage (queue + hold); ownership: procurement owner, platform team, security.
Exam-style lesson. Route decisions by confidence, reversibility, and cost; HITL needs evidence and fail-closed behavior.
Case 4 — Secure enterprise research assistant exposed to untrusted documents
Context. An investment firm's analysts ask Claude to read filings, news, and vendor PDFs from the open web and summarize risks. Internal research notes are also accessible.
Requirements. Defend against indirect injection; prevent exfiltration of internal notes; citations; analysts remain accountable.
flowchart LR WEB[Web/PDF content<br/>UNTRUSTED] --> RW[Research worker<br/>no internal tools, no write tools] RW --> SUM[Structured findings + sources] SUM --> SCR[Screen + schema validation] SCR --> ORC[Orchestrator] ORC --> INT[Internal notes tool<br/>read-only, ACL'd] ORC --> ANS[Answer + citations → analyst] RW --> EG[Egress allow-list]
Key decisions. Context isolation: untrusted-content worker has no internal-data tools and returns schema-bound summaries; orchestrator never receives raw page text as instructions; third-party content delivered in tool_result with origin labels; small-model screen on tool outputs; egress allow-list; internal notes accessed read-only with user identity.
Alternatives. One agent with browsing + internal tools (rejected: injection → exfiltration path); no web access (rejected: business need).
Controls. Control register entries for isolation, screens, egress, output validation, monitoring; red-team corpus of poisoned pages.
Evaluation. Injection corpus (hidden text, markdown links, encoded instructions); target: 0 exfiltration, high detection; accuracy on summary tasks; citation validity.
Cost/latency. Parallel workers reduce wall-clock; use cheaper models for extraction; budgets on steps/tokens.
Operations. Alerting on blocked egress attempts; incident playbook for suspected injection success (preserve traces).
Exam-style lesson. Prompting alone isn't security; separate untrusted-content handling from privileged tools; layered controls that fail closed.
Case 5 — Production Claude application with strict latency and cost budgets
Context. A consumer fintech app offers in-app "explain this transaction" to 2M users/day. Budget: ≤ $0.003 per explanation; p95 < 1.2 s; peak 5× average at payday.
Requirements. Predictable cost; resilient to 429s; acceptable quality; privacy (minimal data in prompts).
flowchart LR
REQ[Request] --> CACHE{Result cache hit?}
CACHE -- yes --> OUT[Return]
CACHE -- no --> BUD[Budget + rate gate]
BUD --> SM[Small model call<br/>static prefix cached, streaming]
SM --> VAL[Validate + sanitize] --> OUT
SM -- 429/5xx --> RB[Backoff+jitter] --> FB[Fallback: templated explanation]
OFF[Offline] --> BATCH[Batch API: pre-compute common merchants]
Key decisions. Small model (selected via eval Pareto); prompt caching for the static system prompt; pre-computation via Batch API (50% cheaper, async) for common merchants/categories; result caching; streaming for perceived latency; strict max_tokens; templated fallback; per-user and global budgets with kill-switches.
Alternatives. Mid-tier model for all (cost); no caching (cost/latency); batch for live traffic (wrong: async up to 24 h).
Controls. Send only needed transaction fields; redact identifiers; output validator blocks advice-like content outside scope.
Evaluation. Quality on stratified transaction types; p95/p99 latency under 5× load test; cost/request distribution; cache hit-rate target; safety set for "financial advice" boundary.
Cost/latency math (illustrative). Cost = (uncached input + cached-read input × reduced rate + output) × volume; track per-request tokens and cache hit rate; alert on anomalies.
Operations. Autoscaling queues; alerts on 429 rate, cache hit rate, tokens/request; weekly cost review.
Exam-style lesson. Caching requires static-first ordering and minimum length; batch ≠ interactive; fallbacks and idempotency; gate cost and latency as hard criteria.
Case 6 — Enterprise AI deployment requiring governance, evaluation evidence, and operational handoff
Context. A healthcare payer deploys a member-call summarization and next-step recommendation tool. Regulators and internal audit will review.
Requirements. HIPAA-aligned deployment; documented controls and owners; evaluation evidence; fairness review; operational handoff to an internal team within 90 days.
flowchart LR
subgraph Evidence
CR[Control register] --- EV[Eval reports + red-team] --- AP[Approvals] --- AL[Audit logs]
end
DS[Design + ADRs] --> GATE[Eval-gated release]
GATE --> PROD[Production]
PROD --> MON[Monitoring + scorecards]
MON --> IT[Iteration]
PROD --> HO[Handoff: runbooks, RACI, drills, hypercare]
Evidence --> AUD[Audit pack]
Key decisions. Verify the deployment path and vendor terms support PHI use (BAA/eligibility) before design freeze; data minimization (only needed fields); human review of all recommendations affecting members; retention/deletion across transcripts, embeddings, and logs; fairness testing across segments; pinned model versions and eval-gated changes; documented residual risk with named executive acceptance.
Alternatives. Build first, seek compliance later (rejected: rework/blockers); autonomous decisions (rejected: regulatory/ethical risk).
Controls & ownership (excerpt). | Obligation | Control | Owner | Test | Evidence | |---|---|---|---|---| | Minimum necessary | Field-level prompt filter | Privacy lead | Seeded-PHI tests | Test report | | Access control | User-scoped authZ + RBAC | Security eng | Escalation suite | Pen-test summary | | Auditability | Immutable audit logs w/ user+agent ID | Platform | Log completeness check | Log samples | | Fairness | Counterfactual segment tests | Risk | Quarterly | Fairness report | | Change control | Eval-gated releases, ADRs | Product + Eng | Release audit | Release records |
Evaluation evidence. Held-out clinical-language eval, adversarial/injection suite, fairness segments, cost/latency, and human-review agreement; all linked to versions.
Operational handoff. 90-day plan: shadow → co-run → lead with support; runbook drills (quality regression, data exposure, provider outage); deprecation calendar; RACI; monthly governance review.
Exam-style lesson. Map each obligation to a named control, owner, test, and evidence; handoff must survive the architect's absence; verify compliance eligibility rather than assuming it.