Mastering TOGAF Deliverables: The Governed Package Explained

In the complex world of Enterprise Architecture, clarity is currency. One of the most critical concepts to master is the distinction between a deliverable and the various artifacts that populate it. According to the TOGAF® standard, a deliverable is a formally specified work product that is reviewed, agreed upon, and typically approved by stakeholders or a governance body. It serves as the tangible output of your architectural labor, ensuring that your work meets specific business needs and regulatory obligations.

This tutorial will deconstruct the anatomy of a TOGAF deliverable, explain why they are created, and detail how they are controlled. We will specifically focus on the Architecture Definition Document as the primary example of a governed package.

1. Defining the Core Concept

A deliverable is not just a document sitting in a folder; it is a formal + governed work product. It represents a milestone of trust and verification. For a work product to be classified as a deliverable, it must satisfy three fundamental criteria:

• Reviewed and Agreed: It must be scrutinized by peers and stakeholders.
• Approved: It must receive formal sign-off from a governance body or decision-maker.
• Controlled: It must be managed through the organization’s architecture governance process.

When these criteria are met, the work product becomes a “governed package.” This is the unit of work that provides assurance to the business that the architecture is sound and ready for implementation.

2. Why Do We Create Deliverables?

Deliverables are not created in a vacuum. They are the response to specific triggers and requirements within an organization. Understanding the “why” behind a deliverable helps architects prioritize their efforts. Deliverables are typically created to satisfy:

1. Project Requirements: Specific needs identified during the initiation of a new project.
2. Statement of Work (SOW): Formal contractual agreements outlining expected outputs.
3. Governance Checkpoints: Mandatory reviews required to proceed to the next phase of development.
4. Regulatory or Compliance Obligations: Ensuring the architecture adheres to legal or industry standards.
5. Decision-Making Needs: Providing the data necessary for stakeholders to make high-level strategic choices.
6. Transition or Implementation Milestones: Marking progress in the journey from current state to target state.

3. Anatomy of a Deliverable: The Architecture Definition Document

The Architecture Definition Document (ADD) is perhaps the most common and comprehensive example of a TOGAF deliverable. However, it is crucial to understand that a deliverable is not a single file; it is a governed package.

The ADD acts as a container that aggregates various views of the architecture. A well-structured ADD typically includes:

• Architecture Principles: The guiding rules that define the organization’s stance.
• Baseline & Target Descriptions: A clear picture of where the organization is now versus where it needs to be.
• Business, Data, Application, and Technology Views: The four core domains of the Enterprise Architecture.
• Gap Analysis: The identification of the differences between the baseline and the target.
• Constraints: Limitations imposed by the environment or regulations.
• Risks and Assumptions: An honest assessment of potential pitfalls and underlying beliefs.
• Architecture Decisions: A log of critical choices made during the design process.
• Dependencies: How different parts of the architecture rely on one another.
• Traceability to Requirements: Proof that the architecture solves the stated business problems.

4. Control Attributes: Managing the Package

Because a deliverable is a governed package, it requires strict control attributes to ensure its integrity over time. Every deliverable should be managed with the following metadata:

• Owner: The individual responsible for the content.
• Audience: Who is expected to read and use this document?
• Review Date: When is the next scheduled review?
• Approval Authority: Who has the power to sign off on this work?
• Version Number: Tracking changes and iterations.
• Status: Is it Draft, Under Review, or Approved?
• ADM Phase/Governance Gate Relationship: Linking the document to the specific stage of the Architecture Development Method.
• Repository Location: Where the asset is stored within the Architecture Repository.

5. Deliverable vs. Artifact: The Crucial Distinction

A common point of confusion is the difference between a deliverable and an artifact. The image and the TOGAF standard clarify this relationship:

• Deliverable: The governed package (e.g., the Architecture Definition Document).
• Artifact: The individual diagrams, catalogs, matrices, models, or decision records contained inside the package.

Think of the deliverable as the folder that has been stamped “Approved.” The artifacts are the contents of that folder. While the artifacts provide the visual and data evidence, the deliverable is the formal entity that stakeholders interact with for approval.

Conclusion

Understanding the nuance of TOGAF deliverables is essential for any architect aiming to deliver value. By treating your work products as governed packages rather than loose collections of documents, you ensure that your architecture is robust, traceable, and approved. To facilitate this process effectively, it is recommended to utilize specialized tooling such as the Visual Paradigm TOGAF ADM Tool. This tool helps architects automate the creation of these governed packages, manage versioning, and maintain the strict traceability required between artifacts and the final deliverable.