We checked every TOGAF box. Produced every artifact. Followed every process. Our architecture maturity assessment score was perfect. And absolutely nothing improved.
If this sounds familiar, you have encountered Goodhart's Law in action. Named after economist Charles Goodhart, it states: "When a measure becomes a target, it ceases to be a good measure." In architecture, this translates to a dangerous pattern: when framework compliance becomes your success metric, the framework stops enabling results and starts hindering them.
This post explores how well-intentioned frameworks become organizational theater, why compliance metrics can sabotage actual outcomes, and how to shift from checkbox architecture to decision-enabling architecture. Whether you are drowning in TOGAF artifacts or questioning why your perfect process produces imperfect results, understanding Goodhart's Law will change how you approach frameworks forever.
The Perfect Compliance Disaster
Three years ago, I was part of an enterprise architecture team at a financial services organization that had just achieved something remarkable: perfect framework compliance. Our TOGAF implementation was textbook. Every artifact existed. Every phase was documented. The governance board met religiously. Our architecture maturity assessment scored in the top percentile.
Six months later, our flagship digital transformation project collapsed spectacularly. The post-mortem was brutal but illuminating. Despite having comprehensive architecture documentation, implementation teams had made critical decisions without consulting it. The artifacts existed, but they were not used for actual decision-making. We had optimized for assessment scores while the real work happened around us.
My initial reaction was defensive. This was execution failure, not architecture failure. Our artifacts were correct; implementation had deviated from the plan. But leadership did not care about the distinction. Architecture was supposed to guide execution. If execution deviated without architecture noticing, we had failed at our core purpose - regardless of how beautiful our documentation looked.
That failure taught me something fundamental about frameworks and human behavior. When you measure people on compliance, they optimize for compliance. When you measure them on outcomes, they optimize for outcomes. We had been measured on artifacts produced, processes followed, and governance meetings attended. So that is exactly what we delivered - at the expense of everything else.
Understanding Goodhart's Law in Architecture
Goodhart's Law explains why this pattern is so common and so destructive. Originally applied to monetary policy, it describes what happens when any measure becomes a target: people game the system. In architecture, this manifests in several predictable ways.
First, teams optimize for the metric instead of the goal. When compliance becomes the target, architects focus on producing artifacts that satisfy auditors rather than documents that enable decisions. The resulting documentation looks comprehensive but provides little practical value to the teams that should be using it.
Think about teaching to the test. When schools are measured solely on standardized test scores, they optimize for test performance rather than learning. Students memorize answers without understanding concepts. Teachers drill test-taking strategies instead of fostering critical thinking. High test scores and poor education coexist because the measure displaced the goal.
Architecture frameworks suffer the same fate. When teams are measured by compliance scores, they optimize for artifacts without enabling decisions. Comprehensive documentation and poor architecture outcomes coexist because compliance displaced effectiveness. The framework becomes theater rather than tool.
This pattern accelerates because compliance is easier to measure than outcomes. Counting artifacts is straightforward. Determining whether those artifacts influenced decisions requires deeper investigation. Organizations gravitate toward measurable metrics, even when those metrics correlate poorly with actual success.
The signs are everywhere once you know what to look for. Architecture reviews focus on artifact completeness rather than decision quality. Teams spend more time updating documentation than using it for guidance. Governance meetings discuss process adherence instead of architectural trade-offs. Success is measured by artifacts produced rather than decisions enabled.
Why does this happen so consistently? Because frameworks provide comfort through structure. In complex environments, following a proven process feels safer than making judgment calls. Compliance offers psychological safety - if the project fails but you followed the framework, you cannot be blamed for the approach. This creates perverse incentives where teams optimize for defensibility rather than effectiveness.
From Compliance Theater to Selective Application
One year after our compliance disaster, I faced the same organizational pressures on a new project. The expectation of TOGAF compliance had not changed, but my approach had to. I could not abandon the framework entirely - organizational politics made that impossible. But I could not repeat the checkbox exercise that had failed so spectacularly.
The solution came from an unexpected source: a comment from one architect that reframed everything. He said, "TOGAF is a framework. I think of it as a pantry. You do not use everything in your pantry for every meal."
This pantry analogy transformed how I approached frameworks. A well-stocked pantry contains many ingredients - spices, grains, proteins, vegetables. But using every ingredient for every meal produces inedible results. A skilled chef selects based on what the dish requires, not what the pantry contains.
Similarly, TOGAF contains many components - artifacts, processes, techniques, governance structures. But using every component for every project produces unusable architecture. A skilled architect selects based on what the situation requires, not what the framework provides.
The key insight is that selection requires understanding the whole framework, not just picking favorites. You need to know what each artifact enables, what each process addresses, and how components interact. Then you can make informed choices about what your specific context needs.
I adopted what I call the "outcome first" test. For each framework artifact, I asked: "Will this artifact enable a specific decision, or am I creating it to check a box?" If I could not identify a decision this artifact would influence, I questioned whether it should exist. If I could identify the decision but the artifact would not actually influence it, I looked for alternative approaches.
This selective application produced fewer artifacts but higher-impact ones. The governance board initially questioned the "incomplete" approach. When the project succeeded and architecture decisions visibly influenced implementation, the questions stopped. Decisions were influenced, outcomes improved, and compliance concerns became secondary.
The framework had returned to its proper role: tool rather than target. As one other architect observed, "If the framework becomes the target, the framework is hindering the results." When we stopped optimizing for the framework and started optimizing through the framework, everything changed.
Auditing Your Framework Practice
The shift from compliance to effectiveness requires honest assessment of your current practice. Most architects know intuitively when they are producing theater rather than value, but organizational pressures make it difficult to acknowledge.
Start with one framework artifact you created in the last month. Ask yourself: "What specific decision did this artifact enable?" If you cannot answer clearly and specifically, you may have created a compliance artifact rather than a decision enabler. This is not necessarily wrong - sometimes compliance artifacts serve political purposes - but you should be conscious of the choice.
Look for warning signs in your architecture practice. Are your governance meetings focused on process adherence or architectural trade-offs? Do implementation teams reference your artifacts when making decisions, or do they work around them? Are you measured on documentation completeness or decision influence? Do you spend more time updating artifacts than creating them?
The goal is not to abandon frameworks but to use them effectively. Frameworks provide valuable structure, proven practices, and common vocabulary. The problem arises when the framework becomes an end rather than a means. When compliance displaces effectiveness, when process supersedes outcomes, when measurement becomes more important than results.
Consider implementing your own "pantry" approach. For each framework component, understand what it enables before deciding whether to use it. Document your selection rationale - this satisfies governance concerns while demonstrating thoughtful application rather than blind compliance. Focus on artifacts that influence decisions, not artifacts that impress auditors.
Remember that frameworks are tools designed to help you make better architectural decisions. When they stop helping and start hindering, when they consume effort without enabling outcomes, when they become targets rather than tools, it is time to step back and reassess. The framework should serve your architecture goals, not the other way around.
Conclusion
Goodhart's Law reveals a fundamental truth about measurement and human behavior: when any measure becomes a target, people optimize for the measure rather than the underlying goal. In architecture, this manifests as compliance theater - comprehensive framework adherence that produces impressive artifacts while enabling few actual decisions.
The solution is not to abandon frameworks but to use them selectively and intentionally. Treat frameworks as pantries, not recipes. Select components based on what your situation requires, not what the framework provides. Focus on artifacts that enable decisions, not artifacts that check boxes. Measure success by outcomes influenced, not processes followed.
This shift requires courage because it means accepting responsibility for judgment calls rather than hiding behind framework compliance. But it also returns frameworks to their intended purpose: helping architects make better decisions in complex environments. When the framework serves the architecture rather than the architecture serving the framework, both the process and the outcomes improve.
The choice is yours: optimize for compliance or optimize for results. The framework will support either approach, but only one will actually improve your architecture outcomes.
Resources
Watch the video for the full story of how perfect compliance led to spectacular failure - and what I learned about using frameworks as tools rather than targets: https://www.youtube.com/watch?v=FF3JAvsfctQ
What framework compliance metrics have become targets in your organization? How do you balance governance expectations with outcome effectiveness?