Enterprise architecture (EA) is the practice of describing how an organization’s business processes, information, applications and technology fit together, and of planning how they should change to support the business’s goals. It produces maps of the current landscape, a target state, and a roadmap for moving between them, along with standards and principles that guide technology decisions. It helps leaders see the effect of a change, such as replacing a system or merging two companies, before committing to it.
At a glance
- EA links business strategy to the systems and technology that support it.
- It is commonly described in layers: business, data or information, applications, and technology or infrastructure.
- Typical outputs include an application inventory, capability maps, integration diagrams, standards and a roadmap.
- Frameworks such as TOGAF are widely used for method and vocabulary, but many organizations use a lighter approach.
- For buyers, EA informs consolidation, replacement and integration decisions.
What problem it solves
Technology landscapes grow by accumulation. Departments buy their own software, acquisitions bring duplicate systems, integrations are built project by project, and old platforms stay because nobody is sure what depends on them. The result is overlapping applications, fragile connections, rising technology debt and slow, risky change.
Enterprise architecture gives the organization a shared map of what exists, what each system does, how data flows and which business capabilities depend on which technology. With that map, leaders can retire duplicates, plan replacements in the right order, set standards new projects follow, and estimate the effort behind strategic moves such as a merger or a cloud migration.
How it works
Business architecture. Defines the organization’s capabilities (what it needs to be able to do) and processes, and links them to the systems that support them.
Data or information architecture. Describes the main data the business relies on, where it is stored, who owns it and how it moves, which links closely to data governance.
Application architecture. Inventories applications, their functions, owners, costs and integrations, and assesses which to keep, replace, consolidate or retire, often called application rationalization.
Technology architecture. Covers the infrastructure, platforms, networks and standards applications run on. Details often come from a configuration management database (CMDB) or discovery tools.
Governance and roadmap. Architects set principles and standards, review significant projects, and maintain a roadmap from the current to the target state. EA tools or repositories store the models, though many smaller teams start with spreadsheets and diagrams.
When it matters for buyers
- Before replacing a core system. An ERP or CRM change touches many integrations; mapping them first reduces surprises.
- During mergers and acquisitions. Comparing two landscapes is the starting point for post-merger IT integration.
- When consolidating vendors or SaaS. An application inventory shows where tools overlap and what vendor consolidation would affect.
- When redesigning the IT operating model. EA informs which platforms and capabilities the IT operating model needs to support.
- When projects keep picking different technologies. Shared standards reduce long-term support cost.
- When auditors or security reviews ask for system maps. Knowing where sensitive data lives, which systems connect to each other and who owns each application makes those questions faster to answer and controls easier to plan.
Questions to ask vendors
These questions apply to EA consultancies and to vendors of EA or application portfolio tools:
- What will we have at the end of the engagement: inventory, capability map, target state, roadmap, or all of these?
- Which framework or method do you use, and how much of it will we actually need?
- How do you collect data about our applications and integrations, and how much staff time does it require?
- How will the architecture be kept current after you leave?
- Can your tool import data from our CMDB, SaaS management, finance and identity systems?
- How do you connect architecture recommendations to cost and business value?
How it differs from IT operating model
Enterprise architecture describes what the organization’s business and technology landscape looks like and how it should evolve. The IT operating model describes how the IT function is organized, governed, sourced and funded to deliver that technology. EA shapes the target the operating model has to support, and the operating model decides who builds and runs it. For keeping the application inventory current, see our SaaS management platforms overview.