# Core Concepts

## Enterprise

In TOGAF, an **enterprise** is the scope being considered. It may be:

- an entire company;
- a government department;
- a business unit;
- a partnership or ecosystem;
- a product line;
- a transformation program; or
- any collection of organizations sharing goals.

Do not assume “enterprise” always means the whole legal organization. State the
boundary explicitly.

## Architecture

Architecture describes the fundamental organization of a subject, its elements
and relationships, and the principles governing its design and evolution.

In practice, architecture is both:

- a **description** of a baseline, target, or transition state; and
- a **discipline** for making and governing consequential design decisions.

## Enterprise Architecture

Enterprise Architecture connects goals and strategy to coordinated change
across operating models, capabilities, people, information, applications, and
technology.

It operates at several levels:

| Level | Typical horizon | Example |
|---|---:|---|
| Enterprise or strategic | 3–5+ years | Common digital operating model |
| Segment, portfolio, or domain | 1–3 years | Customer data architecture |
| Capability or product | Several quarters | Omnichannel service platform |
| Solution | Release to 1–2 years | Design for a new identity service |

These levels should connect. Strategic architecture without delivery evidence
becomes aspirational; solution architecture without strategic context becomes
local optimization.

## Stakeholders, concerns, views, and viewpoints

These four concepts prevent architecture from becoming a diagram collection:

- A **stakeholder** is a person, group, or organization with interests in the
  architecture.
- A **concern** is an issue important to one or more stakeholders, such as cost,
  resilience, compliance, usability, or time to market.
- A **viewpoint** defines the conventions for constructing and using a view. It
  says what the view should address and how.
- A **view** is the actual representation of a specific architecture from a
  viewpoint, created to address stakeholder concerns.

Example:

| Element | Example |
|---|---|
| Stakeholder | Chief Information Security Officer |
| Concern | Privileged access and regulatory exposure |
| Viewpoint | Security controls and trust boundaries |
| View | Diagram and control matrix for the target identity platform |

The rule is simple: create a view because it answers a decision-relevant
question, not because a framework lists it.

## Architecture description

An **Architecture Description** is the collection of work products used to
express an architecture. It may contain models, principles, requirements,
standards, decisions, roadmaps, and other content.

No single model describes the whole enterprise. Different views intentionally
show different concerns.

## Baseline, target, transition, and gap

- **Baseline Architecture**: the relevant current state, including already
  approved or in-flight change when appropriate.
- **Target Architecture**: the future state required to meet agreed objectives.
- **Transition Architecture**: a meaningful intermediate state between baseline
  and target.
- **Gap**: something present in one state but missing, changed, or retired in
  another.

Avoid documenting every current-state detail. Capture only what is needed to
understand the change, risk, and decisions.

## Requirements

Architecture requirements express what the architecture must enable, constrain,
or satisfy. Good requirements are:

- linked to drivers, goals, stakeholders, and outcomes;
- testable or otherwise verifiable;
- prioritized;
- assigned an owner;
- traceable to architecture and implementation; and
- governed through change.

Requirements Management interacts with every ADM phase. New findings may create
requirements; requirement changes may force architecture work to be revisited.

## Principles

An **architecture principle** is a durable rule or guideline used to make
consistent decisions. A useful format is:

1. **Name** — memorable and specific.
2. **Statement** — the rule.
3. **Rationale** — why the enterprise adopts it.
4. **Implications** — consequences, costs, and required behavior.

Principles should guide trade-offs. “Use best practices” is too vague to be a
principle.

## Building blocks

A building block is a potentially reusable component of business, architecture,
or solution content.

- An **Architecture Building Block (ABB)** describes required capability or
  behavior without committing to a specific implementation.
- A **Solution Building Block (SBB)** describes an implementation that realizes
  one or more ABBs.

Example:

| ABB | Possible SBB |
|---|---|
| Enterprise identity federation capability | A configured identity platform and connectors |
| Event distribution capability | A managed event-streaming service |

Keep the problem and required behavior separate from the chosen product long
enough to evaluate alternatives.

## Deliverables, artifacts, and building blocks

These terms are related but not interchangeable:

```mermaid
flowchart TD
    D[Deliverable<br/>reviewable contractual work product]
    A[Artifact<br/>catalog, matrix, or diagram]
    B[Building block<br/>reusable capability or component]
    D -->|contains| A
    A -->|describes| B
```

- A **deliverable** is a formally reviewed work product.
- An **artifact** is a representation of architecture information.
- A **building block** is the reusable subject represented by artifacts.

## Architecture landscape

The **Architecture Landscape** gives an organized view of architecture assets at
different levels and states. It commonly includes strategic, segment, and
capability-level descriptions of baseline, transition, and target architectures.

## Reference models and patterns

- A **reference model** supplies reusable concepts and relationships for a
  domain.
- A **reference architecture** applies patterns and principles to a recurring
  class of problem.
- A **pattern** is a reusable response to a recurring problem in context.

Use these as accelerators, not unquestioned answers.

## Architecture debt

Architecture debt is the future cost or constraint created when implementation
diverges from intended architecture or when the architecture itself becomes
outdated. Record debt explicitly with:

- rationale;
- business impact;
- risk;
- owner;
- remediation trigger or due date; and
- accepted decision authority.

## Fitness for purpose

TOGAF should be tailored. A fit-for-purpose architecture has enough detail to
support the next important decisions—no more and no less. The appropriate depth
depends on uncertainty, blast radius, reversibility, regulatory exposure, and
investment size.

[Next: Architecture Development Method](02-adm.html)