IT management
Enterprise architecture
Enterprise architecture is the practice of describing an organization's business, data, applications and technology as one system and planning how it changes.
Organizations take up enterprise architecture when the number of systems, teams and projects grows past what anyone can keep in their head and expensive mistakes start to repeat: two divisions buy the same platform, a migration stalls on a dependency nobody knew about, a strategy is announced that the systems cannot support. Enterprise architecture is the practice of keeping one honest picture of the whole and using it to decide what to change.
Why does enterprise architecture matter?
- It connects strategy to systems. A goal like selling 40 percent of policies direct implies a portal, a pricing engine and customer data clean enough to use. Architecture makes those implications explicit before the budget is set.
- It removes duplication. Most large organizations run several systems for the same job. Seeing them side by side is the first step to application rationalization.
- It makes change safer. Knowing what depends on what, from a CMDB or dependency map, turns a migration from a guess into a plan.
- It gives projects guardrails. Standards and reference architectures mean each project does not reinvent identity, logging or integration.
What are the four domains of enterprise architecture?
The diagram at the top of this page shows the domains as bands for an insurer, with strategy above and projects below. Each band shapes the one under it.
| Domain | What it describes | Typical artifacts |
|---|---|---|
| Business architecture | What the business does: capabilities, value streams, organization and processes | Business capability map, value stream maps, process maps |
| Data architecture | What the business needs to know: the information it holds, who owns it and how it flows | Conceptual data models, ownership rules, data lineage |
| Application architecture | What the business uses: the systems that hold the data and run the processes | Application inventory, integration diagrams, application dependency map |
| Technology architecture | What those systems run on: platforms, networks, hosting and identity | Platform standards, network diagrams, landing zone designs |
In the example, the goal of leaving the mainframe by 2028 flows down through the processes it runs, the policy and claims data it holds and the policy administration system built on it, then lands as a migration project at the bottom.
What does enterprise architecture produce?
- A capability map. The one-page model of what the organization does, which everything else hangs off. See business capability map.
- An application portfolio. Every application with its owner, cost, lifecycle stage and the capabilities it supports, maintained through application portfolio management.
- Current and target states. The architecture as it is and as it should be, with the gaps between them. See current vs future state architecture.
- A roadmap. The sequence of transition states and projects that close those gaps over several years. See IT roadmap.
- Principles, standards and reference architectures. The rules every project designs within, enforced through an architecture review board.
What frameworks does enterprise architecture use?
Frameworks give the practice a method and a vocabulary. TOGAF, from The Open Group, is the most widely adopted and is built around a repeatable cycle for developing an architecture. The Zachman Framework is a classification grid rather than a method. ArchiMate is a modeling notation that pairs with either, and governments publish their own, such as FEAF in the United States. Most teams borrow the domain split and the current-to-target cycle and skip the rest.
How does enterprise architecture compare with solution architecture?
| Level | Scope | Horizon | Question it answers |
|---|---|---|---|
| Enterprise architecture | The whole organization | Three to five years | Which capabilities, platforms and standards should we have? |
| Solution architecture | One business problem and the systems that solve it | One program, 6 to 18 months | How do these systems fit together to solve it? |
| System architecture | One system or service | Release to release | How is this system built inside? |
Enterprise architecture sets the standards and the target state. A solution architect designs within them for one program, and the enterprise architect reviews that design to check it moves the organization toward the target rather than away from it.
How do you start enterprise architecture?
- Pick the decisions it must inform. A cloud migration, a merger, a cost target. Architecture with no decision to serve becomes documentation.
- Build the capability map. One page, two levels, agreed with business leaders. This is the index for everything else.
- Inventory the applications and their dependencies. Pull from the CMDB, procurement, cloud accounts and service mapping rather than surveys.
- Describe the target state only for the parts the decisions touch, and record why each choice was made.
- Write the roadmap and set up governance. Transition states with measurable outcomes, a small set of standards and a review projects can get through in days.
What are common enterprise architecture mistakes?
- Modeling everything. A complete model of a large organization takes years and is wrong before it is finished. Model what the current decisions need.
- Architecture by slide. Target states that exist only in presentations, with no inventory beneath them, cannot be checked and are not trusted.
- Governance as a gate. When review takes longer than the work, teams route around it. Standards should make the right choice the easy one.
- Stale current state. An inventory from last year’s survey misleads every decision built on it. Connect it to live sources.
What tools help with enterprise architecture?
- EA repository tools. Dedicated platforms hold the capability map, application portfolio and standards in one model, with views for each audience. They need steady effort to keep current.
- CMDB and discovery tools. A CMDB and its discovery feeds supply the application and technology layers with real data, which the architecture overlays with business context.
- Connected architecture maps. Tools like Eraser maps draw the application and infrastructure landscape from live sources such as a CMDB and cloud accounts, so the current-state view updates when the estate does.
For more on this kind of diagram, see architecture diagrams.
Frequently asked questions
-
What is the difference between enterprise architecture and IT architecture?
IT architecture covers the application and technology domains: which systems exist, how they connect and what they run on. Enterprise architecture adds the business and data domains and ties all four to strategy, so the question changes from how do we run this system to which systems should we have at all.
-
Does a small company need enterprise architecture?
Not as a function, but the questions still apply. A company with twenty applications can list them, note which capability each supports and decide what to retire in an afternoon. The practice becomes a job when nobody can hold the whole landscape in their head, usually somewhere past a few hundred people or systems.
-
What is an enterprise architecture framework?
A framework is a published method and vocabulary for the work: which domains to describe, which artifacts to produce and in what order. TOGAF is the most widely used, Zachman is the oldest and several governments publish their own. Most organizations adopt a framework loosely and keep the parts that fit.
-
What is an enterprise architecture repository?
The repository is where the architecture lives: the capability map, the application inventory with owners, costs and lifecycle, the technology standards and the relationships between them. It can be a dedicated tool, a disciplined wiki or a CMDB extended with business context. It has to stay current and be used by people other than architects.
