Architecture Domains

TL;DR

TOGAF splits Enterprise Architecture into 4 linked domains: Business, Data, Application, and Technology. Business Architecture drives all the others. Together, the four domains give a complete view of how an enterprise works and how change should be designed.

Why architecture domains?

Enterprise Architecture is big.
Domains help break it into manageable parts without losing the full picture.

In TOGAF, the four core domains are:

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

The 4 core domains (simple view)

Domain	Main question it answers	Typical content
Business Architecture	What does the business do, and why?	strategy, governance, capabilities, value streams, processes, organization units
Data Architecture	What information do we need and manage?	information objects, data entities, conceptual/logical/physical data structure, data management resources
Application Architecture	Which systems support the business?	application portfolio, interfaces, application functions, app-to-process relationships
Technology Architecture	What technical foundation runs everything?	infrastructure, network, middleware, platforms, cloud services, runtime environments

Two key Business Architecture concepts

Two concepts within Business Architecture are often confused but are distinct:

Business Capabilities

A business capability is a particular ability or capacity that a business may possess or exchange to achieve a specific purpose.

• Describes what the business does — not how, why, or where
• Expressed as nouns: “Customer Management,” “Product Development,” “Order Fulfilment”
• Stable over time — capabilities remain relevant even as processes, technology, and org structure change around them
• Independent of organizational structure or IT systems

Value Streams

A value stream is an end-to-end collection of value-adding activities that create an overall result for a customer, stakeholder, or end-user.

• Describes how value flows from a triggering event to a delivered outcome
• Expressed as verb-noun: “Acquire Customer,” “Fulfil Order,” “Resolve Complaint”
• Customer-centric — starts with a trigger and ends with value delivered to a stakeholder
• A higher-level abstraction than business processes; each stage may encompass many processes

How they relate

Note

Value streams and capabilities are different and complementary concepts in Business Architecture.

• Value streams show the context for why certain capabilities are needed at each stage
• Capabilities show what is required to successfully execute each stage of a value stream
• Mapping capabilities to value stream stages is a core Business Architecture practice

How the domains connect

In TOGAF 10 ADM practice, Business Architecture provides the primary context first, then Information Systems Architecture (Data + Application), then Technology Architecture. The work is iterative, not strictly one-way.

flowchart LR
    B["Business Architecture (Phase B)"]
    C["Information Systems Architecture (Phase C: Data + Application)"]
    T["Technology Architecture (Phase D)"]

    B --> C
    C --> T
    B -. "priorities and constraints" .-> T
    T -. "implementation feedback" .-> C
    C -. "business impact feedback" .-> B

1. Business Architecture (Phase B) defines capabilities, value streams, and outcomes.
2. Information Systems Architecture (Phase C) defines Data and Application together.
3. Technology Architecture (Phase D) defines the technical platform that supports Phase C designs.
4. Feedback loops across phases refine decisions as implementation realities emerge.

If Business Architecture changes, all other domains are affected. Technology changes may or may not affect Business Architecture, depending on business impact.

Domain groupings

TOGAF formally groups some domains together:

• Information Systems (IS) Architecture = Data + Application
  This is the official TOGAF grouping used in the ADM. It captures how data is structured and how applications use that data to support business needs.
• Technology Architecture stands separately alongside IS Architecture.

Important

The term “IT Architecture” is often used loosely in practice to mean Data + Application + Technology, but the official TOGAF term is “Information Systems Architecture” for the Data + Application grouping.

How domains map to ADM phases

The four domains directly correspond to phases in TOGAF’s Architecture Development Method (ADM):

ADM Phase	Domain covered
Phase B	Business Architecture
Phase C	Information Systems Architecture (Data + Application)
Phase D	Technology Architecture

This mapping helps you understand which domain work happens at which stage of an architecture development cycle.

Artifact types

In TOGAF, every domain is described using artifacts — architectural work products. The TOGAF Content Framework formally classifies all artifacts into exactly three types:

Artifact type	Purpose	Example
Catalogs	Lists of building blocks — what exists in the architecture	Application Portfolio Catalog, Technology Standards Catalog
Matrices	Relationships between building blocks shown as a two-dimensional grid	Application/Data Matrix, Business Interaction Matrix
Diagrams	Visual representations of content and relationships	Value Chain Diagram, Platform Decomposition Diagram

Note

You don’t create all artifacts for every project. You choose based on scope, stakeholder needs, and the questions you need to answer.

Architecture Building Blocks vs Solution Building Blocks

Artifacts describe the architecture in terms of building blocks — reusable components that make up the architecture. TOGAF defines two types:

Type	What it defines	Technology stance	Example
Architecture Building Block (ABB)	What functionality is needed — abstract, logical, reusable	Technology-agnostic	”Web Server,” “Identity Service,” “Customer Data Store”
Solution Building Block (SBB)	How that functionality is delivered — concrete, product-specific	Technology-specific (vendor/product-aware)	“Apache Tomcat,” “Azure Active Directory,” “Salesforce CRM”

ABBs are defined during architecture design phases. SBBs are selected during implementation and migration planning, once vendors and products are decided.

Common artifacts by domain

Business artifacts

• business capability map
• value stream map
• value chain diagram
• organization map
• functional decomposition diagram
• business footprint diagram

Data artifacts

• conceptual data diagram
• logical data diagram
• data dissemination diagram
• data lifecycle diagram
• data entity/business function matrix

Application artifacts

• application portfolio catalog
• application communication diagram
• application/data matrix
• application/function matrix
• application/organization matrix

Technology artifacts

• technology portfolio catalog
• technology standards catalog
• platform decomposition diagram
• environments and locations diagram
• network computing diagram

Additional architecture views

You can also define additional views by combining the four core domains. These are composite views, not separate domains.

Common examples:

• Digital Architecture — how digital capabilities span business, data, applications, and technology
• Risk and Security Architecture — security controls and risk frameworks across all four domains
• Integration Architecture — how data flows and applications interoperate across the enterprise
• Cloud Architecture — technology and application decisions specific to cloud adoption

Note

These are perspectives on top of the four core domains, not replacements for them. You choose additional views based on scope, stakeholder needs, and program goals.

Practical example: Employee Onboarding

Business Architecture

You model the main process flow and identify the capabilities involved:

• Candidate accepted
• Employee record created → HR Management capability
• Access and devices provisioned → IT Provisioning capability
• Orientation completed → Workforce Development capability
• Employee fully productive

The value stream trigger is “Offer Accepted.” Each stage uses specific capabilities to deliver value to the new employee.

Data Architecture

You define key information objects:

• employee profile (role, location, manager, start date)
• access profile (systems, permission levels)
• asset assignment (laptop, phone, security tokens)

Application Architecture

You decide which applications support this flow and how they interact:

• HRMS — creates and holds the employee record
• Identity & Access Management — provisions system access based on role
• Service Desk — manages asset requests and hardware delivery
• Collaboration tools — set up email, calendar, and team spaces

These systems must exchange data automatically. This is the application interaction design.

Technology Architecture

You define the technical foundation:

• Cloud identity services (e.g. Azure AD or Okta) running the IAM platform
• Endpoint management service for device provisioning and policy enforcement
• Integration platform (API gateway or ESB) connecting HRMS to all downstream systems
• Secure network access for day-one connectivity

This gives a single end-to-end view from business capability to technical implementation.

Exam note

• TOGAF defines 4 primary domains: Business, Data, Application, Technology — often abbreviated BDAT.
• Business Architecture is the prerequisite for all other domains. It drives the definition of Data, Application, and Technology architectures.
• Data + Application are formally grouped as Information Systems (IS) Architecture — this is the correct TOGAF term.
• IS Architecture is covered in ADM Phase C; Technology Architecture in Phase D; Business Architecture in Phase B.
• Business Capability = what the business does (stable, noun-form, technology-independent).
• Value Stream = how value flows end-to-end to a stakeholder (triggered by an event, verb-noun form). Not the same as a capability.
• TOGAF artifacts have three formal types: Catalogs, Matrices, and Diagrams.
• ABBs are abstract and technology-agnostic. SBBs are concrete and product/vendor-specific.
• Domains must be linked; isolated domain views lead to weak decisions.

Enterprise Architecture is easiest to understand when you view it through domains.

The value is not only in documenting each domain, but in linking them — starting from Business — so that every IT decision traces back to a business need.

Sources

• The Open Group - TOGAF Standard