I came across a cartoon last week that I haven't been able to stop thinking about. A bull labeled AI Hype, Silver Bullet, Vendor Promise, Quick Win, and Refactor Later is charging at a stone archway marked ARCHITECTURE. A calm figure stands in front of it, hand raised, saying: "Not everything gets through the gate." The caption underneath read: Good architecture isn't about letting everything in. It's about knowing what to keep out.
It's a sharp image, and it's mostly right. But it gave me an uncomfortable thought that I want to sit with honestly, because it's the thing I actually wrestle with in practice.
The gate isn't the hard part. Standing at it and being allowed to, is
The perception we're quietly fighting
Most people outside the function still believe enterprise architecture is the team that draws the diagrams. You hand us a decision that's already been made, we make it look coherent on a slide, and everyone moves on—architecture as decoration. Architecture is the department of pretty rectangles.
The reality is that the value of the work sits almost entirely in judgment — deciding which options deserve investment, which assumptions need testing, and which proposals will create more problems than they solve. That's a much harder thing to make visible than a diagram. You can photograph a solution. You can't easily photograph a bad idea that didn't happen because someone asked the right question at the right time.
So we carry a structural disadvantage: our best work is invisible, and our most visible work is the part anyone can criticize.
The narrative that dilutes the role
Here's the move I've learned to watch for, because it's so reasonable on the surface that it slips past almost everyone.
A new technology shows up. Maybe it genuinely solves a problem. The framing arrives pre-packaged: "This is just capacity expansion. We already do this category of thing. It doesn't need an architecture assessment — operations can stand it up."
Every clause in that sentence is plausible. And together they quietly relocate an architectural decision out of architecture's hands. Capacity expansion sounds like more of the same; often it's a new vendor, a new data path, a new integration pattern, and a new long-term cost we'll be operating for a decade. Operations can handle it, which is true for running the thing, and exactly wrong for deciding whether the thing should exist in our estate at all.
I want to be careful here, because the cynical read is that this is always about procurement games or someone's preferred supplier. Sometimes it is. Usually it isn't. Most of the time, it's just speed — a leader under pressure to deliver, choosing the path with the fewest gates. Intent doesn't actually matter to the outcome. Whether the motive is a kickback or an honest deadline, the result is the same: a decision with enterprise-wide consequences gets made without enterprise-wide visibility, and the standardization roadmap we're trying to build picks up another exception nobody recorded.
That's the part I'll say plainly. The damage isn't the deviation. The damage is the undocumented deviation — the one that doesn't make it onto the radar, so the next team inherits it as the standard.
Accountability is the real gatekeeper, not the architect.
If the role keeps getting diluted, the fix isn't a louder architect at the gate. It's clarity about who is accountable for what. Responsibility for delivering capacity can sit with operations. Accountability for whether a technology choice conforms to the target architecture has to sit somewhere named and explicit — an Architecture Board, a review checkpoint, a decision right written down. When that accountability is fuzzy, the narrative wins by default, every time, because the path of least resistance always does.
This reframes the architect's job in a way I find more honest. Our role is not to veto. It's to make sure decisions are made with eyes open and recorded. A function whose only move is "no" gets routed around. A function that ensures every significant choice is visible, deliberate, and owned becomes very hard to bypass — because bypassing it now means choosing, on the record, to make a decision blind.
On deviations, and the document nobody talks about
So what happens when a deviation is forced — when management, for whatever reason, overrides the recommendation and adopts something the Tech Radar would have put in Hold?
For a long time, my instinct was to document it carefully in an Architecture Decision Record (ADR) and move on. But that creates a trap I walked into more than once. Write the ADR too honestly, and it reads like a charge sheet against a named leader. Soften it to protect the relationship, and you've destroyed the one thing an ADR is for: an honest account of context, options, and consequences. You cannot make a single document both fully candid and politically weightless. Trying to is how you end up with records nobody trusts.
The way out is separation, and it's an old idea that's underused. Keep the ADR strictly decision-centric — institutional voice; the decision attributed to a governance body or role rather than a person; and trade-offs stated as accepted consequences, not accusations. Then put the deviation where it belongs: in a dispensation — a waiver, in TOGAF's language; an exception or variance record in other frameworks.
A dispensation is built precisely for this. It's a time-boxed, conditional exemption from a standard, granted through governance, that records the scope, justification, compensating controls, named risk owner, and — crucially — the expiry date and the path back to the standard. It changes the grammar of the whole thing. A deviation logged as a violation reads as someone's failure. The same deviation logged as a dispensation reads as a managed, owned, temporary exception with a return route. One is a black mark. The other is governance doing its job.
That single shift — from violation to managed exception — is what lets you stay objective without turning your decision log into a record of management's sins. You're not hiding the deviation. You're giving it a respectable, owned, expiring home, and you're forcing the quiet conversation it deserves: if we're stepping off the standard, when and how do we step back on?
Back to the gate
The cartoon is right that not everything should get through. But after years of standing near that gate, I've come to think the better image isn't a wall. It's a customs desk. Some things pass freely. Some get inspected. And some pass with a declaration — logged, conditional, and accountable — precisely so that the next person through knows exactly what came before them.
The architect's authority was never really the power to keep things out. It's the power to ensure nothing important passes unseen.
If this resonates — or if you think I'm wrong about the veto — I'd genuinely like to hear how your organization handles forced deviations. The comments are the interesting part.