Your Governance Framework Is Thorough, Well-Documented, and Mostly Ignored.
Governance failure in large organizations rarely announces itself. It accumulates quietly — in the exception requests that always get approved, the review processes that always run late, the policies that teams know exist and have quietly stopped consulting. This article names the patterns. You'll recognize some of them.
The Governance Document Nobody Had Read in Eighteen Months
The discovery came during a platform maturity assessment. The consulting team asked a governance question and was directed to a SharePoint folder containing the organization's enterprise architecture governance framework — a 94-page document last updated in the third quarter of the previous year. It was thorough. It was professionally formatted. It had a table of contents, an executive summary, and a clearly-worded section on architectural review processes.
Asked whether their teams used this document regularly, three of the five people in the room looked uncomfortable. One admitted that the architecture review board referenced it occasionally, but mostly from memory. Another noted that the document existed primarily because the organization had needed to demonstrate governance capability to an auditor. A third observed that several of the policies in it were no longer accurate for the current environment.
The organization had governance. What it didn't have was a governance program that was actually governing anything.
This is the most common governance failure in large enterprises — not the absence of governance frameworks, but the presence of governance theater: structures that exist, documentation that's been written, processes that are technically in place, and none of it meaningfully influencing how decisions get made or how the platform gets managed day to day.
What follows is a catalog of the patterns that produce this outcome. Most organizations have at least two of them. Some have all eight.
✦ ✦ ✦
The Anti-Patterns
Eight Ways Governance Fails in Plain Sight
01 — Documentation as Governance ("We Have a Policy for That")
The most common anti-pattern is mistaking the production of governance documentation for the practice of governance. Policies are written, approved, published, and filed. The governance team checks the box. Nobody changes how they work.
Governance documents have no operational effect unless they are embedded in the systems, workflows, and decisions that people actually encounter daily. A ServiceNow CMDB governance policy that lives in SharePoint doesn't govern the CMDB. A ServiceNow CMDB governance policy embedded in the service creation workflow, enforced at record submission, does. The difference between those two is the difference between documentation and governance.
The tell: when you ask "how does governance actually work here?" and the answer starts with "we have a document that covers that" — you're looking at this anti-pattern.
02 — Governance as Tollbooth ("Everything Goes Through the Board")
The second anti-pattern turns governance into a series of approval gates that exist to control rather than to enable. Architecture review boards require extensive documentation packages for changes that carry minimal risk. Every deviation from a standard — however minor — requires escalation to a committee that meets biweekly.
The predictable result: delivery teams learn to game the process. They scope work to avoid governance thresholds. They seek verbal approvals before submitting formal requests. They write documentation that says the right things without accurately describing what they're actually building. The governance process runs. The governance process is not governing.
Governance should operate differently for a minor configuration change to an internal reporting tool and a proposed architectural shift in a citizen-facing system. Risk-based governance — applying oversight proportionate to actual impact — is how you avoid the tollbooth model without abandoning oversight entirely.
03 — Over-Centralized Decisions ("Ask the Committee")
This anti-pattern concentrates authority at the top without distributing accountability downward. Small decisions — naming conventions, integration patterns, service record structures — require escalation to governance bodies that were designed for strategic decisions. The governance body becomes a bottleneck. Decisions queue up. Teams wait. Eventually, teams stop asking.
The fix isn't removing oversight. It's clearly defining which decisions belong at which level. Enterprise governance sets the principles. Domain governance applies them to specific contexts. Individual teams execute within defined guardrails. The governance framework is a hierarchy of decision rights, not a single checkpoint at the top.
04 — Named Without Active Ownership ("Owner: TBD — Last Updated 2022")
This one is particularly familiar to anyone who has run a CMDB health assessment. Service records with ownership fields populated by someone who left the organization. Application records assigned to a team that was dissolved in a reorg. Data assets claimed by a governance body that expects operational teams to maintain them, while operational teams expect the governance body to do it.
Ownership without accountability is noise. The record has a name in it. The name doesn't translate into anyone actually taking responsibility. Real ownership is active — meaning the owner validates their records on a schedule, responds when incidents affect their service, and updates the model when their architecture changes. If the ownership model doesn't produce that behavior, the ownership model isn't working.
05 — Manual Enforcement in a Digital Platform ("Please Remember to...")
Some governance frameworks describe what should be true of a platform without embedding those requirements in the platform itself. Service naming conventions are documented in a wiki rather than validated at record creation. Data quality requirements are communicated in onboarding rather than enforced at data entry. Required fields are listed as required in a policy document but left optional in the system.
In a platform like ServiceNow, most governance requirements can be enforced structurally — through required fields, workflow gates, automated health checks, and creation wizards like Service Builder. Governance that relies on human compliance with documented standards will always underperform governance embedded in the tools people use. People follow the path of least resistance. Design the path to be the governed one.
06 — Governance That Discovers Problems by Accident ("We Found Out During the Audit")
Reactive governance is governance that exists primarily to explain failures after they occur. Architectural fragmentation is discovered during a platform assessment. Data quality problems surface when an analytics report produces inconsistent results. Integration failures reveal undocumented dependencies that the governance framework was supposed to prevent.
None of these outcomes were inevitable. They were predictable — and they were preventable — if governance had continuous monitoring in place to surface the warning signals. CMDB health dashboards that flag missing service relationships before they cause impact. Data quality metrics that trigger alerts before inaccurate records influence operational decisions. Integration health checks that identify architectural drift before it accumulates into technical debt.
Proactive governance requires the same monitoring discipline applied to operations. If you can't see the health of your governance posture in real time, you're not governing — you're auditing after the fact.
07 — Governance That Works Until It Has to Scale
This one shows up reliably in organizations that have outgrown their governance models without updating them. The process that worked when the platform had 50 services and three development teams cannot survive 500 services and thirty teams without structural redesign. Central review boards become bottlenecks.
Manual certification cycles slip from quarterly to annual to whenever someone remembers. Documentation falls behind the environment.
Scalable governance distributes accountability to domain teams operating within centrally-defined standards. It relies on automated enforcement and health monitoring rather than manual review of every record. It applies oversight in proportion to risk rather than uniformly across everything. If your governance model requires the same amount of human attention per service at 1,000 services as it did at 100, it will not survive the growth.
08 — The Culture That Routes Around It ("Just Don't Put It in the System")
The final anti-pattern is cultural, and it's usually downstream of all the others. When governance is experienced as bureaucratic, punitive, slow, or disconnected from actual work, teams develop workarounds. Requests are made verbally to avoid the formal process. Work is scoped to stay below governance thresholds. Documentation is written for the governance audience rather than for accuracy.
A team that has learned to route around governance is telling you something important: the governance framework has lost credibility with the people it needs to govern. That's not a compliance problem. It's a governance design problem. Governance that people work around is governance that isn't working — regardless of how thorough the policies are.
"Governance fails silently. Nobody announces that they've stopped following the process. They just route around it quietly, and the framework keeps running as if it's governing — right up until the audit, the incident, or the consultant's assessment."
The Diagnosis
How to Know Which Ones You Have
Recognizing governance anti-patterns in your own organization requires a specific kind of honesty about how governance actually works rather than how it's supposed to work. Three questions cut through most of the self-assessment noise:
How does a new service actually enter the platform? Trace the path from a team's decision to deploy a new application to the moment a service record exists in the CMDB with correct taxonomy, ownership, and dependency relationships. If the answer involves steps that sometimes get skipped, information that's sometimes missing, or timing that varies by who's asking — you have anti-patterns 01, 03, and 05.
When did governance last prevent something from happening? Not delayed it. Not flagged it in an after-action review. Prevented it from proceeding until requirements were met. If you're struggling to recall a recent example, governance may be operating primarily as documentation rather than as an active control. That's anti-pattern 01 and 06.
What do your delivery teams say about the governance process when governance isn't in the room? If the honest answer involves words like "unnecessary," "slow," or "a box-checking exercise" — you have anti-pattern 02 and possibly 08. And the people saying those things have probably found workarounds they're not disclosing in formal governance meetings.
Summary
The 94-Page Document Isn't the Problem. It's the Symptom.
The organization with the unread governance framework didn't fail to document its policies. It failed to turn those policies into operational reality. The document was a substitute for governance — a way to demonstrate that governance existed without requiring the harder organizational work of making governance actually govern.
Most governance anti-patterns have the same underlying cause: governance designed for the optics of oversight rather than the function of it. Committees that look like decision-making bodies but act as rubber stamps. Ownership fields that look like accountability but represent nobody's active responsibility. Review processes that look like risk management but operate on a schedule that never intersects with the actual pace of change.
The corrective path is less dramatic than it might sound. Pick the anti-patterns you recognize, prioritize the two or three that are creating the most operational friction, and make structural changes — not policy changes, structural ones — that make the governed path the path of least resistance. Embed the governance in the platform. Distribute the accountability. Apply oversight in proportion to risk. Monitor continuously rather than auditing periodically.
Governance that works doesn't look like a framework. It looks like a platform that enforces its own standards, teams that maintain their own service models, and a governance team that spends its time on exceptions and evolution rather than on chasing compliance from people who have already decided the process isn't worth following.
Name the pattern. Fix the structure. Stop writing policies nobody reads.
