TOGAF ADM: Architecture Development Method
Preliminary through Phase G

§1 Architecture Development Method

The ADM, governed end to end. Not just walked through.

Each phase below produces a specific artifact for the ClaraVis engagement. The Enterprise Architecture Board (EAB) — chartered in Phase G, §9 — owns the gate between every phase: no Solution Train consumes a Phase D artifact as architecture runway until the EAB has certified it sufficient, and no work package enters delivery until its build-vs-buy decision is recorded. Requirements Management is continuous — every requirement from Page 02 is live throughout every phase.

Every decision this page produces becomes an input two pages downstream consume without re-deriving: Lean Portfolio Management (Page 04) funds Solution Trains against the runway certified here, and the Go-to-Market adoption argument (Page 08) cites the ADRs recorded here by number. This page is upstream of both — get the gate wrong here, and every page after it inherits the error.

The Preliminary Phase is where the EAB's authority — and the principles it enforces — are established first.

§2 Preliminary Phase

Architecture Principles — the rules the design cannot break.

Twelve principles established before any architecture work begins. These are not aspirational guidelines — they are binding constraints on every design decision that follows. Four are load-bearing enough to appear, unchanged, as the platform's headline commitments on Page 1: SHAP Before HITL, SAP Write Guard, Quarantine-Then-Review, Augment Not Replace. That repetition is deliberate — a principle that only matters at the documentation level and never surfaces where a CTO or hiring manager actually looks isn't load-bearing. The other eight govern decisions that are real but operate one layer down. Any component that violates a principle requires a formal ADR documenting the exception and its consequences.

The principles are binding. Phase A is where they first get tested against a real stakeholder's real question.

§3 Phase A — Architecture Vision

Phase A is fully elaborated on Page 02 — not duplicated here.

The full nine-stakeholder register has grown to twelve, and the As-Is/To-Be positioning argument now spans all four pillars. Both live on Page 02, at platform scope, in more depth than a TOGAF methodology page should attempt to hold. This section states what Phase A produced and points to where each artifact actually lives.

The vision is set. Phase B turns it into a value stream ClaraVis can actually run.

§4 Phase B — Business Architecture

Phase B is fully elaborated on Page 02, §4a — not duplicated here.

The To-Be value stream, the four-pillar comparison, the Time/Money/Effort incommensurability table, and the cost-of-inaction sequencing map all live there — Business Architecture at platform scope means comparing four pillars' value streams against each other, work that belongs at the requirements layer, not restated at the methodology layer.

The business architecture is defined. Phase C is where it becomes a data model every module can share.

§5 Phase C — Information Systems Architecture

§6 Phase D — Technology Architecture

The architecture runway — certified once, consumed by every Solution Train. Layer naming reconciled with Page 1.

This is the artifact Lean Portfolio Management (Page 04, §1) calls "architecture runway" without re-deriving it: the four-layer contract every module in every pillar is built against. Get this wrong here, and four Solution Trains inherit the error independently, each discovering it at a different, more expensive moment. The concept overview establishes the four-layer model and the principal services. The full technical diagram on each pillar's own page shows every named GCP service, the VPC-SC perimeter, network topology, IAM boundaries, and data flow paths.

The runway is certified. Phase E is where the EAB decides what gets built once, centrally, and what each pillar builds for itself.

§7 Phase E — Opportunities & Solutions

The build-vs-buy gate, decided once. Not re-litigated per pillar.

Every work package below was tested against the same question before it entered the migration roadmap: does a GCP-managed service already solve this, or does ClaraVis's specific regulatory and architectural requirement mean it has to be built? The pattern that recurs across every row — build the orchestration and the audit trail, buy the commodity signal underneath it — is the EAB's standing rule, not a one-off judgment call made fresh for each package.

The build-vs-buy pattern that recurs across every work package: build the orchestration and the audit trail, buy the commodity signal underneath it. No work package proposes building a substitute for a Google-managed service the Portfolio already has access to.

§8 Phase F — Migration Planning

Three horizons, one sequence — the single source of truth every other page points back to.

This is the definition LPM's PI cadence (Page 04) expands into nine Programme Increments, and the definition GTM's adoption argument (Page 08) restates through an adoption lens. Both pages reference H1/H2/H3 by name; neither redefines them. If this section changes, both of those pages' framing changes with it.

The horizons are sequenced. Phase G is where the EAB keeps every Solution Train honest against this sequence as it executes.

§9 Phase G — Implementation Governance

The EAB, chartered. Not designing — certifying.

Every certification this page has made — the runway in §6, the build-vs-buy ownership in §7, the horizon sequencing in §8 — is only as good as the body that keeps checking it's still true after the ink dries. The Enterprise Architecture Board is that body. It does not design architecture; Phases A through F already did that. It certifies that what's being built still matches what was designed, continuously, for as long as the platform runs.

The EAB watches conformance. Requirements Management watches whether the requirements themselves are still the right ones.

§10 Requirements Management

Continuous, not a phase you pass through once. Every requirement, traced.

Every BR, AR, and Constraint from Page 02 stays live across every phase above — this section is the traceability record proving each one actually landed somewhere, rather than being captured in Phase A and quietly forgotten by Phase F. Where the EAB (§9) checks whether the build still matches the design, Requirements Management checks whether the design still matches the requirement — a different failure mode, equally fatal if no one's watching for it.

Every requirement is traced. Every decision is governed. What gets funded next is Page 04's question to answer.

§11 Next in the Portfolio

The method is complete. Investment and adoption follow.

Every artifact this page produces — the runway (§6), the build-vs-buy ownership (§7), the horizon sequence (§8), the EAB's conformance authority (§9) — is now a settled input. Lean Portfolio Management funds against it. The Go-to-Market strategy adopts against it. Neither page re-derives what's already been decided here.