A board that reviews everything ends up governing nothing. I’ve sat through review meetings that burned a full hour on one team’s API contract, argued clause by clause, while the actual risk in the portfolio sat three agenda items down, untouched, ticking. The fix isn’t more rigor in the room. It’s a shorter, sharper definition of what the room is actually for.
I hold one of these seats myself, and I take the calendar invite seriously enough that it changes how I spend the rest of my week. The decisions this board signs off on get built on for years, sometimes longer than anyone in the room expects, which is exactly why I want the docket narrow and the authority on it real.
Scope the docket by blast radius, not by project size
An ARB earns its meeting time on decisions no single domain owner can see end to end, shared infrastructure changes that cross value streams, exceptions to enterprise standards, a new platform category entering the environment, anything that touches a cyber, data, or cloud guardrail. It has no business reviewing an application design that already fits the reference architecture, or a low-risk implementation choice, or every project that happened to type the word “architecture” into its charter document. A board whose calendar reads like a PMO queue picked the wrong docket, and I’d argue it picked it on purpose, because a narrow docket means someone has to say no to a lot of well-meaning people.
The Azure incident from February 2026 makes the point, and it never went anywhere near a project review. A policy remediation job got applied to a broader set of Microsoft-managed storage accounts than anyone intended, which blocked the public read access that VM agents need during provisioning. The cascade took down virtual machine deployments and managed identity token issuance across multiple regions for hours, according to Microsoft’s own Azure status history for the incident. Nobody had asked, ahead of time, what happens if that remediation policy applies more broadly than intended on shared infrastructure. That’s the question. Asked before the change goes wide instead of after, it’s precisely what an ARB is for. Spend the board’s cycles arguing over a team’s microservice boundary and there’s no time left for the one question that can actually take the company down.
Six to eight seats, chosen for risk exposure, not politics
I keep the voting seats around six to eight: cybersecurity, infrastructure and platform, data, and the value-stream architecture leads, the ones who map to how the business actually makes and delivers money, not to how the org chart happens to be drawn that quarter. A subject-matter seat rotates in when the topic needs it, and that’s fine, that’s the system working. What I resist, every time it comes up, is adding a permanent chair for every function that wants a vote, because a board built for political coverage is a board built for slow, mushy decisions, and I’ve watched that happen too many times to pretend otherwise. I’ve made this argument before about why the federated EA model beats both the ivory tower and fully distributed extremes, and it holds here just as well: a small central group with real authority over a short list of guardrails outperforms a large representative body chasing consensus.
Solution rationalization lives here too. When two architects sitting on the same board are each quietly sponsoring a tool that solves the same problem, that’s a catch for this room, not something procurement discovers six months later staring at two invoices for one capability. Every domain believes, genuinely believes, it needs to own its own stack. Most of the time it doesn’t. The board’s job is to ask whether the enterprise needs two of them, out loud, before the money’s spent.
An exception is only governance if it has an expiration date
The most valuable thing this board produces most weeks isn’t an approval. It’s a time-boxed exception. TOGAF’s architecture change management guidance has said this for years, when a project can’t meet a standard, the risk, the compensating control, the accountable owner, and the review date all get recorded, not just the waiver itself, per the Open Group’s TOGAF 9.2 guidance on architecture compliance and governance. A waiver with no expiration date is just permission that never gets revisited, and I don’t care how it’s dressed up, that’s not governance. Every exception this board grants gets a hard date, gets logged as an ADR against the affected capability in our EAM tool (LeanIX, in my case, and I’ll say so plainly since I recommend it to anyone who asks), and comes back to the board automatically when the clock runs out. No default renewal, none, ever. The team either closes the gap or comes back and makes the case again with current facts, not the facts from six months ago.
AI agents are already testing whether this discipline holds
Teams are standing up their own AI agents faster than any review process was ever built to handle, and that makes the exception discipline matter more right now, not less. Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, and the drivers cited are escalating costs, unclear business value, and inadequate risk controls. That last one, right there, is the board’s business. Not every AI pilot belongs on the docket, I want to be clear about that, burying the board in pilot reviews would defeat the whole purpose. But an exception to skip identity guardrails or data handling standards so a team can move faster on an agent prototype belongs there every single time: time-boxed, logged, revisited. AI coding tools have made it cheap, almost trivially cheap, to build a one-off integration or a bespoke agent instead of reusing what already exists. Same failure mode I laid out in the piece on why companies skip reuse and default to build. It’s just arriving faster now, because the tooling lowers the perceived cost of building and nobody feels the real cost until later.
Picture the meeting working the way it should. Thirty minutes, four items, no slides. First: a platform team wants to replace its message queue across two value streams, approved, with a follow-up ADR requirement attached. Second: an exception request to bypass the standard identity provider for an agent prototype, granted for ninety days, logged in LeanIX, owner named, calendar reminder set for the review date. Third: a data team flags that its planned event-streaming buildout duplicates a capability another domain already owns, so the board tables the new build and sends both teams off to reconcile. Fourth: last quarter’s expired exception comes back up automatically, the underlying gap still isn’t closed, and the board declines to renew it without a harder deadline and a named executive sponsor attached to it. Nobody debated a microservice boundary. Nobody drafted a slide, I already said that, but it’s worth saying twice. Four decisions got made that no single domain owner was positioned to make alone, and every one of them is written down somewhere the next architect will actually find it, which is the entire point.
Photo by Amsterdam City Archives on Unsplash