Architecture Domains

TOGAF commonly organizes architecture into four domains: Business, Data, Application, and Technology. They are distinct viewpoints on one enterprise, not independent plans.

flowchart TD
    Goals[Strategy, drivers, and outcomes] --> Business[Business Architecture]
    Business --> Data[Data Architecture]
    Business --> Apps[Application Architecture]
    Data <--> Apps
    Data --> Tech[Technology Architecture]
    Apps --> Tech
    Cross[Security, risk, privacy, integration,<br/>experience, sustainability] --- Business
    Cross --- Data
    Cross --- Apps
    Cross --- Tech

Business Architecture

Purpose

Business Architecture explains how an enterprise creates value and how it needs to operate. It connects strategy to change without assuming that every problem is an IT problem.

Typical subjects

drivers, outcomes, goals, and measures;
business models and operating models;
capabilities and capability maturity;
value streams and customer journeys;
products and business services;
organization, roles, and responsibilities;
processes, events, policies, and controls;
locations and channels; and
business information concepts.

Useful questions

Which capabilities differentiate the enterprise?
Which capabilities are weak, duplicated, or missing?
Where does value stall across organizational boundaries?
Which outcomes and measures prove the change worked?
What responsibilities or policies must change?
Which business services should be common, local, outsourced, or retired?

Common views

capability map and heat map;
value-stream map;
organization/decomposition diagram;
business service/capability matrix;
actor/role matrix;
process or journey view; and
strategy-to-capability mapping.

Failure mode

Equating Business Architecture with process diagrams. Processes matter, but capabilities, value, organization, information, and strategic choices matter too.

Data Architecture

Purpose

Data Architecture makes information usable, trustworthy, protected, and available for operational and decision needs.

Typical subjects

conceptual and logical data entities;
definitions and semantic models;
ownership and stewardship;
systems of record and authoritative sources;
lifecycle, retention, archival, and disposal;
quality rules and measures;
exchange, lineage, and integration;
classification, privacy, and access; and
analytical, operational, master, reference, and metadata concerns.

Useful questions

What data is critical to each capability and value stream?
Does the same term mean different things in different areas?
Who is accountable for quality and permitted use?
Where is the authoritative record?
How is data discovered and traced?
What must remain local, and what should be shared?

Common views

conceptual data model;
data entity/business function matrix;
application/data matrix;
data lifecycle or dissemination diagram;
data security/classification matrix;
data lineage view; and
data migration view.

Failure mode

Starting with physical database schemas. Enterprise Data Architecture begins with meaning, use, ownership, and policy; physical design follows.

Application Architecture

Purpose

Application Architecture defines how applications and application services support business capabilities and manage information.

Typical subjects

application portfolio and lifecycle;
application services and responsibilities;
application interactions and interfaces;
functional overlap and gaps;
buy, build, reuse, consolidate, and retire decisions;
integration patterns and contracts;
user groups, channels, and locations; and
quality attributes such as availability and maintainability.

Useful questions

Which capabilities does each application support?
Where does functionality overlap?
Which applications create concentration, obsolescence, or vendor risk?
What should be a shared platform versus product-owned service?
Which interfaces are brittle, duplicated, or undocumented?
What must be decoupled to enable the roadmap?

Common views

application portfolio catalog;
application/capability matrix;
application interaction diagram;
application/information matrix;
application use-case or service view;
interface catalog; and
application migration diagram.

Failure mode

Treating the current application inventory as the architecture. An inventory lists assets; architecture also explains responsibilities, relationships, principles, target choices, and change.

Technology Architecture

Purpose

Technology Architecture defines platform and infrastructure services, standards, and deployment environments that enable applications and data.

Typical subjects

compute, storage, network, and edge;
cloud, data center, and hosting models;
operating systems, runtimes, and middleware;
integration and API platforms;
identity, cryptography, and security services;
observability, operations, backup, and recovery;
workplace and endpoint technology;
engineering platforms and delivery tooling;
technology standards and lifecycle; and
performance, resilience, scalability, and sustainability.

Useful questions

Which platform services should be standardized or shared?
What service levels and resilience patterns are required?
Where is technology obsolete or unsupported?
What constraints follow from sovereignty, latency, cost, or regulation?
How will systems be operated and observed?
How will technology choices stay reversible enough?

Common views

technology standards catalog;
environment/location diagram;
platform decomposition diagram;
application/technology matrix;
network and communications view;
deployment view; and
technology lifecycle roadmap.

Failure mode

Choosing products before agreeing on required capabilities and quality attributes.

Cross-cutting concerns

The four domains are a useful organizing scheme, but important concerns cross them:

Concern	Business	Data	Application	Technology
Security	Accountability and controls	Classification and use	Authorization and secure design	Identity, protection, detection
Privacy	Lawful purpose and policy	Minimization and retention	Consent and subject rights	Encryption and isolation
Resilience	Critical services	Recovery points	Degradation behavior	Redundancy and recovery
Integration	Partner and process boundaries	Semantics and exchange	Contracts and orchestration	Connectivity and platforms
Sustainability	Operating choices	Retention volume	Efficient software	Energy and hardware lifecycle
Experience	Journeys and channels	Relevant, trusted information	Interaction behavior	Performance and accessibility support

Assign cross-cutting requirements owners and trace them through all domains.

Keeping domains coherent

Use matrices and traceability to test alignment:

goal → outcome → capability;
capability → value stream → business service;
capability → information → application service;
application → data entity → interface;
application → technology service;
requirement → architecture element → work package → verification evidence.

The most valuable architecture findings often appear at domain boundaries.

Next: Content, deliverables, and artifacts