Enterprise Architecture

What Is Enterprise Architecture (EA)? A TOGAF‑Based Primer for Connecting Strategy and IT

The term Enterprise Architecture (EA) is appearing more frequently in boardrooms and IT roadmaps, yet even within Japanese manufacturing companies, many IT departments still lack a structured understanding of what EA actually entails. As someone working in an EA role and supporting Japanese manufacturers with EA proposals and guidance, I continue to see a significant gap between the promise of EA and how it is practiced on the ground.

In this article, I will unpack the essence of EA based on TOGAF from three angles, with a focus on practical application in manufacturing and large enterprises:

  • What is Enterprise Architecture (EA)?
  • What value does EA aim to deliver?
  • Why is EA attracting so much attention now?

In a follow‑up article, I will connect these concepts to “EA Methodology in SAP” and discuss how to apply EA on SAP‑centric landscapes in real projects.


What Is Enterprise Architecture (EA)?
TOGAF’s Definition of Enterprise Architecture


TOGAF defines Enterprise Architecture as a structured approach for designing and governing an organization’s business and IT with consistent structures, principles, and roadmaps, in order to systematically define and manage “how the enterprise creates value.” Two points are critical here for practitioners:

  • Alignment of business and IT for value creation
  • Roadmaps and frameworks to make that alignment executable

Even the most compelling business initiatives fail to scale if the required IT capabilities are missing; organizations are forced into manual workarounds, struggle to keep pace with market and customer change, and eventually erode their competitive edge. 

On the other hand, trying to roll out every strategic initiative company‑wide at once leads to massive up‑front investments, rising risk and governance overhead, and longer lead times before tangible results appear.

TOGAF addresses these challenges by recommending smaller, incremental execution units and an iterative approach to planning and governance rather than one‑shot, big‑bang designs. 

EA is therefore not a one‑time architecture blueprint, but an ongoing capability to evolve the enterprise structure in a controlled and repeatable way.


The Four Architecture Domains and How EA Progresses

When asked to “design the architecture of the entire enterprise,” many organizations struggle to know where to start. 

TOGAF tackles this by splitting EA into four architecture domains and defining a consistent development approach across them:

  • Business Architecture
  • Application Architecture
  • Data Architecture
  • Technology Architecture

By designing and managing these four domains together, enterprises can maintain end‑to‑end traceability from strategy through business processes and systems down to infrastructure (“strategy → process → system → infrastructure”).

The four architecture domains of Enterprise Architecture

At a practical level, EA work typically follows these high‑level steps:

  1. Clarify the company’s medium‑ to long‑term business plans and objectives.
  2. Analyze the current state (AS‑IS) of the target business domains and define the future state (TO‑BE).
  3. Define the target maturity for each domain based on the TO‑BE and assess gaps against the AS‑IS.
  4. Prioritize domains and initiatives based on cost, value, and risk, then define the execution order (roadmap).
  5. Execute and continuously refine the roadmap as business and technology conditions change.

TOGAF structures these steps as an iterative process called the Architecture Development Method (ADM). 

The next section outlines what makes ADM particularly powerful in real‑world EA work.


TOGAF ADM: Building EA as an Iterative Capability

At the heart of TOGAF is the Architecture Development Method (ADM), an iterative cycle that defines how to design and update EA over time. The main ADM phases are:

  • Preliminary: Establish EA principles, scope, governance model, and tools.
  • Phase A – Architecture Vision: Define scope, stakeholders, vision, and business case.
  • Phases B–D: Design AS‑IS and TO‑BE for Business, Information Systems (Data & Applications), and Technology Architectures.
  • Phases E–F: Develop portfolios of projects, roadmaps, and priorities to realize the target architectures.
  • Phases G–H: Govern execution and manage architecture change once solutions go live.
  • Requirements Management: Manage requirements across all phases and feed them back into the ADM cycle.
TOGAF ADM Reference – Phase Overview

Excerpt and edited from the TOGAF website The Open Group Architecture Framework Version 8.1.1 ADM Reference

By continuously cycling through these phases, ADM embeds EA into the organization as an ongoing capability instead of a one‑off project. Among the many elements of ADM, three areas are especially critical in practice:

  • Stakeholder and governance definition
  • Prioritization and decision‑making
  • Continuous change management and feedback

Stakeholder and governance definition

Even when TO‑BE architectures are well designed, EA remains a “paper tiger” if execution responsibilities and decision rights are unclear. 

To avoid ending up with broad conceptual agreement but no concrete action (“everyone agrees in principle, but nobody owns the specifics”), it is essential to design stakeholder roles and governance structures in the early phases of EA.

Prioritization

For each improvement domain and initiative, EA must clarify how value will be generated and in what sequence. Without top management involvement and explicit approval of priorities, initiatives rarely move beyond the slide deck, especially given limited investment capacity; EA should make transparent “where to start and in what order to harvest benefits.”

Continuous change management and feedback

If organizations complete only the first ADM cycle and stop updating EA as conditions change, their architecture quickly diverges from reality. 

This reduces the effectiveness of planned initiatives and increases the risk of misaligned investments; by continuously revisiting EA in response to market and customer dynamics, organizations can keep executing context‑appropriate initiatives over time.


TOGAF Components That Support EA Practice

Beyond ADM, TOGAF defines several components that support day‑to‑day EA work. Key elements include:

  • Architecture Content Framework: Defines structures and templates for deliverables such as views, diagrams, catalogs, and matrices.
  • Enterprise Continuum: A conceptual model that positions architectures along a spectrum from generic reference models to organization‑specific detailed architectures.
  • Architecture Capability Framework: Guidance for designing the EA function itself—organization, processes, skills, and governance.

These components ensure EA is not just a set of diagrams but an organizational capability that can be defined, executed, and governed consistently. I will break each of these down in more detail in separate, dedicated articles.


What Does EA Aim to Achieve? The Value of EA and TOGAF

Put simply, the value of EA and TOGAF lies in “closing the gap between business strategy and IT, and building an enterprise structure that can adapt to continuous change.” Representative benefits include:new.

  • Alignment and traceability between business and IT (from strategy to processes, systems, and infrastructure).
  • Cost reduction and complexity control through standardization and reuse.
  • Clear visibility of the change portfolio and roadmap, enabling prioritization and stronger transformation governance.

The latest TOGAF standard (including the TOGAF Standard, 10th Edition) positions EA as an enabler of the “agile enterprise.” Here, “agile enterprise” does not only refer to agile development practices such as sprints, but to an organization that can continuously design, deliver, and evolve its enterprise architecture in small increments.

TOGAF guides organizations to break down strategic, segment, and capability architectures into manageable units and deliver them iteratively—often aligned to agile delivery cycles—so that enterprises can respond quickly to business change while preserving overall coherence. From this, it is clear that both speed of response and sustainability of change are at the core of EA’s intent.


What TOGAF Means by “Enterprise Agility”

TOGAF uses the term “enterprise agility” to describe a target state in which organizations become more customer‑ and product‑centric, more efficient, and more compliant while simultaneously increasing their ability to respond to change. TOGAF highlights the following characteristics of enterprise agility:

  • Responsiveness to change
  • Value‑driven decision‑making
  • Practical experimentation with small, learnable changes
  • Empowered, autonomous teams
  • Ongoing customer communication and collaboration
  • Continuous improvement
  • Respect for people

The final point—“Respect for people”—captures a key philosophical aspect of TOGAF that often resonates strongly with practitioners: enterprise architecture is not only about technology and processes, but also about creating an environment where people can contribute and adapt effectively.


Why EA Tools Matter: SAP and LeanIX

In recent years, a growing number of vendors have introduced tools to support EA practices. SAP, for example, acquired LeanIX—a leader in enterprise architecture management (EAM)—and now offers it as a core platform for managing EA across complex landscapes.

Without a dedicated EA platform and relying instead on manual approaches (for example, spreadsheets and slide decks), organizations quickly encounter issues such as:leanix+1

  • Difficulty managing architectures over long time horizons (5–10+ years).
  • Explosive growth in object counts as scope expands, making impact analysis nearly impossible.
  • Lack of transparency around reuse, resulting in high manual costs and duplicated effort.
  • Slow visibility into the impact of portfolio changes, which drags down transformation speed.

Because governance and continuity are the keys to successful EA, IT tools that enable systematic, long‑term management of EA information have become essential. I will cover concrete usage patterns and integration with SAP and other platforms in a future article.


Why EA, and Why Now? Enterprise Architecture in the Era of Digital Transformation, Cloud, and AI

EA is gaining renewed attention because digital transformation, cloud adoption, AI initiatives, and legacy modernization are all happening simultaneously, making it essential to design and govern business and IT as an integrated whole. Below are six particularly important perspectives.

1. The need for a “blueprint” for digital transformation

Fragmented, department‑level DX initiatives are no longer sufficient; enterprises must design and prioritize transformations across the entire portfolio. EA visualizes strategy, processes, applications, data, and infrastructure in a single blueprint and makes it explainable “what to invest in, and in what order.”

2. Controlling cloud and SaaS sprawl and complexity

Multi‑cloud, SaaS, and API‑driven integration have turned application landscapes into living, evolving organisms; uncoordinated adoption leads to silos and technical debt. EA uses standard architectures and reference models to guide cloud/SaaS selection and integration patterns, thereby controlling complexity and cost.

3. Acting as a bridge for legacy modernization

Replacing core systems in a single big‑bang is risky; most enterprises now seek stepwise modernization that keeps legacy systems running while moving toward target architectures. EA supports this by inventorying current assets, analyzing dependencies, designing target architectures, and defining migration steps that bridge legacy and modern platforms.

4. Making AI and data‑driven management sustainable

Proof‑of‑concepts for generative AI and analytics have become easy to spin up, but scaling them safely and with proper governance remains a major challenge. EA designs the supporting data architecture, model deployment patterns, responsibility boundaries, and risk management structures required to upgrade AI from one‑off experiments to sustained enterprise capabilities.

5. EA evolving from “cost center” to “growth engine”

Recent studies and case examples show that EA is increasingly recognized not just as an IT control function but as a strategic driver of growth and innovation. With AI‑enabled scenario planning and digital twin capabilities embedded in EA tools, EA is starting to accelerate both the speed and quality of executive decision‑making.

6. Addressing uncertainty and building resilience

Supply chain disruptions, regulatory tightening, and cyber risks are amplifying threats to business continuity. EA clarifies which processes, systems, and data are critical, what alternatives and recovery patterns exist, and provides the foundation for designing resilient enterprise structures.new.


Conclusion: Designing “Change‑Resilient” Enterprises with EA and TOGAF

This article has explored Enterprise Architecture (EA) and TOGAF with a focus on how they help organizations become more resilient to change:

  • EA is an approach for linking business and IT through coherent structures, principles, and roadmaps, in order to define and manage how the enterprise creates value.
  • TOGAF provides a comprehensive framework—including four architecture domains and the ADM—to institutionalize EA as a continuous organizational capability.
  • The core value of EA and TOGAF lies in closing the gap between strategy and IT and building an enterprise structure capable of sustained, agile response to change.
  • In an era of digital transformation, cloud, AI, legacy modernization, and resilience, EA’s holistic design capability is more critical than ever.
  • Realizing EA at scale requires tools that support governance and continuity, such as modern EA management platforms like LeanIX integrated with ERP and cloud ecosystems.

In the next EA article, I will introduce real‑world EA examples and discuss how SAP’s EA Methodology relates to TOGAF, with a focus on turning “EA as theory” into “EA you can actually use on the ground.”

For more insights on SAP, please also check out the following articles:


Reference Links

•LieberLieber Software: Volkswagen accelerates with Enterprise Architect
Volkswagen accelerates with Enterprise Architect < LieberLieber

•Enterprise Architecture in Toyota Automotive
Enterprise Architecture in Toyota Automotive | PDF | Enterprise Architecture | Business

•The new shape of IT at Volkswagen
A program of change for Volkswagen Group IT | Article | Automotive Manufacturing Solutions

•Vintage – Architecture On Demand’s Post
Building a Mature Enterprise Architecture Practice: The Toyota Story | Vintage – Architecture On Demand

•Group Management Report
Information Technology – Volkswagen Group Annual Report 2024

•Volkswagen’s digital transformation gathers speed
Volkswagen’s digital transformation gathers speed | Volkswagen Newsroom

•How EA benefits Volkswagen of America: a case study
How EA benefits Volkswagen of America: a case study | Samuel Holcman posted on the topic | LinkedIn

•CARIAD’s Unified Data Platform: A Data Streaming Automotive Success Story Behind Volkswagen’s Software-Defined Vehicles
CARIAD’s Unified Data Platform: A Data Streaming Automotive Success Story Behind Volkswagen’s Software-Defined Vehicles – Kai Waehner

•Toyota accelerates digital transformation with SAP S/4HANA upgrades
Toyota accelerates digital transformation

•Toyota shifts into overdrive: Developing an AI platform for enhanced manufacturing efficiency
How Toyota is revolutionizing manufacturing with AI | Google Cloud Blog

•The Value of Enterprise Architecture by Tony Brown
Admiral.doc

•Toyota Credit Canada Inc.
Toyota Credit Canada Case Study

•The Toyota bZ4X was the best-selling car in Norway for October
The Toyota bZ4X was the best-selling car in Norway for October : r/electricvehicles

•トヨタの成長を支えるITの革新
トヨタの成長を支えるITの革新:手本はクルマの開発(1/3 ページ) ITmedia エンタープライズ

•トヨタvs中国EV】競争軸は「知能化」へ/トヨタも中国EVも勝ち組/2035年の世界シェア/中国EVの4分類/BYDの苦難とジーリーの躍進/ファーウェイの戦略/
(6) 【トヨタvs中国EV】競争軸は「知能化」へ/トヨタも中国EVも勝ち組/2035年の世界シェア/中国EVの4分類/BYDの苦難とジーリーの躍進/ファーウェイの戦略/トヨタの「中国版マルチパスウェイ」 YouTube

•過去の遺産は食いつぶすためにある? 自社の名車を現代に蘇らせたメーカーたちの狂宴
過去の遺産は食いつぶすためにある? 自社の名車を現代に蘇らせたメーカーたちの狂宴 | トップギア・ジャパン Top Gear JAPAN

•続・トヨタが取り組むサーキュラーエコノミーとは?
TTR_Vol70-2_J.pdf

•TOYODA GOSEI 特集:様変わりする車社会を支える製品開発
vol.59.pdf


Disclaimer

Parts of this article were developed with reference to generative AI suggestions and were reviewed, refined, and supplemented based on the author’s professional expertise and judgment.


Back to Top

REI

Recent Posts

Why SAP Programs Need TOGAF® from a PM Perspective

A global SAP template will not remain sustainable by agile delivery alone. This article explains…

10 hours ago

How to Design the MRP4 View in SAP S/4HANA Private Edition for Manufacturing and MRP by Location

The MRP4 view in SAP S/4HANA Private Edition is the fine‑tuning dial for manufacturing logic…

1 day ago

The True Power of Enterprise Architecture in Driving Successful SAP Implementations

A deep dive into how Enterprise Architecture (EA) empowers SAP success through TOGAF’s four key…

3 days ago

A Must‑Read for Digital Transformation Practitioners: What Is DPBoK and How Does It Differ from TOGAF® Enterprise Architecture?

The Digital Practitioner Body of Knowledge (DPBoK) is a practical standard for planning, building, operating,…

4 days ago

TOGAF® Agile × Product Management: Shifting Manufacturing from Projects to Continuous Value Creation

Why should manufacturing companies shift from one-time system projects to continuously evolving products? This article…

4 days ago

TOGAF® Agile Architecture in Practice: Understanding Landscape and the Three-Layer Model (Strategy, Segment, Capability)

A practical guide to TOGAF Agile Architecture using the three-layer model. Learn how to connect…

5 days ago