# Architecture Domains

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

```mermaid
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](04-content-and-artifacts.html)