# Architecture Content, Deliverables, and Artifacts

## Why a content framework matters

Architecture work needs a shared structure so that information can be reviewed,
traced, reused, and governed. TOGAF distinguishes:

- **deliverables** — formally reviewed work products;
- **artifacts** — representations such as catalogs, matrices, and diagrams; and
- **building blocks** — reusable architecture or solution components.

The content structure should be tailored. Producing every possible artifact is
not compliance; it is waste unless each item serves a purpose.

## The three artifact forms

| Form | Best for | Example |
|---|---|---|
| Catalog | Lists of related things | Requirements catalog |
| Matrix | Relationships between two kinds of thing | Capability/application matrix |
| Diagram | Structure, behavior, sequence, or context | Application interaction diagram |

Use a catalog for completeness, a matrix for coverage and gaps, and a diagram
for comprehension. These are complementary.

## Core deliverables

Names and packaging vary, but the following are common in a TOGAF-aligned
practice.

### Architecture Vision

A concise, stakeholder-oriented explanation of:

- drivers and problem;
- scope;
- baseline and target at a high level;
- value and success measures;
- stakeholder concerns;
- key requirements, assumptions, constraints, and risks; and
- proposed approach.

It should help leaders decide whether to authorize the work.

### Statement of Architecture Work

The engagement agreement:

- objectives and scope;
- approach and tailored method;
- work plan, milestones, and deliverables;
- roles and governance;
- effort and resources;
- acceptance criteria;
- assumptions, constraints, dependencies, and risks.

### Architecture Definition Document

The integrated architecture description, typically including relevant baseline,
target, gap, rationale, and viewpoints across domains.

It explains **what architecture is intended and why**.

### Architecture Requirements Specification

The set of measurable requirements the architecture and implementations must
satisfy.

It explains **what must be true** and how conformance can be assessed.

### Architecture Roadmap

A time-oriented view of work packages, transition architectures, dependencies,
and expected outcomes.

It explains **the strategic sequence of change**.

### Implementation and Migration Plan

The executable plan integrated with delivery and portfolio management:

- prioritized projects, products, or work packages;
- costs, benefits, resources, risks, and dependencies;
- transition states and milestones;
- ownership and governance; and
- benefits and completion measures.

### Architecture Contract

An agreement between architecture and implementation stakeholders covering
responsibilities, required conformance, review points, and how deviations are
handled. It may be a dedicated document or embedded in delivery governance.

### Compliance Assessment

Evidence that a proposed or implemented solution conforms, partially conforms,
or does not conform to relevant requirements, principles, standards, and
architecture decisions.

## Frequently useful catalogs

- stakeholder catalog;
- principles catalog;
- requirements catalog;
- business capability catalog;
- organization/actor catalog;
- business service catalog;
- data entity catalog;
- application portfolio catalog;
- interface catalog;
- technology standards catalog;
- risk and issue catalog;
- decision and exception catalog.

## Frequently useful matrices

- stakeholder/concern;
- driver/goal/outcome;
- capability/value stream;
- capability/organization;
- capability/application;
- business function/data;
- application/data;
- application/application interaction;
- application/technology;
- requirement/architecture element;
- requirement/work package;
- work package/outcome.

## Frequently useful diagrams

- solution or enterprise context;
- capability map;
- value stream;
- organization decomposition;
- business process or journey;
- conceptual data model;
- data lifecycle or dissemination;
- application interaction;
- integration context;
- platform decomposition;
- environment and location;
- roadmap and transition states.

## Content metamodel

A content metamodel defines the types of architecture information and their
relationships. A lightweight metamodel might use:

```mermaid
flowchart LR
    Driver --> Goal --> Outcome
    Goal --> Requirement
    Capability --> Outcome
    ValueStream --> Capability
    BusinessService --> Capability
    ApplicationService --> BusinessService
    Application --> ApplicationService
    DataEntity --> BusinessService
    Application --> DataEntity
    TechnologyService --> Application
    Requirement --> WorkPackage
    WorkPackage --> Outcome
```

The point is traceability, not semantic perfection. Extend the metamodel only
when the additional relationship supports a decision, query, control, or reuse
case.

## ABBs and SBBs

Architecture Building Blocks describe required characteristics. Solution
Building Blocks describe realizations.

Example:

| Architecture need | ABB | Candidate SBB |
|---|---|---|
| Consistent customer identity | Identity resolution capability | Master-data product and matching engine |
| Reliable integration | Managed event distribution | Selected cloud event service |
| Auditability | Immutable audit service | Central logging and retention implementation |

Keep mappings many-to-many: one SBB may realize several ABBs, and one ABB may
require several SBBs.

## Minimum viable architecture pack

For a medium-risk initiative, a useful minimum may be:

1. one-page vision and scope;
2. stakeholder/concern map;
3. principles and constraints;
4. baseline and target context views;
5. key requirements and quality attributes;
6. decisions and alternatives;
7. gaps, risks, and dependencies;
8. roadmap with owners and outcomes; and
9. conformance and exception approach.

Increase detail for high risk, low reversibility, high cost, or strong
regulatory exposure. Reduce it for small, bounded, reversible change.

## Quality checks

Architecture content should be:

- **purposeful** — tied to a concern or decision;
- **consistent** — terms and relationships agree across views;
- **traceable** — goals connect to implementation and evidence;
- **current** — state, owner, and review date are visible;
- **understandable** — audience-appropriate;
- **controlled** — material changes are reviewed;
- **reusable** — structured and stored accessibly; and
- **actionable** — clear about decisions, ownership, and next steps.

## Versioning and status

Every controlled item should expose:

- identifier and title;
- owner;
- version;
- status such as draft, approved, superseded, or retired;
- effective and review dates;
- scope;
- source and dependencies; and
- decision or approval record.

[Next: Enterprise Continuum and repository](05-enterprise-continuum-and-repository.html)