Architecture Governance in Large Technology Programs
Governance earns its keep when it speeds decisions up, not when it slows them down. A working model for architecture governance inside large infrastructure programs.
Editorial note: This is a sample article included with the initial site build. Its publication date is editorially assigned to demonstrate the blog's historical-date capability and can be changed in the frontmatter.
"Architecture governance" has a deserved reputation problem. In too many programs it means a monthly meeting where slides are reviewed six weeks after the decisions were actually made. The delivery teams learn to route around it, and the governance function learns to rubber-stamp.
Governance that works has one measurable property: decisions happen faster with it than without it. Here is the model I use on large infrastructure and security programs.
Three artifacts, nothing more
1. A decision record, per decision
Every significant technical decision gets a short, numbered record: context, options considered, decision, consequences. Not a template with forty sections — one page. The archive of these records becomes the program's institutional memory, and six months later it answers the question every program eventually asks: "why on earth did we do it this way?"
2. Standards that fit on a wall
A standard that nobody can remember is documentation, not governance. Standards earn their place by being short, versioned, and paired with the reason they exist. "All inter-zone traffic passes inspection — because our regulator requires demonstrable segmentation" survives contact with delivery teams far better than a 60-page policy.
3. A review board that decides
The review board exists to make decisions, not to witness them. Practical rules that keep it honest:
- Anything submitted with a completed decision record gets a decision within one cycle.
- The board's output is one of three words: approved, approved-with- conditions, or declined-with-reasons.
- If the board cannot decide, the item escalates immediately — it does not return to the queue.
Where governance should be automatic
Human review is expensive; spend it only where judgment is required. Everything that can be checked mechanically should be:
- Policy-as-code guardrails in cloud environments
- Configuration compliance scanning against the published standards
- Pipeline checks for naming, tagging, and placement rules
The politics are the work
The honest part nobody writes down: governance succeeds or fails on sponsorship. A review board that has never been backed by an executive when it declined something popular is advisory, and everyone knows it. Securing that backing — and spending it rarely and visibly — is as much a part of the architect's job as any diagram.
Summary
Keep three artifacts: decision records, short standards, and a board that decides. Automate every check that does not require judgment. Measure the governance function by decision latency, and defend it with real sponsorship. Programs run this way spend their meetings arguing about the future instead of documenting the past.