DevOps and EA

DevOps and Enterprise Architecture were once seen as opposing forces — DevOps valuing speed and autonomy, EA valuing coherence and control. In mature enterprises they have converged: DevOps provides the delivery capability, EA provides the coherence, and platform engineering is where they meet. The pipeline has become an architectural surface, and infrastructure as code has made architecture a versioned, reviewable artifact.

The convergence is healthy. DevOps without EA produces fast delivery of incoherent systems; EA without DevOps produces coherent designs no one can deliver. Together, with the paved-road platform as the shared instrument, they produce fast delivery of coherent systems — the combination that wins.

This page covers the DevOps foundation, the pipeline as architecture, infrastructure as code and GitOps, platform engineering as EA's delivery arm, DORA metrics, and how EA governs DevOps through enablement rather than gates.

DevOps rests on four pillars — Culture, Automation, Measurement, and Sharing. Culture is the shift from siloed dev and ops to teams owning what they build end-to-end. Automation is the removal of manual handoffs through CI/CD and infrastructure as code. Measurement is the use of metrics (DORA) to guide improvement. Sharing is the cross-team visibility that prevents reinvention.

EA's relationship to DevOps runs through all four. Culture: EA must work with teams organised around products and value streams, not projects. Automation: EA's standards become enforceable in the pipeline. Measurement: EA's governance shifts from activity metrics to outcome metrics. Sharing: the reference architecture and patterns become the shared, reusable assets.

The common failure is adopting DevOps automation without the culture — automating a broken handoff rather than removing it. The same applies to EA: governing DevOps through gates rather than enablement reproduces the old friction in a faster pipeline. The convergence requires the culture change, not just the tooling.

The CI/CD pipeline has become an architectural surface. What it enforces — security scans, IaC validation, compliance checks, deployment standards — is architecture delivered as code. A pipeline that requires signed images, approved IaC modules, and passing tests before deploy is enforcing the reference architecture by construction, not by review.

This shifts EA's leverage. Standards encoded in the pipeline are followed by 100% of deployments through it; standards encoded in a document are followed by whoever remembers. The most effective modern EA governance moves as much as possible into the pipeline — policy-as-code — and reserves human review for genuine architectural judgment.

The architect's job expands to include the pipeline's architecture: what it gates, how it gates, and how teams can extend it. A pipeline that gates too little ships non-conformant systems; one that gates too much becomes a bottleneck teams route around. The discipline is proportionate, automated governance.

Infrastructure as Code (IaC) makes infrastructure declarative — described as the desired state in version-controlled code, applied by automation. This makes infrastructure reviewable, reproducible, and auditable in a way manual provisioning cannot be. Terraform, Pulumi, and Crossplane are the dominant tools; the choice is less important than the discipline.

GitOps extends IaC to delivery: the desired state lives in Git, and an operator (ArgoCD, Flux) continuously reconciles the real environment to it. Changes are pull requests, reviewed and merged; drift is automatically corrected. This makes the environment's history and changes as auditable as application code — a major governance and reliability gain.

For EA, IaC and GitOps mean the technology architecture is now a versioned, reviewed artifact. Standards can be encoded as approved IaC modules teams consume; environments are reproducible from the repository; and the snowflake server — the unmanaged, drifted configuration — is eliminated. This is architecture becoming engineering.

Platform engineering is where DevOps and EA most directly converge. The internal developer platform (IDP) embodies the reference architecture and standards as golden paths, and product teams consume it. The platform team is, in effect, EA's delivery arm — it makes the architecture real and usable rather than documented.

This shifts the EA posture from review-and-approve to build-the-road-and-teams-will-use-it. The platform's golden paths encode security, observability, compliance, and architectural patterns by default; teams using them are conformant without a review. Reviews then focus on genuine exceptions, not routine conformance.

The implication for EA organisation is significant: EA and the platform team must work as one, not as separate functions. EA defines the reference architecture; the platform team implements it; both own the golden paths. When they are separate, the platform drifts from the architecture and the architecture becomes irrelevant to delivery.

The DORA metrics — deployment frequency, lead time for changes, mean time to restore (MTTR), and change failure rate — are the established measures of delivery performance. Elite performers deploy multiple times per day with low change-failure rates and fast restoration; low performers deploy monthly with high failure rates.

EA governance should be measured against DORA, not against activity. A governance process that depresses deployment frequency and inflates lead time without improving change-failure rate is obstructing delivery without adding safety — a failing governance process. A governance process that enables elite DORA performance while maintaining conformance is succeeding.

This reorients EA from 'how many reviews did we hold?' to 'are governed teams delivering faster and safer than ungoverned ones?' The answer should be yes; if it is not, the governance is the problem, not the solution. DORA gives EA an honest mirror.

The convergence of DevOps and EA changes governance from gates to enablement. The paved road — a reference platform with security, observability, and compliance built in — is the primary governance mechanism. Teams use it because it is the fastest path; conformance happens because the road embeds the standards.

Exceptions still need governance, but the volume drops dramatically when the paved road covers the majority of cases. The Architecture Board's time shifts from routine approvals to genuine architectural questions — novel integrations, high-risk changes, and the evolution of the reference architecture itself.

The ultimate test, as with all governance, is whether teams choose the governed path because it helps them. A DevOps + EA convergence where teams prefer the paved road to their own is succeeding; one where teams build their own because the road is slow is failing, however well-architected the road is. Enablement, not enforcement, is the measure.