In the rigorous world of Enterprise Architecture (EA), specifically within frameworks like TOGAF, the terminology surrounding documentation can be confusing. Architects often struggle to categorize their work: Is this specific diagram a deliverable, an artifact, or a building block? Getting this classification right is not merely about semantics; it dictates the governance process, the level of effort required, and how the asset is reused.
This tutorial breaks down the decision-making process for classifying these architectural assets, using the visual logic provided in the architecture governance model.
The Core Decision: The “Formal Submission” Test
The most effective way to categorize an architectural item is to apply a single, binary filter. This filter serves as the primary decision point in your architecture governance workflow. Before assigning a specific role or label to a document or model, you must ask:
Is it formally submitted for approval?
This question acts as the gatekeeper. The answer determines whether the item is a high-stakes contractual agreement (a Deliverable) or a working asset (an Artifact or Building Block).
Scenario A: The Answer is “YES”
If the item has been formally submitted to a governing body (such as an Architecture Review Board) for a formal decision, it is classified as a Deliverable.
- Definition: A Deliverable is a formally submitted item intended for official approval. It represents a commitment to a specific standard or scope.
- Key Characteristic: It is the output of a specific architecture phase that is “signed off” upon.
- Implication: Because it is a Deliverable, it requires strict version control, formal documentation, and a clear approval signature.
Scenario B: The Answer is “NO”
If the item is being created for internal use, analysis, or planning, but has not yet been formally submitted for an official decision, it falls into the Artifact or Building Block category.
- Assessment Required: If the answer is “No,” you must assess its purpose further. Is it a tool used to create the deliverable? Or is it a reusable component?
- Flexibility: These items generally do not require the same level of governance overhead as deliverables, though they must still be high quality.
Deep Dive: The Deliverable
When an item passes the “YES” test, it becomes a Deliverable. In the context of TOGAF, these are the critical milestones of your project. The visual model identifies three specific examples of common Deliverables:
- Architecture Definition Document (ADD): This is often the primary output of a major architecture phase. It describes the current and target architectures and the transition plan. It is submitted for approval to ensure stakeholders agree on the direction.
- Architecture Contract: This is a formal agreement between the architecture function and the organization (or project team) being served. It outlines the scope, responsibilities, and deliverables. It is a legalistic or formal agreement, making it a quintessential Deliverable.
- Compliance Review: This document assesses whether a system or project complies with the established architecture standards. Submitting this review for approval validates that the project is on track.
Deep Dive: Artifact vs. Building Block
When the answer to the formal submission question is “NO,” you must distinguish between the tools you use to build the architecture and the components you are designing.
1. The Artifact
An Artifact is a piece of work that supports the architecture but is not necessarily a standalone product to be approved. For example, a rough sketch of a process flow, a brainstorming session whiteboard, or a preliminary data model used to derive the final ADD is an Artifact. It is the raw material of the architecture.
2. The Building Block
A Building Block is a reusable component that has been identified as a candidate for implementation. While it is an “asset” of the architecture, until it is formally packaged and submitted for approval as part of a solution, it remains a Building Block. It is the functional unit (e.g., a specific software module, a cloud service, or a business capability) that will eventually be constructed.
Conclusion: Managing the Lifecycle of Your Assets
Understanding the distinction between these three concepts is vital for maintaining a clean and manageable architecture repository. By applying the “Formal Submission” filter, you ensure that governance resources are focused on the items that truly matter (Deliverables) while maintaining a flexible workspace for the creative and iterative parts of the job (Artifacts and Building Blocks).
To effectively manage this lifecycle, particularly when dealing with complex TOGAF ADM cycles, it is highly recommended to utilize specialized tooling. A powerful tool for this purpose is Visual Paradigm TOGAF ADM Tool. This software automates the linking of artifacts to deliverables, tracks the approval status of your architecture documents, and ensures that your Building Blocks are properly cataloged and ready for implementation.
