The Four TOGAF Architecture Domains Explained

When you first encounter TOGAF, one of the most important concepts you will meet early on is the idea of architecture domains. TOGAF organizes the entire enterprise into four distinct areas, each representing a different dimension of how a business operates and uses technology.

Understanding these four domains is not just academic. It directly shapes how you develop an enterprise architecture, in what sequence you tackle each one, and how they link together to form a complete picture.

This post covers all four TOGAF architecture domains in plain language with practical examples, so you can see exactly how they apply in real organizations.

Why TOGAF Uses Four Domains

Large organizations are complex. They have hundreds of people doing different jobs, dozens of software systems, enormous volumes of data, and physical infrastructure spread across locations and cloud providers.

If an architect tried to describe all of this in one giant document, it would be unmanageable. No one would read it, and it would be impossible to keep up to date.

TOGAF solves this by dividing the architecture into four clearly defined areas called domains. Each domain focuses on one layer of the organization, and together they form a complete, coherent picture.

The four domains are:

Business Architecture: The strategy, processes, and organization of the business itself
Data Architecture: The data and information assets the business relies on
Application Architecture: The software applications that process and present that data
Technology Architecture: The infrastructure that hosts and connects everything

The domains are developed in this specific order during the TOGAF Architecture Development Method (ADM). This sequence is intentional. Business decisions drive data requirements. Data requirements influence application design. Application needs determine infrastructure choices. Skipping this order leads to technology-first thinking, which is one of the most common and costly mistakes in IT.

The BDAT Sequence

Practitioners often refer to the four domains as BDAT: Business, Data, Application, Technology. This acronym helps you remember both the domains and the development sequence used in the ADM.

Domain 1: Business Architecture

Business Architecture is the foundation of everything in TOGAF. It describes the strategy, capabilities, governance structures, and key processes of an organization.

The goal of Business Architecture is to answer one essential question: what does the business do and why?

What Business Architecture Covers

Business Architecture maps out the following:

Business capabilities: The core things the organization must be able to do, such as "process customer payments" or "manage regulatory compliance"
Business processes: The step-by-step workflows that deliver value, such as onboarding a new customer or processing an insurance claim
Organizational structure: Departments, teams, roles, and reporting lines
Governance and decision-making: How decisions are made, who has authority, and how policies are enforced
Business goals and strategy: The long-term direction the organization is heading

A Real-World Example

Imagine a bank undergoing digital transformation. Before writing a single line of code or choosing a cloud provider, the enterprise architect builds the Business Architecture. This reveals that the bank's core capability of "loan origination" involves twelve separate departments, three legacy approval workflows, and significant manual work that causes delays.

This discovery shapes every technology decision that follows. Without Business Architecture, the bank might have automated the wrong process entirely.

Key Deliverables

Common outputs from Business Architecture work include business capability maps, process flow diagrams, organizational charts, and the Strategy Map that links objectives to capabilities.

Domain 2: Data Architecture

Data Architecture describes the structure of an organization's logical and physical data assets and the processes and resources used to manage them.

In simple terms, it answers: what data does the business have, where does it live, and how is it managed?

What Data Architecture Covers

Logical data models: The conceptual structure of key data entities, such as "Customer", "Order", "Product", and their relationships
Physical data models: How data is actually stored in databases, data warehouses, or data lakes
Data flows: How data moves between systems, departments, and external partners
Data governance: Who owns data, who can access it, and how quality is maintained
Data standards: Agreed formats, naming conventions, and definitions used across the enterprise

A Real-World Example

A healthcare provider might find in their Data Architecture review that patient records are stored in six different formats across four separate systems. Each system calls the same data something different. This inconsistency creates compliance risks and makes it impossible to get a unified view of a patient.

Data Architecture identifies this fragmentation and provides a blueprint for consolidating it into a single, governed data model that all applications will use.

Data Architecture Comes Before Applications

A common mistake is building applications first and letting data architecture emerge from them. This creates fragmented, inconsistent data that becomes harder and more expensive to fix over time. Always define your data model before designing applications.

Key Deliverables

Typical outputs include logical data models, data flow diagrams, entity-relationship diagrams, and data governance policies.

Domain 3: Application Architecture

Application Architecture provides a blueprint for the software applications that support the business, how they interact with each other, and how they relate to the core business processes identified in the Business Architecture.

It answers the question: what applications exist, what do they do, and how do they connect?

What Application Architecture Covers

Application portfolio: A complete inventory of all software systems in use
Application capabilities: What each application does and which business capabilities it supports
Application interactions: How applications share data, trigger each other, and integrate via APIs or middleware
Gaps and redundancies: Applications doing the same thing (redundancy) or missing capabilities the business needs (gaps)
Target application landscape: The future state of the application portfolio after planned changes

A Real-World Example

A retailer running a digital transformation project discovers through Application Architecture that they have four separate systems for managing customer data. Three were built by different teams over the years, and none of them talk to each other. The Application Architecture establishes a plan to consolidate these into one customer data platform and expose it through a shared API.

Key Deliverables

Common outputs include application portfolio catalogs, interaction diagrams, interface specifications, and gap analysis documents.

Domain 4: Technology Architecture

Technology Architecture is the most technically detailed of the four domains. It describes the hardware, software infrastructure, cloud services, networks, and platforms that host and connect all the applications and data.

It answers: what infrastructure does the organization need to run its applications and manage its data?

What Technology Architecture Covers

Infrastructure inventory: Servers, storage, networking equipment, cloud services in use
Platform standards: Approved operating systems, databases, and middleware platforms
Network and security design: How systems are connected and protected
Cloud and hosting strategy: On-premises, cloud-native, hybrid, or multi-cloud decisions
Infrastructure capabilities: Scalability, availability, disaster recovery, and performance characteristics

A Real-World Example

Following on from the retailer example above, once the Application Architecture defines the new customer data platform, the Technology Architecture specifies where it will run (a Kubernetes cluster on AWS), what database engine it will use (PostgreSQL), what the backup strategy will be, and what security controls will protect it.

This is where the enterprise architect hands off to the infrastructure and cloud engineering teams with a clear, approved design.

Technology Architecture Enables the Business, Not the Other Way Around

Technology decisions should always trace back to a business requirement. In TOGAF, this traceability is built into the process: Business → Data → Application → Technology ensures that every infrastructure choice serves a defined business purpose.

Key Deliverables

Common outputs include technology standards catalogs, infrastructure diagrams, platform selection justifications, and security architecture specifications.

How the Four Domains Work Together

The four domains are not isolated. They are deeply interconnected, and changes in one domain ripple through the others.

Consider this chain of events in a government agency:

Business Architecture identifies a new government regulation requiring citizen data to be processed within national borders
Data Architecture maps which data sets are affected and establishes new data residency rules
Application Architecture identifies which applications process that data and which need to be modified or replaced
Technology Architecture specifies that a local data center must be used for those applications instead of the current US-based cloud region

This is exactly why TOGAF insists on developing the domains in order. A change at the business level always propagates downward. Architecture developed out of sequence will have gaps, conflicts, and hidden costs.

The Domains and the ADM

If you have started reading about the TOGAF ADM, you will notice that the four domains do not each have their own single phase. Instead:

Business Architecture is developed in Phase B
Data and Application Architectures are both developed in Phase C
Technology Architecture is developed in Phase D

This means Phase C carries a double responsibility. Architects often choose to tackle Data Architecture first within Phase C, then Application Architecture, preserving the BDAT sequence even within a single phase.

We will examine each of these phases in detail in the upcoming posts in this series.

Summary

The four TOGAF architecture domains provide a structured way to describe and manage the entire enterprise:

Business Architecture defines strategy, capabilities, and processes
Data Architecture maps data assets, flows, and governance
Application Architecture blueprints the software landscape and integrations
Technology Architecture specifies the infrastructure, platforms, and networks

Developing them in sequence ensures that technology decisions always trace back to a business need, which is the core principle that makes TOGAF valuable.

In the next post, we will move into the foundational concepts and terminology every TOGAF professional must know, covering the key definitions that appear throughout the framework and on the certification exams.

If you missed the first post in this series, start with What is TOGAF 9.2? A Complete Framework Overview before continuing here.

For broader professional context, our guide on Why TOGAF Is More Important Than You Think explains the business case for enterprise architecture in today's organizations.