How to Build a Successful Enterprise Architecture Practice
Twelve elements, one executive sponsor, and the lesson most architects skip.
The title of this piece is almost embarrassingly common. Search “how to build an EA practice” and you will find hundreds of articles and frameworks, most of them written by people who have read the right things but know how difficult it is to implement in practice. This one is written from having actually done it, with resistance at every level and no room for the practice to fail.
Almost a decade ago, I joined a data management company to build something that did not exist yet. The engineering culture was strong. A talented CTO had built something real, and the engineers were good at their jobs and knew it. What was missing was any structured way of making architectural decisions at the enterprise level. The engineers were shipping code, but nobody had designed how the technology connected to what the business needed to protect legally, financially, and operationally. There were no principles to guide trade-offs, no governance over how changes got made, and no shared picture of the enterprise that anyone could reason from.
At this company, the reason for establishing the EA practice was not abstract, and that mattered more than I understood at the time. The trigger was a compliance deadline. ISO 27001 and several other regulatory requirements had to be implemented and enforced across the whole enterprise, not just IT but finance, marketing, operations, and legal. GDPR had landed in Europe the year before, and customers everywhere, not only the European ones, were insisting their vendors held proper certifications. No certification, no deal. The CTO hired me to build the architecture practice, and I reported directly to him, a structural detail that turned out to matter more than I expected.
What a Real Practice Needs
Across that engagement and several since, I have come to believe a working EA practice needs twelve things. It is less a checklist than a system, where each element holds up the ones around it and the order matters as much as the content.
Here they are, roughly in order of priority, with the first three being non-negotiable
Purpose and business objectives
Executive sponsorship
The organisation’s risk appetite
Vision and principles
A structured model of the enterprise
Reference architectures
Alignment with other frameworks
The engagement model
Implementation and architecture governance
Architecture change management
Skills, competencies, and team
Measuring and communicating value
Most people building a practice pour their energy into the middle of that list: the reference architectures, the information models, the governance. The failures I have seen, and the near-misses I have navigated myself, almost always trace back to the top: a purpose that was never made explicit, sponsorship that was assumed rather than secured, and a risk appetite nobody surfaced until a decision went sideways. Get the top three right and the rest becomes easier to establish. Get them wrong, and no framework, and no amount of hiring, will ensure a successful practice.
1. Purpose and business objectives
The first thing to do is understanding the enterprise and defining what the EA capability is actually for.
“To improve architecture quality” and “to align IT and business” are aspirations, not concrete objectives. They are what gets written when nobody has done the harder work of sitting with a sponsor and pulling out an honest, specific and measurable objective. For us, the objective was concrete: build a capability that could achieve ISO 27001 certification by the next fiscal year, connect technology risk to enterprise risk, and create a governance model the whole enterprise could actually operate within. That specificity shaped every decision that followed, including how I explained to a sceptical engineer why any of it mattered. The answer was tied directly to customer retention and the company’s ability to keep operating.
2. Executive sponsorship
This is the element most practitioners assume is already in place, then discover too late was never actually secured.
Sponsorship is not a nod in a meeting or a supportive email from someone senior. It is a named, visible, resourced commitment from someone with real authority who will back the practice publicly when resistance comes, and resistance always comes, because change asks people to give up something familiar. Mine was the CTO, and the fact that I reported directly to him was not an administrative detail. It was the mechanism that made the practice legitimate in the eyes of the organisation. Without a sponsor, you have no authority to see anything through, no matter how good or influential an architect you are. That is simply the fact. Teams align to what leadership visibly prioritises, so when engineers pushed back on governance, the signal from the top stayed consistent. Had the CTO been ambivalent, the engineers would have treated architecture as something to work around rather than work within. Before you write a single principle or craft the architecture vision for your practice, get your sponsor on record with an explicit, resourced mandate.
3. The organisation’s risk appetite
Every architectural decision is, underneath it all, a risk decision, and you cannot make good ones without knowing where the organisation actually sits on the risk curve.
Some organisations are conservative by design: heavily regulated industries, public bodies, critical infrastructure. Their tolerance for ambiguity is low and their governance reflects it. Others are built for speed and will carry technical debt in exchange for market velocity. A practice designed for one will likely fail in the other. For us, the compliance deadline made the risk appetite unusually explicit. There was a hard line, a date, and a clear set of consequences if it was missed, which gave every trade-off a reference point everyone could reason from. In most engagements you are not handed that. You have to surface it yourself, through deliberate conversations with the CFO, the risk owner, legal, and the CEO, and you need to do it before you design anything.
4. Vision and principles
Principles come after purpose and risk appetite, because they are derived from both.
They are decision rules. When two credible options are on the table, a good principle tells you which way to lean, based on what the organisation actually values, not what looks good on a slide or suits the loudest voice in the room. A strong set of principles does four things: it enables decisions, aligns the enterprise on shared priorities, supports governance, and reflects the real culture of the organisation. Principles lifted from a template, without being tested against those four, read well and settle nothing. The first real disagreement is where you find that out.
5. A Structured Model of the Enterprise
This is the element many architects find satisfying and everyone else usually treats as optional, until something breaks and nobody can explain why.
The structured model is your comprehensive picture of the enterprise: what the business does, how it does it, which systems support which capabilities, where data flows, and who is accountable for what. It is the foundation that gives every other element something concrete to stand on. Without it, you usually cannot make sense of the enterprise as information is scattered all over the place; some in the heads of people, some in wiki pages and PowerPoint documents.
Defining that structured model explicitly was what let me have genuinely useful conversations with the CFO. I could not just tell the finance team that certain controls were necessary. I had to show them, through abstract architecture views, how a specific gap in the information flow created a specific financial and regulatory exposure. The moment I could connect a technology risk to a financial implication in language the CFO could verify and act on, the conversation changed completely. That is what a structured model buys you: a shared language with the people who do not speak architecture but who hold the decisions you need.
6. Reference architectures
Reference architectures are reusable models, and their value is plain: they save time, create consistency, and give teams something to work from rather than reinvent. For us, they gave the engineering and operational teams a starting point for implementing the 114 controls required under ISO 27001. Instead of each team inventing its own approach to access control or data classification, they had a pattern to follow, which cut variation and review time and made the whole implementation more manageable.
A word on their role. Reference architectures are tools. The moment one becomes a rule that cannot be questioned, it stops being an architectural asset and turns into bureaucracy. Used well, they make delivery faster and more coherent. Used badly, they become the thing teams point to when they say architecture slows everything down, and they are not entirely wrong.
7. Alignment with other frameworks
No practice operates in isolation. Most enterprises already run established frameworks for sales, project management, risk, operations, and compliance, and your EA practice has to fit into that landscape rather than set itself up as a competing authority. The practice does not own a domain the way sales or finance does. It manages and evolves the architecture of the whole enterprise, and every other function is part of that architecture.
The practical question is not which framework is theoretically superior. It is where the enterprise already has planning, change management, and benefits realisation covered, and where the real gaps are that the EA practice needs to fill. For us, that meant working out carefully where the ISO 27001 control framework ended and where architectural governance began, then designing that boundary on purpose. Where existing frameworks did the job, I aligned to them. Where there was a genuine gap, the practice stepped in.
8. The engagement model
Establishing an EA practice is hard and the most common reason is not the poor quality of architecture artefacts. It is that the architecture leader builds a practice that is technically sound but the organisation never truly adopts.
The engagement model defines how the practice connects to the rest of the organisation: who comes to you, when and why, how you show up for different groups, and where architecture sits in decision-making. It is fundamentally a question of organisational psychology, because different parts of an organisation carry entirely different concerns and entirely different reasons to embrace or resist what you are building.
For us, the resistance came from two directions. The engineers and product teams worried that standardisation and governance would slow delivery, and from where they stood that was not unreasonable. They had spent years building something, and here was someone arriving to put structure around it. The business heads in marketing, finance, and operations were not hostile so much as indifferent, which is the harder problem, because indifference is harder to move than opposition. Sponsorship gets you into the room. Moving people who do not report to you, and who feel no urgency, takes influence you earn rather than authority you can invoke.
The way through was not a presentation or a strategy document. It was late evenings working through specific concerns with specific executives. It was architecture views built around each person’s actual problem rather than a generic overview of what EA could offer. Every conversation started with their concern and worked towards how the practice could address it, and that repeated engagement is what built the legitimacy the practice needed to operate.
9. Implementation and architecture governance
Governance has a reputation problem. In most organisations it means committees that exist to slow things down, and that reputation is not always unearned. Think of the architecture review boards that meet mainly to slow things down, or the ivory-tower architects who theorise without grasping what their decisions mean in practice. Done well, governance is a lightweight, embedded process that gets the right decisions in front of the right people at the right time.
For us, governance could not stay inside the IT organisation alone, because delivery involved external partners who had to work within the same controls. The model had to reach into third-party delivery, which added complexity but clarified something useful: governance is not a gate at the end of a process. It shapes how the target architecture is developed, how it directs change as things get built, and how it evolves as conditions shift. It is a continuous engagement. For example, we used Architecture Decision Records to capture the decisions we made, and a review board to grant exceptions. Every exception granted was linked to an entry in the risk register and tracked by the risk team until it was closed.
10. Architecture change management
The architecture you design on day one will not be the architecture the organisation needs in two years. If you have not designed for that from the start, you spend those two years watching carefully built decisions slowly go stale.
Architecture change management governs how the target architecture evolves: when a decision needs revisiting, who is involved, and how the impact of a proposed change is assessed before it is made. This is what gives a practice staying power beyond its first purpose. Without it, even a well-built practice tends to drift. An EA practice exists to support change, innovation, and agility, but that value rarely shows up early. It surfaces later, which is exactly why the twelfth element, measuring and communicating value, is what keeps the budget flowing to evolve the capability.
11. Skills, competencies, and team
No architect builds an EA capability alone. I certainly did not, and I want to be direct about why that matters. Too many architects try to carry a capability as a solo effort, become the bottleneck every decision passes through, and eventually burn out, leaving nothing sustainable behind. The practice has to be built into a team.
The team I assembled spanned cloud engineering, security architecture, and technical programme management: different domains, different strengths, and one shared understanding of what we were trying to achieve. Building it was the hardest part of the whole effort, harder than the compliance work and harder than the governance design. The difficulty was not only finding the right people. It was that the engineers who became the most committed contributors to the practice were, at the start, among its loudest critics. They believed architecture would slow delivery, and they said so. What changed their minds was experience. They watched enough good decisions get made well that they began driving the processes themselves, running the agile disciplines and holding others to the standards they had once resisted.
12. Measuring and communicating value
Practices rarely fail on architectural quality. They fail because the value they create stays invisible to the people who control the budget.
Architecture work produces outcomes that are hard to point to: better decisions, risks avoided, complexity kept from compounding. None of those show up on a dashboard, and in organisations where budget decisions run on visible evidence, invisible value gets cut. For us, putting architecture into financial terms was what opened the serious conversations. Showing the CFO how a specific information gap created a specific regulatory exposure, in terms he could verify and act on, was a different conversation from anything a standard architecture review could produce. Building that rhythm, tying architectural outcomes to the planning cycles and financial metrics executives actually use, is what decides whether the practice is successful.
How You Know the Practice Is Working
The clearest signal came when the CEO started requesting time with me directly. I had not lobbied for it. He had simply found that having architectural thinking – trade-off visibility, dependency mapping, capability gaps as strategic risk – in his decisions was useful, and he wanted more of it. When the people running the business seek out the practice rather than tolerate it, something real has changed.
The other signal was the engineers and operational staff – the builders. The ones who had argued hardest that architecture would slow them down became the ones holding others to the standards and running the processes they had once resisted, without being asked. That does not come from a mandate. It comes from enough experience of good decisions, made well, to shift what people believe is worth caring about.
That is what a successful practice looks like. Not the volume of artefacts it produces, but the shift in how the organisation reasons about the decisions that shape it.
What to Take Away
Start with purpose: a specific, explicit answer to what this is for, tied to business outcomes rather than aspirations.
Secure your sponsor before building anything: named, resourced, and publicly visible. Everything else depends on it.
Surface the risk appetite early: it shapes every decision you will make before you have made any of them.
Let principles follow purpose: they have to reflect the enterprise you are actually in, not a template.
Build your engagement model before your governance model: the architecture of stakeholder relationships carries more than the architecture artefacts.
Invest in your team as seriously as your frameworks, and work to embed architectural thinking across functions: the practice that outlasts you is built with people.
Measure and communicate value constantly, tying deliverables to outcomes the business already tracks: invisible value gets cut.
Frameworks are useful. The experience of studying and leading change is more useful. Use both.
If you are building or rebuilding a practice right now, which is your weakest link today: the sponsor, the value you can prove, or the people you need to bring with you?
I write about the intersection of strategic foresight and enterprise design, and how executives can make better-informed decisions there. If this was useful, share it with a leader who would benefit.