Governance programs don’t usually fail from missing policy. Most boards I’ve sat on already have a principles document, a review process, an exception form, some kind of vendor questionnaire. What they don’t have is a loop that closes, where each piece actually feeds the next one instead of sitting in its own binder. A decision gets made without an ADR. An exception gets approved without an expiration date anyone tracks. A vendor clears procurement before architecture ever sees the data flow. None of that shows up as a missing policy, it shows up as governance that exists on paper and does nothing under pressure.
I’ve written about each piece of this separately, the review board, the ADR discipline, the exception process, vendor risk, retirement. This one’s the connective tissue. Here’s how the pieces are actually supposed to fit together, and where I’ve watched programs quietly stop closing the loop.
The review board’s real job
Start with the Architecture Review Board, because it’s the piece everyone builds first and the piece most likely to collapse under its own scope. A board that tries to review every project ends up governing nothing, it burns an hour on one team’s API contract and never gets to the decision that actually carries blast radius. I’ve made the case before for a narrow docket in a small room, the ARB isn’t a gate for everything, it’s a forum for the handful of decisions per quarter that touch shared risk: identity, data residency, a new pattern that other teams will copy whether you sanctioned it or not.
The failure mode isn’t usually that the board is too strict. It’s that it’s strict about the wrong things and silent about the ones that matter, because nobody built a filter for what actually needs to land on that agenda.
Where ADRs actually plug in
The filter is the ADR. Not as documentation, as a control. I’ve argued this directly: an ADR functions as a governance control, not a documentation habit, the same way an audit trail is a control and not paperwork. The reasoning behind a decision has to survive the person who made it leaving the company, and it has to survive an AI coding agent that will happily undo an undocumented constraint the moment it looks unused.
Most ADR programs that die don’t die from neglect. They die from wrong granularity, someone writes one up for “adopt Prettier for the billing service” and skips the decision that actually locks in a vendor for five years. I’ve laid out the scope test that keeps ADRs from turning into tooling trivia, reversibility, blast radius, cost to unwind, and it has to live in the same chain as the ARB’s own blast-radius test above. If your ADR scope test and your ARB intake criteria are answering different questions, you’ve built two governance programs that don’t talk to each other.
Exceptions that actually expire
Every review process eventually produces exceptions, and this is where I’ve seen the most governance quietly rot. A credential issued for a limited pilot integration sat active for roughly four years after the pilot was abandoned, nobody owned it, nobody was forced to revisit it, and the exception form that approved it in the first place had no expiry field to begin with. I wrote about an exception process that actually expires because that’s the whole mechanism, not the intake form, the clock. An exception process only works as a risk control if it’s built to default to off, where the review cadence and the expiry state force the conversation instead of waiting for someone to remember to have it.
This is the piece I’d flag first if you’re auditing your own program. Pull your current exception log right now and check how many entries have no expiration date at all. If it’s more than a handful, you don’t have an exception process, you have a permanent amnesty program with extra paperwork.
The board that never votes to retire anything
New systems have a natural sponsor. Someone wants the budget, someone champions the business case, someone shows up to the ARB ready to defend it. Retirement has none of that, which is exactly why the board approves new systems constantly and almost never votes to retire the old ones. Decommissioning loses every budget fight by default, not because anyone decided legacy systems should live forever, but because nobody structurally has to answer for the ones sitting there costing money and attack surface.
The fix isn’t a decommissioning initiative, those get funded once and quietly die. It’s forcing every new-system proposal to name what it retires, and tracking sunset status in the same system of record as everything else, as a first-class state, not a note in a slide deck that nobody revisits.
Vendor risk and the RFP scorecard
Vendor risk is where governance most often shows up too late to matter, at contract signature, after the deal’s effectively closed and architecture’s role has shrunk to a yes/no gate on something already decided. I’ve made the case, with the actual breach data behind it, for moving vendor risk review to intake instead of contract signature, scoring identity and data-handling implications directly in the RFP rather than bolting a security questionnaire on at the end.
That only works if your principles document actually does something at scorecard time. Ten principles on a slide reviewed twice a year and opened by nobody in between isn’t governance, it’s decoration. The gap is TOGAF’s own “Implications” step, and I’ve walked through turning principles into weighted RFP criteria with worked examples on interoperability and vendor identity access. A principle that can’t become a pass/fail gate or a scored line item isn’t a principle yet, it’s a value statement.
What actually closes the loop
None of this holds together as five separate programs. The ARB’s blast-radius test, the ADR scope test, the exception expiry clock, the retirement tracking, the RFP scorecard, they’re one governance loop or they’re nothing, five binders that reference each other in theory and drift apart in practice. What actually closes it, in my experience, is refusing to let any of it live in a wiki or a slide. I run all of this through one EAM system of record, and the reason isn’t the tooling itself, it’s that a single system of record is what forces ADR capture and portfolio mapping to become an operating discipline instead of something people mean to get around to.
This isn’t optional anymore in the way it used to be. NIST CSF 2.0 elevated Govern to a standalone function alongside Identify, Protect, Detect, Respond, and Recover, and most EA teams I talk to are already running the practices it requires, the ARB charter, the ADRs, the vendor review. What’s changed is that Govern is now a named, auditable function, not an implicit best practice you could quietly deprioritize when budget got tight. State legislatures are starting to write versions of it into law independently. Treating it as a compliance checkbox misses the point, the practices were already the job. The checkbox just means someone’s finally going to ask whether the loop actually closes, or whether you’ve got five well-intentioned programs that stopped talking to each other somewhere around year two.
That’s the test I’d apply to any governance program, yours included. Not whether the policy exists. Whether an exception from eighteen months ago got revisited, whether last quarter’s ADR actually shaped this quarter’s ARB agenda, whether the system nobody uses anymore has a retirement date on it or just a “legacy” tag nobody acts on. If the answer’s no across the board, you don’t have a governance gap. You have five governance programs that never learned to talk to each other, and that’s a smaller, more fixable problem than it sounds like.