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:

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:

one-page vision and scope;
stakeholder/concern map;
principles and constraints;
baseline and target context views;
key requirements and quality attributes;
decisions and alternatives;
gaps, risks, and dependencies;
roadmap with owners and outcomes; and
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