Recent advances in AI-driven content creation are making knowledge more accessible across business domains. As a practising Enterprise Architect, however, it is worth remembering that some of the most important professional knowledge comes from experience gained by having committed mistakes, trade-offs, and lessons learned the hard way. This is true in many professional fields where expertise lies at the intersection of theory, practice, and change, and it is certainly true in Enterprise Architecture.
It is often stated that becoming a strong Enterprise Architect requires many years of experience, and there is a great deal of truth in that. The discipline demands judgement, perspective, and the ability to navigate complexity rather than simply describing it. One of the most valuable capabilities a successful Enterprise Architect can develop is strong professional judgement about what can work in practice, rather than blindly trusting the theoretical concepts. Equally important is the ability to communicate arguments to stakeholders, often shaped by ambiguity. This combination of judgement and communication is central to what makes an Enterprise Architect effective. Senior Enterprise Architects also have an important role in mentoring younger practitioners to develop these qualities earlier in their careers.
One of the most important and underrated qualities to develop is pragmatism. This insight explores why pragmatism is not to be considered a compromise in Enterprise Architecture, instead it is one of the primary reasons why the discipline becomes valuable in practice.
Enterprise Architecture has an important role to play in any organisation that depends on complex systems, cross-functional collaboration, and long-term change. When utilized to its full potential, it helps leaders make better decisions by clarifying how strategy, processes, data, applications, and technology fit together. However, when used poorly, it becomes detached from the organisation it is meant to serve. It produces elegant models, ideal target states, and governance structures that look coherent on paper but fail to gain traction in reality.
This should not, however, be read as a criticism of ambition, rigour, or strategic thinking. Organisations do need direction. They do need principles. They do need an architectural perspective that looks beyond the next project or budget cycle. The problem emerges when architecture becomes an exercise in perfection rather than a discipline for enabling change.
Too often, Enterprise Architects devote disproportionate effort on designing the ideal end state and too little on defining a credible path towards it. The focus therefore tilts towards “what to achieve” rather than “how to achieve it”. The path must account for incremental risk reduction, change-management challenges, the friction of immature solutions, and the trade-offs and constraints that shape what can realistically be achieved. In practice, value rarely comes from the purity of the model. It comes from whether the organisation can use the architectural guidance to make better decisions, move with greater coherence, take meaningful steps in the right direction, and improve without losing momentum.
The Gap Between Theory and Practice
A recurring weakness in Enterprise Architecture is the assumption that organisations can move rationally and deliberately from a current state to a desired future state. The guiding star has for long been a methodology based on four steps:
- Base Architecture
- Target Architecture
- Identifying Gaps
- Building a Roadmap
In theory, this is still a sensible division of tasks, but organisational change and evolution are rarely linear. They are shaped by legacy investments, local optimisations, competing priorities, customer needs, regulatory obligations, financial constraints, skill shortages, and delivery pressures. The roadmap may suggest a clean transformation path, but the terrain rarely cooperates. It may also identify temporary transition states on the way to the target architecture, but some of these transition states can persist far longer than originally intended and require investment in their own right.
This is why target architectures is in risk of becoming shelfware. They are typically designed as if the organisation can pause, align, simplify, and then execute according to plan but that’s a luxury, only a select few enterprises enjoy. Most must transform while continuing to operate, sell, serve customers, and deliver while changes are underway. They must work with systems that are too critical to replace immediately, processes that have grown around historical compromises, and business areas where incentives and priorities are not fully aligned. If Enterprise Architecture does not account for these ever-changing realities, it becomes an abstract design language disconnected from real-world execution.
One of the most important realities architects often underestimate is that clarity in processes drive behaviour more than a model does. Even if the processes are unclear, fragmented, or missing entirely, people will find a way to get the work done by following the path with least resistance. Teams create spreadsheets, side systems, manual handovers, informal approvals, and local conventions to keep the organisation moving. These workarounds may appear messy from an architectural perspective, but they often reveal unmet operational needs or weaknesses in the supporting IT environment which may not provide adequate support or may be perceived as inflexible. Pragmatic architects pay attention to these workarounds and do not dismiss them as non-compliant. They ask what problem they are solving and what that says about the actual operating model of the enterprise.
What Pragmatic Enterprise Architecture Looks Like
Pragmatic Enterprise Architecture starts with curiosity and humility. The best Enterprise Architects continue asking questions until they understand the problem rather than assuming they have understood it. They recognise that architecture is not the centre of the enterprise; it is a support function for better decisions and more coherent change. The architect’s job is not to impose theoretical completeness or sell the perfect model, but to help the organisation move in a better direction from its current state. This requires staying close to business priorities, understanding the pressures facing delivery teams, and accepting that useful architecture is often partial, iterative, and situational rather than comprehensive and final. This also requires time and patience, qualities that can be difficult to sustain when EA teams are measured primarily on how quickly they can drive change towards a target architecture.
This changes both the scope and the style of the work. The focus shifts from producing exhaustive artefacts to identifying the critical structures: important business capabilities, key information assets, core system and investment boundaries, primary integration patterns, non-negotiable guardrails, and priority risks. The aim is not to model everything but, to create enough shared understanding to support better choices.
This also changes governance. In a pragmatic model, governance is less about enforcing detailed conformance to an ideal design and more about setting clear guardrails within which teams can operate. Guardrails matter because organisations do need coherence: security must be protected, data ownership must be clear, integration cannot become chaotic, and duplication should be challenged where it adds cost without value. Guardrails should make progress secure, not slower. When architecture governance becomes a mechanism for slowing down the flow of work, it undermines its own legitimacy.
Pragmatism also means acknowledging the strategic influence of major enterprise platforms such as ERP, PLM, and CRM suites. These platforms are not neutral components that can simply be repositioned or reconfigured. They represent significant investments, dependencies, and business commitments. Pragmatic architecture should therefore protect the value of those investments rather than treating major platforms as disposable components. Not every inherited platform decision is optimal, but years of implementation effort and business adoption should not be discarded in pursuit of architectural idealism. Major platforms contain embedded process assumptions, data structures, integration patterns, functional capability scope, and vendor roadmaps. Together, these create architectural gravity and shape the practical boundaries of change. A useful and pragmatic Enterprise Architecture does not ignore this gravity but chooses to work with it. It defines where standardisation is worth embracing, where differentiation is strategically necessary, and where local workarounds may be preferred temporarily because immediate remediation is costly.
Architecture in a World of Competing Forces
Enterprise Architecture is rarely a matter of solving one problem in isolation. More often, it involves balancing competing forces. Business leaders want speed, delivery teams want autonomy, risk functions want control, platform owners want standardisation, and customers expect reliability and continuous improvement. These forces interact in ways that cannot be fully optimised at the same time. Architects should therefore avoid presenting roadmaps as a route to perfect alignment. Architecture is better understood as a discipline of intelligent trade-offs.
This is where some architecture efforts go wrong: they try to eliminate complexity by replacing it with conceptual purity. The pursuit of elegant and coherent solutions is implied in all architectural work. But large organisations are complex as they serve different markets, products, regions, and stakeholders under changing conditions. The architect’s responsibility is not to pretend that this complexity can be designed away, but to make it navigable. It means clarifying decision rights, exposing dependencies, distinguishing strategic constraints from accidental ones, and helping teams understand where flexibility is possible and where it is not.
What Enterprise Architects Need to Do Differently
Firstly, Enterprise Architects need to spend more time where important decisions and trade-offs are made—working closely with transformation programs, product teams, process owners, operations leaders, and business stakeholders. If architects mainly engage with each other, their work can gradually become self-referential. It is easy to fall into a mindset of “we and them” rather than “us”. Architects should stay close to the points where decisions and trade-offs are made. Then their guidance and facilitation are more prudent, realistic and more credible.
A related challenge is the divide that can emerge between line Enterprise Architecture and program Enterprise Architecture. These two perspectives should be complementary: Line Enterprise Architects safeguard long-term coherence, shared capabilities, and enterprise-wide guardrails, while programme Enterprise Architects apply these principles to the urgency and constraints of transformation initiatives. However, differences in priorities can create divergence. Line Enterprise Architects may be seen as abstract, slow, or disconnected from delivery, while programme Enterprise Architects may be seen as opportunistic or overly accommodating. Pragmatism requires closer collaboration between the two. Line Enterprise Architects need to provide clear direction without being rigid, while program Enterprise Architects need to adapt that direction to delivery realities without creating fragmentation. When both work in partnership, architecture can be both strategic and executable.
Secondly, Enterprise Architects should replace static target-state thinking with incremental architectural progression. A good roadmap should not describe an ideal future that is disconnected from current constraints. It should define a practical sequence of improvements an organisation can realistically implement and sustain. It should clarify which decisions need to be made now, which dependencies must be addressed first, which legacy elements need to be retained for business continuity and where are next architectural inflection points. This is where transition architectures are helpful. If the target architecture defines the long-term direction, transition architectures define the practical path towards it. If the target architecture defines the long-term direction, transition architectures define the practical path towards it. It makes the necessary trade-offs explicit and provide a basis for sequencing change across transformation programs and line operations. Transition architectures can be more complex than both the current and target architectures because it must accommodate elements of both while supporting a business that continues to operate and change. Robust transition architectures are thus, one of the most challenging parts of large-scale transformation. Without them, a target architecture can remain a conceptual destination without a credible route to reach it. With them, architecture becomes actionable and can help the organisation manage and reduce transformation risks. Each transition should be achievable within a timeframe short enough to avoid being overtaken by changing priorities.
Thirdly, Enterprise Architects need to communicate in a language that the organisation understands and relates to. Framework terminology, modelling notations, and abstract classifications have their place, but they should not become the primary interface between architecture and the business. One of the key objectives of an Enterprise Architect is to bridge the gap between business and technology teams by presenting architecture in terms relevant to the decisions they need to make. Executives need to understand costs, savings, risks, speed, resilience, customer impact, and strategic alternatives and scenarios. Delivery teams need clarity on constraints, standards, interfaces, and priorities. When architecture is communicated in terms that matter to its stakeholders, it becomes a practical enabler.
Finally, success should be judged differently. Architecture should not be measured by the completeness of the repository, the elegance of the meta-model, or the refinement of the target state. It is whether the organisation makes better decisions because the architecture is in place.
Does it reduce costly duplication and make transformation more coherent? Does it help leaders understand trade-offs earlier and build consensus on the path ahead? Does it provide useful guardrails without slowing teams down? Does it improve the organisation’s ability to evolve? These are the questions that should define the value of Enterprise Architecture.
Conclusion
Pragmatic Enterprise Architecture is not anti-strategic, and it is not anti-ambition. On the contrary, it takes strategy seriously enough to recognise and address the complex conditions under which strategy must be executed. It accepts that enterprises are shaped by real processes, real people, legacy constraints, platform gravity, organisational dynamics, and competing and changing priorities. The architect’s role is not to design a perfect future detached from the present, but to help the enterprise move deliberately, coherently, and realistically towards better outcomes. In a time when organisations need both direction and adaptability, pragmatism is not a compromise. It is the discipline that makes enterprise architecture practical, relevant, and useful.
If you’re interested in hearing more on how Opticos can help you building a pragmatic Enterprise Architecture capability, please feel free to contact: hans.bergstrom@opticos.se
