The TOGAF 10 Architecture Development Method applied to the ClaraVis Autonomous Enterprise engagement. Every phase produces a living artifact that traces back to a requirement documented on Page 02. This is not a textbook summary — it is a working architecture engagement record.
TOGAF's Architecture Development Method provides the process framework. Each phase below produces a specific artifact for the ClaraVis engagement. Requirements Management is continuous — every requirement from Page 02 is live throughout every phase.
Twelve principles established before any architecture work begins. These are not aspirational guidelines — they are binding constraints on every design decision that follows. Any component that violates a principle requires a formal ADR documenting the exception and its consequences.
The Business Architecture translates the Architecture Vision into a concrete model of how ClaraVis's commercial operations work after the AE is deployed. The As-Is value stream from Page 02 is the baseline. The To-Be below is the target — every manual handoff replaced by an agent-mediated state transition with a defined SLA and an audit record.
Phase C defines what data the enterprise needs to manage and what applications manage it. The canonical data model below shows the six shared entities that underpin all eight AE modules — the proof that the AE is a coherent system, not a collection of applications.
Two diagrams. The concept overview establishes the four-layer model and the principal services. The full technical diagram below it shows every named GCP service, the VPC-SC perimeter, network topology, IAM boundaries, and data flow paths. This is the diagram that makes a Google Cloud architect stop and read.
| Capability Area | Current State (As-Is) | Target State (To-Be) | Horizon |
|---|---|---|---|
| ML Explainability | 3 production models — no SHAP, no explanation contract, EU AI Act non-compliant | Every inference produces SHAP values written to audit log before downstream action. Model Cards versioned in Vertex AI Registry. | H1 |
| HITL Architecture | Ad-hoc email/Slack approvals. No formal state machine, no timeout, no audit record of human decision. | HITL is a first-class state machine node in every agent. Named approver, presentation contract, decision interface, immutable Firestore record. | H1 |
| Asset Telemetry | 6 disconnected regional systems, no common schema, no cross-regional query capability. | Unified Pub/Sub ingestion pipeline, validated common schema, BigQuery dataset for fleet analytics, RUL model in production. | H1 |
| Revenue Recognition | Manual ASC 606 classification by Finance team. 12-day month-end close. No ML-assisted recognition. | RevRec AI classifies each transaction with SHAP explanation, routes through Finance Controller HITL, posts to SAP automatically post-approval. | H2 |
| Contract Intelligence | Contracts stored in on-premise DMS, not analysed. Legal review triggered manually, no precedent reference. | ContractGuard reads full contract via Gemini 1.5 Pro, scores every clause, routes non-standard terms to Legal HITL with precedents and draft counter-position. | H2 |
| Q2C Orchestration | 9 manual handoffs, no SLA, no end-to-end owner, no audit trail, 47-day average cycle. | Agent-mediated state machine with defined SLAs, immutable audit record at every transition, automated SAP write post-HITL approval. | H2 |
| Executive Visibility | C-suite data requires manual pulls from Salesforce, SAP, and 6 regional systems. No unified view. | Strategy Dashboard unifies pipeline, fleet status, revenue posture, and compliance status in a single real-time BigQuery-backed view. | H3 |
| Sales Agent | All inbound inquiries require immediate AE involvement. 3–5 day time-to-qualified-AE. | CCAI Sales Agent handles first 11 turns autonomously. Escalation to AE is a designed state transition with a full briefing document prepared by the agent. | H3 |
Requirements Management is continuous throughout the ADM. The matrix below shows how every requirement from Page 02 is satisfied by a specific phase, artifact, and module. No requirement is unaddressed. No phase produces an artifact that cannot be traced back to a requirement.
| Req ID | Requirement (summary) | ADM Phase | Artifact | AE Module / Component |
|---|---|---|---|---|
| BR-01 | Q2C cycle orchestration with SLAs | Phase B | To-Be Value Stream | CCAI Agent · ContractGuard · RevRec AI · Orchestrator |
| BR-02 | EU AI Act compliance — 3 models | Phase D | XAI Layer · HITL Framework | RevRec AI · Asset IQ · ContractGuard · Vertex AI |
| BR-03 | Unified asset telemetry + predictive maintenance | Phase C/D | Data Model · GCP Architecture | Asset IQ · Pub/Sub · BigQuery · Vertex AI |
| BR-04 | ASC 606 revenue recognition automation | Phase B/D | Value Stream · Data Model | RevRec AI · Finance HITL · SAP integration |
| BR-05 | Contract clause intelligence + risk scoring | Phase B/D | Value Stream · GCP Arch. | ContractGuard · Document AI · Gemini 1.5 Pro |
| BR-06 | Data sovereignty — no data leaves EU | Phase D | GCP Reference Arch. | VPC-SC · CMEK · Organisation Policy · Terraform |
| AR-01 | SHAP explanation per ML inference | Phase D | XAI Layer design | SHAP layer · BigQuery audit · all ML modules |
| AR-02 | HITL as formal state machine node | Prelim + D | P-02 principle · HITL spec | Firestore state machine · all agent modules |
| AR-03 | Immutable audit trail for all agent actions | Phase C/D | Data Model · Firestore | Agent Action entity · Firestore · BigQuery |
| AR-04 | Salesforce as system of record | Prelim | ADR-001 · ADR-002 | SFDC REST API · Developer Edition |
| AR-06 | VPC-SC for data sovereignty | Phase D | GCP Reference Arch. | VPC-SC · Terraform Organisation Policy |
| AR-08 | ASC 606 as write-path constraints | Phase C | Data Model · Transaction entity | RevRec AI · Transaction entity · BigQuery |
| C-01 | Zero additional licensing cost | Prelim | P-12 · ADR-001 | Free tier · SFDC Dev Edition · GCP credits |
| C-04 | EU data residency — europe-west3 | Phase D | GCP Reference Arch. | Terraform region var · Org Policy constraint |
| C-05 | MVP-plus build standard | Phase E/F | Migration horizons | H1–H3 scope definition · demo pathways |
ADR-001 and ADR-002 were established in Phase A. ADR-003 through ADR-006 are produced in Phase D. Every ADR states the decision, the alternatives considered, and the consequences — the pattern Google and major engineering organisations use to make architecture reasoning persistent.
The TOGAF ADM has produced the architecture. Page 04 shows how it gets delivered — the SAFe Solution Train structure, the Agile Release Train mapping for each module domain, and how cross-cutting enablers (security, data governance, HITL) are coordinated across all ARTs.