IT Enterprise Architecture: A (Brief) Field Guide

Most guidance on this subject converges on the same three steps: document the current state, define the target state, plan the gap between them. That is sound, and it stops where the hard part starts. Nobody tells you what happens next: the document begins going wrong the day after you finish it.

That gap between the model and the running system is the actual job at a senior level. This guide covers what IT enterprise architecture means, how it differs from enterprise-wide EA, the domains it spans, and which frameworks earn their overhead. Then it covers how to keep the model true rather than merely produced. We wrote it for architects and principal engineers already in the role.

What Is IT Enterprise Architecture?

No standards body defines an IT-scoped enterprise architecture as a separate discipline, so treat what follows as our working distinction rather than a field-wide definition. IT enterprise architecture, here, means enterprise architecture scoped to the systems, applications, data, and infrastructure the IT function owns and operates. It covers the current state, a target state, and the decisions that move one toward the other.

NIST’s glossary, sourcing CNSSI 4009-2015, defines enterprise architecture at the whole-organization level and specifies that it “includes a baseline architecture, target architecture, and sequencing plan.”

IT Enterprise Architecture vs. Enterprise-Wide EA (and vs. IT Architecture)

The three terms get used interchangeably and shouldn’t be. No standards body arbitrates them, so here is the split that survives contact with an org chart: IT architecture at one end, enterprise-wide EA at the other, and IT enterprise architecture in between. Which one you are running determines what you are accountable for and who has to be in the room for a decision.

Where IT Enterprise Architecture Ends and Enterprise Architecture Begins

The boundary is authority, not subject matter. IT enterprise architecture can tell you three teams run three different message queues and that consolidating would cut overhead. It cannot force the reorganization that makes consolidation stick.

Enterprise-wide EA claims that broader mandate, and whether it earns it depends on sponsorship. The narrower scope is often the more honest one, because a practice that changes what gets built beats one that produces artifacts and no decisions.

The Four Domains of IT Enterprise Architecture

The four-domain split is TOGAF vocabulary, and it is where most IT-scoped practices get theirs. It isn’t universal: Zachman classifies on a different axis, and FEAF v2 uses six sub-architecture domains. Treat four as a working shorthand rather than a law.

Business Architecture

Business architecture describes what the organization is able to do, not what it does step by step. Capabilities outlast the processes that implement them, which is why capability maps age better than process maps. In an IT-scoped practice, this domain is usually thin, and that is a legitimate choice rather than a gap. You need enough of it to answer “which business capability does this system serve,” and not much more.

Application Architecture

The application layer covers the systems themselves, who owns each, and how they interact. Ownership is the cheapest field to leave blank, and the most expensive one to have left blank: an unowned system is one nobody volunteers to migrate. This domain overlaps most with application portfolio management, and the overlap is worth exploiting rather than duplicating.

Data Architecture

The data layer covers what information exists, where it lives, and how it moves between systems. Treating this as a separate exercise from the application layer is conventional, but the two are overlapping investigations that should share evidence. You can’t map application dependencies without discovering data flows, and the interesting failures live at the join: the reporting database three services write to that only one of them is supposed to. The overlap is in discovery, not in scope, since data architecture also carries models, ownership, lifecycle, lineage, and governance that the application layer does not.

Technology Architecture

Technology architecture is the infrastructure everything runs on: compute, networking, storage, runtime platforms and the standards governing them. It is the domain that breaks the annual-survey model hardest. A system architecture view gives you the design patterns; the technology domain gives you what is actually provisioned underneath them, which is the difference between a logical picture and physical truth.

Common IT Enterprise Architecture Frameworks (TOGAF, Zachman, FEAF)

You already know the frameworks exist. The useful question is which one to focus on.

The Open Group describes TOGAF as “a proven Enterprise Architecture methodology and framework,” now in its 10th Edition, and says it is used by commercial businesses of every size, government departments, non-government public organizations, and defense agencies. That tells you the standard travels widely, not that it fits your practice. It is built to be configured rather than run as shipped, which is why two TOGAF shops rarely look alike.

Zachman is the most misunderstood of the three, usually because people run it as a process. It isn’t one. John Zachman’s own description calls the framework “a schema” and “an ontology,” depicted as “a bounded 6 x 6 ‘matrix’” with Communication Interrogatives as columns and Reification Transformations as rows. It “IS NOT a methodology for creating the implementation,” and the distinction reduces to “A Structure is NOT a Process.” That makes Zachman a useful completeness check and a poor project plan.

FEAF is narrower than its reputation suggests. Version 2, published January 29, 2013, describes “a suite of tools to help government planners implement the Common Approach,” and says its Consolidated Reference Model equips “OMB and Federal agencies with a common language and framework to describe and analyze investments.” Outside the U.S. federal government, it’s a reference rather than a fit.

Why IT Enterprise Architecture Matters for P2/P3 Architects and Principal Engineers

The version of this we keep running into treats the architecture model as a deliverable to produce rather than as a system to keep true.

That distinction is the whole job at a senior level. Producing a current-state model is a project with an end date. Keeping one accurate is an operational commitment: the estate changes whenever deployed work alters infrastructure, dependencies, or data flows, and the model has to refresh from its connected sources on a known cadence.

The failure mode is quiet, which makes it expensive. A consolidation plan scoped against nine services is wrong if there are thirteen, and it stays wrong through approval, scheduling, and delivery, because nothing downstream re-checks the number the plan was built on. Nobody gets paged. The cost shows up as a quarter that overran and an explanation that sounds like bad luck.

This is where the practice earns or loses its budget: a governance forum reviewing decisions against a picture that was accurate last spring isn’t governing; it’s ratifying. The pressure runs one way: delivery keeps accelerating while the cycle that refreshes the model has not. That gap is the one we built our platform around.

How to Operationalize IT Enterprise Architecture (A Practical Process)

Three moves, in order. The third is the one most practices skip, and it determines whether the other two hold.

Assess the Current State

Start from the systems, not from interviews. Interviews capture what people remember, which is a subset of what exists and skewed toward what was planned. The unplanned resource spun up on a Thursday to unblock a report is exactly what a survey misses and what breaks a migration scope later.

Derive inventory from cloud accounts, orchestration, and source control first, then use interviews to explain what you found rather than to find it. Supplement with finance data, because recurring software spend catches the vendor and SaaS layer that infrastructure discovery cannot see.

Model the Target State

Target state is where practices over-invest. A twelve-month target for a technology domain that turns over quarterly is fiction with a Gantt chart attached.

Model the target at the level that is stable. Principles and constraints hold for years: one source of truth per data domain, no direct database access across service boundaries. Specific technology selections hold for months. Write both down, mark which is which, and revisit them on separate cadences.

Keep the Model Live, Not Static

This is what separates a practice that compounds from one that resets every eighteen months.

The test is simple: when somebody deploys a new service, does your model know? If the answer depends on a human remembering to update something, the model is decaying from the moment it’s finished, fastest where things get created outside the standard path.

Tools that derive the model from the environment rather than asking you to describe it change what the practice can assume. We built Stacks to work that way, and our read-only integrations assemble the model from code, cloud config, and observability data rather than from a diagram somebody drew. The limit is ours to state as plainly as the capability, because we only see as far as the integrations you connect, which leaves the SaaS and vendor layer needing a separate route.

Tools for IT Enterprise Architecture

Framework-style documentation, a repository, and a pile of spreadsheets is a legitimate starting point, and it works where the estate changes slowly.

The category splits on one question: where does current-state data come from? Repository and diagramming tools ask you to model the estate; others derive it from the environment. We sit in the second group. Our scope is a decision and design layer rather than an EA repository, which means the model exists so a decision can be made against it, not so the estate can be cataloged. Archie reasons on top of that model and the decisions already recorded against it, which is only worth anything because the layer underneath refreshes itself.

Our supported configuration today is AWS estates at companies past the early-stage startup phase, and both conditions apply. We also do not replace architecture practice; we change where the current-state picture comes from. For a category-level comparison including the repository-first incumbents, see our enterprise architecture tools roundup.

Frequently Asked Questions

Is an enterprise architect an IT role?

It depends on the mandate, not the title. Where the role reports into technology leadership and is scoped to systems, applications, data and infrastructure, it is an IT role in practice. Where it carries executive sponsorship to shape business capability and operating-model design, it is not. Two questions define any given post: who does it report to, and can it change things outside the technology organization?

What are the components of IT enterprise architecture?

Business architecture (what the organization is able to do), application architecture (the systems and how they interact), data architecture (what information exists and how it moves), and technology architecture (the infrastructure underneath). Frameworks split or merge these differently, so treat the four as shorthand rather than a fixed rule.

Is TOGAF certification worth it?

Three things decide it. Two are external: whether your employer or your clients require it, and whether you are hiring into a market that screens on it. The third is whether your organization actually runs a TOGAF-configured practice you need the vocabulary for. Where none of those hold, the certification buys shared vocabulary and little else. It does not substitute for having owned a system through a full lifecycle.

How is IT enterprise architecture different from solution architecture?

Scope and planning horizon. Solution architecture designs a system to meet a defined set of requirements, typically bounded by one initiative. IT enterprise architecture covers how systems fit together across the estate and how that estate should look several planning cycles out. The two collide when a locally sound solution design turns out to add the fourth message queue.