Governance-as-Code: Turning Enterprise Architecture Into a System of Action

AI coding assistants now generate production-ready code within minutes, and development teams deploy multiple times a day. Governance that relies on periodic reviews quickly becomes a bottleneck.

Traditional Enterprise Architecture governance relies on review boards and approval workflows, with architecture principles maintained in slide decks and repositories built for human readers. These approaches help organizations document decisions and communicate standards, but they struggle to keep pace with AI-assisted development and autonomous systems.

Organizations therefore face a new challenge: How can they increase agility and autonomy without weakening architectural consistency, while staying secure and compliant? Governance-as-Code answers that question by turning architectural rules into machine-readable policies that are evaluated automatically during development and deployment.

Governance-as-Code isn’t a replacement for Enterprise Architecture. It’s the operationalization of Enterprise Architecture governance.

Governance doesn’t always require the same level of control.

Gartner’s concept of Adaptive Enterprise Architecture Governance recognizes that different initiatives require different governance approaches. Depending on the context, organizations typically apply one of four governance styles:

• Control-based governance focuses on compliance with standards and on risk mitigation.
• Outcome-based governance focuses on achieving business objectives.
• Agility-based governance accelerates delivery through reusable assets and predefined patterns.
• Autonomy-based governance empowers teams to make decisions independently within defined guardrails.

Organizations want to move toward agility and autonomy without losing control. Governance-as-Code helps achieve exactly that.

Developers no longer have to wait for an architecture review on every change, because governance is embedded directly into development workflows and CI/CD pipelines, including AI-assisted development environments.

Many discussions about Governance-as-Code start with YAML files and policy engines in CI/CD pipelines. But governance starts earlier, in Enterprise Architecture.

Enterprise architects already define principles and standards, along with constraints and technology strategies. The challenge is that these decisions are often documented for humans but not consumable by machines.

Modelling them in ArchiMate is the first step. Architects can represent governance concepts such as:

• Principles
• Constraints
• Application Components
• System Software

A simple governance pattern could look like the one below.

Principles are refined into constraints for Systems of Record,
and the approved technologies are modelled as realizing them

EA Suites like ADOIT then act as the authoritative source of governance intent. They provide the principles and constraints, together with the classifications and architectural context, that guide technology decisions across the organization.

The architecture team models governance once. The organization consumes it everywhere.

Imagine an organization operating a Payment Platform. Within ADOIT, the Payment Platform is modeled as an Application Component, and the architects classify it as a System of Record.

Application classifications help organizations apply different governance approaches to different types of systems. A commonly used classification, often described in terms of pace layers, distinguishes between:

• Systems of Record are stable, business-critical systems that support standardized core processes, such as ERP or payment platforms.
• Systems of Differentiation support unique business capabilities and contribute to competitive advantage, such as industry-specific customer onboarding or pricing solutions.
• Systems of Innovation are experimental or rapidly evolving solutions designed to explore new technologies and business opportunities, including new customer experiences.

The Payment Platform falls into the first category because it supports a critical business capability and requires a high degree of stability and strict compliance controls.

This classification is important because governance shouldn’t be identical for every application. A payment platform requires different governance than an innovation sandbox or a prototype AI application.

The Application Component passes its classification down to its Application Services and Application Interfaces. As a result, the Payment API automatically inherits the governance profile of the Payment Platform.

This is adaptive governance in practice.

A developer wants to extend the Payment API. The developer doesn’t need to search through architecture documents or contact an architecture board. They open an AI-enabled development environment such as Cursor and enter the request there.

The developer asks the AI assistant in Cursor to create a new endpoint for the Payment API

Through its built-in MCP (Model Context Protocol) server, ADOIT retrieves the required governance style from the Application Component that provides the API …

The Payment API is part of the Payment Platform and inherits its System of Record classification.

… and returns the relevant governance context:

For Example:

application: Payment Platform 
classification: 
  system_of_record 
principles: 
- Use Approved Technologies 
constraints: 
  - Java or Go only 
- OAuth2 required 
  - Architecture review required 

The repository now actively provides governance information to the development process.

Pace-layer classifications such as Systems of Record, Systems of Differentiation and Systems of Innovation provide an excellent foundation for adaptive governance.

However, organizations can further refine governance by introducing additional classifications. One example is CIAA:

• Confidentiality
• Integrity
• Availability
• Accountability

While application classifications determine how much governance is required, CIAA classifications help determine which controls must be enforced. A system rated high for confidentiality and availability will require stronger security controls than one rated low on both.

Combining business and architectural context with risk classifications allows organizations to generate governance policies that are both adaptive and enforceable. For example, the Payment Platform may be classified as follows.

This additional context can also be retrieved through MCP and translated into further controls, such as mandatory encryption and audit logging, or backup requirements and multi-region deployment policies.

The retrieved governance information can now be combined into a single governance profile. For the Payment Platform, the System of Record classification and the CIAA ratings together produce the following:

yaml

governance:
  allowed_technologies:
    - Java
    - Go
  authentication:
    - OAuth2
  architecture_review_required: true
  security:
    encryption: required
    audit_logging: required
  resilience:
    backup: required
    multi_region_deployment: required

For a System of Record, the profile still requires an architecture review. A System of Innovation might not, which is exactly how adaptive governance matches control to context.

Depending on the target platform, this governance profile can be translated into a range of executable policy formats.

• Rego (OPA)
• Cedar
• Terraform Sentinel
• Kubernetes policies
• GitHub Actions workflows
• YAML-based configuration files

These policies become part of the Git repository and can be evaluated automatically during development and deployment.

The architecture team defines governance. The delivery platform enforces it.

Shifting left means moving governance checks to the earliest point in the delivery process. Architectural violations are identified while code is being created, not discovered later in a review meeting. Architects define reusable guardrails that scale across teams, so they no longer need to review every implementation manually.

Traditional governance checks a solution after it’s built.
Governance-as-Code applies the rules while it’s being built.

Many architecture tools have focused on making architecture easier for humans to consume, through simplified metamodels and intuitive interfaces, along with dashboards and presentation-ready views. These capabilities remain important, but AI-assisted software delivery adds a second audience, the machines that now help write and deploy code.

Traditionally, EA repositories have functioned primarily as systems of record. They store:

• Capability maps
• Application landscapes
• Technology standards
• Reference architectures

Governance-as-Code fundamentally changes this role.

When architectural policies can be retrieved through MCP and enforced automatically as executable rules, the repository begins to influence real-time decisions. The Enterprise Architecture repository itself evolves from a system of record into a system of action.

Architectural knowledge then shapes development decisions and deployment pipelines, including the solutions AI assistants generate.

AI-assisted development has made periodic architecture reviews too slow to govern how software gets built. Governance-as-Code closes that gap by turning architectural decisions into policies that apply during development. Those policies depend on the architecture behind them, though. Policy engines can only enforce what someone has defined, which makes Enterprise Architecture the foundation of the whole approach.

For organizations ready to act on this, the place to start is the architecture model. Once principles and classifications are modelled and connected to the systems they govern, every developer and AI assistant can work from them.

The future of governance is Enterprise Architecture that both humans and machines can understand.