TOGAF content, repository, and governance

Why this module matters

Module 5 covered the process of TOGAF. This module covers what it produces and how it is governed. In the exams these topics are mostly about definitions and relationships. In practice they’re what makes architecture stick after the presentation is over.

Architecture content

TOGAF classifies architecture outputs into three types:

Type	What it is	Example
Deliverable	A work product that is contractually specified, formally reviewed, agreed, and signed off	Architecture Definition Document, Statement of Architecture Work
Artifact	A more granular work product that describes an aspect of the architecture	An application portfolio catalog, a capability/application matrix, a data flow diagram
Building block	A (potentially reusable) component of enterprise capability that can be combined with others to deliver architectures and solutions	“Customer identity service”, “Event streaming platform”

Deliverables typically contain artifacts, and artifacts describe building blocks.

Artifacts: catalogs, matrices, diagrams

• Catalogs are lists of things, such as an application portfolio catalog or a principles catalog.
• Matrices show relationships between things, such as an application/capability matrix or a data entity/application matrix.
• Diagrams are visual views, such as an application communication diagram or a capability map.

Architecture vs Solution Building Blocks

Architecture Building Block (ABB)	Solution Building Block (SBB)
Captures architecture requirements	Defines what products and components implement the functionality
Directs and guides the development of SBBs	Product- or vendor-aware
“A customer identity provider supporting SSO via OIDC, MFA, and EU data residency”	“Our chosen identity platform, deployed in the EU region”

The content metamodel

TOGAF defines a content metamodel: the types of entities an architecture describes (actors, capabilities, processes, data entities, application components, technology components, and so on) and how they relate. You don’t need to memorize all of it. It matters because it’s what makes architecture content queryable: “which applications support which capabilities and hold which data?” Many EA tools implement a version of it, and ArchiMate (module 7) is closely aligned with it.

The Enterprise Continuum

The Enterprise Continuum is a way of classifying architecture and solution assets by how generic or specific they are. Its purpose is reuse: don’t build from scratch what exists in a more generic form.

              Generic ◄─────────────────────────────────────────► Specific

Architecture   Foundation  ──►  Common Systems  ──►  Industry  ──►  Organization-
Continuum      Architecture     Architectures        Architectures  Specific Architectures
                    │                 │                    │                │
                    ▼                 ▼                    ▼                ▼
Solutions      Foundation  ──►  Common Systems  ──►  Industry  ──►  Organization-
Continuum      Solutions        Solutions            Solutions      Specific Solutions

• Foundation: generic building blocks that apply to any enterprise
• Common Systems: architectures for common system types, such as security or networking
• Industry: patterns for a particular industry, such as banking or retail reference models
• Organization-Specific: your enterprise’s own architecture

At Quillfeather, an industry-level reference model for payments (common across fintechs) informed PayNest’s SEPA design. Quillfeather’s own payments architecture sits at the organization-specific end.

The Architecture Repository

The Architecture Repository is where architecture outputs are stored and managed. Its main components:

Component	Holds
Architecture Metamodel	The tailored framework and content metamodel
Architecture Capability	How the EA practice runs: its processes, roles, and governance
Architecture Landscape	Architectures at strategic, segment, and capability levels: baseline, target, and transition
Standards	The standards that solutions must comply with
Reference Library	Guidelines, templates, patterns, and reference architectures
Governance Log	Decisions, compliance assessments, dispensations, and the history of governance activity
Architecture Requirements	Requirements agreed with sponsors and the Architecture Board
Solutions Landscape	Solution Building Blocks supporting the Architecture Landscape

Exam note: Some component names differ slightly between TOGAF 9.2 and the 10th Edition (for example, 9.2’s “Standards Information Base”). Learn the names used in the edition your exam covers.

At Quillfeather: The “repository” started as a wiki space with sections for principles, ADRs (the governance log), the capability map and roadmap (the landscape), and templates (the reference library). That’s enough until it isn’t. Module 7 discusses when to invest in a proper EA tool.

Architecture principles

Principles are durable rules that guide decisions. They’re one of the most useful things an EA produces, because they let people make consistent decisions without asking you.

TOGAF principles have four parts:

Part	Purpose
Name	Short and memorable
Statement	The rule, stated clearly and unambiguously
Rationale	Why it matters, in business terms
Implications	What following it requires: cost, effort, behavior changes

TOGAF suggests good principles are understandable, robust (precise enough to support decisions), complete, consistent with each other, and stable.

A worked example from Quillfeather

Name: One customer, one identity

Statement: Every customer and tenant has a single identity, managed by the central identity platform, across all Quillfeather products.

Rationale: Customers expect one Quillfeather experience. Separate identities create support costs, security risk, and an inconsistent view of the customer, which blocks cross-sell and reporting.

Implications: New products must integrate with the central identity platform before launch. FixIt Pro’s separate login must be retired. Teams can’t build local user stores. Exceptions require a dispensation with an end date.

Good and bad principles

✗ Weak	Why	✓ Stronger
“We use best-of-breed technology”	Not actionable; everyone thinks their choice is best-of-breed	“Buy commodity capabilities; build only what differentiates us”
“Data is important”	Not a rule	“Every data entity has a single named owner and source of truth”
“All services must use Kafka”	A standard, not a principle; will date quickly	“Integrate asynchronously by default between domains”

Aim for 8–12 principles. If you have 40, nobody will remember any of them.

Architecture governance

Architecture governance is how the organization makes sure architecture decisions are made well and followed. TOGAF frames it around a few mechanisms.

The Architecture Board

A cross-organizational group that oversees architecture. Its typical responsibilities include:

• Keeping architectures consistent with each other and with the enterprise direction
• Approving standards and principles
• Resolving conflicts and making decisions that cross team or domain boundaries
• Granting dispensations
• Improving the maturity of the architecture practice

In a scaling organization, a formal board can easily turn into a bottleneck. A lighter architecture forum with clear decision rights often works better (see module 11).

Architecture Contracts

Joint agreements between the architecture function and the people delivering change, setting out what will be delivered, to what standards, and how compliance will be checked. In practice: the Statement of Architecture Work (with the sponsor) and contracts with delivery teams or partners.

Compliance

TOGAF defines levels of conformance between an implementation and its architecture specification:

Level	Meaning
Irrelevant	No features in common
Consistent	The features it shares with the specification are implemented in line with it, but some of the specification is missing and there are extra features outside it
Compliant	Everything implemented is in line with the specification, but not all of the specification is implemented
Conformant	All of the specification is implemented, but some extra features aren’t covered by it
Fully conformant	Full correspondence between specification and implementation
Non-conformant	Implements features in a way that contradicts the specification

Exam note: The difference between compliant (everything built follows the spec, but not everything is built) and conformant (everything in the spec is built, plus extras) is a favorite exam question.

Dispensations

When a project can’t comply, for a good reason, the Architecture Board can grant a dispensation: an approved, time-limited exception, usually with conditions and a plan to return to compliance. Dispensations are recorded in the governance log, and the pattern of dispensations tells you which standards may need revisiting.

At Quillfeather: FixIt Pro needed EU customers before its migration to the central identity platform was finished. It got a six-month dispensation from “One customer, one identity”, on condition that EU customer data stayed in the EU and the migration was funded in T2.

Stakeholder management

TOGAF treats stakeholder management as a core technique. The basic tool is the power/interest grid:

	Low interest	High interest
High power	Keep satisfied	Key players: manage closely
Low power	Minimal effort: monitor	Keep informed

For each stakeholder, TOGAF also suggests identifying their concerns and the views that address them (module 7).

At Quillfeather (for the EU expansion work):

• Key players: CTO, CPO, CFO, Head of Payments
• Keep satisfied: CEO, the board (they want confidence, not detail)
• Keep informed: engineering managers, Head of Security & Compliance, customer success
• Monitor: back-office functions such as HR and marketing

You’ll go deeper on stakeholders in module 10.

Reflection

• Draft three principles for your own organization in the TOGAF format. Does each one change a real decision?
• What is your organization’s equivalent of a governance log? Could you find the reasoning behind a decision made two years ago?
• Who would be on your power/interest grid for your organization’s most important current initiative?