What this is
Enterprise Architecture is the discipline of making an organization's structure match its strategy. Concretely, that means producing a coherent set of designs across four domains — business, data, applications, and technology — that describes both how the organization works today and how it intends to work tomorrow.
That's the working definition. Almost everything else in this course either expands on it or applies it.
Why it matters
Most organizations don't have a single mind. They have many teams making decisions in parallel — product teams shipping features, IT teams running systems, business leaders pursuing goals, finance teams allocating budgets. Each of those teams can be very good at what it does and still leave the organization as a whole worse off.
Enterprise Architecture exists because of the gap between local optimization and global coherence. A product team that picks the database that's fastest for its use case is doing its job — but if every product team makes that choice independently, the organization ends up with eight database technologies, no integration story, and a data team that can't answer basic questions like "how many customers do we have." Multiply that pattern across applications, integrations, security, and platforms, and you get the kind of organization where every change is expensive and every strategic shift takes years.
EA is the discipline of saying: somebody has to think about the whole. Not to slow individual teams down, but to make sure that what they each ship contributes to a structure the organization can keep building on.
How it works
Three things make EA recognizable as a discipline rather than just "good architectural thinking":
1. It works at the enterprise scope, not the project scope.
The unit of attention is the organization, not a system. An enterprise architect cares about how Sales, Marketing, Operations, and Finance fit together as much as how an individual application is built.
2. It produces specific kinds of artifacts.
Capability maps. Application portfolios. Reference architectures. Roadmaps. Architecture principles. These are the deliverables of EA work, and they're how an EA function makes its thinking concrete and usable. We'll cover each of these in detail in later lessons.
3. It uses frameworks.
Most disciplines work without explicit frameworks. EA is unusual in that practitioners largely agree that doing it well requires one — TOGAF being the most widely adopted. The framework gives you a vocabulary, a method, and a set of artifact templates. We'll spend the next 90 lessons working through TOGAF's particular take.
What EA is not
Three common misconceptions worth clearing up before we go further:
- It's not just IT architecture. EA covers business architecture (capabilities, processes, organization structure) every bit as much as technical architecture.
- It's not pure documentation. A binder full of as-is diagrams that no one reads is the canonical failure mode of bad EA. The artifacts exist to drive decisions, not to be filed.
- It's not the same as Solution Architecture. A Solution Architect designs one solution to one problem. An Enterprise Architect designs the context in which many such solutions will be built, over years.
A concrete example
Imagine a regional insurance company called Boreal Mutual. It has 800 employees and three product lines — auto, home, and life insurance. Each product line was built at a different time, by different teams, on different technology. Customer data is duplicated across all three. The auto team's quote engine is fast and modern; the life team's is twenty years old and held together by overnight batch jobs.
Boreal's CEO wants to launch a unified customer portal where any customer can see and manage all their policies in one place.
Without an Enterprise Architect, the project team will build the portal as a fourth system, reading from each of the three back-ends through whatever integration it can scrape together. The portal might ship. It will be brittle, slow, and expensive to maintain — and it won't solve the underlying problem that "a customer" doesn't exist as a single concept in Boreal's data.
An Enterprise Architect, looking at the same problem, would notice that the customer portal is the symptom of a deeper structural issue: Boreal has no enterprise customer data model. The right architectural move isn't to build a fourth system on top of three; it's to introduce a unified customer service that all three product lines (and the new portal) consume. That's a multi-year program, not a project — and it's exactly the kind of decision EA exists to surface.
The portal still gets built. But it gets built on a foundation that the next ten initiatives can also use, instead of being yet another snowflake.
Common mistakes
Treating EA as a documentation function. The classic anti-pattern: an EA team produces beautiful diagrams of the as-is state, files them in a repository, and is never consulted on actual decisions. EA artifacts exist to inform decisions; if no decision flows from a diagram, the diagram was probably not worth making.
Confusing EA scope with project scope. Project architects ask "how do we build this thing?" Enterprise Architects ask "what should we be building, given everything else we're building and where the organization is going?" The distinction is not subtle, and confusing them produces either trivial EA or paralyzed projects.
Believing EA is mostly about technology. It isn't. The discipline gives equal weight to business architecture (what capabilities the organization has and needs) and to data architecture (what information it manages). Architects who think EA is "the senior tech architect's job" produce strong technical designs in service of unclear business goals.
Where this fits next
Tomorrow we'll get more specific about the alignment problem — the particular way organizations drift apart from their strategy, and the specific moves EA uses to pull them back together. After that we'll spend a few days on the four architecture domains in turn, and then move into TOGAF itself.