Enterprise Architecture

Enterprise architecture, usually shortened to EA, is the discipline of describing how an organization is put together and planning how it should change. It looks at an organization's structures and behaviour: its business functions and processes, the people and roles that carry them out, the information they create and use, the applications that support them, and the technology underneath. The goal is to make change deliberate and coordinated instead of piecemeal.

The Federation of Enterprise Architecture Professional Organizations (FEAPO) describes enterprise architecture as "a well-defined practice for conducting enterprise analysis, design, planning, and implementation." The research firm Gartner describes it as a way to proactively and holistically lead an enterprise's response to disruptive forces, by identifying and analysing the changes needed to reach its desired business vision and outcomes.

A common analogy compares enterprise architecture to city planning. A building architect designs one building. A city planner thinks about zoning, roads, utilities and how districts connect, and sets rules so that individual buildings fit together. In the same way, a solution architect designs one system, while an enterprise architect looks across all of an organization's systems, processes and data, and sets the direction and standards that let individual projects fit together. The US Government Accountability Office (GAO) puts it this way: "an enterprise architecture is to an organization's operations and systems as a set of blue prints is to a building."

This article covers what enterprise architecture is, where it came from, the main schools of thought, the major frameworks (Zachman, TOGAF, the US Federal Enterprise Architecture Framework, DoDAF and ArchiMate), how an EA practice works, its claimed benefits, the evidence and criticism, common misconceptions, and frequently asked questions.

Core Definitions

Enterprise

In EA, an enterprise is not necessarily a whole company. The International Institute of Business Analysis (IIBA) defines it as an organizational unit, an organization, or a group of organizations that share common goals and deliver products or services to customers. An enterprise might be a government department, a whole multinational, a single division, or a partnership of several organizations. It includes the whole sociotechnical system: people, information, processes and technologies. Defining which enterprise is in view is the first step in any EA effort.

Architecture

The international standard ISO/IEC/IEEE 42010 defines architecture as the fundamental concepts or properties of a system in its environment, embodied in its elements, their relationships, and the principles of its design and evolution. The important point is that architecture is about fundamentals, the things that are expensive to change and that shape everything else, rather than every detail.

Enterprise architecture framework

An enterprise architecture framework is a methodology for using architecture to guide an organization from a baseline state, sometimes called "as-is," to a target state, sometimes called "to-be," often through transition states in between. A framework typically provides processes, techniques, descriptions of the documents and models to produce (called artifacts), reference models and guidance.

Architecture description, views and viewpoints

The product that describes an architecture is called an architecture description. Following ISO/IEC/IEEE 42010 and its predecessor IEEE 1471, an architecture description is organized into views. A view expresses the architecture from the perspective of particular stakeholders and their concerns. Typical views in EA cover:

• Business functions or capabilities
• Business processes
• Human roles and organization structure
• Data flows and data stores
• Applications and their interactions
• Hardware and communications infrastructure

The vocabulary of 42010 is worth knowing, because most frameworks build on it:

Enterprise architect and solution architect

The MITRE Corporation's Enterprise Architecture Body of Knowledge places enterprise architects at the top of the hierarchy of architects. They oversee solution architects and work with business functions. Solution architects focus on individual solutions. Enterprise architects focus on aligning people, process and technology decisions with the organization's strategic vision.

Origins and History

Zachman, 1987

John Zachman is often called the father of enterprise architecture. He worked at IBM in the 1980s on Business Systems Planning, a method for analysing an organization's information needs. By 1982 he had realised that such analysis could support strategic planning, not only the design of systems. In 1987 he published "A Framework for Information Systems Architecture" in the IBM Systems Journal. He drew on classical architecture and engineering, where different people (owner, designer, builder) need different representations of the same building. He argued that information systems need the same thing.

Zachman's 1987 paper is often said to have coined the term "enterprise architecture," but it did not use it. The paper was about information systems architecture.

NIST, 1989

The first publication to use the term enterprise architecture was from the US National Institute of Standards and Technology (NIST). Elizabeth Fong and Alan Goldfine described the NIST Enterprise Architecture Model in December 1989, in work that appeared in SIGMOD Record under the title "Information management directions: the integration challenge." The NIST model arranged architecture in levels, with business unit architecture at the top, and set frameworks, standards, policies and procedures for an organization's internal and external information needs.

There was a difference of emphasis. Zachman was concerned with building individual information systems that were well suited to the business. NIST was concerned with managing all the information systems in a business unit together. Both agreed that growing system size and complexity demanded a logical architecture for defining interfaces and integrating components.

Expansion

In 1992 John Sowa and John Zachman extended and formalised the framework in a second IBM Systems Journal paper. In the 1990s Zachman's work was renamed the Framework for Enterprise Architecture. Around the same time, US defence work on the Technical Architecture Framework for Information Management (TAFIM) fed into the first version of TOGAF in 1995. The US Clinger–Cohen Act of 1996 made enterprise architecture a recognised management practice in the US federal government, and federal frameworks followed.

Timeline

Three Schools of Thought

Practitioners do not all mean the same thing by enterprise architecture. James Lapalme, writing in 2012, identified three schools of thought.

These schools explain why people argue past each other. An IT department that says it "does EA" may mean an inventory of applications and technology standards. A strategy office may mean the design of the whole operating model. An academic in the third school may mean helping the organization adapt to a changing environment. All three are legitimate, but they need different skills and produce different results.

The Main Frameworks

Dozens of EA frameworks exist. The most influential are described below.

The Zachman Framework

The Zachman Framework is a classification scheme rather than a method. It is a matrix with six columns, one for each basic question, and six rows, one for each perspective. The column headings in version 3.0 are:

The rows in version 3.0 are:

That gives 36 cells. Each cell is a distinct representation, such as the executive's list of key business things (row 1, What) or the architect's logical data model (row 3, What). Zachman stated rules for the framework. Columns can be swapped in order but not added or removed. Each column has a simple, unique basic model. Each row is a distinct perspective. Each cell is unique. The logic is recursive, so the framework can classify itself.

The US Department of Veterans Affairs used the Zachman Framework in 2001 to develop its One-VA Enterprise Architecture. It built a Zachman Framework portal and a repository based on a metamodel at the cell level. The framework also influenced the NIST model, C4ISR, DoDAF and the US Federal Enterprise Architecture Framework, which used the first three columns.

Critics point out the lack of detailed published examples of the full framework working in practice. Zachman himself said in 2004: "If you ask who is successfully implementing the whole framework, the answer is nobody that we know of yet."

TOGAF

TOGAF, from The Open Group, is the most widely known EA method. Development began in the early 1990s. TOGAF 1.0 appeared in 1995, based largely on the US Department of Defense's TAFIM and on Capgemini's Integrated Architecture Framework. Later versions include TOGAF 7, the "Technical Edition," in December 2001; TOGAF 8, the "Enterprise Edition," in December 2002; TOGAF 9, which added a formal content metamodel, the Architecture Repository and the Enterprise Continuum; and the TOGAF Standard, 10th Edition, launched on 25 April 2022. The Open Group makes TOGAF available free for internal, non-commercial use.

TOGAF divides architecture into four domains:

The core of TOGAF is the Architecture Development Method, or ADM, an iterative cycle that organizations tailor to their needs. Its phases are:

TOGAF's Enterprise Continuum classifies architectures and solutions on a scale from generic foundation architectures to organization-specific ones. It has two parts: an Architecture Continuum for reusable architecture assets and a Solutions Continuum that implements them through reusable building blocks.

TOGAF is widely used for certifying practitioners. Wikipedia reports more than 15,000 certified individuals as of February 2011 and more than 77,500 certifications on the official register by April 2018. In 2016 The Open Group claimed that 80 per cent of Global 50 companies and 60 per cent of Fortune 500 companies used TOGAF. That is the publisher's own claim and should be read as such.

US Federal Enterprise Architecture

The US federal government has been one of the largest and most visible users of EA. The Clinger–Cohen Act of 1996 made enterprise architecture an expected management practice. The Federal CIO Council published version 1.1 of the Federal Enterprise Architecture Framework (FEAF) in September 1999. It drew on the NIST model and divided architectures into business, data, applications and technology.

After the 2001 E-Government Task Force, the federal approach shifted toward reusable components organized by reference models. Version 1 had five reference models: performance, business, service component, data and technical. In May 2012 the Office of Management and Budget (OMB) issued the "Common Approach to Federal Enterprise Architecture." It aimed to reduce waste and duplication, expand shared services and close performance gaps. It defined eight levels of scope, from international down to application, and a Collaborative Planning Methodology. FEAF version 2, released on 29 January 2013, regrouped the reference models into six:

The point of reference models is comparison. If every agency describes its services using the same business reference model, OMB can see when five agencies are paying for five separate systems that do the same thing.

DoDAF and its relatives

The US Department of Defense Architecture Framework (DoDAF) grew out of the C4ISR Architecture Framework, whose version 1.0 appeared in 1996 and version 2.0 in 1997. DoDAF 1.0 was released in 2003 and 1.5 in 2007. DoDAF 2.0 was approved in May 2009, and the current release is 2.02. Version 2.0 renamed "views" as "viewpoints" to align with ISO usage and defined eight of them: All, Capability, Data and Information, Operational, Project, Services, Standards and Systems. It introduced a new metamodel called DM2, based on the IDEAS Group foundation ontology.

DoDAF supports six core defence processes, including capabilities integration, planning and budgeting, acquisition and systems engineering. Related frameworks include the UK Ministry of Defence's MODAF and the NATO Architecture Framework (NAF). The Object Management Group's UPDM effort standardised how DoDAF and MODAF models are expressed in UML and SysML.

ArchiMate

ArchiMate is a modelling language for enterprise architecture, as opposed to a framework or method. It was developed in the Netherlands from July 2002 to December 2004 by a project team at the Telematica Instituut working with Dutch government, industry and academic partners. Ownership passed to The Open Group in 2008. Versions include 1.0 (2009), 2.0 (2012), 2.1 (2013), 3.0 (2016), 3.1 (2019) and 3.2 (2022).

ArchiMate's core has three layers: business, application and technology. The full language adds physical, strategy, motivation, and implementation and migration elements. Within each layer it distinguishes three aspects:

ArchiMate was designed to be small. Version 2.0 had about 50 concepts, aimed at "the proverbial 80% of practical cases." It is often used alongside TOGAF, with TOGAF supplying the method and ArchiMate the diagram notation.

Framework comparison

How an EA Practice Works

The basic loop

Whatever framework is used, most EA work follows a simple pattern:

1. Understand the strategy. What is the organization trying to achieve, and what is changing around it?
2. Describe the current state. What capabilities, processes, information, applications and technology exist today, and how do they connect?
3. Define the target state. What should they look like to support the strategy?
4. Analyse the gaps. What is missing, duplicated, outdated or poorly connected?
5. Plan the roadmap. Which changes, in which order, with what transitions, costs and risks?
6. Govern the change. Check that projects follow the roadmap and standards, and update the architecture as reality and strategy shift.

The sponsor

The Wikipedia article on EA calls identifying the sponsor "paramount." The sponsor's mission, vision, strategy and governance set the frame for everything else. Without a senior sponsor who cares about the result, EA tends to drift into documentation that nobody uses.

Typical changes EA supports

Changes that EA commonly guides include:

• Innovation in the structure or processes of an organization.
• Innovation in the use of information systems or technology.
• Integration or standardisation of business processes.
• Improving the quality and timeliness of business information.

Common artifacts

EA and governance

EA is often built into IT governance. Architecture review boards check proposed projects against the target architecture and standards. Investment committees use capability maps and portfolio data to decide where money should go. The US federal government links EA to its Capital Planning and Investment Control process for IT spending.

Worked Example: Rationalising an Application Portfolio (Hypothetical)

A common practical use of EA is reducing duplication in an organization's applications. The following example is entirely hypothetical.

A mid-sized insurer creates a capability map and links each of its applications to the capabilities it supports. The analysis finds three separate customer-relationship systems, inherited from two acquisitions, all supporting the "manage customer relationship" capability.

The three together cost $400,000 + $250,000 + $150,000 = $800,000 a year. Customer data is split three ways, so no one sees a complete customer history.

The target architecture proposes moving everyone to CRM A. The vendor quotes extra licences for the 230 additional users (150 + 80 = 230) that raise CRM A's cost to $520,000 a year. A one-off migration project is estimated at $600,000.

• Annual saving after migration: $800,000 − $520,000 = $280,000
• Simple payback period: $600,000 ÷ $280,000 ≈ 2.1 years

The financial case is only part of the argument. A single customer view may improve service and reduce errors, and retiring the unsupported CRM C removes a security risk. EA's contribution here is not the arithmetic, which anyone could do. It is the capability map and portfolio inventory that revealed the duplication in the first place, and the roadmap that sequences the migration around other changes.

Who Uses Enterprise Architecture

EA is used across government and industry. Wikipedia lists examples including the US federal government, through its Capital Planning and Investment Control processes, and companies such as Independence Blue Cross, Intel, Volkswagen AG and InterContinental Hotels Group. The US Federal Enterprise Architecture reference guide exists specifically to help federal agencies develop their own architectures.

Different sectors use EA for different reasons:

In each case the underlying problem is the same. The organization has grown complex enough that no one person can see how everything connects, and decisions made in one place have costly effects somewhere else.

Building an EA Practice

Maturity

Organizations rarely start with a complete EA capability. They build it over time. The GAO has published a framework for assessing EA management maturity since 2001. Version 1.0 was a practical guide in February 2001, version 1.1 (GAO-03-584G) followed in April 2003, and version 2.0 (GAO-10-846G) in August 2010. GAO developed version 2.0 with comments from 27 federal departments and agencies as well as private-sector, state and academic representatives. The framework is meant as a benchmark that organizations can use to plan for and measure the maturity of their EA programmes. The general idea of such maturity models is that a practice moves from basic awareness and commitment, through building and using architecture products, to measuring results and continually improving them.

Roles

A typical EA function might include:

Small organizations may combine all of these in one or two people. Large ones may have dozens of architects in a central team and in business units.

Tools

EA teams often use specialised repository and modelling tools that store architecture elements and relationships, so a change in one place is reflected in every diagram and report that uses it. Wikipedia lists products certified against TOGAF 9, including ABACUS from Avolution, products from Bizzdesign, ADOIT from the BOC Group, iServer from Orbus Software and ARIS from Software AG. Open-source options also exist. Oshifeko and Polovina, in a 2022 paper, evaluated the open-source Essential Project tool. Many teams start more simply, with spreadsheets, diagramming tools and a wiki, and move to a repository when the volume of information justifies it.

Claimed Benefits

Wikipedia's survey of the literature lists a long series of reported benefits. They include:

• Supporting organizational redesign during mergers, acquisitions and other change.
• Enforcing discipline and standardisation of processes, and enabling reuse and integration.
• Supporting investment decisions and work prioritisation.
• Improving project scoping, collaboration between stakeholders and requirements gathering.
• Optimising system design and resource allocation.
• Reducing implementation and operating costs and duplicated infrastructure.
• Reducing IT complexity and improving data consolidation and interoperability.
• Supporting regulatory compliance and transparency.
• Reducing business risks from system failures, security breaches and failed projects.

The GAO's 2010 framework for assessing EA management, version 2.0 of its guide, calls effective use of EA "a hallmark of successful organizations." It lists benefits such as consolidating and reusing shared services, better information sharing and streamlined business processes. It warns that without an EA, organizations risk building duplicative, poorly integrated systems that are costly to maintain and "unable to respond quickly to shifting environmental factors."

Evidence, Challenges and Criticism

Measuring value is hard

The case for EA is easy to state but hard to prove. EA projects are broad and often opaque, which makes it difficult to define measures of success. Benefits such as better decisions or avoided duplication are real but hard to attribute to the architecture team instead of to the projects that delivered them.

The GAO has studied this in the US federal government. A 2011 GAO report concluded that most agencies expected to realise the benefits of their EA programmes at some point in the future, and that "the real value in the federal government from developing and using enterprise architectures remains largely unrealized." A 2012 GAO report, Enterprise Architecture Value Needs to Be Measured and Reported (GAO-12-791), looked at 27 agencies:

Agencies blamed a lack of guidance, and the GAO found that OMB had not provided enough detail on how to measure outcomes. According to the GAO's recommendation tracker, many of those recommendations were later closed as not implemented, because OMB no longer required agencies to report EA outcomes.

Acceptance

A major challenge, and a common reason EA initiatives fail, is getting EA accepted as an integrated concept at the operational and tactical levels. People running daily operations may see architecture as overhead or as an "ivory tower" imposing rules from above.

Published criticism

EA has faced pointed criticism from inside the field. Ivar Jacobson, a pioneer of software engineering methods, wrote a 2007 piece titled "EA Failed Big Way!" Gartner raised concerns in 2007. Roeleven and Broer, writing for Erasmus University Rotterdam and IDS Scheer in 2010, published "Why Two Thirds of Enterprise Architecture Projects Fail." Dion Hinchcliffe in 2009 and Stanley Gaver in 2010, with "Why Doesn't the FEA Work?", added further critiques. These critics argue, in various ways, that EA often fails to deliver and that heavy, documentation-centred approaches may fade.

Common themes in the criticism include:

• Too much documentation, too little impact. Large models can take years to build and be out of date when finished.
• Detachment from delivery. Architects who do not work with project teams can produce plans nobody follows.
• Framework worship. Treating a framework as the goal rather than a tool.
• Slow governance. Review boards that delay projects without improving them.
• Unproven value. As the GAO findings show, benefits are often asserted rather than measured.

Responses

Practitioners have responded with lighter, more iterative approaches. These involve producing just enough architecture to support decisions, working closely with delivery teams, focusing on capability maps and roadmaps rather than exhaustive models, and measuring outcomes such as reduced application count, lower run costs or faster delivery. TOGAF's own Architecture Development Method is meant to be tailored rather than applied whole.

Relationship to Other Disciplines

FEAPO lists a wide range of disciplines that EA draws on or works with. They include performance engineering and management, process engineering and management, IT and enterprise portfolio management, governance and compliance, IT strategic planning, risk analysis, information and metadata management, organization development, design thinking, systems thinking and user experience design.

Some relationships are worth singling out:

Common Misconceptions

"EA is just IT architecture." That is one school of thought, the enterprise IT design school. Others see EA as covering the whole organization, including its strategy, processes, people and environment.

"Zachman coined the term in 1987." His 1987 paper was about information systems architecture. The term enterprise architecture first appeared in a 1989 NIST publication.

"A framework is a method." Zachman is a classification scheme. ArchiMate is a modelling language. TOGAF is a method with a content framework. Mixing them up leads to the wrong expectations.

"EA means drawing diagrams." Diagrams are tools. The purpose is better decisions about change, investment and integration.

"EA is only for big organizations." Large organizations have the most complexity to manage, but the basic questions of what we have, what we need and how we get there apply at any size. Small organizations need far less formality.

"Once the architecture is documented, it's done." Architectures go out of date as organizations change. EA is a continuing practice, which is why TOGAF ends its cycle with architecture change management.

"Certification makes someone an enterprise architect." Certifications show knowledge of a framework. Effective EA also depends on business understanding, communication and judgement.

Frequently Asked Questions

What is enterprise architecture in one sentence?

It is the practice of describing how an organization's business, information, applications and technology fit together, and of planning and guiding change so they keep supporting its goals.

Who invented enterprise architecture?

No single person. John Zachman's 1987 framework for information systems architecture is the best-known starting point, and a 1989 NIST publication first used the term enterprise architecture.

What is the most popular framework?

TOGAF is the most widely known method and has the largest certified community. The Zachman Framework is widely cited as a classification scheme, and ArchiMate is a widely used modelling language. Governments often use their own frameworks, such as FEAF and DoDAF.

What is the difference between enterprise architecture and solution architecture?

Solution architecture designs a particular system or project. Enterprise architecture looks across the whole organization and sets the direction, standards and roadmap within which individual solutions are designed.

What does an enterprise architect actually do?

Typical work includes building and maintaining capability maps and portfolio inventories, defining target architectures and roadmaps, setting principles and standards, reviewing major projects, advising executives on technology investments, and helping plan mergers, divestments and large transformations.

Does EA work with agile development?

It can. Agile teams make many local design decisions quickly. EA provides the shared direction, such as standards, integration patterns and roadmaps, that keeps many teams' decisions coherent. Problems arise when EA is run as a slow approval gate rather than as guidance and collaboration.

Is there an international standard for EA?

ISO/IEC/IEEE 42010 standardises how architecture descriptions are expressed, including stakeholders, concerns, viewpoints and views. It applies to architecture in general, including enterprises. Specific frameworks such as TOGAF and ArchiMate are standards published by The Open Group.

What are baseline, transition and target architectures?

The baseline, or "as-is," architecture describes how the organization works today. The target, or "to-be," architecture describes how it should work to support the strategy. Transition architectures are intermediate states that are stable enough to operate in while the change continues. Large changes are rarely made in one step. A roadmap of transitions lets the organization keep running and keep earning value while it moves toward the target. TOGAF's migration planning phase is largely about choosing these transition states and the order of work between them.

How does EA help with mergers and acquisitions?

When two organizations combine, they usually bring overlapping processes, applications, data and infrastructure. EA's maps let the combined organization see where the overlaps are, decide which systems and processes to keep, and plan the integration in sensible steps. Supporting organizational redesign during mergers and acquisitions is one of the most commonly reported benefits of EA. The worked example above, three customer systems inherited from acquisitions, is a typical case.

What skills does an enterprise architect need?

Technical breadth matters, but so do business understanding, communication, negotiation and the ability to explain trade-offs to non-specialists. Because EA's value depends on acceptance across the organization, an architect who cannot persuade people will struggle however good the models are.

How is EA's value measured?

With difficulty. Useful measures include the number of duplicate applications retired, run-cost reductions, the proportion of projects aligned with the roadmap, and delivery speed. The GAO found that most US federal agencies it studied had not measured and reported EA outcomes.

Summary

Enterprise architecture is the discipline of understanding and planning how an organization's business, information, applications and technology fit together. It grew from John Zachman's 1987 framework and a 1989 NIST publication into a field with many frameworks. Zachman provides a classification scheme. TOGAF provides a step-by-step method. The US federal government's FEAF and the defence world's DoDAF serve government needs, and ArchiMate supplies a common modelling notation. Practitioners divide into schools that see EA as IT design, as whole-enterprise integration, or as a way to help the organization adapt to its environment.

The promise of EA is better-coordinated change: less duplication, better integration, clearer investment decisions and fewer failed projects. The evidence is mixed. Practitioners report real benefits, but measuring them is hard, and US government audits found value often unmeasured and unrealised. The most useful EA practice is usually the least grandiose: just enough architecture, tied closely to real decisions and real delivery, and kept up to date as the organization changes.

Sources

• Enterprise architecture (Wikipedia)
• Zachman Framework (Wikipedia)
• The Open Group Architecture Framework (Wikipedia)
• Federal enterprise architecture (Wikipedia)
• Department of Defense Architecture Framework (Wikipedia)
• ArchiMate (Wikipedia)
• IEEE 1471 (Wikipedia)
• GAO-03-584G, A Framework for Assessing and Improving Enterprise Architecture Management (Version 1.1)
• GAO-10-846G, A Framework for Assessing and Improving Enterprise Architecture Management (Version 2.0)
• GAO-12-791, Enterprise Architecture Value Needs to Be Measured and Reported