Deliverables, artefacts, building blocks, and viewpoints

Teams often call every document a deliverable, every diagram an architecture, and every product choice a building block. The result is confusion in reviews, poor reuse, and weak governance.

Part 4 of the TOGAF Standard (the Content Framework) gives cleaner language. It distinguishes the packaged output of architecture work, the specific representations inside that output, and the reusable elements that sit behind architectural design choices.

These are not interchangeable labels. Each term occupies a different layer. Governance operates on deliverables, because those are the packages that get formally reviewed and approved. Reuse operates on building blocks, because those are the components that other projects can adopt. Communication operates on artefacts, because those are the specific representations that stakeholders actually read, question, and challenge. When teams blur these layers, governance reviews lose focus, reuse conversations become imprecise, and stakeholder communication fails.

The TOGAF Standard defines a deliverable as:

“An architectural work product that is contractually specified and in turn formally reviewed, agreed, and signed off by the stakeholders.”

TOGAF Standard, 10th Edition - C220 Part 4

The word 'contractually' is important. A deliverable is not just anything the team produces. It is a package that has been agreed in advance as an expected output, and it goes through a formal review and sign-off process.

In plain language: a deliverable is the submitted pack. Think of it as the folder that lands on the Architecture Board's desk for review. The Architecture Definition Document, a Statement of Architecture Work, a compliance assessment pack, or a transition roadmap pack are all deliverables.

Key characteristics of a deliverable:

• It is formally specified in advance, typically in the Statement of Architecture Work or an architecture contract.
• It goes through a review and approval process.
• It usually contains multiple artefacts inside it.
• It is the unit that governance acts on: approve, reject, request rework, or waive.

The ADM defines specific deliverables for each phase. Phase A produces the Statement of Architecture Work and the Architecture Vision. Phases B, C, and D collectively produce the Architecture Definition Document. Phase E produces the Architecture Roadmap. Phase F produces the Implementation and Migration Plan. Each of these is a deliverable because it is a formally agreed output.

The TOGAF Standard defines an artefact as:

“An architectural work product that describes an aspect of the architecture.”

TOGAF Standard, 10th Edition - C220 Part 4

An artefact is a specific item of architecture content. It might be a catalogue, a matrix, or a diagram. The crucial point is that artefacts live inside deliverables. They are the individual pieces, not the submitted pack.

In plain language: an artefact is one specific document, diagram, table, or list produced during architecture work. If the deliverable is the book, artefacts are the chapters. A capability map is an artefact. An application interaction matrix is an artefact. A network diagram is an artefact. A data entity catalogue is an artefact.

Artefacts are where the actual analytical and design content lives. When a stakeholder challenges an architecture decision, they are typically challenging something shown in an artefact, not the deliverable as a whole. When an architect needs to update the design after a requirements change, they update specific artefacts within the deliverable.

The TOGAF Standard defines a building block as:

“A (potentially re-usable) component of enterprise capability that can be combined with other building blocks to deliver architectures and solutions.”

TOGAF Standard, 10th Edition - C220 Part 4

Building blocks are things the enterprise builds, buys, or acquires. They are not documents. They are not diagrams. They are the actual components of capability that artefacts describe and deliverables package for review.

In plain language: a building block is a chunk of capability that exists in the enterprise (or will exist after implementation). An identity management service is a building block. A customer relationship management platform is a building block. A data integration layer is a building block.

The relationship between the three terms is directional:

• A deliverable contains one or more artefacts.
• Artefacts describe, select, or specify building blocks.
• Building blocks are the reusable elements that the artefacts are about.

A common mistake is to call a software product a building block before the architecture need has been clarified. The product is a candidate for a building block, but the building block itself is the capability or function that the product provides. This distinction becomes critical when an organisation needs to replace one product with another: if the building block was defined at the capability level, the swap is straightforward. If it was defined as a specific product, the swap feels like an architecture change when it is actually just a solution change.

TOGAF divides building blocks into two levels. An Architecture Building Block (ABB) describes what is needed at the architecture level, without naming a specific product or technology. A Solution Building Block (SBB) names the specific product, tool, or technology that implements the ABB.

Think of it this way: the ABB is the job description; the SBB is the person hired to fill the role. The ABB says "we need a network monitoring capability that can detect faults across 33 kV and 11 kV circuits in real time." The SBB says "we will use a specific Distribution Management System from vendor X to fulfil that requirement."

This separation matters because:

• Architecture decisions should stabilise before solution decisions. If you jump straight to product selection (SBB thinking) before the capability need is clear (ABB thinking), you risk choosing a product that solves the wrong problem.
• ABBs are more stable than SBBs. The need for "real-time network monitoring" will outlast any specific vendor product. When the product is eventually replaced, the ABB remains valid.
• Governance reviews need both levels. The Architecture Board should confirm that ABBs are justified before approving SBB procurement. A board that only sees product selections has no way to judge whether the right capability was specified.

In the London Grid case, an ABB might be "publish network capacity data in a standards-compliant format for external consumption." The SBB would name the specific data platform, the CIM profile used, and the publication interface. Stages 4 and 5 of this course explore ABB-to-SBB decisions in detail. Stage 1 introduces the language so that later modules do not have to stop and repair vocabulary.

A view is what you show. A viewpoint is the specification of how and why you show it for a particular stakeholder concern. That distinction matters because architecture is communication as well as analysis.

The TOGAF Standard defines a stakeholder as any person or group with an interest in the architecture. This includes the CTO who funds the programme, the network engineer who implements changes at substations, the data steward who manages publication quality, and the regulator who checks compliance. Each stakeholder has different concerns: the CTO cares about investment risk, the engineer cares about implementation feasibility, the data steward cares about accuracy and timeliness, and the regulator cares about evidence and traceability.

A viewpoint defines what a particular type of stakeholder needs to see, and at what level of detail. It specifies:

• Which stakeholders it serves
• Which concerns it addresses
• Which artefacts (catalogues, matrices, diagrams) it uses
• What conventions, notation, and abstraction level it follows

A view is then a specific instance: the actual diagram, table, or representation that results from applying a viewpoint to a particular architecture. If a viewpoint is the camera angle, the view is the actual photograph taken from that angle.

A weak architecture pack usually shows views with no disciplined viewpoint thinking behind them. The team produces a single diagram and presents it to every audience. The board wants decision context. The engineering team wants implementation constraints. The regulator wants evidence traceability. One diagram almost never serves all three concerns at the resolution each audience needs.

Part 4 of the TOGAF Standard includes the Content Metamodel, a detailed model that defines all the types of architecture content an organisation should produce. The metamodel organises artefacts into three families:

Catalogues are lists of things. They answer the question "what do we have?" A catalogue captures entities of a particular type, such as business services, applications, technology components, or data entities. Catalogues are the inventory of the architecture.

Matrices show relationships between two types of thing. They answer the question "how do these things relate to each other?" An application-to-data matrix shows which applications create, read, update, or delete which data entities. A business-service-to-application matrix shows which applications support which services. Matrices are the wiring diagrams of the architecture.

Diagrams show things visually in context. They answer the question "how does this look and flow?" A business process diagram shows how work moves through the organisation. A network topology diagram shows how technology components connect. Diagrams are the views that stakeholders most commonly associate with architecture.

The metamodel matters because it gives architecture teams a shared language for what they should be producing. Without it, every team invents its own artefact types and the Architecture Repository becomes a pile of incompatible documents.

The following lists are not exhaustive, but they cover the major artefact types that appear across the ADM phases. Learning these now saves confusion when later modules reference specific artefact names.

Catalogues (inventories)

• Principles Catalogue ( Preliminary Phase) lists the architecture principles that guide all decisions.
• Organisation/Actor Catalogue ( Phase B) lists the organisational units and actors involved in business processes.
• Business Service/Function Catalogue (Phase B) lists the services and functions the business performs.
• Driver/Goal/Objective Catalogue (Phase B) lists the business drivers, goals, and objectives.
• Role Catalogue (Phase B) lists the roles that actors play within the organisation.
• Location Catalogue (Phase B) lists the physical and logical locations where the business operates.
• Data Entity/Data Component Catalogue ( Phase C) lists the major data entities and data components.
• Application Portfolio Catalogue (Phase C) lists all applications in the enterprise.
• Interface Catalogue (Phase C) lists the interfaces between applications.
• Technology Standards Catalogue ( Phase D) lists the approved technology standards and products.
• Technology Portfolio Catalogue (Phase D) lists the technology components in the infrastructure.

Matrices (relationships)

• Stakeholder Map Matrix maps stakeholders to their concerns and the viewpoints that serve them.
• Business Interaction Matrix maps the relationships between organisational units.
• Actor/Role Matrix maps actors to the roles they play.
• Data Entity/Business Function Matrix maps which business functions create, read, update, or delete which data entities.
• Application/Data Matrix maps which applications access which data entities.
• Application/Function Matrix maps which applications support which business functions.
• Application/Technology Matrix maps which applications run on which technology components.
• Application Interaction Matrix maps the interfaces and dependencies between applications.

Diagrams (visual representations)

• Business Footprint Diagram links business goals to organisational units, functions, services, and data.
• Business Service/Information Diagram shows the information exchanged between business services.
• Functional Decomposition Diagram breaks capabilities and functions into component parts.
• Goal/Objective/Service Diagram links goals and objectives to the services that fulfil them.
• Organisation Decomposition Diagram shows how the organisation is structured.
• Process Flow Diagram shows how work flows through business processes.
• Data Dissemination Diagram shows how data moves between system components.
• Application Communication Diagram shows the interfaces between applications.
• Application and User Location Diagram maps applications and users to physical or network locations.
• Environments and Locations Diagram shows the technology environments and their locations.
• Platform Decomposition Diagram breaks the technology platform into its component services.
• Networked Computing/Hardware Diagram shows the physical hardware and network topology.

1. An architecture effort produces a deliverable such as the Architecture Definition Document, a review pack, or a target-state submission.
2. That deliverable contains artefacts: catalogues (inventories of entities), matrices (relationship maps between entities), and diagrams (visual representations of the architecture).
3. Some of those artefacts describe, select, or specify reusable building blocks, expressed first as ABBs (what is needed) and later as SBBs (how it will be provided).
4. Different stakeholders see different views, shaped by different viewpoints, even when the underlying architecture logic is the same.
5. The Content Metamodel defines the standard structure for all of these elements, ensuring consistency across the Architecture Repository.

The following vocabulary errors appear repeatedly in architecture practice. Each one creates a specific downstream problem:

• Calling the whole pack an artefact. When teams call the entire submitted package an "artefact," governance reviews lose the ability to distinguish the formal sign-off boundary (the deliverable) from the analytical content inside it.
• Calling every software product a building block before the architecture need is clear. If the ABB has not been defined, the organisation cannot evaluate whether the product actually addresses the right capability.
• Showing the same diagram to every stakeholder. Without viewpoint discipline, a single diagram tries to serve executive decision-making, engineering implementation, and regulatory compliance simultaneously. It usually fails all three.
• Treating a building block choice as automatically a good architecture decision. A building block might be reusable and well-designed, but if it was selected without reference to the architecture principles or the target state, it can still be the wrong choice.
• Producing catalogues without explaining their purpose. A catalogue that lists 200 applications without explaining why the list exists, what decisions it supports, or how it relates to other artefacts is an inventory exercise, not architecture.
• Confusing a matrix with a diagram. A matrix shows structured relationships (application X uses data entity Y). A diagram shows context and flow. Both are useful; they are not interchangeable.

The London Grid case gives concrete examples of all three layers. Consider a quarterly architecture review where the enterprise architecture team presents its work to the Architecture Board.

Deliverables London Grid would produce

• Architecture Definition Document covering the target state for connections modernisation, network visibility, and data publication.
• Statement of Architecture Work defining the scope, approach, and governance for the current ADM cycle.
• Architecture Roadmap showing the transition states from the current legacy landscape to the target architecture over three to five years.
• Compliance Assessment Pack demonstrating how the architecture aligns with Ofgem ED3 requirements and NCSC CAF expectations.

Artefacts inside those deliverables

• Catalogues: Application Portfolio Catalogue listing all SCADA, DMS, GIS, metering, and customer-facing systems. Technology Standards Catalogue listing approved standards including CIM profiles and smart meter communication protocols. Data Entity Catalogue listing network asset data, customer connection data, and LTDS publication data.
• Matrices: Application/Data Matrix showing which systems create, read, update, or delete network model data. Business Service/Application Matrix showing which applications support connections processing, fault management, and data publication. Application/Technology Matrix mapping applications to their hosting platforms and network segments.
• Diagrams: Network topology diagram showing how OT and IT systems connect. Data dissemination diagram showing how LTDS publication data flows from source systems to external platforms. Application communication diagram showing interfaces between SCADA, DMS, GIS, and the enterprise data platform.

Building blocks behind the design

• ABB examples: "Real-time network monitoring capability," "standards-compliant data publication service," "customer connection request management capability," "identity and access management for OT/IT boundary systems."
• SBB examples: A specific DMS product, a specific CIM-compliant data integration platform, a specific identity provider deployed at the OT/IT boundary, a specific flexibility market interface.

Different stakeholders at London Grid would need different views of this same material:

• The Architecture Board needs a viewpoint shaped around investment decisions, risk exposure, and regulatory compliance.
• The engineering team needs a viewpoint shaped around implementation constraints, dependencies, and migration sequencing.
• The Ofgem review team needs a viewpoint shaped around evidence traceability, regulatory alignment, and publication obligations.
• The OT security team needs a viewpoint shaped around trust boundaries, access control, and CAF alignment.