Link: https://eawheel.com/blog/2026/04/more-practicality-less-theory/
From EAWheel
Enterprise Architecture frameworks are rarely questioned at the conceptual level. Most architects accept their value. Many organizations reference them explicitly. Certifications remain popular, methods are well known, and the language of architecture has become increasingly standardized across the profession. Yet something interesting happens when these frameworks enter daily practice: the translation becomes challenging, resulting in difficulty gaining stakeholder buy-in. However, stakeholder buy-in is not the issue. We need more practicality, and less theory.
Investigating The Cause Of The Issue
Frameworks are designed to create structure. Organizations, however, rarely behave structurally. They move under pressure, negotiate priorities continuously, and expect architecture to contribute without slowing decisions down.
To better understand how architects currently experience this reality, I asked the architecture community a few practical questions through three polls:
- How manageable is using architecture frameworks in practice?
- Where do you experience the most difficulty when applying frameworks?
- What would improve your ability to use frameworks effectively?
The answers were highly consistent. And they point to a familiar architectural truth: the difficulty is rarely the framework itself; it is translation.
Frameworks Are Usable, But Not Comfortable
The first poll focused on practical experience. I asked the community “How would you describe your experience using architecture frameworks in practice?” The results are shown below.
Very manageable — 14%
Somewhat manageable — 45%
Somewhat challenging — 28%
Very challenging — 13%
This means nearly sixty percent of respondents experience frameworks as manageable. That is important. It tells us frameworks are not failing outright. Most practitioners clearly find enough value in them to continue using them in their work.
But another number deserves equal attention. Forty-one percent still describe the experience as challenging. That is too large to dismiss as incidental. It means that while frameworks are broadly accepted, practical ease remains uneven. This should not surprise us.
A framework is intentionally comprehensive. It covers governance, strategy, capability, principles, transition, and change across an enterprise landscape. It must be broad because enterprise reality is broad. But breadth introduces distance. A framework explains what matters, yet rarely tells an architect exactly what to do when a product owner asks for direction, a delivery lead needs immediate clarity, or a sponsor wants to understand why architecture should be involved at all.
That distance is where friction begins. And friction becomes visible in the second poll.
An Obfuscated Main Difficulty
The second poll asked where architects experience the most difficulty:
Understanding the concepts — 1%
Translating it into daily work — 34%
Aligning with delivery pace — 19%
Gaining stakeholder buy-in — 46%
At first sight, the conclusion seems obvious. Stakeholder buy-in dominates. Nearly half of respondents identify it as the main difficulty when applying frameworks. This immediately feels familiar. Many architects have experienced resistance when introducing architectural structure. Stakeholders may perceive frameworks as overhead, governance as delay, or architectural language as unnecessarily abstract.
But this result deserves caution. Because stakeholder buy-in is often not the original problem. It is often the result of one.
Resistance Starts Earlier
The second-largest answer may actually explain the first. Thirty-four percent selected translating frameworks into daily work. That is highly significant. Because if architecture struggles to convert framework thinking into practical decisions, stakeholder resistance becomes almost inevitable. People rarely resist usefulness. They resist distance.
When architecture introduces concepts without immediate relevance, stakeholders struggle to connect. When framework language dominates the conversation, practical value becomes harder to see. Or, when architecture enters too late or too heavily, resistance appears quickly. And that resistance is then experienced as lack of buy-in. But often the actual issue began earlier.
If we cannot get stakeholder buy-in on the architecture, we must take a critical look at ourselves. That would mean we failed to explain the profession’s added value.
Architecture did not fail because stakeholders rejected it. Architecture failed because relevance was not visible early enough. This is uncomfortable because it shifts part of the responsibility back to architecture itself. Yet that is often where the truth sits. Human nature plays a role here. When something does not land well, we naturally look outward first. It is easier to conclude that stakeholders do not understand architecture than to ask whether architecture was translated well enough to deserve immediate recognition.
That does not mean stakeholders are never difficult. It means stakeholder resistance is frequently delayed feedback.
Framework Understanding Is Not the Core Problem
Perhaps the most telling result in the second poll is the smallest one. Only one percent selected understanding the concepts. That number says a great deal about where the profession stands today. Architects largely understand frameworks. The conceptual foundation is not missing. Terms such as capability, principle, target state, governance, transition, and value stream are no longer unfamiliar territory. The profession has matured intellectually.
What remains difficult is something else entirely. Knowing a framework does not automatically create practical fluency. That distinction matters because it explains the third poll almost perfectly.
More Practicality, Not More Theory
The third poll asked what would improve framework use most:
Clearer practical examples — 52%
Simplified or tailored guidance — 30%
Better integration with tools — 11%
More training or coaching — 7%
Again, one result stands out immediately. Only seven percent ask for more training. That strongly suggests the community does not experience theory as the primary shortage. What architects want most are examples. Not descriptions. Not additional concepts. Examples.
This is important because examples perform something frameworks often cannot. They remove interpretation distance. A framework may say that capability-based planning supports better investment decisions. But an example shows how an architect uses capability language during a portfolio discussion when priorities compete and ownership is unclear. That difference matters. Because practical examples teach architectural behaviour. And behaviour is where frameworks become real.
Practical Examples Build Trust Faster
This explains why clearer examples dominate the third poll. A practical example immediately answers the hidden question every architect faces:
What does this look like when I actually use it?
There is a large difference between saying:
Use capability-based planning.
and saying:
Map the investment to affected capabilities, identify which capability lacks ownership, and use that to expose why execution risk exists.
The first sounds architecturally correct. The second creates immediate practical movement. Stakeholders respond to movement. Not terminology. And once architecture creates visible movement, trust follows more naturally. That trust is often what later gets called buy-in.
Frameworks Rarely Fail On Their Own
These poll results do not show a profession rejecting frameworks. They show a profession asking for stronger practical architecture. That is an important distinction. Architects are not saying frameworks should disappear. They are saying frameworks become difficult when practical conversion remains too dependent on individual interpretation. That is where architectural maturity matters most. Because the real professional skill is not framework knowledge alone.
It is deciding what part of a framework matters now, how deeply to apply it, and how to make that useful without introducing unnecessary weight. That is craftsmanship.
The Real Problem Is Rarely Buy-In
This brings us back to the strongest result of the second poll. Stakeholder buy-in appears to be the biggest problem. But often it is not the first one. In many situations, stakeholder resistance is simply the moment architecture discovers whether its own translation was strong enough. If relevance appears late, buy-in weakens early. If usefulness appears early, buy-in often follows naturally.
That changes how we should interpret the results. The challenge does not lie in convincing stakeholders to accept frameworks or architecture. Rather, the challenge lies in applying frameworks in ways that stakeholders immediately recognize as helpful. Because architecture is rarely judged by how accurately a framework is explained. It is judged by whether people can use what architecture makes visible.
A More Practical Approach
One way to make architecture more accessible is to use an approach that most people, including architects and stakeholders, can understand. One such approach is the Enterprise Architecture Implementation Wheel.
The Enterprise Architecture Implementation Wheel is based on the TOGAF® Standard, but the approach adapts TOGAF’s structure and flow by reorganizing it into four main stages: Document, Define, Execute, and Control. Each stage is broken down into one or more steps, each of which includes key focus areas and actionable artifacts.
Rather than aiming for exhaustive coverage, the Enterprise Architecture Implementation Wheel provides a scalable foundation that organizations can build upon as they mature. It provides a solid foundation for making architecture practical, pragmatic, visible, and valuable.
After all, we need more practicality and less theory.
The post More Practicality, Less Theory appeared first on EAWheel.
