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.

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

Without company-wide alignment you get duplicate investment. Different customer-management systems per department, similar data in separate DBs — without EA you build the same thing repeatedly.

It is 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 the legacy assets is not optional. 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.

Frameworks, and how EA differs from solution architecture

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.

EA and solution architecture are often confused, and they are not the same job.

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.

What actually gets decided splits across the four layers — BA and DA first.

Then AA and 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 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.

AI decision axes — Competitiveness in the AI era turns on EA maturity

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.

The hard parts of EA as a whole

Of the forbidden moves the individual articles cover, here are the six that matter at EA level.

The assumption that “EA is only for large enterprises” is wrong too. Silos and duplicate investment happen at small and mid-size companies as well, and the value of drawing a company-wide map at a granularity that matches the scale is the same.

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.

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.