Ask ten people what an enterprise architect does and you will get ten different answers.
Some think we draw diagrams. Some think we pick technologies. Some think we are the people who say "no" in review meetings.
After many years in this role, I describe it much more simply:
Enterprise architecture is the discipline of making sure an organization's technology decisions add up to its business strategy.
Not each decision on its own. The sum of them.
Why Enterprise Architecture Exists
Every large organization makes hundreds of technology decisions every year. Which CRM to buy. How to integrate a new acquisition. Whether to build or buy. Which cloud. Which data platform.
Each of those decisions is usually made by a capable team trying to solve a real problem. And each one usually makes sense on its own.
The trouble is that nobody is looking at how they fit together.
Five years later you have three CRMs, four integration tools, customer data in eleven places, and a transformation program that costs ten times what it should. Nobody made a bad decision. The organization simply never made a joined-up decision.
Enterprise architecture exists to prevent that drift.
The Four Classic Domains
Most frameworks describe enterprise architecture across a set of connected domains.
Business architecture
What the organization does, expressed as capabilities: "manage customer relationships", "fulfil orders", "price products". Capabilities are stable even when org charts and systems change, which makes them a powerful anchor for planning.
Data architecture
What information the business depends on, who owns it, where the trusted version lives and how it flows. In my experience, most transformation problems turn out to be data problems wearing a disguise.
Application and integration architecture
Which applications support which capabilities, and how they talk to each other through APIs, events and integration platforms. This is where duplication and complexity usually hide.
Technology architecture
The cloud platforms, infrastructure, security controls and operational tooling that everything runs on.
The value is not in documenting each domain. It is in connecting them, so that a change in business strategy can be traced all the way down to the systems and data it affects.
What an Enterprise Architect Actually Does
Day to day, the job is less about frameworks and more about judgment. A typical week might include:
- Helping leadership understand the technology impact of a strategic decision
- Reviewing a solution design and asking how it fits the bigger picture
- Spotting that two programs are about to build the same capability
- Shaping a multi-year roadmap for a platform or domain
- Defining principles and standards that teams can actually follow
- Mentoring solution architects and senior engineers
The best enterprise architects I have worked with share one trait: they can talk to a CFO about value and risk in the morning, and to an engineering team about API versioning in the afternoon, without changing who they are.
Frameworks: Useful, Not Sacred
TOGAF, Zachman and similar frameworks give you a shared vocabulary and a structured way of thinking. They are worth learning.
But I have seen architecture teams spend a year building a perfect framework implementation that nobody outside the team ever used.
Use frameworks as a toolbox, not a religion. Take what helps your organization make better decisions, and leave the rest.
Signs Your Enterprise Architecture Is Working
You do not measure enterprise architecture by the number of diagrams. You measure it by outcomes:
- Projects reuse existing capabilities instead of rebuilding them
- The application portfolio is getting simpler, not more complex
- Major investments can be traced to business goals
- Teams know the principles and use them without being forced to
- Transformation programs start faster because the landscape is understood
And maybe the most important one: business leaders ask architects for input early, not after the decision is made.
Common Traps
The ivory tower
Architecture that lives only in documents and review boards loses influence quickly. If teams see architects as a gate rather than a help, they will route around them.
Documenting everything
A complete model of every system is expensive to build and impossible to keep current. Model what helps you make decisions. Nothing more.
Chasing technology instead of outcomes
New technology is exciting. But the job is to serve the strategy, not to collect the newest tools.
Enterprise Architecture in the AI Era
AI is making enterprise architecture more important, not less.
Organizations now need to decide where AI agents can act, what data they can see, which capabilities they can call and how their decisions are governed. Those are architecture questions. Organizations that already understand their capabilities, data and integrations are far better prepared to adopt AI safely than those that do not.
Final Thought
Enterprise architecture is not about drawing the future.
It is about helping an organization get there on purpose, one connected decision at a time.