Recommended resources
The freely available resources this lesson will direct you to.
Hello! Last time, you distinguished an architecture view—a representation of a particular architecture—from the viewpoint that guides its construction. We now begin the module on architecture content: what architects produce, what those products describe, and what can be reused.
This lesson introduces three TOGAF terms that are easy to mix up: deliverable, artifact, and building block. You will use them to classify examples, particularly the Architecture Definition Document and the Architecture Requirements Specification. The distinction matters for Foundation questions, but it also prevents a practical mistake: confusing a description of an architecture with a component of the architecture itself.
Three different roles in architecture work
Imagine an organization changing the way it handles customer calls. Architects need to describe the existing process, define a proposed process, and communicate requirements to the people implementing the change. Those tasks generate different kinds of content.
A deliverable is a formally specified output of the architecture work, intended for review and approval by its stakeholders. A diagram showing the proposed call-handling process is an artifact: a representation that describes some aspect of the architecture. The call-handling process represented in that diagram is a building block: a component of the architecture being described.
The useful distinction is not “large document versus small document versus physical object.” It is the role each item plays:
| Ask about the item | Classification |
|---|---|
| Is it a formal output that the architecture engagement is expected to provide? | Deliverable |
| Does it describe or represent an aspect of the architecture? | Artifact |
| Is it a component of the architecture or solution being described? | Building block |
Read the following explanation for the basic vocabulary. It is a secondary account; we will check named examples against a publication from The Open Group afterward.
Deliverables, Artifacts, and Building Blocks: Decoding the ... - Medium
Read the article by Xin-Kuan (Leo) Yeh for its explanation of the three roles and how they relate.
Under “What Are Deliverables?”, read the opening definition. Under “What Are Artifacts?”, read the description and examples. Under “What Are Building Blocks?”, read the opening paragraph; stop before the two building-block types, which are the subject of the next lesson. Finally, under “How Do These Elements Interact?”, read the relationship paragraph. Focus on what an artifact does in relation to a building block, rather than trying to memorize every example.
The relationships are important, but they are not rigid packaging rules. A deliverable commonly contains one or more artifacts; an artifact can appear in more than one deliverable or be maintained separately. Several artifacts may describe the same building block from different angles. For example, a process flow can show the order of call-handling activities, while a use-case diagram can show interactions involving that process.
See what is contained—and what is described
The diagram below makes the distinction visible. Its gray area represents a deliverable, the Architecture Definition Document. Inside are artifacts, including process flow and use-case diagrams. The orange boxes represent building blocks described by those artifacts.
Notice the difference between contains and describes. The Architecture Definition Document contains the diagrams. The diagrams describe the call-handling process; the process is not itself a diagram tucked into the document. A building block need not be a piece of hardware or software: a business process or role can be an architectural component too.
The diagram also shows why you cannot always classify by size or by the number of items involved. Both the baseline and target call-handling processes are building blocks in the example. The document can contain multiple diagrams about them, and a single diagram may describe relationships involving more than one building block.
This connects to the previous lesson. A diagram may help present a view addressing a stakeholder concern, but “view” and “artifact” answer different questions. View emphasizes a representation of an architecture for particular concerns; artifact classifies a descriptive work product within TOGAF architecture content.
Classify the named outputs, not just their contents
Two names deserve special attention. The Architecture Definition Document is a deliverable that brings together the architecture description, including relevant artifacts for the baseline and target architectures. The Architecture Requirements Specification is also a deliverable. It sets out the architecture requirements an implementation must meet to conform to that architecture.
The fact that the second deliverable contains requirements does not turn it into a “Requirements Catalog” artifact. A Requirements Catalog is an artifact that records requirements; the Architecture Requirements Specification is the formal output that specifies requirements for implementation. Their content may be related, but their classifications differ.
The Open Group’s public white paper below provides descriptions of these named items and examples of catalogs and diagrams. It uses a TOGAF 9 example, not the 10th Edition you are studying. Use it here to verify the enduring content distinctions and names, not to infer that its templates or phase mappings are mandatory for your exam.
Framework Guidance and TOGAF™ 9 Example
Read selected entries in The Open Group’s Appendix B and the short distinction at the start of Appendix C. These provide concrete examples without requiring you to study the full catalog of templates.
In Appendix B, Table 5, on p. 26, locate the consecutive “Architecture Definition Document” and “Architecture Requirements Specification” entries. Read both descriptions, concentrating on what each formal output is for. Then, on p. 27, locate “Requirements Catalog” and read its description. On p. 28, locate “Value Chain Diagram” and read its description as another artifact example. Finally, at the beginning of Appendix C, p. 29, read the distinction. You can stop before Table 6; its phase mappings are not needed for this lesson.
Here is how the classifications work across several examples:
| Example | Classify it as | Reason |
|---|---|---|
| Architecture Definition Document | Deliverable | A formal output containing the architecture description and supporting artifacts |
| Architecture Requirements Specification | Deliverable | A formal output specifying requirements for an implementation to comply with the architecture |
| Requirements Catalog | Artifact | A structured record of requirements |
| Process Flow Diagram | Artifact | A representation of activities and their relationships |
| Value Chain Diagram | Artifact | A representation of how enterprise activities create value |
| Call-Handling Process | Building block | A business component the artifacts can describe |
A common trap is to classify something solely by its title or format. “Document” often signals a deliverable in these named TOGAF examples, but an arbitrary working document is not automatically a formal deliverable. Equally, a diagram does not become a building block because it pictures one. Ask what role the item named in the question plays, not merely what related information it contains.
Keep the boundary clear
Building blocks are the components architects identify and describe as they develop architectures and solutions. They can be specified at different levels of detail and can support reuse. A process may be described before its future operation is in place; an application component may be described in enough detail to guide a solution decision. In either case, the building block is what the architecture is composed of—not the page or picture used to communicate it.
For a compact Foundation-study rule, keep three verbs in mind: a deliverable is provided as a formal output; an artifact describes architecture; a building block is described as part of an architecture or solution. The verbs help when an example contains all three at once, as the call-handling illustration does.
Key takeaways
Architecture Definition Document and Architecture Requirements Specification are deliverables, despite their different purposes. Catalogs and diagrams are examples of artifacts that describe architecture. Processes, roles, and other architectural components can be building blocks. A deliverable can contain artifacts, and those artifacts can describe the same building blocks in different ways.
Next, you will look more closely at building blocks themselves, distinguishing an Architecture Building Block from a Solution Building Block.