Governance Operating Model
The arrangement of decision rights, review points and automated controls through which architectural intent is maintained across an organisation.
Governance fails in two opposite directions, and both stem from the same cause: decisions made at the wrong distance from the work.
Too centralised produces a queue: teams wait, decisions are made by people without context, and the outcome depends on who is in the room. Teams route around it. Too devolved produces an estate with no coherence, duplicated capabilities and inconsistent security posture.
The model that works distributes decisions by consequence and reversibility:
Automated policy for anything mechanically checkable — dependency direction, forbidden versions, API compatibility, security configuration, licence compliance. This replaces most of what review boards were doing, and does it on every commit rather than at a checkpoint.
Team decision rights, published, for everything reversible and local. Publishing what a team may simply decide is most of the governance improvement in most organisations.
Advisory review for significant designs — early, and structured as a service teams want rather than a gate they must pass.
Escalation reserved for the genuinely irreversible: data models, public contracts, vendor commitments, regional topology.
The health signals to watch: lead time for architectural decisions, fitness function pass rates, and exception volume — where a rising exception rate means a rule is wrong rather than that teams are non-compliant.