Enterprise Architecture
Executive view
Technical view
Why this matters
Enterprise AI fails in the gap between demo architecture and review architecture. A team can wire OpenAI, a vector database, and a React UI in a week; the same team cannot answer: Which business capability owns policy answers when the model is wrong? Which application is system of record for escalations? Which data classification applies to retrieved chunks in logs? Which identity propagates from IdP to retrieval ACL trim? Which technology standard applies to API gateways and secret stores?
Without EA framing, programmes accumulate shadow platforms—each product team deploys its own Kubernetes cluster, vector store, and observability stack. A global bank discovered 11 separate "GenAI platforms" in one region, combined run cost £4.2M/year, none sharing GPU reservation or identity integration. EA work is how an AI Solution Engineer prevents portfolio entropy while still shipping use cases.
EA is also the language of governance. Architecture review boards do not reject AI because "AI is risky"; they reject designs that lack traceability from use case to component to control. TOGAF-style views (business, application, data, integration, security, technology) give reviewers familiar hooks. ADRs capture decision rationale so the next team does not relitigate residency six months later.
This topic pairs with the Architecture Guide for pattern depth and with topics 15 (build), 16 (cloud), and 24 (integration) for specialised views. EA is the spine; those topics are limbs.
Learn
TOGAF-aligned architecture views for AI solutions
Definition. Architecture views partition complexity so stakeholders see what matters to them. For AI engagements, adapt classical TOGAF domains:
| View | Question it answers | AI-specific content |
|---|---|---|
| Business | Why and for whom? | Capabilities enhanced (servicing, underwriting, engineering productivity); KPIs; human-in-the-loop roles |
| Application | What software interacts? | Agent UI, orchestration API, RAG service, eval service, admin console; C4 containers |
| Data | What moves and is stored? | Corpora, embeddings, feature stores, prompt logs, eval sets; classification |
| Integration | How does it connect? | ERP, CRM, ITSM, IdP, DMS, event bus; sync vs async (topic 24) |
| Security | What must be protected? | Zero trust paths, secrets, model abuse, output filtering, audit |
| Technology | On what is it built? | Hyperscaler services, containers, GPU pools, IaC, observability stack |
Engagement use. Deliver one page per view for HLD pack minimum—not 200 slides. Cross-link views: business capability "Dispute resolution" maps to application container "Case orchestration" maps to data "CRM case notes + policy corpus" maps to integration "Salesforce read, ServiceNow write" maps to security "PII masking + role-based retrieval" maps to technology "Regional Azure OpenAI + private endpoints."
Pitfalls.
- Single DevOps diagram labelled "architecture" with no business traceability.
- Data view omitted because "RAG handles data"—lineage and classification still required.
- Security view as generic boilerplate without AI abuse cases (prompt injection, tool misuse).
- Technology view listing every SaaS the team likes—no reference architecture alignment.
Worked example. HR policy assistant: Business view—capability Employee self-service HR; KPI −25% Tier-1 HR ticket volume. Application—SharePoint connector, RAG API, Teams bot, eval dashboard. Data—gold policy corpus, no employee PII in index. Integration—SharePoint read, ServiceNow create ticket on escalation. Security—Entra ID SSO, retrieval trim by country entity. Technology—approved landing zone subscription, Azure OpenAI EU region, APIM gateway.
Business capability maps and heatmaps
Definition. A business capability map is a stable, organisation-level picture of what the business does (not org chart). Capabilities are outcomes-oriented: "Manage credit risk", "Onboard customer", "Resolve billing dispute." Heatmaps overlay AI opportunity or delivery status (none, pilot, scaled) per capability.
Engagement use. Start from enterprise EA repository if one exists—do not invent parallel capability models. Mark AI enablement per capability: assist (human-in-loop), automate (bounded), augment (decision support). Align investment to Stage 1 value cases—avoid orphan copilots. Capability maps settle ownership: who signs off when AI answers wrongly in "Manage regulatory reporting"?
Pitfalls.
- Capabilities copied from vendor slide decks—not client's EA model.
- Heatmap all green before pilots complete—portfolio theatre.
- Ignoring shared capabilities (identity, document management)—duplicate integrations.
- No link from capability to risk tier—regulated capabilities need stricter NFRs.
Worked example. Retail bank capability map excerpt: Retail lending origination—AI status pilot (credit memo summarisation); Fraud detection—scaled (classical ML, separate from GenAI); Branch teller servicing—none (planned Q3). Heatmap drives standard pattern reuse: origination and servicing share same RAG platform product on landing zone.
Current state, target state, and transition architecture
Definition. Current state (baseline) documents as-is systems, pain points, and constraints. Target state describes the desired end architecture for the use case or programme. Transition architecture phases movement—what ships in pilot, MVP, scale—without pretending big-bang cutover.
Engagement use. Always produce baseline summary—even if ugly. Target state uses C4: context (actors + systems), container (deployable units), optional component for complex services. Transition roadmap ties to 8D phases: Discover baseline, Design target, Develop pilot path, Deliver scale. Flag temporary components (manual CSV ingest) with sunset ADR.
Pitfalls.
- Target-only diagrams—reviewers ask migration path; silence kills trust.
- Transition with no rollback state—pilot becomes accidental production.
- Baseline understated—legacy ERP batch jobs ignored until they throttle APIs.
- Target state ignores decommission—two systems of record forever.
Worked example. Insurance claims: Baseline—adjusters search 3 systems, avg 12 min per FNOL lookup. Target—single orchestration API, RAG over gold guidelines, CRM sidebar. Transition—Phase 1 read-only RAG in pilot region; Phase 2 write summary to claims notes with human approve; Phase 3 retire legacy search portal for pilot LOB only.
C4 model and architecture communication
Definition. C4 (context, container, component, code) structures diagrams at increasing zoom. AI Solution Engineers typically need context + container for HLD; component for orchestration/RAG internals when multiple teams build.
Engagement use. Context diagram: users, AI solution boundary, external systems (IdP, ERP, model API). Container diagram: web app, API gateway, orchestration service, retrieval service, vector index, policy CMS, observatory/eval, secrets vault. Annotate sync/async and auth on edges. Keep diagrams versioned alongside ADRs.
Pitfalls.
- C4 code-level for executives—wrong audience.
- Missing external systems—diagram shows magic "Enterprise Data."
- Container names as technologies only ("Redis") without responsibility label ("Session cache").
- No legend for dashed lines (future phase) vs solid (pilot).
Worked example. Context: Customer → Servicing Assistant → Salesforce, Core banking API, Azure OpenAI (via private link), Entra ID. Container inside assistant boundary: BFF, Orchestrator, Retrieval, Vector DB, Content sync job, Eval batch.
Architecture Decision Records (ADRs)
Definition. An ADR captures one significant decision: context, options, decision, consequences, status (proposed/accepted/deprecated). ADRs are immutable history—supersede with new ADR, do not silently edit old.
Engagement use. Minimum ADR set for AI pilot: (1) model hosting region and privacy mode; (2) identity and auth pattern; (3) logging and retention; (4) retrieval vs fine-tune boundary; (5) integration pattern for writes. Template: title, date, status, context, decision, consequences, compliance notes. Review with security and EA before build.
Pitfalls.
- ADRs written post-incident only—decorative archaeology.
- "We use Azure" with no rationale—fails audit.
- No consequence section—teams repeat mistakes.
- ADRs in wiki nobody links from HLD.
Worked example. ADR-004: No customer PII in prompts without Presidio masking. Context: servicing assistant has account numbers in CRM snippets. Decision: mask before LLM; store mapping only in session vault; log redacted prompts only. Consequence: +80ms latency; engineering must maintain mask library; compliance accepts inference path.
Non-functional requirements (NFRs) for AI systems
Definition. NFRs specify how well the system behaves: performance (latency p95), availability (uptime), scalability (concurrent users, tokens/min), reliability (error budget), security, residency, recoverability (RTO/RPO), maintainability, cost ceilings, observability, accessibility.
Engagement use. Quantify every NFR—"fast" is not testable. AI-specific: time-to-first-token, retrieval latency, eval regression pass rate, human escalation rate, grounded answer rate. Align with business SLA: if human agent SLA is 20s response, assistant p95 <8s leaves room. Document degradation mode: retrieval down → cached FAQ only → graceful error.
Pitfalls.
- Copying generic web app NFRs—ignore token rate limits.
- No cost NFR—FinOps surprise at scale.
- Availability target 99.99% without budget for HA retrieval index.
- Missing quality NFR—accuracy folded only into ML metrics, not ops.
Worked example. NFR table excerpt: Orchestration API p95 <2.5s excluding model; model stream start <1.2s; availability 99.5% monthly; RPO 15 min conversation state; RTO 4 hr; EU-only processing; max £28K/month inference at 10K daily sessions; eval suite ≥92% pass before promote.
Platform engineering vs product engineering
Definition. Platform engineering provides shared runway: landing zones, CI/CD templates, identity integration, observability baselines, approved model endpoints, GPU pools, API gateways, golden paths. Product engineering builds use-case services: agent workflows, domain prompts, retrieval configs, integrations, UX, eval sets for that product.
Engagement use. RACI clarity prevents platform in product clothing—product team should not create subscriptions or peerings. Product teams consume platform APIs (embed, chat completion with guardrails, indexed corpus product). Exceptions need ADR and time-bound sunset. EA diagram shows platform layer vs product layer containers.
Pitfalls.
- Product team forks entire stack "for speed"—debt in 90 days.
- Platform team owns product backlog—delivery stalls.
- No internal SLA between platform and product—blame loop at outage.
- Platform mandates tool with no GPU capacity plan—eval queues block releases.
Worked example. Bank GenAI platform product offers: approved Azure OpenAI endpoint, vector index service with ACL plugin, prompt registry, CI eval runner. Lending copilot product team owns: credit memo templates, retrieval filters for LOB, Salesforce integration, golden questions. Platform SLO: index API 99.9%; Product SLO: task completion rate for memo draft.
Domain-driven design awareness for AI boundaries
Definition. DDD concepts—bounded context, aggregate, ubiquitous language—help place AI where domain rules are enforced. AI should not span bounded contexts with one prompt; orchestration calls domain services that enforce invariants.
Engagement use. Map use case to bounded contexts: "Pricing" vs "Fulfilment" vs "Billing." Assistant intents route to context-specific retrieval indexes and tools—not one mega-index. Domain events (topic 24) cross contexts asynchronously. Ubiquitous language in prompts matches approved glossary—avoid model inventing product names.
Pitfalls.
- Single RAG index mixing HR policies and trading desk procedures—wrong answers + leakage.
- LLM calculates discounts—business rules belong in domain service.
- Anemic domain model hidden in prompt spaghetti.
- Ignoring anti-corruption layer for legacy ERP terminology.
Worked example. Telecom billing assistant: bounded context Billing inquiries reads invoice API and FAQ corpus; Network faults separate context with NOC runbooks; router agent classifies intent—never merges retrieval across contexts. Discount eligibility checked via Pricing service API, not LLM arithmetic.
Reference architecture alignment and standards
Definition. Reference architectures are organisation-approved patterns (microservices, event-driven, data mesh consumption, zero trust). AI solutions align or document exception. Standards cover naming, tagging, API style (REST/OpenAPI), event schema (CloudEvents), secret management, logging formats.
Engagement use. Early engagement: request EA repository artifacts—don't rediscover. Map target state to approved patterns; gap analysis drives ADR or EA waiver. Tag resources per FinOps policy. API specs in corporate gateway catalog.
Pitfalls.
- "AI is special" waiver for every standard—reviewer fatigue.
- Reference architecture from 2019 ignoring managed model APIs—update via EA process, not bypass.
- Inconsistent event schemas break enterprise monitoring.
- Missing architecture principles traceability—decisions feel arbitrary.
Worked example. Enterprise principle "Cloud-first" → target state on landing zone. Principle "Integration via API gateway" → no direct ERP calls from browser. Exception ADR: batch embedding job uses service principal with narrower scope—approved 12 months.
Well-Architected and AI-specific quality lenses
Definition. Hyperscaler Well-Architected frameworks (AWS, Azure, GCP) provide review pillars: operational excellence, security, reliability, performance, cost, sustainability. Extend with AI lenses: grounding quality, eval discipline, model abuse resistance, data residency for training vs inference.
Engagement use. Run pre-go-live WAR (well-architected review) checklist—even internal. Map findings to remediation backlog. Pair with topic 21 eval gates. Document trade-offs explicitly: cost vs latency for smaller model route.
Pitfalls.
- Checkbox WAR with no remediation owners.
- Ignoring sustainability when GPU utilisation low—executive scrutiny rising.
- Security pillar only—reliability for retrieval dependency skipped.
- No follow-up after pilot—drift unchecked.
Worked example. WAR finding: single-region vector index—reliability risk. Remediation: read replica in DR region (EU pair), RPO 1h async replication; ADR accepts no automatic failover due to residency approval workflow.
Governance: ARB, waivers, and lifecycle
Definition. Architecture Review Board (ARB) or equivalent approves designs against principles. Waivers time-box exceptions with compensating controls. Lifecycle covers introduce, change, retire—AI models and corpora version and deprecate like software.
Engagement use. Package for ARB: executive summary, views, ADRs, NFR table, risk register, transition plan. Pre-brief security and data owners. Model version pinning and corpus version in change control—prompt-only change still triggers eval gate (topic 15).
Pitfalls.
- ARB first meeting is first time EA sees design—late.
- Waivers without expiry—permanent risk.
- No retirement plan for pilot infrastructure—cost bleed.
- Model swap without impact analysis on integrations.
Worked example. ARB conditions: pilot max 5,000 users; no write-back to core banking; monthly eval report to risk committee; waiver for public SaaS model expires 90 days—migrate to private endpoint or stop.
Frameworks and methods
TOGAF ADM (adapted for AI engagements)
Use a lightweight subset of TOGAF ADM phases—not full enterprise cycle:
| Phase | AI engagement focus |
|---|---|
| Preliminary / A (Vision) | Align to capability heatmap and Stage 1 value |
| B (Business) | Capability map, KPIs, process touchpoints |
| C (Information Systems) | Application + data views, C4 target state |
| D (Technology) | Landing zone, hosting, GPU, observability |
| E (Opportunities) | Transition roadmap, pilot → scale |
| F (Migration) | Cutover, decommission, rollback |
| G (Implementation) | ARB gates, ADR compliance checks |
| H (Change) | Model/corpus version governance |
Skip heavy artifact generation where EA repository already holds standards—consume, don't duplicate.
Zachman "who/what/when/where/why/how" sanity check
For each major container, answer: Who uses it? What data? When in process? Where hosted? Why this boundary? How implemented? Gaps surface missing NFRs or owners.
Business capability → application matrix
| Capability | Priority AI use case | Application components | Owner |
|---|---|---|---|
| Resolve billing dispute | Copilot | Orchestrator, CRM adapter, RAG | Servicing product |
| Manage policy wording | Authoring assist | CMS sync, eval dashboard | Policy ops |
| Detect fraud | ML scoring | Feature store, rules engine | Risk |
NFR specification template
| ID | Category | Requirement | Measure | Pilot target | Scale target | Verification |
|---|---|---|---|---|---|---|
| NFR-01 | Performance | Orchestration p95 latency | ms | 2500 | 1800 | APM |
| NFR-02 | Quality | Grounded answer rate | % | 88 | 92 | Eval suite |
| NFR-03 | Security | EU data residency | region | EU-West | EU-West | Config audit |
ADR index (starter set)
| ADR | Typical decision |
|---|---|
| ADR-001 | Model hosting (region, public vs private, BYOK) |
| ADR-002 | Identity pattern (OIDC, service accounts, on-behalf-of) |
| ADR-003 | Logging/redaction and retention |
| ADR-004 | PII in prompts policy |
| ADR-005 | Write integration pattern (sync/async, idempotency) |
| ADR-006 | Platform vs product split |
| ADR-007 | Retrieval index HA and DR |
C4 + views traceability matrix
| Business capability | Container | Data entity | Integration | ADR |
|---|---|---|---|---|
| Employee HR self-service | Teams bot + RAG API | Policy corpus v3 | SharePoint, ServiceNow | 001, 004 |
8D alignment
Design: target state, ADRs, NFRs. Develop: reference implementation aligned to views. Deploy: ARB sign-off, transition execution. See 8D Framework.
Real-world scenarios
Scenario A: Global bank servicing copilot (platform vs product)
A Tier-1 bank launches 12 BU-led copilot pilots in 9 months. Each BU deploys separate vector DB, gateway, and observability—combined run rate £4.2M/year, 0 shared eval framework. EA intervenes with target-state platform layer: single landing-zone subscription pattern, shared GenAI platform product (identity, model endpoint, index service, CI eval), BU product teams own prompts and CRM integration.
Numbers: Platform consolidation reduces projected run rate to £2.6M/year by year 2; 18-week migration for first 4 pilots; ARB mandates ADR-006 for all new use cases. NFR: platform API 99.9% availability; product escalation rate <15%. Lesson: EA stops portfolio fragmentation before regulator asks for integration map.
Scenario B: UK insurer policy assistant (views + residency)
UK insurer needs internal policy assistant over 22,000 clauses. Baseline: adjusters use 4 document stores; 18% of sampled answers in POC used outdated PDFs. Target state: gold corpus in CMS feed, RAG API, Teams app; data view classifies clauses as internal confidential; security view mandates UK processing only; technology view Azure UK South with private endpoints.
ADRs: ADR-001 private Azure OpenAI; ADR-004 no customer PII in prompts; ADR-007 index replica in UK pair only. NFR: retrieval p95 <800ms; grounded rate ≥90% on 120-question eval. Outcome: Pilot 2,400 users; mis-citation incidents −67% vs baseline search; ARB approves Phase 2 LOB expansion.
Scenario C: Manufacturing spare-parts agent (DDD + integration view)
Industrial manufacturer wants agent for spare parts identification across 3 ERP instances (legacy SAP, regional Oracle, cloud ERP). Bounded contexts: Parts catalogue vs Order fulfilment. Target architecture: vision API → orchestration → parts domain service (SKU resolution) → read-only ERP adapters; orders placed only via fulfilment API with human approve—not LLM direct write.
Transition: Phase 1 catalogue Q&A only (5 plants); Phase 2 order draft to workflow. Integration view documents idempotency on order create (topic 24). Failure avoided: prototype that posted duplicate POs (£140K) scrapped before pilot. NFR: vision inference p95 <3s; 99.5% availability during shift hours.
Scenario D: Healthcare prior-auth support (security + clinical view)
US health system wants clinician assistant for prior auth criteria. Business capability: Utilization management. Strict security view: no PHI in general chat logs; separate clinical enclave; BAA-compliant hosting; break-glass audit. Application view: EHR read via FHIR for patient context only after explicit session start; guideline RAG separate index.
ARB waiver: 6-month pilot cap 800 users; no automated approval decisions—recommendation only. NFR: session log retention 30 days redacted; eval 200 Q&A pairs pharmacist-reviewed monthly. Outcome: Internal time per case −12 min average; zero PHI in central log audit sample (n=500).
Scenario E (stretch): Post-merger telecom integration architecture
Two telecoms merge; duplicate CRM and billing stacks. AI programme proposes single customer 360 assistant. EA produces transition architecture: Year 1 read-only federated retrieval with source tags; Year 2 consolidated index after MDM alignment. Capability map shows Retain customer on both stacks during transition.
Numbers: 14M customers; 2 CRMs; target state deferred 18 months; interim design prevents wrong-stack writes—estimated avoided incidents £1.1M regulatory exposure. ADR-008: federated retrieval with mandatory source_system metadata filter.
Scenario F: Retail payments dispute platform (NFR-driven target state)
A payments fintech adds GenAI for merchant dispute summarisation. Baseline: analysts copy-paste from 6 internal tools; average case prep 38 minutes. Target state separates read-only aggregation service (pulls CRM, ledger, chargeback API) from generation service (summarises with citations). NFR-04 mandates p99 <4s for aggregation; NFR-08 mandates 100% citations link to transaction_id.
Architecture board rejects monolith: proposes microservices with event-sourced audit log for every field entering prompt context. Platform team delivers API gateway + mTLS mesh; product team owns summarisation prompts and eval. Numbers: Pilot 120 analysts; prep time −31%; zero uncited monetary amounts in sample audit (n=200); ARB approves scale with £55K platform budget vs £180K if each squad built own stack.
Facilitation: target-state workshop (90 minutes)
Run with product, EA, security, data owner, integration COE:
| Block | Duration | Output |
|---|---|---|
| Capability + KPI recap | 10 min | Confirmed scope boundary |
| Baseline pain walk-through | 15 min | Current-state facts with numbers |
| C4 context draft live | 20 min | Actors and external systems |
| Container + ADR candidates | 25 min | ≥4 containers; ≥3 ADR titles |
| NFR prioritisation | 10 min | Top 5 measurable NFRs |
| Transition phase agree | 10 min | Pilot vs MVP vs scale |
Rules: Ban vendor selection until NFR list exists. Capture conflicts (e.g., latency vs residency) as ADR topics, not unresolved arguments.
Architecture principles for AI programmes (sample set)
| Principle | Implication for AI |
|---|---|
| Data minimisation | Retrieve smallest snippet set; mask PII early |
| Human accountability | No fully autonomous regulated decisions without waiver |
| Reuse over rebuild | Consume platform index/model services |
| Observable by default | Log versions, not raw prompts |
| Secure by design | Private paths; tool allow-lists |
| Evolvable models | Pin versions; eval gate on change |
Map each HLD component to ≥1 principle—gaps trigger ADR or redesign.
Transition roadmap template (pilot → MVP → scale)
| Phase | Duration | Scope | Architecture gate |
|---|---|---|---|
| Pilot | 8–12 weeks | Read-only, single LOB, <5K users | ARB conditional approval |
| MVP | 3–6 months | Write paths with HITL, one region | Full NFR monitoring |
| Scale | 6–18 months | Multi-LOB, HA, DR tested | Platform SLOs, FinOps steady state |
Each phase lists components introduced, components retired, and rollback trigger (eval pass rate, incident severity, cost breach).
Non-functional requirements workshop facilitation
Facilitate NFR elicitation separately from functional wish lists—stakeholders often conflate "good answers" with "fast system."
Technique: For each user journey, capture peak load, acceptable latency, error rate, data freshness, compliance constraint, recovery time. Convert adjectives to numbers on the spot: "fast" → "What second feels slow on phone chat?"
Sample facilitation questions:
- How many concurrent users at peak—and in which regions?
- If the assistant is down 1 hour, what is £ or risk impact?
- What worst-case AI error is unacceptable (money movement, medical, legal citation)?
- What audit must exist 3 years later for a sampled answer?
- What cost ceiling triggers steering committee review?
Document dissenting answers—silent disagreement resurfaces at go-live.
Reference architecture mapping worksheet
| HLD container | Enterprise ref pattern | Compliant? | Exception ADR |
|---|---|---|---|
| Orchestration API | Microservice on AKS | Yes | — |
| Vector index | Managed search PaaS | Yes | — |
| Batch embed | Kubernetes Job | Partial | ADR-011 spot GPU |
| Model access | Private endpoint only | No (dev) | ADR-012 dev waiver 90d |
Complete before ARB submission—reviewers use this table first.
Stakeholder-specific architecture views
Different stakeholders need tailored one-pagers derived from the same source model—avoid maintaining five divergent diagrams.
| Stakeholder | Emphasise | De-emphasise |
|---|---|---|
| CFO / FinOps | Cost envelope, run-rate, scale sensitivity | Container internals |
| CISO | Identity paths, data classification, tool allow-list | Prompt wording |
| Enterprise architect | Reference alignment, transition, ADRs | Model temperature |
| Product owner | Capability outcomes, phase scope | Subnet CIDRs |
| Operations | SLOs, degradation, runbook links | Business case narrative |
Rule: single source diagram in repo; exports filtered per audience. Updates propagate once—prevents security view lagging application view after CRM integration added.
Target-state validation checklist (pre-ARB)
Use before submitting architecture pack:
- Every external system on context diagram has owner and SoR role documented.
- Every container maps to ≥1 business capability.
- ≥5 ADRs cover hosting, identity, logging, PII, integration, platform/product.
- NFR table has numeric targets for latency, availability, RTO/RPO, residency, cost.
- Transition phases include rollback triggers and decommission notes.
- Security view lists AI abuse cases (injection, tool misuse, data exfil) with controls.
- Data view aligns with topic 09 readiness scores—no gold corpus fiction.
- Integration view cross-references topic 24 idempotency for writes.
- Technology view references landing zone fit (topic 16)—not sandbox IDs.
- Stakeholder one-pagers scheduled for post-approval communication—not rework of facts.
Score ≥8/10 before ARB slot requested; gaps become explicit actions with dates, not meeting surprises.
Cost allocation and showback in architecture views
Architecture packs should include rough-order run-rate by container: orchestration compute, vector storage, model inference tokens, integration middleware, observability. Finance stakeholders engage when £ appears next to containers—not only in FinOps retro.
Template:
| Container | Cost driver | Pilot £/mo | Scale £/mo | Notes |
|---|---|---|---|---|
| Orchestration | AKS CPU | £800 | £4.5K | HPA 3–20 |
| Retrieval index | Vector SKU | £1.2K | £6K | QPS growth |
| Model inference | Tokens | £3K | £18K | PTU at scale |
| Integration | iPaaS messages | £400 | £2K | Per escalation |
Sensitivity row: 2× users → inference ~1.8× (not linear due to caching). Attach to NFR cost ceiling—architecture review rejects designs exceeding sponsor-approved envelope without re-baselining Stage 1 value case. Update the cost table when scope or model routing changes—stale numbers erode ARB trust quickly.
Practice exercises
Primary exercise: Target-state architecture pack (4–5 hours)
Choose internal HR policy assistant, commercial lending memo assistant, or field service parts copilot.
Deliver:
- Business capability map excerpt (≥5 capabilities) with AI heatmap status.
- C4 context + container diagrams (ASCII or drawn).
- Six views one-pager each (business, application, data, integration, security, technology).
- NFR table with ≥8 measurable requirements.
- Five ADRs covering hosting, identity, logging, PII, platform vs product split.
Acceptance criteria: Reviewer traces one user journey from capability → container → ADR → NFR; platform vs product ownership explicit in RACI.
Stretch exercise: ARB submission and waiver (3 hours)
For EU retail banking customer servicing assistant with CRM read and payment dispute ticket write:
- Executive summary (≤1 page) for ARB.
- Transition phases with rollback triggers.
- Waiver request for 90-day public API use during pilot—with compensating controls.
- Risk register (≥10 items) with mitigations.
- Decommission plan for pilot if waiver not renewed.
Acceptance criteria: Write path has integration cross-reference; degradation modes documented for model and retrieval outage.
Reflection exercise: EA anti-pattern post-mortem (45 minutes)
Using Scenario A, write one-page post-mortem as if bank rejected platform standardisation and allowed 12 stacks. Include cost, security audit finding, and remediation timeline. File in pattern library.
Questions you should be able to answer
- Which business capabilities does this use case enhance—and who owns outcomes when AI is wrong?
- What is in baseline vs target vs transition architecture for this programme?
- Draw C4 context and container views—what external systems and auth paths appear?
- Which ADR governs model hosting, identity, logging, PII, and write integrations?
- What are quantified NFRs for latency, availability, RTO/RPO, residency, and cost?
- Where does platform end and product begin—who operates each layer?
- How does design align to enterprise reference architecture—where are waivers?
- What data classification applies to prompts, logs, and retrieved chunks?
- How do bounded contexts map to retrieval indexes and tools?
- What happens in degradation mode when model, retrieval, or ERP is unavailable?
- What eval quality NFR gates promotion from pilot to scale?
- How will model and corpus versions change under governance?
- What integration view shows sync vs async and systems of record?
- What Well-Architected or EA principles are satisfied or excepted?
- What is the retirement/decommission plan for pilot components?
Negative cases
Diagram-only EA. Pretty C4 with no ADRs or NFRs—fails ARB. Fix: ADR index linked from HLD.
Capability map ignore. AI bolted onto org chart politics—not capabilities. Fix: use enterprise capability model.
Platform duplication. Each product builds full stack. Fix: platform product ADR and shared services.
NFR adjectives. "Highly secure." Fix: measurable controls and targets.
LLM as domain layer. Business rules in prompts. Fix: domain services + DDD boundaries.
Baseline denial. "Greenfield" fiction hides legacy batch constraints. Fix: honest current state.
Transitionless target. Big-bang fantasy. Fix: phased roadmap with rollback.
Waiver forever. Permanent exception without review. Fix: expiry and compensating controls.
View silos. Security not aligned with data classification. Fix: traceability matrix.
ARB surprise. First review week before go-live. Fix: pre-brief and iterative submission.
Retire nothing. Pilot infra runs forever. Fix: decommission ADR and dates.
Context mega-index. One RAG for all domains. Fix: bounded retrieval products.
Integration with Architecture Guide
| Topic 08 capability | Guide chapter |
|---|---|
| Solution patterns, C4, ADRs | Architecture Guide |
| Delivery views | Delivery Guide |
| Data boundaries | Data & Knowledge |
| Methodology gates | 8D Framework |
Study patterns in the Guide; produce engagement artefacts from this topic.
Crosswalk to Stage 3 topics
| EA artefact | Downstream consumer |
|---|---|
| Container boundaries | Topic 15 API ownership |
| NFR table | Topic 16 capacity and DR |
| Integration view | Topic 24 contracts and idempotency |
| Platform vs product RACI | Topic 16 landing zone ownership |
| ADR-001 hosting | Topic 11/16 model deployment |
When NFR residency is EU-only, topic 16 landing zone must not default to US DR failover without waiver.
Practice checklist
- I can explain each TOGAF-aligned view for my practice use case
- Capability map links to owners and risk tier—not only technology
- Target state traceable to baseline pain points and transition phases
- ≥5 ADRs accepted or proposed with consequences documented
- NFRs have numbers and verification method
- Platform vs product split reviewed with peer or EA
- Practice artefacts filed in pattern library with sector tag
Related playbook content
- Architecture Guide — solution patterns, ADRs, and review gates
- Delivery Guide — build and release alignment
- Software Architect roadmap — career depth on architecture practice
- The Complete Software Architect Roadmap
- 8D Framework — Design and ARB gates
- Architecture and cloud — where this topic sits
- Software Engineering — API and CI realisation of containers
- Cloud and Platform Engineering — technology view detail
Discussion
Comments
Share feedback or questions about this page. No account required.
Loading comments…