Somewhere in almost every company there is a diagram that claims to be the architecture. It is laminated on a wall near the engineering floor, or it is a PDF in a governance folder, last edited by someone who has since left. It shows the target state: the boxes, the approved integration patterns, the layers stacked in the correct order, the arrows pointing the way data is supposed to flow. It is careful, it is often beautiful, and it is completely powerless.
It is powerless because it describes intent, and intent is not a control. The systems the teams actually shipped diverged from that diagram the day after the review board approved them, and nothing in the toolchain noticed, because nothing in the toolchain was watching. Enterprise architecture, as most organizations still practice it, is a documentation exercise wearing the costume of a governance function. It produces artifacts that describe how things ought to be and holds no mechanism to make them so.
I want to be precise about where I sit, because this is a seat-above-mine topic and I am reasoning up toward it. I don't run an enterprise architecture function and I have never owned the enterprise IT P&L. I run security and DevOps in a regulated fintech, and my team built a governed internal platform with real users. From the delivery side I watch which architecture decisions hold and which evaporate. The pattern is boringly consistent. The decisions that hold are the ones something enforces. The rest are opinions with a diagram attached. So here is the claim: enterprise architecture did not fail because it was too ambitious. It failed because it shipped posters. Bring it back as guardrails.
The diagram is a snapshot of an intention
The frameworks are not the problem. TOGAF and its architecture development method, ArchiMate as a modeling language, the C4 model for describing a system at different zoom levels: these are genuinely useful ways to think, and the discipline of drawing a system before you build it is worth keeping. The failure is downstream of the drawing. The model is produced once, at design time, and never reconciled against the running system again.
So drift starts immediately. Conway's law reshapes the system around the team boundaries the diagram never anticipated. A vendor gets swapped, a service gets split under load, an integration that was supposed to be asynchronous becomes a synchronous call because a deadline demanded it. Six months later the diagram describes a company that no longer exists, everyone quietly knows it, and they stop consulting it. The artifact turns into archaeology: accurate about a past state, mute about the present one.
The deeper problem is that a review board approves a design, not a system. Approval is a point-in-time event. The system is a moving object. You approved the intention and you have no hold on the implementation, and the gap between the approved architecture and the running architecture is exactly the gap that examiners, security incidents, and the next re-platforming all fall into. A control that only exists at the moment of approval is not a control. It is a memory.
Ship three things, not a target-state slide
An architecture function that actually wants to govern ships three products, not one document. None of them is a future-state slide.
- Reference patterns. Opinionated, working, forkable starting points for the handful of system shapes your company actually builds. Not diagrams of them: the things themselves, in a repo.
- Paved roads. The golden path that is genuinely the fastest way to get to production, so teams take it because it is easier, not because a policy told them to.
- A small number of enforced constraints. The few things that must always be true, expressed as code, checked by a pipeline, and capable of failing a build.
Everything else (the aspirational diagrams, the capability maps, the future-state architecture that assumes three re-orgs and a budget you don't have) is thinking material. It is useful to the architects and invisible to the systems. Keep it. Just stop confusing it with governance. Governance is the part a machine can enforce while everyone is asleep.
Reference patterns are forkable, not aspirational
A reference pattern is not a diagram of how you would build the thing. It is the thing, built, sitting in a repository, that a team clones on day one. A service template with logging, identity, and the encryption defaults already wired in. An infrastructure module that provisions the compliant version of a data store because the non-compliant version was never parameterized in. The pattern earns adoption by being the shortest path to a running system, not by being the mandated one.
The failure mode is the "reference architecture" that is a document describing a system nobody has built. It asks every team to re-derive the same decisions from prose, and they derive them differently, because prose is ambiguous and deadlines are not. Two teams read the same paragraph about "appropriate encryption in transit and at rest" and ship two different implementations, one of which is wrong. Ship the pattern as code and the interpretation problem disappears. There is one implementation, it is the one you maintain, and improving it improves every system that forked it.
Team Topologies, the Skelton and Pais book, has the frame I keep returning to: run the platform as a product, and treat the paved road as its interface. Netflix is where a lot of us first heard "paved road" as a phrase. The shared idea underneath all of it is that the standard has to be the easy choice. Curbs, not tunnels. Wide enough that a team can do real and unusual work inside them, high enough that leaving the road is a deliberate decision rather than an accident nobody noticed until the audit.
The constraint that isn't in the pipeline isn't a constraint
This is the heart of it. The move that converts architecture from advice into governance is taking a small set of invariants and putting them into the toolchain as executable checks. The discipline even has a name. In Building Evolutionary Architectures, Ford, Parsons, and Kua call them fitness functions: automated tests for architectural characteristics, run continuously, that fail when the system drifts outside tolerance. An architecture you can test is an architecture you can defend. An architecture you can only draw is an architecture you can only hope about.
In practice this looks like policy-as-code. Open Policy Agent with conftest to evaluate configuration and infrastructure plans against written policy; checkov or tfsec for infrastructure baselines; HashiCorp Sentinel where Terraform Cloud is in the path. The tool is not the point. The point is that the check runs in the pipeline, on every change, and a violation fails the build the same way a broken unit test fails it: visibly, automatically, before anything reaches production, with no human required to remember to look.
The hard part is restraint, and this is where most attempts die. A pipeline that enforces two hundred rules is a pipeline that teams learn to disable, and a disabled control is worse than no control because it also carries the false comfort of a green check. So pick the constraints that are genuinely invariant (no unencrypted data store, no public network path to regulated data, no service without an identity, no deploy without logging wired to the central pipeline) and enforce those absolutely. Be silent about everything else. A short list, enforced without exception, changes behavior. A long list, enforced by nagging, changes nothing except the team's opinion of the platform team.
The reframe I can't unlearn is this: the architecture is whatever the pipeline enforces. Not what the diagram claims, not what the review approved, not what the standards document asserts. If a rule is not in the pipeline, it is a preference, and preferences lose to deadlines every single time. We built AgentOS, our governed internal agent platform, on exactly this premise. Its architecture is not a diagram in a wiki. It is the reference pattern a team forks to ship an agent and the constraints the control plane enforces before anything runs. The governance is not a meeting someone attends. It is the set of checks the platform will not let you skip, and that is the entire difference between a control and a suggestion.
The review board curates the road, it doesn't wave the traffic through
Reframing the artifacts reframes the body that owns them. In the diagram model, the architecture review board is a gate: every significant design comes to a meeting, gets discussed, gets approved or sent back. That model becomes the bottleneck the whole company routes around, and its approval has almost no purchase on what ships once the meeting ends.
In the guardrail model, the review board owns two things and reviews almost no individual designs. It owns the pattern catalog and it owns the constraint set. Its job is to decide what the paved road looks like and which invariants the pipeline enforces, then to maintain both as the estate and the regulatory picture evolve. It stops inspecting traffic and starts curating the road everyone drives on. That is a smaller number of higher-leverage decisions, made once and encoded, instead of a hundred point-in-time approvals that decay on contact with delivery.
What is left for humans is the exception, which is where human judgment belongs. When a team needs to leave the paved road, for a genuinely novel system shape or a constraint that has to bend for a defensible reason, that conversation is now rare enough to have properly instead of rushing. Record it. Architecture Decision Records, the lightweight format Michael Nygard popularized, are the right artifact: short, versioned, living in the repo next to the code, capturing what was decided and why. An ADR is the one document that survives, precisely because it lives where the work lives and answers the question someone will otherwise re-litigate from scratch in a year.
Make the architecture executable
Stop shipping target-state diagrams as if they govern anything; they inform, they do not enforce. Ship reference patterns as code teams fork, not prose they will interpret wrongly under deadline. Enforce a short list of invariants in the pipeline and stay silent about the rest, because a control's power comes from being few and absolute. Reconvene the review board around the road and the rules instead of the traffic.
The test for whether you actually have an architecture is blunt. Name a constraint, then find the line in the pipeline that enforces it. If you can't find the line, you don't have an architecture. You have a diagram.