What Is Enterprise Architecture? Aligning Tech with Business

Large IT shops tend to carry a map of what they run today, a second map of what they want to run later, and a plan for getting from one to the other. That is enterprise architecture in its plainest form. The maps cover the business, data, application, and technology layers in their current and target states, and the plan is meant to point IT spending at strategy instead of whatever happened to be urgent last quarter.

IT leadership teams and large enterprises run the practice through frameworks such as TOGAF and the Zachman Framework. Government agencies often work with FEAF.

Results are uneven, though. In Bizzdesign’s 2024 survey of more than 500 practitioners, an average of 29.5% of respondents fully agreed their program achieved each business outcome asked about.

What Is Enterprise Architecture?

The scope is the whole organization, which is what separates it from the architecture of any one project or system. It describes the business, data, application, and technology layers as they are now and as they should be, then uses that description to steer IT investment toward business strategy.

The practice mostly comes down to a baseline view of how things work today and a target view of how they should work. The gap between them is where the real work sits. Roadmaps and principles, with governance behind them, exist to close that gap in a controlled order.

Published definitions do not match, and the differences show what each body cares about.

• Gartner’s 2008 wording describes a process that turns business vision and strategy into enterprise change, through shared principles and models of the future state.
• By 2013 the Gartner glossary had swapped “process” for “discipline” and framed the job as leading an enterprise’s response to disruptive forces.
• FEAPO, also in 2013, went with a practice of enterprise analysis, design, planning, and implementation, applied holistically, for developing and executing strategy.
• TOGAF defines an enterprise as any collection of organizations with a common set of goals, so the scope might be a whole corporation or a single department, and it can stretch across several linked organizations.
• US Code, 44 U.S.C. 3601, calls it a strategic information asset base that defines the mission and the information needed to perform it, along with the technologies involved.

The Open Group’s TOGAF leader’s guide quotes the 2008 Gartner wording, while the 2013 one comes from Gartner’s IT glossary.

Put side by side, the definitions agree more than the wording suggests. Strategy goes in and managed change comes out, with the whole organization as the scope.

Nobody has settled the question, either. A 2017 conference paper published by SCITEPRESS states the field has no single accepted definition.

Enterprise Architecture vs Solution, Business and Technical Architecture

Enterprise architecture sits above solution architecture, which sits above technical architecture. Business architecture is one domain inside enterprise architecture, not another name for it.

The boundary shows up in what each level decides. At the enterprise level the question is which capabilities the organization needs and which systems support them. At the technical level it’s how one system gets built, which is the software architecture of a single system and not of the organization.

The most common failure is letting enterprise architecture collapse into technology architecture. Sree Sundaram’s 2010 article in Enterprise Systems Journal noted that the discipline is nominally championed by the business but usually started by IT, which breeds suspicion among business managers.

A program that never leaves the technology domain stops being enterprise architecture, whatever it is called.

What Are the Four Domains of Enterprise Architecture?

TOGAF develops the domains in the order business, data, application, technology, and it treats data and application architecture together as the information systems layer (Phase C). In practice they get built together, not as separate technical disciplines.

Business architecture

This domain covers business strategy and goals, plus the organizational structure and governance around them. Capabilities and the processes that deliver them sit here too.

The capability map is the main artifact. It shows what the organization can do, independent of who does it or which system supports it.

Data architecture

Data architecture records which data entities the business depends on. It also notes where they are stored and how they move between systems.

It bridges business terms and application design, which is why TOGAF groups it with application architecture.

Artifacts here are usually a data entity catalog and data flow diagrams. The question that tends to come up is which system is the source of truth for customer records.

Application architecture

Application architecture covers the application systems, how they interact, and how they support core business processes. The application portfolio and the interface catalog are the usual artifacts, along with an application-to-capability matrix.

Application rationalization and cloud migration planning both start from this inventory. Overlapping legacy systems pile up technical debt, and the portfolio view is where the overlap becomes visible.

Technology architecture

Most people already picture this layer, which holds infrastructure, platforms, networks, and the services that host applications and data.

It comes last in the build order because its design depends on what the upper three domains need. Standards and approved products live here, and the architecture review board checks new purchases against them.

Which Enterprise Architecture Frameworks Are Used Most?

TOGAF, the Zachman Framework, FEAF, and DoDAF keep turning up across the sources. They solve different problems, so the choice depends on whether you need a method or a classification scheme, and on whether a regulator has already decided for you.

The Open Group calls TOGAF the world’s most widely used framework, and a September 2025 review preprint by Volkan Erol (not yet peer reviewed) ranks it the same way. Neither source gives an independent market-share count.

The choice usually sorts itself out like this.

• TOGAF and its ADM suit teams that need a method to follow.
• Zachman fits when the goal is classifying every artifact.
• A US federal agency will end up on FEAF and the Common Approach.
• Defense programs use DoDAF.

Zachman’s 1987 IBM Systems Journal paper limits itself to architecture and leaves out a strategic planning method, so the framework classifies and does not prescribe steps. It began with three columns, and Zachman’s own history places the six-column matrix in the early 1990s.

Government use traces to the Clinger-Cohen Act of 1996. OMB memo M-97-16 (1997) says the law makes each agency CIO responsible for developing and maintaining the IT architecture, and that the architecture includes an enterprise architecture.

Some explainers, Orbus Software’s wiki among them, still list TOGAF 9.2 (2018) as the latest version. The Open Group released the 10th Edition on 25 April 2022 with a modular structure and more guidance for business strategy and agile work, and the ADM stays at the core.

ArchiMate is not a framework. It is a modeling language, version 3.2 (October 2022), from the same publisher and aligned with TOGAF.

A heavy framework in a small team fails. (DoDAF in a four-person IT shop is the extreme case.) Sundaram’s 2010 article names that mismatch as a program killer, so pick the lightest option that meets the need.

How Does Enterprise Architecture Work, Step by Step?

TOGAF’s Architecture Development Method (ADM) runs the practice as a cycle. It opens with a preliminary phase, moves through eight lettered phases from A to H, and keeps requirements management running underneath all of them.

1. The preliminary phase prepares the organization and tailors the framework, then sets the architecture principles.
2. Phase A, Architecture Vision, scopes the work, names stakeholders, and agrees the intended outcome.
3. Phase B, Business Architecture, describes the baseline and target business capabilities and processes.
4. Phase C, Information Systems Architectures, does the same for data and applications.
5. Phase D, Technology Architecture, covers infrastructure and platforms the same way.
6. Phase E, Opportunities and Solutions, starts implementation planning and identifies the delivery vehicles.
7. Phase F, Migration Planning, groups projects into work packages and finalizes the implementation and migration plan.
8. Phase G, Implementation Governance, keeps delivery in line with the target architecture.
9. Phase H, Architecture Change Management, handles changes to the architecture after delivery.
10. Requirements management feeds requirements in and out of every phase.

Phases B, C, and D all work the same way. Document the baseline, define the target, then analyze the gaps between them. Those gaps feed Phases E and F, where they turn into projects and a sequenced plan.

The ADM is deliberately flexible. A team can return from Migration Planning to Business Architecture when a roadmap exposes a business constraint nobody had mapped.

The Preliminary phase doubles as the safeguard against a heavy framework. It exists to tailor the method to the organization’s size and needs, so a small team does not run every phase at full depth.

What Does Enterprise Architecture Produce?

The TOGAF Standard, 10th Edition defines 21 formal deliverables. The usual starting set is the Architecture Vision, Architecture Principles, Architecture Definition Document, Architecture Requirements Specification, Architecture Roadmap, and the architecture repository that stores them.

Deliverables are the formal work products of an architecture project, while artifacts, such as a capability map or an application catalog, are the individual views inside them.

• The Architecture Vision sets the intended outcome and scope in Phase A.
• Principles are standing rules for decisions, and they get defined in the Preliminary phase.
• The Architecture Definition Document gives the qualitative description of the baseline and target, and it holds the core artifacts.
• The Architecture Requirements Specification lists the measurable criteria an implementation has to meet.
• The Roadmap sequences work packages over time to reach the target.
• Models and standards, along with finished deliverables, end up in the architecture repository.

The Open Group treats its deliverable definitions as a baseline for tailoring, not a template to fill in. A small program that produces all six at full depth spends its time on paper.

ISO/IEC/IEEE 42010 sets the rules for how an architecture description gets written. The second edition (November 2022) covers enterprises alongside software and systems, and it requires the description to name stakeholders and their concerns and to record decisions with their rationale.

Bizzdesign’s 2024 survey of more than 500 practitioners asked which artifacts support business change. Solution architecture diagrams came first, then application and technology catalogs and roadmaps, and business capability maps ranked below all of them.

Artifacts closest to delivery get used. The application portfolio is the clearest case, because the same survey found many organizations cannot see which of their applications are duplicated or obsolete.

Who Runs Enterprise Architecture and Who Approves Decisions?

A chief architect or lead enterprise architect runs the practice, and an architecture review board approves decisions that cross project lines. TOGAF calls that body the Architecture Board.

The roles split up like this.

• Enterprise architects set cross-system rules and keep the baseline and target views current.
• The chief architect leads the function and often reports to the CTO or CIO.
• An architecture review board, a cross-organization body, looks after the governance strategy.
• An executive sponsor reviews the board’s work and judges whether it is effective.

A software architect owns the design of one system. The enterprise architect owns the rules every one of those designs has to follow.

The board’s main lever is the architecture compliance review, a check of one project against the established architecture. TOGAF says the process needs backing from senior management, and a lead enterprise architect or a board representative can run it.

A review starts when someone requests it and names the project principals. The reviewer then scopes it and tailors the checklist, interviews the team, and analyzes the answers.

In Phase G the outcome is an Architecture Contract, a signed agreement on what the implementation team must deliver.

Authority is where governance breaks down. Sree Sundaram’s 2010 article in Enterprise Systems Journal argued that architects often carry responsibility without matching authority.

EPA’s inspector general raised the same point in a September 2002 audit. It recommended delegating enterprise architecture duties from the CIO through a Chief Technology Officer to a Chief Architect, so the role would hold real authority and resources.

Which Tools and Modeling Languages Do Enterprise Architecture Teams Use?

Teams use a modeling language to draw the architecture and a repository tool to store, link, and analyze it. The two are separate choices.

• ArchiMate covers the business, application, and technology layers, plus strategy, motivation, and implementation and migration elements.
• BPMN handles business processes and is maintained by the Object Management Group (version 2.0.2, January 2014, also ISO/IEC 19510:2013).
• UML describes software structure and behavior.

UML is the closest of the three to software modeling, so it fits application and data design better than business-layer views.

Gartner’s Magic Quadrant for Enterprise Architecture Tools, published 13 October 2026, evaluated 15 vendors. Ardoq, Bizzdesign, Orbus Software, and SAP LeanIX each announced a Leader placement, according to each vendor’s own announcement.

Tool-based modeling has a documented failure mode. A practitioner survey from the University of Reading (SCITEPRESS, 2015) suggested that most modeling efforts had stopped (an estimated 85%), though its sample was small and qualitative.

Start in Archi. Its maintainers pitch it as a way to learn ArchiMate before buying a commercial platform, and that is the cheaper way to find out whether the team will keep modeling at all.

Buy a repository platform when several teams need shared, governed data. Bizzdesign’s 2024 survey found most organizations keep architecture data in more than one system, though a vendor has a stake in that finding.

What Benefits Does Enterprise Architecture Deliver, and How Well Is It Measured?

Practitioners credit enterprise architecture with better system integration and IT governance, but few organizations measure outcomes, so most benefit claims rest on perception.

• Only 5 of 27 US federal departments and agencies had fully or partially measured and reported architecture outcomes (GAO, 2012).
• Practitioners rated improved system integration at 3.6 on a scale of -10 to +10 (Ambysoft, 2010).
• Reduction of technical complexity got a 0.8 on the same scale (Ambysoft, 2010).
• USAID reported $12.3 million in cost savings from moving disparate HR systems to a shared services center (GAO, 2012).

What practitioners report

Ambysoft’s February 2010 survey of 374 practitioners rated existing programs as effective but far from outstanding.

Integration and governance scored well. Complexity reduction, the benefit explainers usually list first, scored far below them.

Bizzdesign’s 2024 survey tells a similar story, with most teams struggling to deliver business outcomes. More mature teams report better outcomes in the same data, though the survey is self-assessed and vendor-run, and a correlation is all it shows.

Why measurement lags

GAO’s 2012 audit explains why agencies skipped it. They could not attribute outcomes to architecture when strategic and capital planning and project management also contributed, and they lacked guidance on how to measure.

Tiitinen and colleagues (2024) point to the same gap in the research, since little empirical work measures what enterprise architecture management delivers.

The practitioner poll from 2010 and the vendor survey from 2024 come from unrelated samples, and the 2012 government audit lands in the same place. Benefits are perceived more than measured.

USAID is the case that shows what measurement looks like. It was the only agency in the GAO sample reporting outcomes monthly, and it tied savings to a named change in how it ran its HR systems.

Agencies that did measure picked very different metrics.

• HHS tracked reuse of service components.
• HUD counted duplicate technology products added and obsolete systems retired.
• Education compared development and modernization spending against steady-state spending.
• Commerce looked at IT cost reduction from enterprise-wide standards.

Why Do Enterprise Architecture Programs Fail, and When Is It Not Worth Doing?

Programs fail mainly because executives never engage and the practice never reaches the teams that build systems. The framework chosen matters less than either.

How often programs fail

Gong and Janssen’s 2022 study in Information Systems Frontiers cites consultancy figures. Two-thirds of initiatives failed (Roeleven, 2010), and about 40% of programs were shut down within three years (Sessions, 2009).

The two numbers measure different events, a failed initiative and a cancelled program, so they cannot be averaged into one rate. The same study describes enterprise architecture failure as undertheorized.

Documented causes

• GAO’s 2002 and 2003 reports cite limited executive understanding, inadequate funding, too few skilled staff, and organizational parochialism.
• Gong and Janssen (2022) say to start with senior managers’ architecture knowledge and the architects’ communication and leadership skills, and to organize the function later.
• Ambysoft’s 2010 survey ranked business-leader involvement as the top success factor, and it found programs cancelled for lack of time and because project teams ignored the architecture.
• A 2017 qualitative case study of success and failure cases (EAPAD archive) found that success came more from how architecture is practiced than from what is practiced.

Executive understanding shows up in three of these sources across two decades, and Bizzdesign’s 2024 survey found C-level engagement the weakest of any stakeholder group. That challenges the common habit of treating framework and tool selection as the main decision.

When enterprise architecture does not fit

It tends to be a poor fit in some situations.

• No executive sponsor on the business side
• A budget too small to carry a full framework, which Sundaram (2010) names as a program killer
• A single-platform organization, where solution architecture does the job
• A team that cannot define how outcomes will be measured, the position most GAO-reviewed agencies were in

Scoping down is usually better than skipping. Orbus Software’s guide argues that narrow architecture projects still pay off, and Sundaram warns that one-size-fits-all programs do not work for small enterprises.

Budgets follow outcomes. Bizzdesign’s 2024 data shows organizations invest more when architecture reduces risk and delivers business value, so a program that cannot show either is the first one cut.

Enterprise Architecture FAQ

Is there a certification for enterprise architects?

Yes. The Open Group certifies individuals through TOGAF Enterprise Architecture Foundation and TOGAF Enterprise Architecture Practitioner, and there is also a TOGAF Business Architecture Foundation.

The Foundation certification is open to all applicants, with no prior certification required.

What skills does an enterprise architect need?

Business knowledge and communication matter more than modeling skill. Gong and Janssen’s 2022 study names the architects’ communication and leadership skills as a starting condition for success.

GAO’s reports from 2002 and 2003 list too few skilled staff among the recurring program challenges.

Is there a maturity model for enterprise architecture?

Yes. GAO’s Enterprise Architecture Management Maturity Framework, issued in August 2010, has 59 core elements grouped into seven stages in version 2.0.

TOGAF 10 also lists architecture maturity models among its reference material. Bizzdesign’s 2024 survey scored maturity from seven self-assessment statements.

Can enterprise architecture work with agile teams?

Yes. The TOGAF 10th Edition includes a Series Guide on enterprise agility, which covers running the Architecture Development Method in an Agile environment through iterative sprints.

The guide also states that enterprise agility is broader than Agile software development.

How does enterprise architecture deal with shadow IT?

It makes shadow IT visible rather than preventing it. An application catalog in the architecture repository records what exists, and compliance reviews check new projects against it.

Visibility is the weak point. Bizzdesign’s 2024 survey found a third of organizations have poor visibility into duplicate and obsolete applications.

How much do enterprise architecture tools cost?

Archi is free and open source, so entry costs nothing. Sparx Systems Enterprise Architect is a commercial licence, and Ardoq describes an application-based pricing model.

Vendors price differently, so compare quotes against the number of applications and users you need to model.

Starting a Small Enterprise Architecture Practice

An organization with no enterprise architecture practice should begin with one business-side sponsor. An application inventory comes second, and one measurable outcome third. That scope needs a single architect, not a framework rollout.

The order follows what each step makes possible. A sponsor gives the architecture review board authority to retire systems, and the inventory shows which retirements deserve the effort.

Sponsors give programs limited time, and attribution is hard to rebuild afterward. A metric defined before the first model, such as duplicate applications retired, is therefore the only proof a small program can produce on schedule.

The cost is a delayed target-state architecture. The first year yields a baseline and a retirement list, not a roadmap across all four domains.

This position holds as of 29 October 2026. It changes if a study compares matched organizations with and without a program, a design the surveys and audits cited here do not use.

• Author
• Recent Posts

Bogdan Sandu

Bogdan Sandu is a front-end developer at TMS Outsource with 8+ years of experience in web technologies. He writes about developer tools, software platforms, and web workflows based on daily hands-on use.

Latest posts by Bogdan Sandu (see all)

• What Communications Teams Should Ask Before Commissioning a Mobile App - November 12, 2026
• How to Install Node JS in VS Code and Run Your First Script - November 11, 2026
• Protecting Users and Brand Standards Across Image-Driven Platforms - November 10, 2026