Enterprise Architecture Overview

About this article

This article is the first article in the “Enterprise Architecture” category of the Architecture Crash Course for the Generative-AI Era series. It covers the big picture of enterprise architecture.

EA handles the enterprise-wide strategy view, so the audience differs sharply from the per-project categories. This chapter is for the people drawing the corporate map — CIOs, CDOs, corporate strategy, IT strategy, EA teams. Readers focused on small/mid projects will find the next chapter, “Solution Architecture,” closer to daily work. This article surveys BA/DA/AA/TA, AS-IS/TO-BE, TOGAF, and granularity by company size.

A full list of all articles in this category, with summaries and learning points, is available at the following page.

Enterprise Architecture — Article Indexen.senkohome.com/arch-intro-index-ea/

What is Enterprise Architecture in the first place

Imagine urban planning. No matter how impressive individual buildings are, if roads, water supply, and the power grid aren’t coordinated, the city doesn’t function. When districts are developed independently, problems emerge: roads that don’t connect to the next town, duplicate water pipes, insufficient power.

Enterprise Architecture (EA) is the discipline of designing the entire company’s IT strategy holistically, like urban planning. It goes beyond individual project designs to align business and IT across the whole organization.

Without EA, departments build similar systems separately, resulting in fragmented data that makes company-wide analytics impossible. The sum of local optima produces the worst global outcome.

Summing local optima yields the worst global outcome

EA is the architecture that integrates the entire company’s IT strategy. Going beyond per-system architecture, the goal is to align business and IT across the whole company, organizing the picture into four layers: Business (BA), Data (DA), Application (AA), Technology (TA). The acronym is EA.

It emerged to address problems like “each department building similar systems separately” and “data fragmentation preventing company-wide analytics” at large enterprises. CIO, corporate strategy, and IT strategy departments are the central owners. The view required is upstream of per-project architects.

EA is “the corporate map.” With a map, individual projects stop wandering.

Why treat it as a separate architecture

Lack of company-wide alignment produces duplicate investment

Different customer-management systems per department, similar data in separate DBs — without EA you build the same thing repeatedly.

The foundation for company-wide DX

DX (Digital Transformation) is not single-app development but redesigning operations, data, and systems across the whole company. Without an EA viewpoint, it cannot proceed.

Sorting out legacy assets is mandatory

Large companies hold decades of stacked system assets. Connecting “keep what, kill what, rebuild what” to executive-level decisions is EA’s job.

EA’s 4-layer model

EA captures the company in four layers. Going top-down moves toward the concrete and technical, with upper-layer decisions binding the lower.

BA changes drive DA changes drive AA changes — the up-down chain is the substance of EA design.

AS-IS and TO-BE

EA’s basic operation is to draw AS-IS (current state) and TO-BE (target state), then plan the gap closure. This is done at each of the four layers.

For an enterprise considering “unify customer data company-wide”, the AS-IS / TO-BE looks like:

• BA AS-IS: Independent customer-management operations per department.
• BA TO-BE: Unified company-wide customer-management process.
• DA AS-IS: Customer data scattered across each department’s DB.
• DA TO-BE: Unified company-wide customer master.
• AA AS-IS: Five independent customer-management systems.
• AA TO-BE: Unified customer foundation + per-business systems.

A 3-5 year medium-term plan to close that gap, broken into individual projects — that’s the typical EA cadence.

Major EA frameworks

EA is typically pursued starting from a framework set up by predecessors. Going fully custom is high-difficulty; borrowing existing thinking is the norm.

In practice, TOGAF is the only effective choice in Japan and many other markets, and the certification (TOGAF Certified) is also widely available.

What you must decide 1: BA / DA

What you must decide 2: AA / TA

EA granularity by company size

A persistent misreading is “EA is for large enterprises only.” The right framing is to think of EA granularity adjusted to scale. Small/mid companies suffer cross-team silos and duplicate investment too, and a lightweight EA produces good ROI.

Even at small scale, just BA + DA delivers significant value. The worst choice is to pursue perfection and start nothing.

EA vs Solution Architecture

EA is often confused with Solution Architecture (the next chapter). They differ in scope.

Inside the company-wide direction EA draws, individual projects are designed by solution architects. That is the relationship.

EA maturity ladder

Note: industry rates as of April 2026. Periodic refresh required.

EA is best grown gradually. Full construction up front fails.

“Full Phase A-H application” stalling at Phase B for 1.5 years is the canonical failure. “Phase A-B-D with Tailoring (narrowing)” is the realistic answer; to “avoid the art-show fate” you must connect to medium-term plans and roadmaps.

EA exists not to draw the map, but to make decisions faster.

Knowledge structure of this category

This category is composed of 6 articles in total. The reading order progresses: big picture -> each of the 4 layers -> framework.

The 4 layers must be read top-down: BA -> DA -> AA -> TA. Changes in BA (Business) drive DA (Data), changes in DA drive AA (Application), and changes in AA drive TA (Technology) — this top-down chain is the essence of EA.

The framework article (TOGAF / ArchiMate) is more meaningful after you understand the 4 layers’ content. Memorizing the framework procedures without knowing the substance of the 4 layers ends as rote memorization of a procedure manual.

Architecture-level traps

EA is “the corporate map,” not scripture. Tailor it into a form the field actually uses.

Author’s note — “15 customer masters” stalling DX for years

Cases of EA-less organizations carrying enormous debt are common, especially around large enterprises.

A major Japanese company started a DX project to “unify customer data company-wide.” Digging through each department’s core systems, they found 15 different tables called “customer master” internally. The same legal entity had been registered 10 times under different customer codes, and which one is correct could only be determined by a senior staffer’s intuition. The integration project: 1 year just to agree on “which is true,” 2 years to introduce MDM, 3-5 years stalled total. No matter how many per-project architects you have, this state cannot be fixed.

The Mizuho Bank system outages (2021-2022, 11 incidents in a year) is a symbolic case where EA absence escalated into an executive-accountability problem. Three banks’ systems (former Daiichi Kangyo, Fuji, IBJ) were consolidated without sufficient EA design, struggled with system integration for nearly 20 years, and finally received a regulatory remediation order from the Financial Services Agency. The price of postponing the corporate map can reach hundreds of billions of yen — a fact engraved in Japan’s financial history.

Both share the structural flaw of “nobody overseeing the company as a whole.” They make the case that EA is not artwork — it’s the foundation of management.

How to choose

EA’s substance is the framing: align business and IT across the whole company. Duplicate investment and silos — different departments building similar systems, different DBs holding similar data — cannot be solved by per-project architects. Visualize the company’s current location (AS-IS) and target state (TO-BE) across BA / DA / AA / TA, then translate the gap into a 3-5 year medium-term plan. That is EA’s actual work. The framework is essentially TOGAF; pure custom is harder than borrowing predecessor work.

The other decisive axis is the recognition that AI-era competitiveness is decided by EA maturity. When AI agents work across business systems, companies with data catalogs, MDM, API-based loose coupling, and IaC ops can use AI company-wide. Companies with silos, monoliths, and manual ops stop at local-optimum AI utilization. Redesigning the DA layer is now the core of AI strategy.

AI-era decision axes

When AI-driven dev (vibe coding) and company-wide AI usage are the premise, EA becomes the center of strategic planning for how to leverage AI company-wide. AI accuracy depends on data quality and accessibility, so EA’s DA layer (Data Architecture) is being reassessed.

In the era where AI agents work across business systems, standardization at the EA level (auth, APIs, data definitions) becomes mandatory. Without EA, AI usage stops at local optima.

AI-era competitiveness is decided by EA maturity.

Selection priority

1. Design the 4 layers top-down — BA changes drive DA changes drive AA changes; building from the bottom up loses the path.
2. Base on TOGAF — custom frameworks are high-difficulty; certifications are also available.
3. Translate AS-IS / TO-BE gaps into a medium-term plan — connect to a company-wide roadmap and individual projects.
4. Sort the DA layer first — the foundation of AI-era competitiveness; catalog, MDM, and quality come first.

EA maturity sets the ceiling of AI utilization

In the era where AI agents use internal systems across the enterprise, the level of EA standardization defines the upper bound of AI utilization. When auth is unified on OIDC, agents can SSO into every system; when APIs are standardized, agents can autonomously execute cross-system integration.

Conversely, when each system has its own auth, data formats are all different, and integration is file-transfer-based, AI agents need a bespoke adapter for each, and integration costs balloon. Organizations without mature EA face a structural barrier to getting results from AI.

Data catalog as the first step of AI utilization

For AI to analyze data, it first needs to know “what data is where.” With a company-wide data catalog (DataHub, Amundsen, etc.) in place, AI can autonomously search for “which table has the sales data?” or “what is the customer-ID definition?” and generate accurate analytical queries. Without a catalog, you must manually tell AI where each piece of data lives, and autonomous utilization is impossible.

“The corporate map” keeps individual projects from wandering. In the AI era, the DA layer decides competitiveness.

Summary

This article covered the big picture of enterprise architecture — the 4-layer model, AS-IS/TO-BE, TOGAF, granularity by company size, the maturity ladder, and AI-era competitiveness.

Design the 4 layers top-down, base on TOGAF, translate AS-IS / TO-BE into a medium-term plan, and sort the DA layer first. The realistic answer for 2026.

The next article covers Business Architecture (processes, capability maps).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.