Extending TOGAF for Continuous and Executable Architecture

The Augmented Enterprise Architect series developed a method built on the Enterprise Architecture Codex, the BMAD operating flow, and the Seed-Validation-Feedback attractor pattern. This essay places that method in relation to TOGAF, the dominant enterprise architecture frame still used in large organizations.

It asks what TOGAF still does well, where its classical practice breaks down under continuous change, and how its central elements need to evolve. Those elements are the Architecture Development Method, the content framework, the architecture repository, and the building blocks. They must change once the repository underneath them is rebuilt as the typed, machine-readable Codex described in earlier essays.

The chapter extends TOGAF rather than replacing it. Read this way, TOGAF becomes the outer frame that holds the continuous and executable architecture of the series together.

What the chapter covers

10 sections, in order.

12.1 TOGAF after the document era
12.2 Where classical TOGAF practice breaks
12.3 The Codex as the living TOGAF repository
12.4 Recasting the ADM as a continuous decision system
12.5 Building blocks, contracts, and controls in executable form
12.6 ACME Pharma: an ADM-aligned change packet for a regulatory submissions platform
12.7 What extending TOGAF asks of the architecture function
12.8 Risks, limits, and trade-offs
12.9 TOGAF as the governing frame of a living architecture system
12.10 Sources

Figures, tables and listings

1 figure · 1 code listing

Reproduced in full, in the order they appear in the published chapter. The reasoning that connects them is in the book.

Figure 12.1: The Codex-Backed ADM driven by BMAD: classical TOGAF phases preserved, run inside continuous BMAD cycles over a Codex semantic substrate.


apiVersion: ea.codex/v1
kind: ArchitectureChangePacket
metadata:
  id: ACP-REG-018
  name: acp-reg-018
  title: Regulatory submissions management service for EU-hosted regulated workloads
  domain: Regulatory Affairs
  status: approved-with-controls
  owners:
    enterpriseArchitect: ea.regulatory@acme.example
    productOwner: submissions-platform@acme.example
    platformOwner: regulated-platform@acme.example
spec:
  intent:                                  # Architecture Vision
    objectiveRef: OBJ-REG-08
    statement: >
      Reduce preparation time for regulated submissions while preserving
      GxP validation, EU data residency, and full traceability of
      submission artefacts from source evidence to regulatory dossier.
    successMeasures:
      - name: submission-preparation-lead-time
        target: "< 15 business days"
      - name: architecture-nonconformance-rate
        target: "< 2% of releases"
  capabilityScope:                         # Business Architecture
    primary:
      - Regulatory Submissions Management
      - Regulatory Document Lifecycle
    related:
      - Identity and Access Management
      - Audit and Evidence Management
  policies:                                # Architecture Principles made enforceable
    - POL-DATA-021: Regulated submission data must remain in EU-approved regions
    - POL-SEC-008: Service-to-service access must use workload identity
    - POL-OPS-015: Production changes require immutable deployment evidence
    - POL-AI-004: No foundation model may process unredacted submission content
  designDecision:                          # Architecture Decision Record
    id: DD-REG-042
    topic: Runtime and delivery pattern for the submissions platform
    context: >
      Service must support validated document ingestion from internal
      systems and external partners, preserve auditability across the
      regulatory dossier lifecycle, and align with validated paved-road
      controls.
    choice: >
      Use the regulated service template on the internal developer
      platform, deploy on the EU-regulated Kubernetes platform,
      provision persistence through the approved PostgreSQL composition,
      and enforce policy through CI/CD checks plus cluster admission
      rules.
    alternatives:
      - bespoke VM-based deployment for regulator-specific submission channels
      - direct ingestion into a general-purpose analytics platform
    rationale: >
      Maximises reuse of validated controls; reduces lead time by using
      pre-approved platform assets; preserves traceability from decision
      to deployment evidence.
  architectureBuildingBlocks:              # ABBs (Content Framework)
    - id: ABB-APP-044
      name: Regulated Document Management Service
    - id: ABB-DATA-019
      name: Regulatory Submission Data Product
    - id: ABB-TECH-027
      name: EU Regulated Container Platform
    - id: ABB-CTRL-012
      name: Immutable Release Evidence
  solutionBuildingBlocks:                  # SBBs (bound realisations)
    - id: SBB-TPL-009
      type: backstage-template
      ref: template://regulated-service-v3
    - id: SBB-PLAT-014
      type: crossplane-composition
      ref: xrd://eu-postgres-validated/v2
    - id: SBB-POL-022
      type: opa-bundle
      ref: policy://regulatory/eu-residency-and-identity/v5
    - id: SBB-OPS-031
      type: kubernetes-admission
      ref: vap://regulated-workload-constraints/v3
  specification:                           # Architecture Specification (attractor seed)
    serviceTier: regulated-critical
    dataClassification: regulated-document-controlled
    regionSet:
      allowed: [eu-west-1, eu-central-1]
      denied: [us-*, ap-*]
    mandatoryInterfaces: [OpenAPI, audit-event-stream]
    requiredEvidence:
      - template-version
      - build-provenance
      - policy-evaluation-report
      - deployment-approval-record
      - validation-test-summary
  controls:                                # Implementation Governance (validation harness)
    - designTime:approved-template-required
    - designTime:prohibited-data-transfer-patterns
    - pipeline:infrastructure-policy-pass
    - pipeline:sbom-generated
    - pipeline:evidence-bundle-complete
    - runtime:admission-policy-region-constrained
    - runtime:workload-identity-required
    - runtime:audit-stream-enabled
  implementationContract:                  # Architecture Contract
    exceptionProcess:
      authority: architecture-review-cell
      validityWindow: "30 days"
      mandatoryCompensatingControls:
        - enhanced-monitoring
        - weekly-conformance-review
    releasePolicy:
      promotionRequires:
        - all-controls-pass
        - no-open-critical-risks
        - named-business-owner-approval
  feedback:                                # Architecture Change Management (convergence)
    telemetry:
      - release-lead-time
      - failed-control-count
      - exception-frequency
      - runtime-policy-violations
    reviewCadence: monthly
    triggersForDecisionReview:
      - repeated-exceptions-over-threshold
      - policy-failure-trend
      - material-platform-change

Figure 12.2: ACME Pharma Architecture Change Packet (ACP-REG-018): a Codex-backed realization of the TOGAF ADM as a single typed change object.

The rest of this chapter

The published chapter runs the argument through all 10 sections above. This page reproduces its structure and every exhibit; the analysis is in the book.