From Architecture as Code to Executable Enterprise Architecture

The previous chapters established the semantic and governance foundations of the EA Codex. This chapter turns that foundation toward execution. It asks how architectural intent becomes usable by delivery systems, policy engines, catalogs, agents, and auditors. Build-time tests live in one tool, runtime policies in another, and the decisions and authorized variations that should bind them sit in catalogs and wikis that platform teams rarely open.

Those fragments live in separate systems. The chain from intent to enforcement is interrupted at every handoff. The missing object is the chain itself: a typed connection from enterprise intent through decisions, specifications, controls, and evidence.

This chapter names the operating model that connects them. It draws on three publicly available bodies of work: Architecture as Code (Ford and Richards) for the executable layer, Software Product Line engineering (Software Engineering Institute, SEI; Pohl, Böckle, van der Linden) for the discipline of commonality and authorized variation, and the EA Codex for the typed enterprise memory that binds them.

What the chapter covers

11 sections, in order.

16.1 A story most architects have lived
16.2 What Architecture as Code means in practice
16.3 Four levels of Architecture as Code
16.4 The fitness function binds the four levels
16.5 Variability changes what fitness functions enforce
16.6 Agentic AI raises the cost of ambiguity
16.7 One real constraint across all four levels
16.8 How to start without creating a metamodel program
16.9 Risks and trade-offs
16.10 Conclusion
16.11 Sources

Figures, tables and listings

5 figures · 1 table · 8 code listings

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

Figure 16.1: Architecture as Code, Software Product Lines, and the EA Codex assembled into one operating model.

Figure 16.2: The four properties that turn a constraint into architecture as code.

Figure 16.3: The four levels at which architecture becomes code, from code structure to enterprise memory.

@Test
void controllers_should_not_depend_on_repositories() {
    JavaClasses classes = new ClassFileImporter()
        .importPackages("com.acme.customer");
    noClasses().that().resideInAPackage("..controller..")
        .should().dependOnClassesThat()
        .resideInAPackage("..repository..")
        .check(classes);
}

Figure 16.4: ArchUnit test enforcing the controller-to-repository dependency rule (Java).

package egress.eu_pii
default allow := false
allow if {
  input.resource.data_classification == "personal"
  input.resource.customer_region == "EU"
  input.resource.target_region == "EU"
}
violation contains msg if {
  input.resource.data_classification == "personal"
  input.resource.customer_region == "EU"
  input.resource.target_region != "EU"
  msg := sprintf(
    "Non-EU egress forbidden for EU personal data (target=%s)",
    [input.resource.target_region]
  )
}

Figure 16.5: Rego policy enforcing EU personal data residency at the runtime layer.

$schema: https://calm.finos.org/schemas/2025-10/architecture.json
metadata:
  name: payment-service
  owner: payments-platform-team
nodes:
  - id: payment-api
    type: service
    region-allowed:
      - eu-west-1
      - eu-central-1
  - id: payment-store
    type: database
    region-allowed:
      - eu-west-1
relationships:
  - source: payment-api
    target: payment-store
    protocol: postgres-tls
controls:
  - rule: eu_data_residency
    enforced-by: opa://egress.eu_pii

Figure 16.6: CALM-style architecture description for a payment service.

apiVersion: ea.codex/v1
kind: FitnessFunction
metadata:
  id: ACP-FF-EU-DATA-RESIDENCY-001
  name: eu-data-residency
  title: EU personal data residency fitness function
  status: approved
  version: "1.0"
  owners:
    chiefPrivacyArchitect: cpa@acmepharma.eu
spec:
  controlType: ci-check
  evaluates:
    - input.resource.data_classification
    - input.resource.customer_region
    - input.resource.target_region
  implementation:
    language: rego
    packageRef: ACP-RGO-EGRESS-EU-PII
  enforcementMode: deny
  enforces:
    decisionRefs: [ACP-DEC-GDPR-DATA-RESIDENCY-001]
    policyRefs: [ACP-POL-GDPR-ARTICLE-44]
  scope:
    capabilityRefs: [ACP-ARC-CUSTOMER-PLATFORM-2026-Q2]
    jurisdictions: [EU]
  evidenceProfile:
    resultEnum: [pass, fail]
    retainEvidenceFor: 7y

Figure 16.7: EA Codex FitnessFunction binding a decision to its executable implementations and evidence stream.

Artifact role	What it does	Example
Structured specification	Defines what is constrained, why, by whom, and against which evidence.	FitnessFunction YAML object
Executable rule	Runs and fails, warns, or blocks when violated.	Rego policy, ArchUnit test, NetArchTest rule
Feedback evidence	Records that a rule was evaluated against a specific artifact at a specific time.	EvidenceRecord, CI report, audit log

Figure 16.8: The three artifact roles in Architecture as Code: descriptions, executables, and memory.

Figure 16.9: TOGAF ADM, BMAD, and the Seed-Validation-Feedback attractor as nested cycles: macro phases, micro loop, convergence principle.

apiVersion: ea.codex/v1
kind: VariabilitySpecification
metadata:
  id: ACP-VAR-DIGITAL-STUDY-001
  name: regulated-digital-study-variability
  title: Regulated digital-study variability envelope
  status: approved
  version: "1.0"
  owners:
    productLineArchitect: pla.digital-study@acmepharma.eu
spec:
  scope:
    family: regulated-digital-study
    appliesTo: [clinical-development]
  variationPoints:
    - id: consentText
      classification: configuration
      bindingTime: deployment
      allowedValues: [default, jurisdiction-variant]
      constraints:
        - allowedBy jurisdiction or studyProtocol
        - approvalRequiredFrom medical-legal-review
    - id: dataResidency
      classification: regulated-configuration
      bindingTime: deployment
      constraints:
        - allowedBy jurisdiction
        - approvalRequiredFrom data-protection-office
    - id: integrationStyle
      classification: time-bound-transition
      bindingTime: design
      allowedValues: [rest_legacy, event_publication]
      constraints:
        - rest_legacy allowed only for existing capabilities, sunset 2026-12-31
        - event_publication required for new capabilities
    - id: auditRetention
      classification: core-invariant
      bindingTime: design
      allowedValues: [P10Y]
      constraints:
        - core invariant, changeAllowed false
    - id: safetyEventReporting
      classification: core-invariant
      bindingTime: design
      constraints:
        - core invariant, changeAllowed false
  exceptionPolicy:
    allowed: true
    approverRole: ea-council
    maxDurationDays: 365
    requiredCompensatingControl: medical-legal-review

Figure 16.10: VariabilitySpecification declaring variation points, allowed values, and invariants for a digital-study capability.

apiVersion: ea.codex/v1
kind: FitnessFunction
metadata:
  id: ACP-FF-STUDY-VARIABILITY-001
  name: study-variant-conformance
  title: Study variant conformance fitness function
  status: approved
  version: "1.0"
  owners:
    productLineArchitect: pla.digital-study@acmepharma.eu
spec:
  controlType: ci-check
  evaluates:
    - input.kind
    - input.spec.integrationStyle
    - input.spec.consentText.variantApplied
    - input.spec.regulatoryClassification
    - input.spec.retentionPeriod
  implementation:
    language: rego
    packageRef: ACP-RGO-STUDY-VARIABILITY
  enforcementMode: deny
  enforces:
    standardRefs: [ACP-VAR-DIGITAL-STUDY-001]
  scope:
    factSheetTypes: [ArchitecturePackage, DataContract, AgentContract, Interface]
  evidenceProfile:
    resultEnum: [pass, fail]
    retainEvidenceFor: 7y

Figure 16.11: FitnessFunction binding the VariabilitySpecification to executable evaluation by an OPA package.

package acme.study.variability
deny[msg] {
  input.kind == "Interface"
  input.spec.capabilityLifecycle == "new"
  input.spec.integrationStyle == "rest_legacy"
  msg := sprintf("New capability %s cannot use legacy REST integration", [input.metadata.id])
}
deny[msg] {
  input.kind == "Interface"
  input.spec.integrationStyle == "rest_legacy"
  input.spec.exception.sunsetDate > "2026-12-31"
  msg := sprintf("Legacy REST exception for %s exceeds the approved sunset date", [input.metadata.id])
}
deny[msg] {
  input.kind == "ArchitecturePackage"
  input.spec.variant.jurisdiction == "FR"
  input.spec.consentText.variantApplied == true
  not input.spec.approvals.medicalLegalReview
  msg := sprintf("French consent-text variant in %s lacks medical-legal approval", [input.metadata.id])
}
deny[msg] {
  input.kind == "DataContract"
  input.spec.regulatoryClassification == "regulated-study-evidence"
  input.spec.retentionPeriod != "P10Y"
  msg := sprintf("DataContract %s violates the ten-year audit retention invariant", [input.metadata.id])
}

Figure 16.12: Rego policy enforcing the authorized variation envelope of the digital-study product line.

apiVersion: ea.codex/v1
kind: DecisionRecord
metadata:
  id: ACP-DEC-GDPR-DATA-RESIDENCY-001
  title: EU personal data residency
  status: accepted
  date: "2024-09-01"
  owner: chief-data-officer@acme-pharma.example
  version: "1.0"
spec:
  trigger:
    type: external-regulator-notice
    source: GDPR Article 44 — transfers of personal data outside the EU
  context: |
    GDPR restricts unjustified transfers of personal data outside the European Union.
    Customer-facing services must respect that jurisdictional boundary.
  decision: |
    EU personal data must remain in EU-approved regions across all customer-facing
    services. Cross-border transfers are prohibited without a documented legal basis
    and a compensating control.
  relatedPrinciples:
    - ACP-PRI-PRIVACY-BY-DESIGN
  relatedSpecs:
    - ACP-SOV-EU-PII-RESIDENCY
  affectedFactSheetTypes:
    - ArchitecturePackage
    - DataContract
    - Interface
  doubleCheck:
    fitnessFunctions:
      - id: ACP-FF-EU-DATA-RESIDENCY-001
        rule: No EU personal data may exit EU regions
        check: Rego package ACP-RGO-EGRESS-EU-PII in CI
---
apiVersion: ea.codex/v1
kind: FitnessFunction
metadata:
  id: ACP-FF-EU-DATA-RESIDENCY-001
  name: eu-data-residency-fitness-function
  title: EU data residency fitness function
  status: approved
  version: "1.0"
  owners:
    enterpriseArchitect: enterprise-architecture@acme-pharma.example
spec:
  controlType: ci-check
  evaluates:
    - input.resource.data_classification
    - input.resource.target_region
  implementation:
    language: rego
    packageRef: ACP-RGO-EGRESS-EU-PII
  enforcementMode: deny
  enforces:
    decisionRefs: [ACP-DEC-GDPR-DATA-RESIDENCY-001]
  scope:
    jurisdictions: [EU]
---
apiVersion: ea.codex/v1
kind: SovereigntySpecification
metadata:
  id: ACP-SOV-EU-PII-RESIDENCY
  name: eu-personal-data-residency-boundary
  title: EU personal data residency boundary
  status: approved
  version: "1.0"
  owners:
    dataProtectionOfficer: data-protection-office@acme-pharma.example
spec:
  intent:
    objectiveRef: ACP-INT-GDPR-COMPLIANCE-2024
    statement: Preserve EU jurisdictional control over personal data across processing, storage, and derived context.
    relatedDecisions: [ACP-DEC-GDPR-DATA-RESIDENCY-001]
  appliesTo:
    capabilityScopes: [customer-platform]
    dataProductRefs: [ACP-DPC-CUSTOMER-PII]
  sovereigntyObjectives:
    controlOfMeaning:
      required: true
      defaultPolicy: enterprise-business-object-glossary
    controlOfDataLocation:
      required: true
      defaultPolicy: eu-only
      enforcementPattern: opa-rego-region-check
    controlOfAccess:
      required: true
      defaultPolicy: deny-non-eu-roles
    controlOfExecution:
      required: true
      defaultPolicy: eu-resident-runtimes-only
    controlOfEvidence:
      required: true
      evidenceStore: ACP-EVD-EU-DATA-RESIDENCY-STREAM
    controlOfExit:
      required: true
      providerSubstitutionTarget: eu-resident-cloud-or-on-prem
  validation:
    deterministicRules:
      engine: opa
      rulePackages:
        - ACP-RGO-EGRESS-EU-PII

Figure 16.13: EA Codex chain linking the GDPR data-residency DecisionRecord, its FitnessFunctions, and the SovereigntySpecification that holds the residency boundary.

Figure 16.14: The Codex specification governs, the RegoPackage executes, and the EvidenceRecord closes the loop.

The rest of this chapter

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