The Concept of Enterprise Architecture

Overview

Enterprise Architecture has suffered from conceptual ambiguity since its inception. Early frameworks — Zachman, TOGAF, FEAF — implied that an organization could be comprehensively modeled and reassembled like a building. That metaphor is influential, and it is largely wrong: organizations are dynamic, political, adaptive systems that never hold still long enough for a blueprint to remain accurate.

This paper sets out the modern, empirically grounded definition of Enterprise Architecture. Building on Kotusev's research — the most rigorous empirical study of EA practice to date — and integrating complementary work from Ross, Weill, Robertson, Bernard, Zachman, and Gartner, it establishes EA as a communication‑centric, decision‑support discipline rather than a modeling exercise.

EA does not design the enterprise; it produces a selective set of artifacts that make implicit organizational knowledge explicit, bridge the language gap between business and IT stakeholders, and give leadership teams a structured basis for better decisions.

What’s Inside

• The persistent ambiguity of Enterprise Architecture, and why the “blueprint” metaphor fails
• Kotusev’s empirically derived definition of EA and its convergence with Ross, Weill, Robertson, Bernard, and Gartner
• The essence of EA: communication medium, pragmatic descriptions, and alignment instrument
• The domains of Enterprise Architecture — Business, Application, Data, Infrastructure, and beyond
• EA artifacts as the fundamental unit of the discipline
• The EA communication model enabling business–IT alignment
• The role of enterprise architects and the EA operating model
• Practical implications for leadership teams evaluating or scaling an EA function

Executive Summary

Enterprise Architecture is one of the most consistently misapplied disciplines in modern organizations. Two decades of framework proliferation created an expectation that EA should produce a single, engineered blueprint of the enterprise — comprehensive enough to be assembled like a building.

That expectation has never matched how organizations behave, and it has produced a well‑documented pattern of EA programs that generate elaborate documentation while failing to influence meaningful decisions.

This paper establishes EA as a communication‑centric, decision‑support discipline rather than a modeling exercise. EA does not design the enterprise; it produces a selective set of artifacts that make implicit organizational knowledge explicit, bridge the language gap between business and IT stakeholders, and give leadership teams the structured basis on which to make better decisions.

Success depends less on framework selection and more on artifact discipline, stakeholder engagement, and lightweight governance that is actually used. This is the operating philosophy DEAA applies in every engagement.