Enterprise Architecture¶

Model an enterprise's business, information, application, and technology layers as one governed baseline-to-target transformation so strategy, investments, and implementation remain aligned.

Version: v3 · 2026-09-19 · History
Domain-specific #: 1769
Domain group: Professional & Organizational Practice
Origin domain: Organizational & Management Science
Subdomains: Enterprise Management, Enterprise Architecture → Organizational & Management Science
Aliases: Enterprise architecture practice

Core Idea¶

Enterprise Architecture is the organization-wide practice of building and governing a coherent set of views that connects strategy to business capabilities and processes, information and data, applications and services, technology and infrastructure, and often performance and security. It describes a baseline or as-is enterprise, specifies a target or to-be enterprise, identifies gaps and dependencies, and sequences transition architectures or increments that guide investment and implementation. The architecture is useful only when these views constrain real decisions and are maintained as the enterprise changes.

How would you explain it like I'm…

The Big Fit-Together Plan

Imagine a huge school with many classrooms, a kitchen, buses and computers. Enterprise Architecture is like a big plan of how all those parts work together now, how the school wants them to work later, and the steps to get there. The plan only helps if people really use it when they make choices.

Whole-Organization Blueprint

Enterprise Architecture is how a big organization, like a company or government agency, plans how all its parts fit together. It connects the big goals to what the organization does, the information it keeps, the computer programs it uses, and the machines underneath. Planners describe how things are now, decide how they should be later, and figure out the steps in between. A drawing of just one app isn't Enterprise Architecture; it has to cover the whole organization. And the plan only matters if people actually use it to make decisions and keep it updated.

As-Is to To-Be Roadmap

Enterprise Architecture is the organization-wide practice of building and governing connected views that link strategy to business capabilities and processes, data, applications, technology, and often security and performance. It describes the current 'as-is' state, specifies a target 'to-be' state, identifies the gaps and dependencies, and lays out a step-by-step roadmap for investment and implementation. 'Enterprise' means the boundary is big enough to reveal dependencies across units, so one application diagram doesn't qualify. 'Architecture' isn't just a pile of diagrams; diagrams are descriptions of the architecture, not the thing itself. It only works if it actually shapes real decisions and keeps up as the organization changes. Frameworks like TOGAF are methods for doing it, not its definition.

Enterprise Architecture is the practice of developing and governing a coherent set of views across an enterprise, connecting strategic outcomes and stakeholder concerns to business, information and data, application and service, technology and infrastructure, and cross-cutting views such as security and performance. It documents a baseline, specifies a target, performs gap and dependency analysis, and sequences transition architectures that guide investment. The enterprise boundary, whether a corporation, agency, coalition, or federation, must be wide enough to expose cross-unit dependencies and shared capabilities, though not every detail needs modeling. Following ISO/IEC/IEEE 42010, an architecture is distinct from its description: models, catalogs, principles, and roadmaps are media expressing selected features via views and viewpoints. Enterprise Architecture adds a change purpose, so representations must help stakeholders assess consistency, trade-offs, conformance, and feasible transitions. Decision rights, conformance checks, and feedback make it binding; diagrams that never constrain decisions are not functioning architecture. TOGAF is one prominent framework for configuring the practice rather than its definition.

Scope of Application¶

Enterprise Architecture applies where local optimization creates material cross-boundary consequences.

Corporate transformation. Mergers, operating-model changes, shared-service programs, platform consolidation, and digital transformation require capabilities, ownership, information, applications, and infrastructure to move together.
Government and public administration. Agencies use enterprise and segment architectures to relate mission and performance to business, data, services, technology, security, investment, and interagency dependencies. GAO's maturity framework treats current and target views plus an enterprise transition plan as an organization-wide decision instrument.
Federated enterprises. Autonomous divisions or agencies can retain local authority while adopting common principles, interfaces, information semantics, and conformance rules where interdependence demands them.
Portfolio rationalization. Application duplication, unsupported platforms, conflicting data ownership, and inconsistent processes become visible when assets are mapped to capabilities and target dispositions.
Regulated and safety-critical settings. Architecture traces policy, security, resilience, privacy, and compliance obligations through processes, information, systems, and technologies.
Ecosystem and acquisition integration. Suppliers, partners, acquisitions, and outsourced services extend the enterprise boundary when their decisions alter shared outcomes or dependencies.

Clarity¶

Enterprise Architecture clarifies four distinctions that organizations routinely collapse.

First, baseline is not inventory. A baseline states what exists, how it behaves, who owns it, what it costs, which capabilities it supports, and where constraints or risks reside. A list of applications with no process, information, service, or ownership links cannot explain enterprise behavior.

Manages Complexity¶

An enterprise is too large to reason about as one undifferentiated object. Enterprise Architecture manages this complexity by decomposing it into views while preserving explicit correspondences across them. Business capabilities connect to processes and owners; processes consume and produce information; applications provide services; technologies host applications; investments change selected elements; measures test whether the promised outcome arrived.

Abstract Reasoning¶

Let the enterprise state at time t be a layered directed graph

E_t = (B_t, I_t, A_t, T_t, R_t),

where B contains business capabilities, actors, and processes; I information and data; A applications and services; T technology and infrastructure; and R the typed relations within and across layers. A strategic target defines desired outcomes O* and constraints C. The target architecture is not simply any E* satisfying O*; it should be coherent under constraints, ownership, interoperability, risk, and resource limits.

Knowledge Transfer¶

Within enterprise management, the role package transfers literally across corporations, public agencies, universities, health systems, military organizations, nonprofit networks, and federated coalitions. The particular layers and names vary, but the recurring task is to make strategy, operating structure, information, systems, technology, investment, and governance mutually legible across time.

Several tools transfer inward from other abstractions. Representation contributes viewpoints and faithfulness scope. Transformation contributes state, invariant, and sequencing analysis. Governance contributes decision rights, accountability, waivers, and conformance. Backcasting contributes target-to-prerequisite reasoning.

Relationships to Other Abstractions¶

Current abstraction Enterprise Architecture Domain-specific

Parents (3) — outgoing typed relations

Enterprise Architecture presupposes Governance Prime

Governance is a strict prerequisite: decision rights, accountability, conformance, waivers, and refresh authority make the architecture binding rather than advisory documentation.
Enterprise Architecture includes Representation Prime

Representation is constitutive: architecture descriptions map selected enterprise structures into views under purpose-relative faithfulness commitments.
Enterprise Architecture presupposes Transformation Prime

Transformation is a strict prerequisite: the baseline, target, and transition sequence describe rule- and constraint-governed restructuring of the enterprise while preserving mission and operational invariants.

Hierarchy paths (4) — routes to 3 parentless roots

Enterprise Architecture → presupposes Governance → includes Accountability → presupposes Authority

Show alternative paths (3)

Neighborhood in Abstraction Space¶

Enterprise Architecture sits in a sparse region of the domain-specific corpus (60^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Software & Systems Architecture (32 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-25