In the rigorous world of enterprise architecture, a document is rarely just a document. Within the TOGAF framework, a deliverable serves as the tangible output of architectural work, acting as the bridge between abstract concepts and concrete business value. However, for a deliverable to be effective, it must be more than just a PDF file sitting on a shared drive. It must be a well-managed work product.
This tutorial explores the five critical characteristics that define a professional TOGAF deliverable. By understanding Formal Status, Defined Accountability, Stakeholder Agreement, Traceability, and Repository Management, you can ensure your architecture is not only created but also governed, reused, and trusted.
1. Formal Status: The Lifecycle of a Deliverable
The first characteristic of a well-managed deliverable is that it possesses a defined state. This is not merely a label; it represents the lifecycle stage of the architecture artifact. Understanding these states is crucial for managing expectations and workflow.
- Draft: The initial state where content is being assembled but has not yet been subjected to formal scrutiny.
- In Review: The deliverable has reached a point where it is ready for feedback and validation from relevant parties.
- Approved: The gold standard. The deliverable has been validated, signed off, and is now the authoritative source of truth for that specific architectural decision.
- Rejected / Superseded / Archived: Crucial for maintaining a clean repository. A rejected item is discarded; a superseded item is replaced by a newer version; an archived item is preserved for historical context but is no longer active.
2. Defined Accountability: Who Owns the Work?
Architecture cannot be a collective responsibility where “everyone” is responsible. To ensure quality and continuity, a well-managed deliverable must have defined accountability. Someone must be explicitly responsible for creating, maintaining, and updating the artifact.
Depending on the complexity of the architecture, this role is typically assigned to:
- Enterprise Architect: Oversees high-level strategy and alignment.
- Domain Architect: Focuses on a specific business or technology domain.
- Solution Architect: Designs specific solutions to business problems.
- Architecture Team: A collective unit responsible for a body of work.
- Project Manager: Often accountable for deliverables tied to specific project milestones.
- Architecture Governance Board: In some structures, the board itself holds accountability for the integrity of the architecture.
3. Stakeholder Agreement: The Power of Validation
Creating a diagram is one thing; having it accepted is another. A deliverable gains its power through Stakeholder Agreement. This characteristic ensures that the deliverable is reviewed by the people who have the authority over the decisions involved.
This review process is vital because it validates that the architecture addresses real needs. The stakeholders who must agree to a deliverable often include:
- Business & Product Owners: Ensuring the solution delivers value.
- Information Security & Data Governance: Ensuring compliance and safety.
- Technology Leadership: Ensuring technical feasibility and standards.
- Portfolio Management: Ensuring alignment with investment strategy.
- Architecture Review Board (ARB): The formal body that governs architectural decisions.
4. Traceability: Connecting the Dots
Isolating a deliverable is a recipe for failure. A well-managed deliverable must demonstrate Traceability. It acts as a link in a chain, connecting the technical work to the broader business context. This ensures that every diagram and document has a “why” behind it.
A traceable deliverable should explicitly connect to:
- Business Drivers: The strategic goals motivating the work.
- Stakeholder Concerns: The specific questions or risks stakeholders want addressed.
- Requirements: The functional and non-functional constraints.
- Architecture Principles: The rules guiding the design.
- Decisions & Risks: The choices made and the potential pitfalls identified.
- Work Packages & Implementation Projects: The actual execution plans.
- Governance Outcomes: The results of the review process.
5. Repository Management: The Single Source of Truth
The final characteristic is Repository Management. Approved deliverables must be stored where they can be found, reused, and governed. If a deliverable is not stored in a central location, it cannot be part of the enterprise knowledge base.
The Architecture Repository is the mechanism that provides the broader structure for this information. It ensures that:
- Deliverables are version-controlled.
- Old versions are archived while current versions are highlighted.
- Searchability allows architects to find existing solutions before reinventing the wheel.
Recommended Tooling for TOGAF ADM
To effectively manage these five characteristics within the TOGAF Architecture Development Method (ADM), you require robust tooling that automates the governance process. A highly recommended solution for this purpose is the Visual Paradigm TOGAF ADM Tool.
This tooling supports the entire lifecycle described above: it allows you to assign accountability to specific roles, manage formal status through workflow states, facilitate stakeholder agreements via review features, maintain traceability between requirements and models, and store everything in a central repository for governance.
By integrating these characteristics into your workflow, you move beyond simple documentation to creating a dynamic, accountable, and traceable architecture practice.
