Deliverable Descriptions Knowledge-Based Study

Study notes

1. Role of Deliverables in the TOGAF Standard

   In the TOGAF Standard, a deliverable is defined as an architectural work product that is contractually specified, formally reviewed, agreed upon, and signed off by stakeholders. Deliverables represent the formal output of an Architecture Development Method (ADM) phase or cycle.

   It is essential to distinguish deliverables from other architecture work products:

   • Deliverables: Typically contain multiple artifacts and represent formal milestones across the ADM.
   • Artifacts: Architectural work products that describe an aspect of the architecture, categorized into catalogs (lists), matrices (relationships), and diagrams (pictures).
   • Building Blocks: Reusable components of business, IT, or architectural capability. Architecture Building Blocks (ABBs) define required capability and shape specifications, whereas Solution Building Blocks (SBBs) represent concrete implementations and physical components.

   Preliminary Phase and Phase A Deliverables

   The initiation of architectural activity establishes governance frameworks, organizational scope, and executive sponsorship through distinct deliverables:

   • Organizational Model for Enterprise Architecture: Produced in the Preliminary Phase, this document outlines the structure, governance bodies, roles, responsibilities, and resource requirements needed to operate an enterprise architecture practice.
   • Tailored Architecture Framework: The customized version of the TOGAF framework adapted to meet the specific culture, constraints, and methodologies of the organization.
   • Request for Architecture Work: The business-driven trigger sent from the sponsoring organization to initiate an architecture engagement. It defines business context, current constraints, and target strategic objectives.
   • Statement of Architecture Work: The approved contractual agreement between the architecture team and executive sponsors defining scope, schedule, deliverables, acceptance criteria, and governance controls for an ADM cycle.
   • Architecture Vision: The early summary deliverable developed in Phase A providing a high-level description of baseline and target states, value proposition, and stakeholder buy-in.

   Documenting Architecture and Requirements

   Phases B, C, and D generate detailed descriptions of the baseline and target states across Business, Data, Application, and Technology domains, accompanied by explicit measurable requirements:

   • Architecture Definition Document (ADD): The primary repository of architectural models and decisions. It contains baseline architectures, target architectures, alternative options considered, and gap analyses across all four architecture domains.
   • Architecture Requirements Specification: Captures the qualitative and quantitative criteria that the architecture must satisfy, including functional requirements, non-functional requirements (e.g., performance, security, availability), and compliance criteria.
   • Architecture Principles: Qualitative statements of operational and architectural posture that guide architectural decision-making and provide foundational design constraints.
   • Capability Assessment: An evaluation of the baseline capabilities of the enterprise, identifying gaps in organizational execution capability, maturity, and business readiness for transformation.

   Realization, Compliance, and Lifecycle Governance

   Phases E through H focus on scheduling implementation projects, overseeing solution compliance, and managing post-deployment change:

   • Architecture Roadmap: Presents a chronological transition strategy consisting of transition architectures, project increments, dependencies, and business value milestones spanning from Phase E onward.
   • Implementation and Migration Plan: Developed in Phase F, this operational plan provides the detailed schedule, cost estimates, work packages, resource allocations, and dependencies for executing projects.
   • Architecture Contract: A formal agreement between architecture governance and implementation partners that specifies technical baseline constraints, acceptance thresholds, and compliance expectations.
   • Compliance Assessment: A governance review artifact evaluating whether an implemented solution complies with the governing architecture contracts and Target Architecture specifications.
   • Change Request: Formally submits proposed modifications to an active architecture baseline, evaluated in Phase H to determine if incremental, radical, or re-architecting action is warranted.