Enterprise architecture governance has always carried a difficult mandate: helping organizations move faster without allowing technology decisions to fragment, duplicate or create unacceptable risk. In large enterprises, that mandate is usually executed through review boards, standards, approved patterns, reference architectures and experienced architects’ judgment. These mechanisms remain necessary, especially in regulated environments, but are increasingly strained by cloud adoption, AI systems, managed services, data platforms and continuous delivery.
Most organizations do not lack architectural intent. They have security standards, cloud patterns, integration principles, data-classification policies, resilience expectations, review forums and exception processes. Too much of this intent remains trapped in documents, slide decks, meeting notes and expert interpretation. That model can work when architecture change is episodic, but it becomes harder to scale when teams are continuously changing APIs, cloud configurations, data flows, identity patterns, observability settings, dependencies and third-party service integrations.
Architecture-as-code offers a different operating model. Instead of treating architectural standards as documents to be interpreted manually, it treats architectural intent, approved patterns, evidence requirements, exceptions and review outcomes as machine-readable artifacts that can be versioned, evaluated, tested and observed. The goal is not to reduce enterprise architecture to infrastructure-as-code, but to make architectural constraints and evidence expectations executable enough to participate in the software delivery lifecycle.
The idea has parallels in software architecture and platform engineering. Thoughtworks has discussed architecture-as-code in the context of fitness functions, while the evolutionary architecture community has used fitness functions as automated checks that preserve architectural characteristics as systems evolve. The next step is applying similar thinking to enterprise architecture governance.
From point-in-time review to continuous architecture assurance
In many enterprises, architecture governance is still organized around a point-in-time review model. A team prepares a design package, presents it to an architecture review board, receives feedback, records decisions or exceptions, and proceeds into delivery. This model remains useful when a system is new, high-risk or materially changing because it creates a forum for judgment, enterprise alignment, risk acceptance and trade-offs.
Its weakness is that software systems do not remain static after the review meeting. APIs change, authentication patterns evolve, cloud services are added, data flows expand, observability settings drift and implementation details diverge from original design assumptions. In traditional governance models, that drift often becomes visible only during a later review, an audit, a production incident or a security assessment.
Architecture-as-code creates the possibility of moving from episodic review to continuous architecture assurance. The analogy is automated testing. Software teams did not eliminate human judgment about quality, but they moved repeatable checks into the delivery pipeline so regressions could be detected earlier and more consistently. Architecture governance can follow a similar pattern: review boards should still handle judgment, trade-offs, exceptions and accountability, while basic conformance checks become executable and repeatable across the software lifecycle.
This is not a purely theoretical direction. The second edition of Building Evolutionary Architectures explicitly connects fitness functions with the automation of architectural governance, while Open Policy Agent provides a well-established policy-as-code precedent for enforcing rules across microservices, Kubernetes, API gateways and CI/CD pipelines. In both cases, the underlying lesson is similar: when important system properties can be expressed as executable checks, governance can move closer to the point where change happens.
In practice, this means architecture evidence can be evaluated when a design brief changes, when an OpenAPI specification is updated, when infrastructure configuration is modified, when a pull request introduces a new dependency or when a service is promoted toward release. The goal is not to turn architecture governance into a rigid gate for every code change. It is to make architectural drift more visible and to surface evidence gaps before they become late-stage delivery risks.
A governance workflow for software delivery
A practical architecture-as-code workflow should sit inside the software delivery lifecycle, not outside it. It should not wait until a final review meeting to discover basic gaps. It should evaluate architecture evidence as part of design iteration, pull requests, CI/CD runs, release readiness checks and periodic posture reviews.
This structure is deliberately layered. Deterministic controls handle what should be deterministic. Human review handles what requires accountability and judgment. AI assists with interpretation and review preparation, but it does not own the decision.
Nitesh Varma
Figure 1: Architecture-as-code embeds governance into the software delivery lifecycle. Design intent and implementation evidence are evaluated through deterministic controls, interpreted by AI-assisted review, and returned to human architects for judgment, exceptions and risk acceptance.
The critical move is comparing what a team claims architecturally with what the implementation evidence shows. Many governance processes rely too heavily on what the design package says. A team may declare that a public API uses an approved identity pattern, that sensitive data is classified, that observability requirements are met or that a threat model exists. Those claims may be accurate, but they still need supporting evidence.
A stronger model compares declared intent with observable implementation signals. If a design brief says a public API uses OAuth/OIDC, but the OpenAPI specification defines an API-key security scheme, the governance issue is not simply that authentication failed. It is that implementation evidence does not support the declared architecture intent. The team may need to update the implementation, correct the design brief or submit a time-bound exception with compensating controls.
Similarly, if a public webhook has proper authentication evidence but no threat model or architecture decision record, the right conclusion may be “needs more evidence,” not “non-compliant.” Governance should distinguish between direct control violations, missing evidence, incomplete documentation, contextual risk and passed controls. That classification makes governance more useful to engineering teams and more defensible to security, risk, audit and compliance.
The role of AI: interpretation, not authority
The rise of agentic AI makes architecture-as-code more interesting, but also more dangerous if framed poorly. The wrong framing is that AI will automate the architecture review board. That would be naïve. Architecture approval involves accountability, risk acceptance, organizational priorities, cost, regulatory obligations, delivery sequencing and long-term platform direction. Those are not decisions that should be delegated to an LLM.
AI’s more credible role is downstream of deterministic evaluation. Once controls-as-code have produced findings, an AI-assisted governance layer can interpret them, draft remediation guidance, identify review questions and prepare an architecture review narrative. It can help architects distinguish hard violations, evidence gaps, design-implementation mismatches and possible exception candidates.
For example, a deterministic control engine might produce the following result:
AUTH-001: Claim/evidence mismatch
Design brief declares OAuth/OIDC.
OpenAPI implements API key.
Outcome: human review required.
CI action: require review.An AI-assisted governance layer can turn that into a more useful review narrative:
The primary governance concern is that the implementation evidence contradicts the declared authentication pattern. Before this design can proceed, the team should either align the OpenAPI specification and implementation with the approved OAuth/OIDC pattern or submit a time-bound exception with compensating controls. The missing threat model and incomplete observability evidence further prevent the package from being approval-ready.
The AI is not deciding the outcome; it is preparing the human review.
The same AI layer can perform a reflection pass, checking whether its narrative overstated a finding, softened a deterministic failure, confused missing evidence with confirmed non-compliance or introduced unsupported claims.
To make that separation concrete, I built a small architecture-as-code sandbox using bounded API governance scenarios. It is not a production governance platform. It is a working demonstration of the operating pattern: design intent is declared, implementation artifacts provide evidence, controls-as-code evaluate the package, a deterministic policy gate assigns a bounded posture, AI assists with interpretation and human architects remain accountable.
A project registry points to design briefs, OpenAPI specifications, architecture decision records, threat models and evidence files. Controls then evaluate whether the declared design intent is supported by the actual implementation artifacts.
The most useful sample case was a public customer-profile API where the design brief declared OAuth/OIDC, but the OpenAPI specification implemented API-key authentication. The deterministic engine classified this as a claim-evidence mismatch, assigned the case to human review and generated remediation guidance. The AI-assisted layer then produced a review narrative and reflection check but did not change the outcome.
Other samples exercised different governance postures. A public webhook with authentication but no threat model or architecture decision record produced “needs more evidence,” while a public API with no authentication produced “does not meet standard.” These distinctions matter because enterprise architecture governance should not treat every gap as the same kind of issue.
Architecture governance becomes part of delivery
One important implication is that architecture governance becomes observable. A review is no longer just a meeting, a diagram or a document attached to a ticket. It becomes a run with inputs, controls, evidence, findings, policy outcome, remediation guidance and review artifacts. In the sandbox, I used MLflow as a lightweight run ledger to capture governance metrics and review artifacts for later inspection.
This does not eliminate formal approvals, but it gives them a stronger evidence base and useful operating history. Architecture leaders could see which controls fail most often, where evidence is frequently missing, which patterns generate exceptions and where standards may be unclear.
This matters even more as organizations adopt AI systems, which increase the need for architectural discipline around data flows, observability, model interactions, security boundaries, policy constraints, operational ownership and runtime monitoring. If governance remains manual and episodic, it will struggle to keep pace. If it becomes executable and observable, it can become part of the delivery system.
The danger is automated governance theater. A system can generate polished reports, plausible AI narratives and dashboards while still resting on vague standards or incomplete evidence. Automation does not fix unclear architecture principles. AI does not compensate for missing accountability. A policy gate is only useful if the underlying controls are meaningful.
Enterprises should therefore treat architecture-as-code as an operating-model change, not just a tooling pattern. The model works only when standards, approved patterns, evidence expectations and exception processes are explicit enough to be evaluated consistently. Exceptions need owners, expiry dates and rationale; deterministic controls need to remain separate from AI interpretation; and human accountability must remain visible throughout the process.
This is why the agentic AI layer should be bounded. It can summarize, interpret, critique, prepare review materials, propose architecture board questions and identify missing artifacts. But it should not override policy gates or approve high-risk designs. The stronger architecture is one in which deterministic controls produce the governance posture, AI explains it and humans decide what to do.
The strategic shift is that architecture governance can move closer to the rhythm of software delivery. Not every architecture concern becomes a CI/CD rule, and many decisions will still require judgment, negotiation and risk acceptance. But many governance signals can be surfaced earlier, more consistently and with better evidence.
The goal is not to replace the architecture review board with software. It is to ensure that architecture review is no longer confined to a single meeting, a static document or a one-time approval. Like automated testing, architecture governance should become a repeatable signal that travels with the system as it changes.
Architecture-as-code creates the foundation, agentic AI adds a reasoning and narrative layer, CI/CD provides the control point, run logging provides observability and human review preserves accountability.
As systems become more distributed, cloud-based, AI-enabled and continuously delivered, enterprise governance cannot depend on static standards and periodic reviews alone. Architecture-as-code offers a path toward governance that is executable, evidence-driven, observable and accountable to human judgment.
This article was made possible by our partnership with the IASA Chief Architect Forum. The CAF’s purpose is to test, challenge and support the art and science of Business Technology Architecture and its evolution over time as well as grow the influence and leadership of chief architects both inside and outside the profession. The CAF is a leadership community of the IASA, the leading non-profit professional association for business technology architects.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?