Skip to content

Architecture development method

Enterprise architecture for an AI program answers two very different questions, and the field has two very different traditions for answering them.

  • How do we develop the architecture? — a process/method. Answered by TOGAF's Architecture Development Method (ADM).
  • What must the architecture describe, and from whose perspective? — a classification/ontology. Answered by the Zachman Framework.

They're not competitors. TOGAF says how you get there; Zachman says what has to be there. The Zachman cells are the artifacts the ADM phases produce and evolve. Every mature AI-program architecture team runs the ADM as its cadence and uses Zachman (or an equivalent grid) to check nothing's missing.

This page is the primary framework beside one peer, as linked method tabs — pick TOGAF once and every tabbed block on the page follows.

Sources verified 2026-08-09

The AI-program lens

An AI program is not just "a system with a model in it." It is a program whose central asset — the model — is trained on data, drifts in production, needs a governance envelope around every write it proposes, and depends on GPU/accelerator supply chains. That reshapes every phase of an architecture method:

  • Data becomes first-class capital. The training/feature/eval datasets are architected artifacts, with lineage, contracts, and privacy classifications.
  • The model is a runtime asset with a lifecycle of its own — train → eval → shadow → canary → production → drift → retrain — that the target architecture must plan for from day one.
  • Human-in-the-loop is architectural, not a UX bolt-on. Approvals, attribution, and least-privilege scoping (see the Trust & attribution arc) are load-bearing parts of the governance capability the architecture must deliver.
  • Compute has physical constraints. GPU/accelerator quota, warm pools, and cost per token/frame drive Phase D and the Migration Plan.

Both frameworks below are used here through this lens.

The two frameworks

The ADM is the iterative process at the heart of the TOGAF Standard. Ten activities, run as a cycle, with Requirements Management at the center feeding every phase.

flowchart TB
  Prelim([Preliminary<br/>frameworks & principles])
  A([A. Architecture Vision])
  B([B. Business Architecture])
  C([C. Information Systems<br/>Data + Application])
  D([D. Technology Architecture])
  E([E. Opportunities & Solutions])
  F([F. Migration Planning])
  G([G. Implementation Governance])
  H([H. Architecture Change Mgmt])
  R{{Requirements Management<br/>feeds every phase}}

  Prelim --> A --> B --> C --> D --> E --> F --> G --> H --> A
  R -.-> A
  R -.-> B
  R -.-> C
  R -.-> D
  R -.-> E
  R -.-> F
  R -.-> G
  R -.-> H

Per-phase AI deliverables

Each ADM phase produces the usual TOGAF outputs; the table below is what those outputs concretely look like for an AI program (i.e. what a competent AI architect actually hands to the next phase, not the generic phase description).

ADM phase AI-program deliverable & key decision
Preliminary Adopt/tailor TOGAF; pick the responsible-AI principles that will bind every downstream decision (fairness, transparency, human-in-the-loop, data residency). Establish the Architecture Repository sections for models, datasets, and evals.
A. Architecture Vision The problem is framed as a value hypothesis: which decision does the model change, for whom, by how much, measured how. Stakeholder map includes a named Responsible-AI Lead and Data Governance Lead. Success metric is not accuracy — it is the business KPI accuracy is meant to move.
B. Business Architecture Business capabilities that will consume the model output; the decision points where human judgement is retained vs. delegated; the value stream that the model participates in; the SLAs the model must meet for the business process to work.
C. Information Systems — Data Feature-store design, training-data lineage, data contracts with source systems, PII classification, retention windows, the eval dataset and its refresh cadence, ground-truth-labeling operating model. This phase is where AI programs live or die.
C. Information Systems — Application Inference service (sync vs async), the model registry, the retrieval layer (for RAG), the tools/functions the model may call, the human-review UI, the observability plane, the guardrails layer.
D. Technology Architecture Accelerator/GPU strategy (own vs rent, on-prem vs cloud, quotas, warm-pool), the MLOps toolchain (training, serving, feature store, monitoring), private networking to model providers, secrets/identity for model calls, DR posture for the model registry.
E. Opportunities & Solutions Work packages sequenced by model risk: prove the model can hit the metric on the eval set (a "PoC gate") before scaling data pipelines or provisioning production compute. Data readiness gates precede model gates precede integration gates.
F. Migration Planning Cutover from the baseline decision path (rules, manual, prior model) to the new one, with a shadow-then-canary rollout, an explicit rollback trigger tied to a live quality metric, and a plan for the ground-truth backfill during shadow mode.
G. Implementation Governance Model risk council; the approval gate that must fire before any AI write hits a system of record (see Trust & attribution — approval workflow); model cards and dataset cards for every promoted artifact; the change-review workflow for new prompt/template versions.
H. Architecture Change Management Drift-triggered retraining cadence; the eval-regression gate that guards every promotion; sunset criteria for a model that stops meeting the KPI; the process for adding a new model to the estate without re-doing A–D from scratch.
Requirements Management (central) Non-functional requirements peculiar to AI: eval-metric thresholds, drift-detection latency, worst-case tail latency for inference, cost-per-decision budgets, explanation coverage, fairness metrics across cohorts.

Architecture Repository & content framework

TOGAF's Architecture Repository and Content Framework name the artifact types the ADM produces. For an AI estate the repository grows three sections a generic-IT repository doesn't need: a model catalog (registry entries + cards), a dataset catalog (with lineage and eval sets), and a prompt/template catalog (versioned, with the eval results that promoted each version). Those three sections are what let you answer "what model produced this decision, on what data, under what prompt?" without doing forensics.

The Zachman Framework is not a method — it's a 6 × 6 classification schema (an ontology). Six columns (the interrogatives What, How, Where, Who, When, Why) crossed with six rows (the perspectives, from executive scope down to running instances). Every cell is a distinct architectural artifact type; a complete architecture description populates every cell that matters.

Version 3.0 names (see the citations block below):

What
Inventory Sets		 How
Process Flows		 Where
Distribution Networks		 Who
Responsibility Assignments		 When
Timing Cycles		 Why
Motivation Intentions
Executive (Scope Contents) · · · · · ·
Business Mgmt (Business Concepts) · · · · · ·
Architect (System Logic) · · · · · ·
Engineer (Technology Physics) · · · · · ·
Technician (Tool Components) · · · · · ·
Enterprise (Operations Instances) · · · · · ·

Populating the grid for an AI program

A worked column-by-column view of what "an AI program" actually puts into each column at the Architect and Engineer perspectives — the two rows the AI architect owns most directly.

Column Architect row (System Logic) Engineer row (Technology Physics)
What (Inventory) Feature catalog; dataset catalog (train / eval / holdout); model catalog Feature-store schema; parquet layouts; model registry entries + cards; embedding index
How (Process) Training pipeline; evaluation loop; inference request flow; human-review flow; retrain trigger DAG code (Airflow / Kubeflow); training containers; inference server config; drift-detector job
Where (Network) Which region / cloud runs training vs inference vs data; data-residency map VPC / subnet layout; GPU-pool location; model-provider egress paths; private-endpoint plumbing
Who (Roles) AI Architect; ML Engineer; Data Scientist; Governance Lead; Domain SME (covered on the Roles & archetypes page in this pillar) Workload identities per service; end-user identities via edge auth; on-call rotations for model-serving
When (Timing) Retrain cadence; eval-regression gate; canary promotion window; drift-review meeting Cron schedules; SLA windows; batch-window vs online-serving contracts
Why (Motivation) The value hypothesis; the responsible-AI principles; the KPI the model must move Guardrail policies (input/output); rate limits; cost-per-decision budgets

Why Zachman helps the ADM

Sit an ADM Phase C review beside the Zachman grid: for each cell the framework says the artifact should exist, ask "who owns this for our AI system, and where does it live in the Architecture Repository?" The empty cells are the risks. The grid does not tell you how to fill a cell (that's the ADM's job) — it tells you a cell is missing before production does.

TOGAF vs Zachman — side by side

Dimension TOGAF ADM Zachman Framework
Kind of thing Process / method (how you get there) Ontology / classification (what has to be there)
Prescriptive or descriptive Prescriptive process, tailorable outputs Descriptive schema, silent on process
Primary artifact The ADM cycle + phase deliverables The 6 × 6 cell grid
Unit of work A phase, iterated in a cycle A cell, populated by whichever process suits
What it forces you to do Follow a repeatable order (Vision → Business → IS → Tech → …) with change-mgmt gates Ensure every perspective × interrogative artifact exists
What it doesn't tell you Whether the set of artifacts is complete How to produce or govern any given artifact
AI-program fit Excellent for cadence, governance, and migration planning Excellent as a completeness check on the artifact estate
Adopt when You need a repeatable programme rhythm and change-mgmt gates You need a shared vocabulary for artifact types across teams
They compose because The ADM produces artifacts; the grid classifies the artifacts it produces. Each phase output lands in one or more Zachman cells.

When to reach for which — and how to compose

  • Start with the ADM. If you're setting up an AI programme from scratch, adopt TOGAF's ADM as the cadence: Preliminary → A → B → C → D as the first delivery, then E–H as the programme runs. You'll fail governance audits without a defensible process.
  • Overlay Zachman as a review lens. Once per iteration — typically at the end of Phase C and again at Phase G — walk the 6 × 6 grid against the actual repository and mark the empty cells. The unpopulated cells are the risks the ADM hasn't surfaced yet.
  • Do not run both as parallel programmes. They answer different questions; running each as its own governance track is a common anti-pattern that doubles the meeting load without doubling the clarity.

Ties into the rest of Chiron

  • The Phase G "approval gate before any AI write" is the pattern built in Trust & attribution — approval workflow.
  • The Phase C data lineage is the operating-mode of the RAG ingestion pipeline in the RAG chapter.
  • The Phase D observability plane is what the Observability chapter provisions.
  • The ArchiMate/TOGAF modelling technique behind these phases — with every layer drawn as a real diagram — is the Enterprise Architecture section, which closes with EA on your AI platform.
  • The roles who staff these phases and populate the Zachman rows are the subject of the Roles & archetypes page at the end of this pillar.

Where the pillar goes next

This is the opening page of the Delivery & practice pillar. The remaining pages, in order under the same nav section, are:

  • Traditional iterative — plan-driven iterative delivery of the AI system the architecture above describes (RUP + Spiral).
  • Project management — scheduling, governance stages, and CPM through an AI-program lens (PMBOK + PRINCE2).
  • Scaled agile — scaling AI delivery across many teams (SAFe + LeSS).
  • Roles & archetypes — the capstone matrix of role × method × archetype, with AI Architect and the AI Transformation archetype worked in depth.