An enterprise architect works one zoom level above everyone else — the plan is not for a system, but for the whole organisation’s technology landscape.

Most architect roles are anchored to a single problem or a single system. An enterprise architect is anchored to something much larger: the shape of an entire organisation’s technology landscape over the next several years. Instead of asking “how should this application be built?”, they ask “how should our hundred applications work together, evolve, and support the business through the next decade?”

The cleanest analogy is a city planner. A city planner does not build houses, dig sewers, or lay tarmac themselves — those are the trades. What they do is decide where the neighbourhoods should go, where the water and power grids should run, which zones are residential and which are industrial, and what the master plan for the next twenty years will look like. Every subsequent build in the city is either constrained or enabled by that plan.

An enterprise architect designs the tech landscape at the level of an entire organisation, aligning it with long-term business strategy.

An enterprise architect (EA) is the senior technical strategist responsible for how an entire organisation’s people, processes, data and systems fit together to support its long-term business strategy. Where a solution architect works at project scope and a technical architect works at system scope, an enterprise architect works at organisation scope.

Their attention lives across the whole landscape at once. Their week typically involves:

• Producing and updating the organisation’s target-state technology roadmap.
• Setting standards, principles and reference architectures that individual projects have to respect.
• Reviewing major initiatives to make sure they move the landscape toward the target rather than away from it.
• Advising executives on which technology investments will best support the business over three to five years.

The value they bring is coherence: keeping many independent teams and vendors moving in a direction that adds up to something greater than a collection of disconnected local decisions.

Enterprise architecture is traditionally split into four stacked layers — business, data, application, technology — each answering a different question about the organisation.

The discipline is usually described through four stacked layers, sometimes called the BDAT stack after their initials. Each layer answers a different question about how the organisation runs.

A good enterprise architect is not equally deep in all four — almost nobody is — but must be fluent enough in each to see how a change in one layer will ripple through the others.

Every organisation past a certain size accumulates local decisions that quietly conflict with each other. That is the problem enterprise architecture is designed to solve.

In a small company, technology decisions can be made ad hoc and things still fit together, because the whole surface area fits in a few peoples’ heads. Past a certain size, that stops being true. Departments buy overlapping tools, teams pick incompatible tech stacks, data ends up duplicated in three places, and integrations sprawl into a jungle. Enterprise architecture exists to reduce that friction on purpose.

Enterprise architects spend most of their time in conversation, alignment and long-horizon planning — not in code or in production support.

An enterprise architect’s calendar looks nothing like a developer’s. A typical day skews toward strategy, alignment and pattern-setting.

Very little of this looks like traditional engineering — and it is not meant to. The value is generated in slower currencies: alignment, coherence, and decisions that hold up years later.

Enterprise architecture is one of the few technical disciplines where formal frameworks genuinely dominate practice — here are the ones you will see most.

Because the scope is so wide, enterprise architects lean heavily on formal frameworks — shared vocabularies and processes that make it possible for large orgs to talk about their landscape consistently. Three come up repeatedly in job postings and RFPs:

Most working enterprise architects treat these frameworks as toolkits to borrow from rather than as gospel to follow line by line — the goal is a landscape that is coherent to run, not a set of diagrams that scores well on a framework audit.

Enterprise architecture is not another kind of solution or technical architecture — it sits above both, providing the constraints they design within.

The clearest way to place the role is to draw the organisation as a pyramid, with enterprise architecture at the top setting the constraints everyone else designs within.

The relationship is not one of hierarchy in the personnel sense — enterprise architects rarely manage solution or technical architects directly. It is one of scope. The enterprise architect defines the guardrails; the solution architect designs a project that respects them; the technical architect designs one system inside that project; the engineering teams build it. Push a decision to the wrong level of that stack and the whole structure starts to strain.

Most enterprise-architecture work follows a recognisable cycle — usually formalised in a framework such as TOGAF’s ADM.

Whatever framework an organisation uses, most enterprise-architecture work follows a recognisable cycle. Simplified, it looks like this:

The loop never really ends. As the business changes, the vision changes; as the vision changes, the target moves; as the target moves, the transition plan is rewritten. Enterprise architecture is a rolling discipline, not a one-off deliverable.

The role sits at a rare intersection of deep technical grounding and executive-level communication — both muscles matter, in roughly equal measure.

Enterprise architecture sits at a rare intersection: it needs enough technical grounding to be credible with senior engineers, and enough business fluency to be trusted in the boardroom. The best enterprise architects tend to share a distinct mix of strengths and constraints.

One concrete example: how an enterprise architect might shape a bank’s move to a modern cloud-and-microservices landscape.

To see the role in motion, imagine a mid-sized bank that has grown by acquisition. It now runs six overlapping loan-origination systems, three customer-data stores, and dozens of point-to-point integrations that everyone is afraid to touch.

No single project in that plan is delivered by the enterprise architect themselves. But the plan — and the coherence between everyone’s independent projects — is very much their work.

Three misconceptions that keep resurfacing whenever the enterprise-architect title comes up — and the reality behind each.

“Enterprise architects just draw big diagrams nobody reads.”

Diagrams are one output of the thinking, not the thinking itself. Behind an honest enterprise diagram sit hundreds of conversations, trade-offs, and decisions that materially shape what individual projects are allowed to do. Landscapes that fall into disrepair usually do so because the diagrams stopped being used to make decisions, not because they were drawn in the first place.

“Only huge corporations need enterprise architecture.”

Even mid-sized organisations benefit from some enterprise thinking as soon as multiple teams start making overlapping technology decisions. It may not warrant a dedicated enterprise architect at that stage — the CTO or a senior architect can do the job part-time — but the discipline still applies.

“An enterprise architect does not need real technical experience.”

The opposite is closer to the truth. An EA without genuine engineering roots quickly loses credibility with the teams whose work they are trying to shape. The most respected enterprise architects almost always have long histories as solution or technical architects before stepping up to this scope.

The five ideas from this guide worth carrying into any conversation about enterprise architecture and the role.