TOGAF Core Concepts and Key Terminology Explained

One of the biggest challenges when you first pick up a TOGAF textbook is the terminology. The framework uses a very precise vocabulary, and many of the terms have specific meanings that differ from everyday usage.

If you confuse an Architecture Building Block with a Solution Building Block, or mistake a deliverable for an artifact, it will cost you marks in the exam and cause confusion in real projects.

This post covers every essential TOGAF core concept and term you need to understand. We have written each definition in plain language with a practical example so the idea sticks rather than just sitting on a page.

By the end, you will have the vocabulary to read any TOGAF document with confidence.

Foundational Concepts

Enterprise Architecture

Enterprise Architecture is the practice of analyzing, designing, planning, and implementing the analysis needed to execute on a business strategy. It takes a holistic view of an organization, looking at business processes, information systems, data, and technology infrastructure as one interconnected whole.

TOGAF provides the method and tools to do this work systematically.

Architecture

In TOGAF, "architecture" has two related meanings. The first is a formal description of a system. The second is the structure of components, their relationships, and the governing principles that guide their design and evolution over time.

Throughout the framework, when you see the word architecture on its own, it almost always refers to one of the four domains: Business, Data, Application, or Technology.

Enterprise

In the TOGAF context, an enterprise does not simply mean a large company. An enterprise is any collection of organizations that has a shared set of goals and a common understanding of what needs to be achieved. This could be a single company, a government department, a division within a corporation, or a consortium of partner organizations.

This definition matters because TOGAF can apply at many different scales.

The Building Block Concepts

This is one of the areas that confuses candidates most in the certification exam. TOGAF defines several types of building blocks, each with a distinct role.

Architecture Building Block (ABB)

An Architecture Building Block is a conceptual component of an architecture. It describes what a capability does without specifying how it will be built or which product will implement it. ABBs come from the Architecture Continuum and are vendor-neutral.

For example, an ABB for "customer identity management" describes the capability to uniquely identify and authenticate customers. It does not specify whether that will be built using Microsoft Azure AD, Okta, or an in-house solution.

Solution Building Block (SBB)

A Solution Building Block is the physical or product-specific implementation that realizes an ABB. It represents the actual technology, product, or component that will be deployed.

Following the example above, the SBB would be the chosen product: "Microsoft Azure Active Directory B2C, deployed as a managed cloud service."

ABB vs SBB Summary

ABBs describe WHAT is needed (the capability). SBBs describe HOW it will be delivered (the implementation). You define ABBs during architecture phases and select SBBs during implementation planning.

Artifacts, Deliverables, and Work Products

Another area where terminology precision is essential.

Artifact

An artifact is an architectural work product that describes an aspect of the architecture. Artifacts are created during the ADM process and can take several forms:

Catalogs: Lists of things, such as an Application Portfolio Catalog or a Technology Standards Catalog
Matrices: Grids showing relationships, such as a Business Capability to Application matrix
Diagrams: Visual representations, such as a Business Process diagram or a Network Topology diagram

Deliverable

A deliverable is a work product that is contractually specified and reviewed, agreed upon, and formally signed off by the stakeholders at a specific point in the ADM. Deliverables are the formal outputs of each phase.

The key distinction: all deliverables are artifacts, but not all artifacts become deliverables. A deliverable implies a formal governance checkpoint.

Work Product

A work product is a generic term for any artifact or deliverable produced during an architecture engagement. It is the broadest category and encompasses everything produced by the architecture team.

Repository and Continuum Concepts

Architecture Repository

The Architecture Repository is a logical store of all architectural outputs. Think of it as a structured filing system for everything the architecture team produces. It stores reference models, standards, previous architectures, patterns, and current project deliverables.

The repository has six classes of content:

Architecture Metamodel: The overall framework and method being used
Architecture Capability: Governance structures and roles for the architecture practice
Architecture Landscape: The current, transition, and target architectures
Standards Information Base (SIB): Industry and organizational standards
Reference Library: External reference models and templates
Governance Log: Records of governance activity and decisions

Enterprise Continuum

The Enterprise Continuum is a classification tool that helps organize architecture assets from generic to organization-specific. It represents a spectrum with two ends.

At one end is the Foundation Architecture, which is completely generic and applies to any organization. At the other end is an Organization-Specific Architecture that is uniquely tailored to a single enterprise.

The Enterprise Continuum itself has two sub-continua:

Architecture Continuum: For abstract architecture building blocks and principles
Solutions Continuum: For physical implementations and products

Why the Enterprise Continuum Matters

The Enterprise Continuum makes architecture assets reusable. A well-built ABB can be applied across multiple projects. Organizations that manage their Enterprise Continuum effectively build faster and more consistently over time.

Architecture Landscape

The Architecture Landscape describes the current state of the enterprise architecture at any point in time across three levels:

Strategic Architecture: Long-term direction and high-level capabilities (multi-year view)
Segment Architecture: Architectures for specific business areas or domains (yearly view)
Capability Architecture: Detailed architectures for specific capabilities or projects (monthly view)

Governance Concepts

Architecture Governance

Architecture Governance is the practice and system by which enterprise architectures are managed, controlled, and made accountable. It ensures that architecture work aligns with organizational policies, standards, and strategic objectives.

Governance addresses questions like: Who approves architecture decisions? What standards must all systems comply with? How are deviations handled?

Architecture Contract

An Architecture Contract is a joint agreement between development partners and their sponsors on the deliverables, quality, and fitness-for-purpose of an architecture. It is the formal commitment that ensures architecture decisions are respected throughout implementation.

Architecture Compliance

Architecture Compliance is the process of checking that an implementation project conforms to the agreed architecture. It typically involves Architecture Compliance Reviews at defined points in the delivery lifecycle.

Statement of Architecture Work

The Statement of Architecture Work defines the scope and approach for an architecture development activity. It is produced during Phase A and acts as the formal mandate for the architecture team to begin their work.

Stakeholder Concepts

Stakeholder

A stakeholder is any individual or group who has an interest in the outcome of the architecture. In TOGAF, stakeholders go far beyond the technical team. They include business executives, regulators, end users, suppliers, and partners.

Understanding stakeholders is critical because the architecture must address their specific concerns. Different stakeholders care about different things.

Concern

A concern is a specific interest that a stakeholder has in a system. A Chief Financial Officer might have concerns about cost. A security officer might have concerns about data breach risk. A software developer might have concerns about system complexity.

Architecture views are designed to address concerns.

Architecture View

An Architecture View is a representation of the overall architecture from the perspective of a related set of concerns. For example, a "Security View" addresses security concerns, while a "Performance View" addresses stakeholders concerned with response times and throughput.

Architecture Viewpoint

An Architecture Viewpoint is the convention or rule for constructing a particular type of Architecture View. It specifies what the view should contain, what notation should be used, and which stakeholder concerns it addresses.

Think of a viewpoint as a template and a view as the completed document built from that template.

Views Are Not Diagrams

A common mistake is thinking that an Architecture View is simply a diagram. A view can contain multiple diagrams, catalogs, and matrices. It is a collection of architecture content organized to address a specific set of stakeholder concerns.

Principles and Requirements

Architecture Principle

An Architecture Principle is a general rule or guideline that informs and supports the way an organization fulfills its mission. Principles are statements that represent the fundamental beliefs of the enterprise about how decisions should be made.

A well-formed principle has:

Name: A short, memorable title
Statement: One sentence describing the principle clearly
Rationale: Why this principle exists and what business value it supports
Implications: The practical impact of following this principle on processes and resources

An example principle: "Data is a Shared Asset." Statement: All data held by the organization is accessible to everyone who has a legitimate need, subject to security constraints. Rationale: Consistent, accurate data enables better decisions and eliminates duplication. Implications: Data silos will not be created. All new systems must integrate with the central data governance framework.

Requirements Management

Requirements Management is not a sequential phase in the ADM. It is an ongoing process that sits at the center of the entire ADM cycle. Its role is to ensure that architecture requirements are identified, stored, managed, and fed into each relevant phase throughout the entire lifecycle.

This is why it appears in the center of the ADM wheel illustration, not in the outer sequence of phases.

Transition Architecture

A Transition Architecture describes an intermediate state the enterprise will pass through on the way from the Baseline Architecture to the Target Architecture. Large transformations rarely happen in a single step.

For example, migrating from an entirely on-premises infrastructure to a cloud-native one might involve three transition states: first moving non-critical systems to the cloud, then core applications, and finally the regulated data environment.

Each transition state is a stable, operable architecture in its own right, not just a half-finished state.

Key Terms Quick Reference

Here is a summary of the most exam-relevant terms covered in this post:

ABB: What a capability is (vendor-neutral)
SBB: How it will physically be delivered (product-specific)
Artifact: A catalog, matrix, or diagram produced by architecture work
Deliverable: A formally signed-off artifact
Architecture Repository: The central store for all architecture outputs
Enterprise Continuum: A spectrum from generic to organization-specific architectures
Architecture View: Architecture described for a specific set of stakeholder concerns
Architecture Viewpoint: The template for constructing a view
Architecture Principle: A fundamental belief guiding architecture decisions
Transition Architecture: An intermediate stable state during transformation

What Comes Next

With these core concepts understood, you are ready to move into the heart of the TOGAF framework: the Architecture Development Method.

In the next post, we will cover Architecture Principles and Governance Basics, explaining how organizations establish the rules that govern all their architecture decisions.

If you are just joining this series, you can start from the beginning with What is TOGAF 9.2? A Complete Framework Overview and then move to The Four Architecture Domains before continuing here.

Understanding these core concepts is also essential preparation for the certification. In Module 5 of this series, we will put this knowledge to the test with full-length mock practice exams designed to mirror the real Foundation and Practitioner tests.