TOGAF 10 Deliverables, Artifacts, and Building Blocks: What Architects Need to Know

TOGAF® 10 distinguishes among deliverables, artifacts, and building blocks—three related but different types of architecture work products.

Understanding the difference matters because these terms describe different levels of formality, abstraction, reuse, and governance. Confusing them can lead to poorly controlled architecture documentation, duplicated work, unclear approvals, and difficulty communicating with stakeholders.

This guide explains what each term means, how the concepts relate to one another, where they appear in the Architecture Development Method (ADM), and how architects can use them effectively.

1. The Three Concepts at a Glance

Concept	What it is	Primary purpose	Typical examples
Deliverable	A formally reviewed and agreed work product	Demonstrate that a contractual, governance, or project obligation has been met	Architecture Definition Document, Architecture Requirements Specification, Implementation Governance Report
Artifact	A work product that describes an aspect of the architecture	Communicate, analyze, or specify architecture content	Catalog, matrix, diagram, principles, gap analysis
Building block	A reusable capability or component that can be combined with others	Support architecture design, standardization, and implementation	Identity management service, customer data service, API gateway, business capability

A useful summary is:

Deliverables are governed packages, artifacts are their contents or supporting views, and building blocks are reusable architectural components.

This is not a strict one-to-one relationship. A deliverable can contain multiple artifacts, and artifacts can describe or identify building blocks.

2. What Is a TOGAF Deliverable?

A deliverable is a formally specified work product that is reviewed, agreed upon, and typically approved by stakeholders or a governance body.

Deliverables are often created to satisfy:

A project requirement
A statement of work
An architecture governance checkpoint
A regulatory or compliance obligation
A decision-making need
A transition or implementation milestone

Deliverables are usually controlled through the organization’s architecture governance process. They may have:

An owner
A defined audience
A review date
An approval authority
A version number
A status
A relationship to an ADM phase or governance gate
A location in the Architecture Repository

Common TOGAF deliverables

Examples include:

Architecture Definition Document
Architecture Requirements Specification
Architecture Roadmap
Architecture Vision
Implementation Governance Report
Compliance Review
Architecture Change Requests
Statement of Architecture Work
Architecture Contract
Request for Architecture Work
Capability Assessment
Migration Planning documentation

The exact set of deliverables depends on the organization’s architecture method and the way it tailors TOGAF.

Deliverables are not necessarily single documents

A deliverable may be:

A document
A collection of diagrams
A repository package
A decision record
A review submission
A set of models
A formally approved baseline and target architecture
A digital workspace containing related information

For example, an Architecture Definition Document may include:

Architecture principles
Baseline architecture descriptions
Target architecture descriptions
Business, data, application, and technology views
Gap analysis
Constraints
Risks and assumptions
Architecture decisions
Dependencies
Traceability to requirements

The deliverable is the governed package. The individual diagrams, catalogs, and matrices inside it are artifacts.

3. Characteristics of a Deliverable

A well-managed deliverable generally has the following characteristics.

Formal status

It has a defined state, such as:

Draft
In review
Approved
Rejected
Superseded
Archived

Defined accountability

Someone is responsible for creating and maintaining it. Responsibility may be assigned to:

An enterprise architect
A domain architect
A solution architect
An architecture team
A project manager
An architecture governance board

Stakeholder agreement

Deliverables are reviewed by the people who have authority over the decisions involved. Depending on the organization, this could include:

Business owners
Product owners
Information security
Data governance
Technology leadership
Portfolio management
Risk and compliance
Architecture Review Board

Traceability

A deliverable should connect to:

Business drivers
Stakeholder concerns
Requirements
Architecture principles
Decisions
Risks
Work packages
Implementation projects
Governance outcomes

Repository management

Approved deliverables should be stored where they can be found, reused, and governed. The TOGAF Architecture Repository can provide the broader structure for this information.

4. What Is a TOGAF Artifact?

An artifact is a work product that describes a specific aspect of an architecture.

Artifacts are usually more focused than deliverables. They are used to:

Describe the current state
Define a target state
Analyze gaps
Show relationships
Communicate decisions
Support stakeholder concerns
Enable architecture governance
Provide input to implementation planning

Artifacts can be textual, tabular, graphical, or model-based.

Three broad artifact categories

TOGAF commonly groups artifacts into three categories:

Catalogs
Matrices
Diagrams

These categories are not mutually exclusive in every architecture practice, but they provide a useful way to organize architecture content.

5. Catalogs

A catalog is a structured inventory of architecture elements.

Catalogs answer questions such as:

What exists?
What capabilities do we have?
What applications are in use?
What data entities are managed?
What technologies are approved?
What stakeholders are involved?

Examples of catalogs

Organization/Actor Catalog
Business Service/Function Catalog
Business Role Catalog
Data Entity Catalog
Data Component Catalog
Application Portfolio Catalog
Application Interface Catalog
Technology Standards Catalog
Technology Portfolio Catalog
Principles Catalog
Requirements Catalog
Building Block Catalog

Example: Application Portfolio Catalog

An application catalog might contain:

Attribute	Example
Application name	Customer Relationship Management
Business owner	Sales Operations
Technical owner	Enterprise Platforms
Business capability	Customer Management
Lifecycle status	Strategic
Deployment model	Cloud
Criticality	High
Key integrations	Customer data platform, billing
Target disposition	Retain and modernize

The catalog is not necessarily a deliverable by itself. It may be one artifact included in an Architecture Definition Document, portfolio assessment, or architecture repository package.

6. Matrices

A matrix shows relationships between two or more sets of architecture elements.

Matrices are useful for:

Traceability
Dependency analysis
Impact assessment
Gap analysis
Ownership clarification
Relationship discovery

Examples of matrices

Business Interaction Matrix
Business Footprint Diagram or matrix
Actor/Role Matrix
Business Function/Organization Matrix
Data Entity/Business Function Matrix
Application/Business Function Matrix
Application/Organization Matrix
Application/Data Matrix
Application/Technology Matrix
Requirements Traceability Matrix
Capability/Value Stream Matrix
Project/Capability Matrix

Example: Application-to-Capability Matrix

Business capability	Application A	Application B	Application C
Customer management	Primary	Supporting	—
Order management	—	Primary	Supporting
Billing	—	Supporting	Primary
Customer analytics	Supporting	—	Primary

This type of artifact can reveal:

Duplicate application support
Missing application support
Overreliance on a single system
Capabilities with no clear owner
Opportunities for consolidation

7. Diagrams

A diagram presents architecture information visually.

Diagrams are particularly valuable when stakeholders need to understand:

Structure
Flows
Dependencies
Boundaries
Sequences
Locations
Ownership
Change over time

Examples of architecture diagrams

Business capability map
Value stream map
Organization map
Process flow
Information flow diagram
Data lifecycle diagram
Application communication diagram
Application interaction diagram
Integration architecture diagram
Networked technology architecture diagram
Deployment diagram
Environment and location diagram
Security architecture diagram
Migration roadmap
Benefits realization diagram

A diagram should have a clear purpose. The same architecture can be represented differently depending on the stakeholder concern.

For example:

Executives may need a capability heat map.
Security teams may need trust boundaries and data flows.
Operations teams may need deployment and dependency diagrams.
Project teams may need application interaction and interface diagrams.

A diagram is therefore not “the architecture” by itself. It is a view of the architecture for a particular audience and concern.

8. What Is a TOGAF Building Block?

A building block represents a potentially reusable component of business, information, application, or technology capability.

Building blocks help architects move from abstract architecture descriptions to practical, repeatable solutions.

A building block may be:

Conceptual
Logical
Physical
Business-oriented
Technology-oriented
Reusable across many initiatives
Specific to one project or solution

Building blocks can represent capabilities, services, processes, platforms, standards, patterns, components, or organizational functions.

Examples of building blocks

Business building blocks:

Customer onboarding capability
Product management capability
Procurement service
Risk assessment process
Workforce planning capability

Data building blocks:

Customer master data service
Data quality service
Metadata management capability
Reference data service
Data exchange model

Application building blocks:

Identity and access management service
Case management platform
Order management service
Notification service
Document management capability
API management platform

Technology building blocks:

Container platform
Cloud landing zone
Enterprise integration platform
Database service
Network security zone
Observability platform
Backup and recovery service

9. Architecture Building Blocks and Solution Building Blocks

A key distinction in TOGAF is between Architecture Building Blocks and Solution Building Blocks.

Architecture Building Blocks

Architecture Building Blocks, often abbreviated as ABBs, describe the required capability or behavior at an architectural level.

They are generally:

Conceptual or logical
Technology-neutral or relatively technology-independent
Concerned with what must be provided
Reusable across multiple solutions
Used to define target architecture structure

Examples:

Identity management
Customer information management
Service integration
Business intelligence
Data governance
Secure communication

An ABB might state that the enterprise needs:

Centralized identity management
Role-based access control
Single sign-on
Multi-factor authentication
Audit logging
Integration with employee and partner directories

It does not necessarily specify the exact product or implementation.

Solution Building Blocks

Solution Building Blocks, or SBBs, describe the concrete implementation of one or more architectural requirements.

They are generally:

Physical or implementation-oriented
Technology-specific or product-specific
Concerned with how a capability is realized
Associated with projects, products, services, and platforms

Examples:

A particular identity platform
A selected API gateway product
A managed Kubernetes service
A commercial CRM package
A specific data warehouse implementation
A project-specific integration service

ABB-to-SBB relationship

The relationship can be expressed as:

[
\text{Architecture Requirement} \rightarrow \text{ABB} \rightarrow \text{SBB} \rightarrow \text{Implemented Solution}
]

For example:

Level	Example
Business need	Improve secure access to enterprise systems
Architecture requirement	Provide centralized authentication and authorization
ABB	Identity and access management
SBB	Selected identity platform and directory service
Implementation	Configured authentication service deployed for business applications

An ABB may be realized by:

One SBB
Several SBBs
A combination of products and services
An existing enterprise platform
A new implementation
A managed service

Similarly, one SBB may contribute to multiple ABBs.

10. Deliverables, Artifacts, and Building Blocks: How They Relate

These concepts operate at different levels.

Deliverables provide governance

Deliverables are formal packages that are reviewed and approved.

Artifacts provide description

Artifacts describe the architecture in a specific way.

Building blocks provide reusable design elements

Building blocks represent capabilities or components that can be assembled into architectures and solutions.

A simplified relationship looks like this:

Deliverable
├── Catalogs
├── Matrices
├── Diagrams
├── Architecture decisions
├── Requirements
└── Building block specifications

Building blocks may also be referenced by artifacts:

Capability Map ─────── references business building blocks
Application Catalog ── identifies application building blocks
Technology Catalog ─── identifies technology building blocks
Architecture Diagram ─ shows relationships among building blocks
Roadmap ────────────── shows when building blocks will be implemented

The same building block may appear in multiple deliverables and be represented by several artifacts.

11. Where They Appear in the TOGAF ADM

The ADM provides a lifecycle for developing and governing enterprise architecture. Deliverables, artifacts, and building blocks support different activities throughout the ADM.

Preliminary Phase

The Preliminary Phase establishes the organization’s architecture capability.

Typical outputs may include:

Architecture principles
Architecture governance model
Architecture capability assessment
Architecture organization structure
Tailored architecture method
Architecture repository structure
Initial reference models
Governance procedures

Artifacts may include:

Principles catalog
Stakeholder map
Capability assessment
Organization model
Governance matrix
Architecture maturity assessment

Building blocks may include:

Architecture governance capability
Architecture repository capability
Architecture compliance capability
Architecture review service

Phase A: Architecture Vision

Phase A establishes the scope, purpose, stakeholders, and expected outcomes of the architecture effort.

Typical deliverables include:

Request for Architecture Work
Statement of Architecture Work
Architecture Vision
Communications plan
Initial risk and issues register
Initial architecture definition

Artifacts may include:

Stakeholder map
Value proposition
Capability overview
High-level business architecture diagram
High-level solution concept diagram
Benefits assessment
Constraints and assumptions
Initial architecture principles

Building blocks at this stage are often high-level and conceptual. Examples include:

Customer experience capability
Digital channel capability
Enterprise data platform
Shared integration service
Cybersecurity capability

Phase B: Business Architecture

Phase B develops the business architecture.

It focuses on:

Business strategy
Organization
Capabilities
Value streams
Business functions
Business services
Business processes
Roles
Business information
Business interactions

Typical artifacts include:

Business capability map
Organization/actor catalog
Business function catalog
Business service catalog
Business process diagrams
Value stream maps
Business interaction matrix
Business role catalog
Business footprint diagram
Capability heat map
Business architecture gap analysis

Potential deliverables include:

Business Architecture Definition
Business Architecture Report
Business requirements package
Capability assessment
Architecture roadmap inputs

Business building blocks may include:

Customer onboarding
Product lifecycle management
Claims processing
Supplier management
Workforce management
Regulatory reporting

Phase C: Information Systems Architectures

Phase C covers:

Data Architecture
Application Architecture

These are often treated as related but distinct architecture domains.

Data Architecture artifacts

Examples include:

Data entity catalog
Data component catalog
Data entity/business function matrix
Data entity/application matrix
Data lifecycle diagram
Data security and privacy diagram
Conceptual data model
Logical data model
Information exchange matrix
Data gap analysis
Master data model

Data building blocks may include:

Customer master data
Product master data
Data quality management
Data integration
Metadata management
Data governance
Reporting and analytics

Application Architecture artifacts

Examples include:

Application portfolio catalog
Application interface catalog
Application communication diagram
Application interaction matrix
Application/business function matrix
Application/data matrix
Application migration diagram
Application landscape
Application gap analysis
Application lifecycle assessment

Application building blocks may include:

Customer management service
Order management service
Billing service
Workflow service
API gateway
Notification service
Document management service

Typical Phase C deliverables may include:

Data Architecture Definition
Application Architecture Definition
Information Systems Architecture
Architecture requirements updates
Architecture roadmap inputs

Phase D: Technology Architecture

Phase D develops the Technology Architecture required to support the business, data, and application architectures.

Typical concerns include:

Infrastructure
Platforms
Networks
Cloud services
Security controls
Hosting
Devices
Middleware
Operations
Environments
Technology standards

Artifacts may include:

Technology standards catalog
Technology portfolio catalog
Technology/ application matrix
Environment and location diagram
Platform decomposition diagram
Processing diagram
Networked computing diagram
Communications engineering diagram
Security architecture diagram
Technology gap analysis
Technology migration diagram

Technology building blocks may include:

Cloud landing zone
Network security zone
Container platform
Database platform
Enterprise integration platform
Identity platform
Monitoring and observability platform
Backup and disaster recovery service

A Technology Architecture deliverable should show how technology capabilities support the intended business and information systems architectures.

Phase E: Opportunities and Solutions

Phase E moves from architecture definition toward implementation planning.

It identifies:

Major implementation approaches
Work packages
Projects
Transition architectures
Opportunities for reuse
Dependencies
Strategic options
Costs and benefits
Procurement considerations

Artifacts may include:

Work package portfolio
Project context diagram
Benefits assessment
Dependency matrix
Transition architecture diagram
Architecture building block catalog
Solution building block inventory
Opportunity assessment
Implementation factor assessment

This phase is where ABBs are often mapped to concrete SBBs.

For example:

Architecture capability	Candidate implementation
Enterprise integration	API management platform
Centralized authentication	Identity platform
Customer data management	Master data service
Event processing	Event streaming platform
Data analytics	Enterprise analytics platform

The output is not necessarily a final procurement decision. It may instead identify viable solution options that require further evaluation.

Phase F: Migration Planning

Phase F develops a detailed implementation and migration plan.

It addresses:

Priorities
Sequencing
Dependencies
Costs
Risks
Resource requirements
Transition architectures
Benefits realization
Migration strategy
Implementation governance

Typical artifacts include:

Architecture Roadmap
Implementation and Migration Strategy
Migration planning matrix
Work package definition
Project sequencing diagram
Transition architecture diagrams
Benefits realization plan
Risk register
Dependency matrix
Implementation factor assessment
Cost and resource estimates

Building blocks help create the roadmap by showing:

Which capabilities are missing
Which components can be reused
Which platforms are strategic
Which services should be retired
Which implementations depend on others

Phase G: Implementation Governance

Phase G ensures that implementation projects conform to the approved architecture.

Typical deliverables include:

Architecture Contract
Compliance reviews
Implementation Governance Report
Architecture decisions
Exception approvals
Architecture change requests
Updated architecture repository content

Artifacts may include:

Compliance assessment
Traceability matrix
Design review checklist
Exception register
Decision log
Architecture conformance report
Updated solution diagrams
Requirements verification matrix

Building blocks are used to verify whether the implementation uses approved or required components.

For example, a project may be required to use:

The enterprise identity service
Approved API standards
The corporate data classification model
The strategic cloud platform
The standard logging service

Where a project cannot use the required building block, it may need an approved exception.

Phase H: Architecture Change Management

Phase H manages changes to the architecture over time.

Changes may be caused by:

New business strategy
Regulatory requirements
Technology changes
Security threats
Mergers and acquisitions
Market changes
Operational lessons
New investment priorities
Emerging platforms

Typical outputs include:

Architecture Change Requests
Impact assessments
Updated principles
Updated roadmaps
Revised architecture definitions
New transition architectures
Governance decisions
Repository updates

Artifacts may include:

Change impact matrix
Technology radar
Risk assessment
Architecture decision record
Updated capability heat map
Dependency analysis
Scenario analysis

Building blocks may be:

Introduced
Modified
Replaced
Retired
Reclassified as strategic, tactical, or transitional

Requirements Management Across the ADM

Requirements Management operates continuously across the ADM.

It captures and maintains relationships among:

Stakeholder concerns
Business requirements
Architecture principles
Architecture requirements
Solution requirements
Compliance requirements
Security requirements
Data requirements
Technology requirements
Implementation requirements

Useful artifacts include:

Requirements catalog
Requirements traceability matrix
Requirements impact assessment
Requirements compliance matrix
Architecture decision log
Assumptions and constraints register

A strong architecture practice ensures that every significant building block and design decision can be traced back to one or more requirements.

12. The Architecture Repository

The Architecture Repository provides a structured way to store, classify, govern, and reuse architecture content.

A repository may contain:

Architecture principles
Reference architectures
Standards
Patterns
Models
Approved deliverables
Architecture decisions
Building blocks
Roadmaps
Governance records
Solution architectures
Historical and superseded versions

TOGAF commonly describes repository areas such as:

Architecture Capability
Architecture Landscape
Standards Information Base
Reference Library
Governance Log
Architecture Requirements Repository
Solutions Landscape

Organizations may implement these areas using:

An architecture management platform
A configuration management system
A document management platform
A modeling repository
A portfolio management tool
A structured collaboration workspace

The implementation technology is less important than the governance discipline.

13. Architecture Landscape, Reference Library, and Standards

The repository should distinguish between architecture content that serves different purposes.

Architecture Landscape

The Architecture Landscape contains descriptions of the organization’s architectures, including:

Current-state architectures
Target-state architectures
Transition architectures
Domain architectures
Segment architectures
Capability architectures
Solution architectures

Reference Library

The Reference Library contains reusable architecture assets, such as:

Reference architectures
Patterns
Templates
Models
Example deliverables
Standard viewpoints
Reusable building blocks
Industry models

Standards Information Base

The Standards Information Base contains approved standards, including:

Technology standards
Data standards
Integration standards
Security standards
Modeling standards
Development standards
Operational standards
Compliance standards

The distinction is important:

A reference architecture explains a recommended structure.
A standard defines what is permitted or required.
A building block represents a reusable capability or component.
A deliverable records an approved architecture or governance outcome.
An artifact describes part of that architecture.

14. Architecture Views and Viewpoints

Artifacts should be designed for a particular concern and audience.

A viewpoint defines how a particular type of architecture concern should be represented. A view is the actual representation created using that viewpoint.

For example:

Stakeholder	Concern	Useful viewpoint or view
Executive sponsor	Strategic outcomes	Capability and value view
Security officer	Threats and controls	Security architecture view
Data owner	Data ownership and movement	Information flow view
Operations team	Runtime dependencies	Deployment and operations view
Project manager	Delivery sequence	Roadmap and work package view
Developer	Interfaces and behavior	Application and integration view

A single architecture can therefore have multiple legitimate representations.

Architects should avoid creating diagrams merely because a framework lists them. Every artifact should answer a question or support a decision.

15. How to Decide Whether Something Is a Deliverable, Artifact, or Building Block

Use the following questions.

Is it formally submitted for approval?

If yes, it is probably a deliverable.

Example:

Architecture Definition Document
Architecture Contract
Compliance Review

Does it describe a specific aspect of the architecture?

If yes, it is probably an artifact.

Example:

Application catalog
Data flow diagram
Requirements matrix
Capability map

Is it reusable as a capability or implementation component?

If yes, it is probably a building block.

Example:

Identity management service
Customer data capability
API gateway
Cloud landing zone

Can one item belong to more than one category?

Yes, depending on how it is used.

For example:

An application catalog is an artifact.
If formally approved as part of an architecture package, it contributes to a deliverable.
Each application listed in the catalog may be treated as an application building block.

The categories describe different dimensions of the work product rather than rigid document types.

16. Example: Designing a Customer Onboarding Architecture

Suppose an organization wants to improve customer onboarding.

Business drivers

Reduce onboarding time
Improve regulatory compliance
Provide a consistent customer experience
Reduce manual processing
Improve data quality

Potential architecture requirements

Support digital and assisted onboarding
Verify customer identity
Apply risk and compliance checks
Capture customer consent
Maintain a trusted customer record
Integrate with downstream systems
Provide audit evidence

Potential business building blocks

Customer onboarding capability
Identity verification
Customer consent management
Compliance screening
Customer service
Case management

Potential data building blocks

Customer master data
Identity data
Consent data
Risk assessment data
Document metadata

Potential application building blocks

Digital onboarding application
Workflow service
Identity verification service
Document management service
Customer data service
Notification service

Potential technology building blocks

API management platform
Identity and access management platform
Integration platform
Secure document storage
Audit logging service
Monitoring platform

Supporting artifacts

Customer onboarding capability map
Customer journey or value stream map
Business process diagram
Application interaction diagram
Data flow diagram
Requirements traceability matrix
Security architecture diagram
Transition architecture roadmap
Application-to-capability matrix

Potential deliverables

Architecture Vision
Business Architecture Definition
Information Systems Architecture
Technology Architecture Definition
Architecture Roadmap
Architecture Contract
Implementation Governance Report

This example shows the relationship clearly:

The deliverables package and govern the work.
The artifacts describe the architecture.
The building blocks represent reusable capabilities and components.

17. Building Block Specifications

A building block becomes much more useful when it is documented consistently.

A building block specification may include:

Name
Type
Description
Purpose
Scope
Business capabilities supported
Functional requirements
Quality attributes
Interfaces
Dependencies
Inputs and outputs
Security requirements
Data requirements
Compliance requirements
Ownership
Lifecycle status
Reuse constraints
Required standards
Candidate implementations
Related ABBs and SBBs
Cost or sizing information
Service-level expectations
Version

Example: Identity Management ABB

Attribute	Description
Name	Enterprise Identity Management
Type	Architecture Building Block
Purpose	Provide consistent authentication and authorization
Capabilities	Identity lifecycle, authentication, authorization, auditing
Requirements	MFA, RBAC, federation, logging
Dependencies	Employee directory, partner directory, security monitoring
Standards	Enterprise security and identity standards
Candidate SBBs	Identity platform, directory service, access governance tool
Owner	Cybersecurity Architecture
Lifecycle	Strategic

The ABB defines what the enterprise needs. The SBB specification would describe the selected technologies and deployment details.

18. Baseline, Target, and Transition Architecture

Deliverables, artifacts, and building blocks can describe different points in time.

Baseline architecture

The baseline describes the current state.

It may include:

Existing capabilities
Current processes
Applications in use
Data stores
Technology platforms
Existing standards
Known constraints
Technical debt

Target architecture

The target describes the desired future state.

It may include:

Strategic capabilities
Target business services
Future application landscape
Target data architecture
Target technology platform
Desired security controls
Target operating model

Transition architecture

A transition architecture is an intermediate state used to move from baseline to target.

It may be necessary when:

The target state cannot be implemented in one step
Large systems must be modernized incrementally
Dependencies require staged delivery
Business risk makes a direct transition impractical
Funding or organizational capacity is limited

Building blocks are especially useful for transition planning because they reveal which reusable capabilities can be introduced incrementally.

19. Common Mistakes

Treating every diagram as a deliverable

A diagram is usually an artifact. It becomes part of a deliverable when it is included in a formally governed package.

Treating every application as an architecture building block

An application can be an SBB, an application component, an asset, or simply an item in a catalog. Whether it is a building block depends on how it is defined, governed, and reused.

Confusing an ABB with a product

An ABB describes a required architectural capability. A vendor product is generally an SBB or part of an SBB.

For example:

ABB: Enterprise integration
SBB: API management platform
Implementation: Configured API gateway, integration flows, policies, and operational procedures

Creating artifacts without a stakeholder purpose

Artifacts should support a concern, decision, analysis, or governance activity. Unused diagrams increase maintenance costs without improving architecture quality.

Failing to distinguish current and target states

A catalog or diagram should make clear whether it describes:

Current state
Target state
Transition state
Proposed option
Approved standard
Deprecated content

Ignoring ownership and lifecycle

Reusable assets need owners and lifecycle states. Otherwise, building block libraries become collections of outdated diagrams and obsolete technologies.

Producing documents instead of architecture decisions

TOGAF work products should support decisions and outcomes. A large document is not automatically a strong architecture deliverable.

20. Practical Governance for Architecture Work Products

Organizations should define a lightweight governance model for work products.

Recommended metadata

For each deliverable, artifact, and building block, record:

Name
Description
Type
Domain
Owner
Author
Status
Version
Date created
Date reviewed
Approval authority
Related ADM phase
Related initiative
Related requirements
Related principles
Related risks
Related decisions
Related building blocks
Repository location
Retention or archival status

Suggested lifecycle

Proposed
   ↓
Draft
   ↓
In Review
   ↓
Approved
   ↓
Published
   ↓
Superseded or Retired

Not every organization needs all these states, but every organization should define what its states mean.

Governance questions

Before approving a work product, ask:

Does it address the intended stakeholder concern?
Is the scope clear?
Are assumptions and constraints documented?
Is the content traceable to requirements?
Are baseline and target states distinguished?
Are dependencies identified?
Are risks and exceptions recorded?
Does it use approved standards?
Can the content be reused?
Is ownership clear?
Is the level of detail appropriate?

21. Tailoring TOGAF Deliverables and Artifacts

TOGAF is not intended to require every organization to produce every possible artifact.

Tailoring should consider:

Enterprise size
Architecture maturity
Regulatory environment
Delivery model
Business complexity
Project risk
Stakeholder expectations
Existing governance practices
Agile or product-based delivery
Tooling and repository capabilities

A small initiative may need only:

Architecture Vision
Key principles
Context diagram
Target-state design
Requirements traceability
Architecture decision log
Implementation governance review

A large, regulated transformation may need:

Formal baseline and target architectures
Multiple domain architecture deliverables
Detailed catalogs and matrices
Security and data views
Transition architectures
Architecture contracts
Compliance evidence
Formal roadmap and benefits tracking

The objective is not to maximize documentation. It is to provide enough architecture evidence to make sound decisions and govern implementation.

22. Agile and Product-Oriented Use

TOGAF concepts can be used in agile environments without producing large, static documents.

Agile and Product-Oriented Use

TOGAF concepts can be used in agile environments without producing large, static documents.

Examples include:

Deliverables as approved architecture packages or decision bundles
Artifacts as lightweight models, diagrams, backlogs, and decision records
Building blocks as reusable platform services, APIs, patterns, and capabilities
Architecture requirements as backlog items or quality attributes
Architecture decisions as version-controlled records
Governance as embedded reviews in product delivery
Roadmaps as living product and capability roadmaps

A practical agile architecture package might contain:

One-page context diagram
Key stakeholder concerns
Architecture principles
Target-state overview
Decision log
Quality attributes
Interface or data flow view
Approved building blocks
Risks and exceptions
Traceability to product outcomes

The terminology remains useful even when the format becomes more lightweight.

Agile and Product-Oriented Use

TOGAF concepts can be used in agile environments without producing large, static documents.

Examples include:

Deliverables as approved architecture packages or decision bundles
Artifacts as lightweight models, diagrams, backlogs, and decision records
Building blocks as reusable platform services, APIs, patterns, and capabilities
Architecture requirements as backlog items or quality attributes
Architecture decisions as version-controlled records
Governance as embedded reviews in product delivery
Roadmaps as living product and capability roadmaps

A practical agile architecture package might contain:

One-page context diagram
Key stakeholder concerns
Architecture principles
Target-state overview
Decision log
Quality attributes
Interface or data flow view
Approved building blocks
Risks and exceptions
Traceability to product outcomes

The terminology remains useful even when the format becomes more lightweight.

Examples include:

Deliverables as approved architecture packages or decision bundles
Artifacts as lightweight models, diagrams, backlogs, and decision records
Building blocks as reusable platform services, APIs, patterns, and capabilities
Architecture requirements as backlog items or quality attributes
Architecture decisions as version-controlled records
Governance as embedded reviews in product delivery
Roadmaps as living product and capability roadmaps

A practical agile architecture package might contain:

One-page context diagram
Key stakeholder concerns
Architecture principles
Target-state overview
Decision log
Quality attributes
Interface or data flow view
Approved building blocks
Risks and exceptions
Traceability to product outcomes

The terminology remains useful even when the format becomes more lightweight.

23. A Practical Template for an Architecture Deliverable

A general-purpose architecture deliverable can use the following structure:

Purpose and scope
Stakeholders and concerns
Business drivers
Requirements
Principles and constraints
Baseline architecture
Target architecture
Architecture views
Building blocks
Gap analysis
Options and trade-offs
Risks and assumptions
Dependencies
Roadmap and transition architectures
Governance and compliance
Decisions and approvals
Traceability
Appendices and supporting artifacts

Not every deliverable needs every section. The structure should be adapted to the audience and purpose.

24. A Practical Template for an Artifact

Each artifact should have enough metadata to explain why it exists.

Artifact name:
Artifact type: Catalog / Matrix / Diagram / Model / Record
Purpose:
Stakeholder concern:
Audience:
Architecture domain:
ADM phase:
Baseline, target, or transition:
Inputs:
Outputs:
Notation or modeling standard:
Owner:
Review status:
Related requirements:
Related decisions:
Related building blocks:
Repository location:

This prevents artifacts from becoming disconnected diagrams with no clear meaning or ownership.

25. A Practical Template for a Building Block

Building block name:
Type: ABB / SBB
Domain: Business / Data / Application / Technology
Purpose:
Description:
Capabilities provided:
Requirements addressed:
Functional characteristics:
Quality attributes:
Interfaces:
Inputs and outputs:
Dependencies:
Applicable standards:
Security considerations:
Data considerations:
Candidate implementations:
Owner:
Lifecycle status:
Reuse guidance:
Related artifacts:
Related deliverables:

The distinction between ABB and SBB should be explicitly recorded.

26. Key Takeaways

The most important points are:

Deliverables are formal, governed work products.
Artifacts are focused descriptions or representations of architecture content.
Building blocks are reusable capabilities or components used to construct architectures and solutions.
Catalogs, matrices, and diagrams are common artifact types.
Architecture Building Blocks describe what is required; Solution Building Blocks describe how it is implemented.
A deliverable may contain many artifacts and building block specifications.
The same building block may be referenced across multiple deliverables and architecture domains.
The ADM provides the lifecycle context for creating, using, and governing these work products.
The Architecture Repository enables reuse, versioning, classification, and governance.
TOGAF should be tailored to the organization rather than applied as a documentation checklist.
Every work product should support a stakeholder concern, decision, requirement, or governance outcome.
Good architecture practice emphasizes traceability, reuse, ownership, and lifecycle management.

In practical terms, architects should think of the three concepts this way:

Deliverables demonstrate progress and secure agreement. Artifacts explain the architecture. Building blocks make the architecture reusable and implementable.