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.
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 (Enterprise Architecture) 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 (Chief Information Officer), 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.
flowchart TB
BA["BA<br/>Business Architecture<br/>(Processes, organization)"]
DA["DA<br/>Data Architecture<br/>(Enterprise data definitions, MDM)"]
AA["AA<br/>Application Architecture<br/>(Systems, portfolio)"]
TA["TA<br/>Technology Architecture<br/>(Infra, cloud, standard tech)"]
BA -->|Operations change<br/>=> data changes| DA
DA -->|Data structure<br/>determines systems| AA
AA -->|Systems<br/>determine infra| TA
classDef top fill:#fef3c7,stroke:#d97706,stroke-width:2px;
classDef data fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
classDef app fill:#f0f9ff,stroke:#0369a1;
classDef infra fill:#f1f5f9,stroke:#64748b;
class BA top;
class DA data;
class AA app;
class TA infra;| Layer | Scope | Owner |
|---|---|---|
| BA (Business) | Processes, org, capabilities | Executive, business |
| DA (Data) | Enterprise data definitions, flow, governance | CDO (Chief Data Officer), data team |
| AA (Application) | Systems, integration, portfolio | CIO, IT |
| TA (Technology) | Infra, cloud, standard tech | Infrastructure |
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.
| FW | Trait | Fits |
|---|---|---|
| TOGAF | Most adopted, industry standard | Large enterprise, international |
| Zachman | Organized as a 6×6 matrix | Academic, educational |
| FEA | US federal | Public sector |
| DoDAF | US Department of Defense | Defense, large organizations |
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
| Item | Examples |
|---|---|
| Business capability map | 5-layer / 7-layer hierarchy |
| Process notation | BPMN (Business Process Model and Notation, ISO standard for processes) / UML / custom |
| Data governance | CDO role / data stewards |
| Master data management | Centralized MDM (Master Data Management) / federated MDM |
| Data catalog | DataHub / Collibra / in-house |
| Data quality criteria | Completeness / consistency / freshness / accuracy |
What you must decide 2: AA / TA
| Item | Examples |
|---|---|
| System standards | Shared auth / shared notification / shared ID |
| Integration patterns | API / event-driven / file integration |
| Application portfolio | Buy / Build / Subscribe criteria |
| Cloud strategy | Cloud First / Hybrid / On-prem |
| Tech standards (TRM — Technical Reference Model) | Approved-tech list |
| Reference architectures | Blueprints for typical configurations |
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.
| Company size | EA granularity | Estimated effort |
|---|---|---|
| Startup (up to 50) | Just BA capability map | Executive, 1 week |
| Small/mid (50-300) | BA + DA (customer-master unification) | Exec + IT, 1 month |
| Mid (300-1000) | BA + DA + AA portfolio | 1 dedicated person, 6 months |
| Large enterprise (1000+) | All 4 layers + TOGAF compliant | Dedicated team, 1-3 years |
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.
| Aspect | Enterprise Architecture | Solution Architecture |
|---|---|---|
| Scope | Whole company | Individual project |
| Period | 3-5 year medium-term | 6 months to a few years |
| Lens | Business strategy + IT | Solving a specific problem |
| Output | Company-wide roadmap, standards | System design docs |
| Stakeholders | CIO, executive | Project team |
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.
| Phase | Time | Output | Investment |
|---|---|---|---|
| 1 Start | 3-6 months | 2-tier BA capability map + main-process BPMN | Exec + IT, 1-2 |
| 2 Foundation | 6-12 months | + DA (customer-master unification plan) + AA inventory | EA part-time, 2-3 |
| 3 Mid | 1-2 years | + TA standard stack + Technology Radar | Dedicated EA, 3-5 |
| 4 Enterprise | 2-5 years | TOGAF full + industry-specific (BIAN etc.) + CDO | Specialized org, 10+ |
| 5 Continuous | Ongoing | EA as Code + quarterly review + AI utilization | Central + BU EA |
“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.
Architecture-level traps
| Forbidden move | Why |
|---|---|
| Full TOGAF ADM application (Phases A-H all in) | 1.5 years stalled at Phase B — canonical big-SI failure |
| Aiming for perfection across all 4 layers in parallel | Cannot start — grow gradually |
| Leaving customer master fragmented per department | The “15 customer masters” problem; DX stalls for years |
| Mizuho-style integration (consolidating 3 banks’ systems without EA) | 11 incidents in a year, regulatory order from FSA |
| ArchiMate as decoration that doesn’t drive decisions | Art show ending — output becomes the goal |
| PowerPoint EA for operations | Unreadable by AI — switch to machine-readable formats |
| Central EA becoming an ivory tower | Disconnected from the field — Agile EA collaborates with the field |
| Talking about AI utilization while deferring DA | AI’s accuracy ceiling is set by data tidiness |
| Adopting multi-cloud at the TA layer without ops capacity | 3x ops cost, 2x infra cost — single-cloud baseline |
| Framework fundamentalism | Treating it as a procedure manual without tailoring — exhausts everyone |
| ”EA is for large enterprises only” — assuming | Even small/mid companies have silos and duplicate investment; drawing the 4-layer corporate map scaled to size has the same value |
| ”Draw AS-IS/TO-BE and done” — stopping | Without translating into a 3-5 year medium-term plan and individual projects, it’s an art show; connecting to the roadmap is the real work |
| ”BA isn’t the business team’s job” — cutting off | BA covers operations and organization; IT alone can’t complete it, joint work with executive and business teams is mandatory |
| ”Roll your own framework from scratch” — reinventing | Output granularity and quality drift, making executive communication difficult; basing on TOGAF is rational |
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.
| Favored in the AI era | Disfavored in the AI era |
|---|---|
| Company-wide data catalog / integrated DWH | Per-department siloed data |
| MDM (Master Data Management) in place | Customer ID different in every system |
| API-based, loosely coupled systems | Monolith, tightly coupled, hard to integrate |
| IaC (Infrastructure as Code), automation-first ops | Manual, request-based ops |
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
- Design the 4 layers top-down — BA changes drive DA changes drive AA changes; building from the bottom up loses the path.
- Base on TOGAF — custom frameworks are high-difficulty; certifications are also available.
- Translate AS-IS / TO-BE gaps into a medium-term plan — connect to a company-wide roadmap and individual projects.
- Sort the DA layer first — the foundation of AI-era competitiveness; catalog, MDM, and quality come first.
“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.
📚 Series: Architecture Crash Course for the Generative-AI Era (69/89)