# Glossary and Quick Reference

This glossary uses concise practitioner-oriented explanations rather than
reproducing the standard’s normative definitions.

For the expanded A–Z reference and abbreviation list, see the
[comprehensive abbreviations and terminology glossary](16-abbreviations-and-terminology-glossary.html).

## A–B

**ADM**  
Architecture Development Method; TOGAF’s central iterative method.

**Architecture**  
The fundamental organization of a subject and the principles guiding its
evolution; also the discipline of making and governing consequential design
choices.

**Architecture Board**  
The governance body accountable for defined architecture decisions and
oversight.

**Architecture Building Block (ABB)**  
A reusable description of required architecture capability or behavior,
independent of a specific implementation.

**Architecture Capability**  
The people, roles, method, governance, information, and tools that enable
architecture work.

**Architecture Contract**  
An agreement defining architecture responsibilities, expectations, evidence,
and conformance between parties.

**Architecture Description**  
The collection of work products used to express an architecture.

**Architecture Governance**  
The decision rights, controls, accountabilities, and feedback used to direct and
monitor architecture.

**Architecture Landscape**  
An organized view of architecture assets across enterprise levels, domains,
states, and time horizons.

**Architecture Principle**  
A durable rule or guideline used to make consistent architecture decisions.

**Architecture Repository**  
The managed store and operating mechanism for architecture content.

**Architecture Roadmap**  
A strategic, time-oriented sequence of work packages and transition states.

**Artifact**  
An architecture representation, usually a catalog, matrix, or diagram.

**Baseline Architecture**  
The relevant current state from which change is planned.

**Building Block**  
A potentially reusable component of architecture or solution content.

**Business Architecture**  
Architecture of strategy, capabilities, value, organization, services,
processes, and related business concepts.

**Business Capability**  
An ability the enterprise possesses or needs to achieve an outcome.

**Business Scenario**  
A concrete description of a business problem, actors, environment, process,
measures, and requirements.

## C–G

**Catalog**  
An artifact that lists architecture entities of a particular kind.

**Concern**  
An interest or issue important to a stakeholder.

**Content Metamodel**  
A definition of architecture entity types, relationships, and rules.

**Data Architecture**  
Architecture of data meaning, structure, ownership, use, movement, lifecycle,
quality, and protection.

**Deliverable**  
A formally reviewed work product that may contain one or more artifacts.

**Enterprise**  
The organizational scope addressed by the architecture; not necessarily an
entire company.

**Enterprise Architecture**  
The discipline that connects strategy and outcomes to coordinated change across
the enterprise.

**Enterprise Continuum**  
A method for classifying architecture and solution assets from generic to
organization-specific.

**Gap**  
A meaningful difference between baseline and target that implies change.

## I–R

**Implementation and Migration Plan**  
The prioritized, resourced plan for executing work packages and reaching
transition and target states.

**Matrix**  
An artifact showing relationships between two types of architecture content.

**Model**  
A simplified representation of a subject for a particular purpose.

**Reference Architecture**  
A reusable architecture approach for a recurring class of problem.

**Reference Model**  
A reusable abstract model of concepts and relationships in a domain.

**Requirement**  
A statement of what the architecture or implementation must enable, constrain,
or satisfy.

**Requirements Management**  
The continuous ADM activity for eliciting, analyzing, tracing, prioritizing,
verifying, and controlling requirements.

## S–Z

**Solution Building Block (SBB)**  
A specific implementation component that realizes architecture building blocks.

**Stakeholder**  
A person, group, or organization with interests in the architecture.

**Standards Information Base**  
The repository area for adopted standards, products, versions, status, and
related guidance.

**Statement of Architecture Work**  
The agreement defining an architecture engagement’s objective, scope, approach,
plan, governance, and acceptance.

**Target Architecture**  
The intended future state that satisfies agreed goals and requirements.

**Technology Architecture**  
Architecture of platform, infrastructure, runtime, network, standards, and
operational technology services.

**TOGAF Fundamental Content**  
The stable core concepts and practices of the modular 10th Edition.

**TOGAF Series Guides**  
Topic-specific guidance for configuring and applying the Fundamental Content.

**Transition Architecture**  
A coherent intermediate state between baseline and target.

**Value Stream**  
The stages through which value is created for a stakeholder.

**View**  
An actual representation of an architecture from a specific viewpoint.

**Viewpoint**  
The conventions and concerns used to construct and interpret a view.

**Work Package**  
A bounded set of actions or change used to implement part of a roadmap.

## ADM quick reference

| Phase | Remember it as |
|---|---|
| Preliminary | Set up the practice |
| A | Agree the vision and work |
| B | Design how the business operates |
| C | Design data and applications |
| D | Design enabling technology |
| E | Package solution opportunities |
| F | Prioritize and plan migration |
| G | Govern implementation |
| H | Monitor and manage change |
| Requirements | Trace needs through everything |

## Artifact quick reference

```mermaid
flowchart LR
    Catalog[Catalog<br/>What exists?] --> Matrix[Matrix<br/>How does it relate?]
    Matrix --> Diagram[Diagram<br/>How should we understand it?]
    Diagram --> Decision[Decision<br/>What will we do?]
    Decision --> Roadmap[Roadmap<br/>When and in what order?]
    Roadmap --> Evidence[Evidence<br/>Did it work?]
```

## Practitioner checklist

- [ ] Outcome, sponsor, and scope are explicit.
- [ ] Stakeholders, concerns, and decision rights are known.
- [ ] Baseline detail is relevant and sufficient.
- [ ] Target choices are linked to requirements and principles.
- [ ] All necessary domains and cross-cutting concerns are coherent.
- [ ] Gaps, dependencies, risks, and assumptions are visible.
- [ ] Work packages and transition states are feasible.
- [ ] Roadmap items have owners, value, and measures.
- [ ] Compliance and exceptions are proportionate and traceable.
- [ ] Architecture is updated from implementation and operational evidence.

[Next: Official references](13-official-references.html)