EA-Ops: Git-Native Architecture as Code for Continuous Enterprise Architecture Governance

1 Introduction

• Architecture as Code and related work motivate machine-readable, version-controlled architecture, but EA needs an operating model that preserves its semantics and governance.The introduction situates EA-Ops alongside work on lightweight decision records, semantic representations, reconstruction, impact analysis, and model-driven engineering.Source: §1 · p. 2
• EA repositories require typed cross-layer relationships, organization-specific policy, stakeholder views, and pre-merge change consequences that generic configuration validation does not address.The workflow should also publish stakeholder-facing views without creating a second source of truth.Source: §1 · p. 2
• The evaluation asks whether EA-Ops detects structural, semantic, and governance faults, scales from 100 to 50,000 objects, matches an independent graph oracle on realistic changes, and runs reproducibly in CI.The evaluation contributions include eight fault classes and 240 trials, scalability measurements through 50,000 objects and 100,000 relationships, and ten controlled Metroville changes.Source: §1 · pp. 2–3
• EA-Ops integrates semantic EA modeling, governance-as-code, pull-request review, impact analysis, and publication in one Git-native operating model.Architecture facts are stored as YAML, and reports and a static interactive portal are generated from the same reviewed source.Source: §1 · p. 2

2.1 Enterprise Architecture Standards and Executable Models

• ISO/IEC/IEEE 42010:2022, ArchiMate 3.2, and TOGAF provide foundations for architecture descriptions, enterprise modeling, and architecture practice.Related studies examine ArchiMate’s strengths and limitations, governance, value modeling, digital-government reference architectures, technical dependency discovery, natural-language assistance, and organizational digital twins.Source: §2.1 · p. 3

2.2 GitOps, Infrastructure as Code, and Continuous Validation

• GitOps, IaC, and CI/CD establish reviewed, versioned, and continuously checked operating practices, which EA-Ops applies to architecture semantics and enterprise governance.The cited work covers GitOps in CI/CD, edge computing, and Kubernetes, alongside IaC testing, user issues, and smells.Source: §2.2 · p. 3

2.3 Architecture Knowledge, Architecture as Code, and Change Impact

• Architecture decision records, semantic modeling, reconstruction, change-impact analysis, and executable validation make architecture knowledge increasingly machine-processable.Architecture as Code treats architecture artifacts as code-like, version-controlled assets; EA-Ops combines that principle with typed EA semantics, policy, pull-request governance, impact, and publication.Source: §2.3 · pp. 3–4

2.4 Model-Driven DevOps and the Remaining Gap

• The remaining gap is a reproducible, continuously governed EA workflow that integrates complementary practices in one Git-native artifact and evaluates correctness and scale end to end.Model-driven engineering and model-driven DevOps illustrate connections between models and operational automation, but the cited literature presents complementary pieces rather than this integrated workflow.Source: §2.4 · p. 4

3.1 Git-Native Repository Model

• The repository stores architecture objects, typed relationships, views, and rules, while Git supplies reviewed changes and provenance.Rules encode organizational constraints independently of the underlying model.Source: §3.1 · pp. 4–5

3.2 Deterministic Validation

• Validation combines structural, semantic, and governance findings, with organization-defined rules able to block CI on errors or expose debt as warnings.Checks include required fields, duplicate IDs, dangling endpoints, ArchiMate-aware relationship combinations, and rule primitives such as required properties and allowed values.Source: §3.2 · p. 5

3.3 Graph-Based Change Impact

• Impact analysis traverses relationships in both directions to return the connected set reachable from changed IDs.The implemented repeated relationship scans are bounded by O(D|E|); typed, directional, and depth-bounded semantics are future extensions.Source: §3.3 · p. 5

3.4 Publication and Human-Facing Views

• The same reviewed YAML source generates reports and a static interactive portal for repository overview, governance findings, motivation concepts, and dependency exploration.Browser layout edits remain local drafts until committed through Git; no database or server-side web application is required.Source: §3.4 · pp. 5–6, Figure 2 · p. 6

4.1 Research Artifact and Execution Environment

• Validation and impact measurements ran in GitHub Actions on hosted Ubuntu 24 and Python 3.12.14 runners, with hardware variation reported as a timing-validity threat.EA-Ops 0.2.0 and the Metroville reference case were pinned to Git commits.Source: §4 · p. 6, §4.1 · p. 7

4.2 Synthetic Scalability Models

• Synthetic models span 100 to 100,000 objects, with relationship counts configured at approximately twice the object count.Completed scales received three warm-ups and 30 measured repetitions; report and portal generation were measured for the first three repetitions.Source: §4.2 · p. 7

4.3 Independent Fault Injection

• Eight injected fault classes were tested in 30 deterministic trials each, with emitted error tuples compared against independently generated ground truth.The experiment measures detector correctness for the explicit fault catalog, not prevalence or accuracy on arbitrary real-world EA repositories.Source: §4.3 · pp. 7–8, Figure 3 · p. 8

4.4 Metroville Controlled-Change Case

• Ten controlled changes were applied to fresh copies of the Metroville architecture, checking validation against scenario manifests and impact sets against an independent breadth-first-search oracle.The oracle traverses modified relationship files without calling the EA-Ops impact implementation.Source: §4.4 · p. 8

5.1 RQ1: Validation Correctness

• All 240 fault-injection trials matched expected error sets, yielding precision, recall, and F1 of 1.000 for the controlled fault catalog.This demonstrates deterministic agreement for the tested fault types, not coverage of every possible EA-quality defect.Source: §5.1 · pp. 8–9, Table 1 · p. 9

5.2 RQ2: Scalability

• At 50,000 objects and 100,000 relationships, median validation time was 52.582 s and peak resident memory was 919.2 MB.At that scale, median impact latency was 627.000 ms, with a median impacted set of 49,045 of 50,000 nodes.Source: §5.2 · p. 9, Table 2 · p. 9
• At 50,000 objects, median Markdown report generation took 823.5 s, while portal generation took 0.898 s after model loading.Repeated relationship scans for application rows yield O(|A||E|) work in the application-heavy synthetic model.Source: §5.2 · p. 9
• The 100,000-object, 200,000-relationship model was generated, but its benchmark exceeded the 180-minute job budget and produced no timing result.The study treats 50,000 objects as the largest fully measured scale and does not extrapolate the incomplete run.Source: §5.2 · p. 10

5.3 RQ3: Metroville Controlled Changes

• All ten Metroville scenarios matched their validation expectations and an independent breadth-first-search oracle's impact sets.The oracle agreed with EA-Ops on every reachable ID; the scenarios included both valid changes and changes expected to produce findings.Source: §5.3 · p. 10

5.4 RQ4: Reproducibility

• The reproducible workflow records environment metadata and retains raw measurements, while controlled-scenario patches make model mutations auditable.The harness makes environmental variation visible and experiments re-executable, but does not eliminate that variation.Source: §5.4 · p. 11

6.1 What the Results Support

• For tested structural, semantic, and policy faults, EA-Ops matched independently declared expectations; Metroville changes also matched an independent graph oracle.The claims are limited to the tested faults and controlled cross-layer changes.Source: §6.1 · p. 11
• At tens of thousands of objects, validation and broad connected-component impact analysis remained operationally practical, but Markdown report generation became the dominant bottleneck.The reported median validation time was 52.6 s for 50,000 objects and 100,000 relationships.Source: §6.1 · pp. 11–12, Figure 7 · p. 13
• Architecture as Code’s engineering value comes from combining machine-readable semantics, repeatable validation, executable policy, reviewed changes, and views derived from one source.Source: §6.1 · p. 12

6.2 Practical Implications

• Reusing standard Git hosting avoids building a separate EA database for users, roles, approvals, and audit history; governance can be adopted progressively as repositories mature.Source: §6.2 · p. 12
• Keep semantic validation lightweight for pull requests and index or pre-aggregate expensive reports; impact analysis could add direction, relationship filters, hop bounds, or risk weights.The discussion identifies report generation as the dominant bottleneck at scale.Source: §6.2 · p. 12, Figure 7 · p. 13

6.3 Threats to Validity

• The fault catalog tests eight explicit classes and exact emitted tuples, but does not establish that its rules cover all architecture-quality concerns; graph reachability is only a structural proxy for impact.Source: §6.3 · p. 13
• Independent ground truth and impact-oracle implementations reduce circularity, but share the Python/CI environment and may share YAML assumptions; malformed serialization beyond selected mutations was not studied.Source: §6.3 · p. 13
• The synthetic topology is application-heavy, while Metroville is fictional and compact, so neither establishes performance or governance outcomes for varied production repositories.Real repositories may differ in layer distributions, relationship density, modularity, and policy complexity.Source: §6.3 · p. 13

• The framework is available under Apache-2.0, and the Metroville reference architecture and controlled-change scenarios are publicly available.Source: §7 · p. 14
• Documented seeds generate benchmark models deterministically, while the repositories provide source code, benchmark configurations, scenarios, and CI workflow definitions.Source: §7 · p. 14
• Executable, version-controlled workflows make reproduction independent of a particular GitHub Actions run or commit; a persistent software archive is suggested for long-term archival reproducibility.Source: §7 · p. 14

• Across 240 trials, eight injected fault classes achieved precision, recall, and F1 of 1.000; at 50,000 objects and 100,000 relationships, median validation was 52.6 s and impact traversal 627 ms.Peak RSS remained below 1 GB, and all ten Metroville scenarios matched expected validation outcomes and an independent impact oracle.Source: §8 · pp. 14–15
• EA-Ops combines YAML architecture facts, ArchiMate-aware relationship validation, organization-specific governance, pull-request review, graph-based impact analysis, and static publication.Source: §8 · p. 14
• The 100,000-object end-to-end job exceeded the 180-minute CI budget, with report generation already dominating runtime at 50,000 objects.Source: §8 · p. 15
• The authors identify production-organization evaluation, comparison of review effort with conventional EA tooling, typed impact propagation, and longitudinal model evolution as future work.Source: §8 · p. 15