Introduction Knowledge-Based Study

Study notes

1. What is an Architecture Deliverable?

   In the TOGAF Standard, an architecture deliverable represents a work product that is contractually specified, formally reviewed, agreed upon, and signed off by stakeholders.

   Deliverables are typically the tangible outputs produced at defined milestones across the phases of the Architecture Development Method (ADM). Because they carry formal governance weight, they usually represent the agreed state of an enterprise architecture initiative at a specific decision point.

   • Contractual status: Deliverables represent commitments between architecture teams and business sponsors or project stakeholders.
   • Formal governance: Each deliverable undergoes formal review, approval, and version control.
   • Scope and packaging: A single deliverable typically packages one or more architecture artifacts to document decisions, designs, and roadmaps.

   Core Conceptual Distinctions

   To apply the TOGAF Architecture Content Framework effectively, architects must clearly distinguish among deliverables, artifacts, and building blocks:

   • Deliverable: A formally reviewed, agreed, and signed-off output of an ADM cycle or phase. Deliverables provide the mechanism to archive or hand over architectural outputs.
   • Artifact: A specific architectural work product that describes an aspect of the architecture. Artifacts are broken down into three categories: catalogs (lists of things), matrices (relationships between things), and diagrams (graphical depictions of things). Artifacts are typically contained within deliverables.
   • Building Block: A component of business, IT, or architectural capability that can be combined with other building blocks to deliver architectures and solutions. These include Architecture Building Blocks (ABBs) and Solution Building Blocks (SBBs).

   In summary, building blocks represent reusable capabilities, artifacts represent views and documentation of those capabilities, and deliverables package artifacts into formally governed containers.

   Lifecycle and Governance of Deliverables

   Deliverables evolve throughout the execution of the ADM cycle. The TOGAF Standard organizes deliverables to support governance, stakeholder communication, and implementation oversight:

   • Preliminary and Scoping Deliverables: Define how the architecture practice operates, captured in outputs such as the Architecture Framework and the approved Statement of Architecture Work.
   • Strategic and Detailed Architecture Deliverables: Articulate the baseline, target, and gap analysis across architecture domains, packaged within the Architecture Definition Document and supported by the Architecture Requirements Specification.
   • Planning and Transition Deliverables: Formulate implementation sequencing, investment schedules, and transition steps, documented in the Architecture Roadmap and Implementation and Migration Plan.
   • Governance and Compliance Deliverables: Ensure adherence during solution deployment, represented by Architecture Contracts and Compliance Assessments.

   Deliverables act as transition milestones between planning and realization, ensuring that all parties maintain architectural alignment.

   Summary of Principles

   When producing architecture deliverables in alignment with the TOGAF Standard, 10th Edition, keep these core principles in mind:

   1. Fit for Purpose: Deliverables must be tailored to address specific stakeholder concerns and business needs rather than produced as exhaustive, bureaucratic paperwork.
   2. Modular Composition: Deliverables are composed of modular artifacts (catalogs, matrices, and diagrams) that can be maintained and updated independently.
   3. Traceability: Architecture deliverables maintain explicit traceability from overarching business drivers and goals down to technical requirements and implementation tasks.
   4. Governed Accountability: Unlike informal working drafts, deliverables hold formal status, requiring approval by identified decision-makers.