TOGAF® Framework Digital Specialist Practice Tests

Explanation

The Preliminary Phase is specifically designed to prepare an organization for TOGAF adoption before any ADM cycle begins. It establishes the Architecture Capability, defines how TOGAF will be tailored to the organization's context, establishes Architecture Principles, and ensures appropriate governance structures are in place. Without completing the Preliminary Phase, there is no agreed framework, no established principles, and no governance structure to guide subsequent ADM work. Phase A marks the start of a specific ADM cycle and assumes the framework is already tailored and ready. Phase B defines business architecture, which comes after vision and scope are established. Phase H manages changes to existing architectures within an ongoing program, not initial framework setup.

Explanation

TOGAF requires every architecture principle to contain exactly four components: Name, Statement, Rationale, and Implications. The submitted principle includes a Name (API-First) and a Statement (all new digital services must expose programmatic interfaces before any user interface is developed). The Rationale is missing — this component explains why the principle is important and the business value it delivers, such as enabling ecosystem partner integrations, reducing front-end and back-end coupling, and supporting faster feature delivery. The Implications component is also absent — this documents the operational consequences of adopting the principle, including changes to development workflows, API governance tooling requirements, developer skill investments, and versioning policies. Version is not one of the four required TOGAF principle components and is not part of the standard structure. Without Rationale and Implications, architects and project teams lack the context needed to apply the principle consistently across the enterprise.

Explanation

An Architecture Building Block (ABB) is a logical, vendor-neutral component that describes what is needed — its capabilities, purpose, interfaces, dependencies, and non-functional requirements such as performance and resilience — without specifying a particular product or vendor. ABBs are created during Phases B, C, and D and are reusable across multiple solution contexts. A Solution Building Block (SBB) is the concrete, vendor-specific implementation that answers how a capability is built — for example, specifying Okta or Microsoft Entra ID as the chosen implementation of the Customer Identity Management ABB. A Technology Reference Model Component is part of the broader TOGAF reference model structure but is not the specific term for a vendor-neutral logical component created during Phase C. Foundation Architecture Assets are part of the Enterprise Continuum representing the most generic reusable reference architectures, not component-level specifications within a specific ADM engagement.

Explanation

The three primary deliverables of the TOGAF ADM Requirements Management process are the Requirements Impact Assessment, which evaluates how new or changed requirements affect the current and planned architecture; the Updated Architecture Requirements Specification, which is the revised documentation of what the architecture must satisfy; and the Updated Requirements Repository, the master store of all captured requirements maintained continuously across every phase. Requirements Management is positioned at the center of the ADM wheel because it operates continuously across all phases rather than belonging to any single sequential step. The Architecture Compliance Report is a Phase G deliverable used to assess implementation conformance. The Stakeholder Management Plan is produced in Phase A. The Architecture Vision Document is the primary output of Phase A, not of Requirements Management.

Explanation

The three primary deliverables of the Requirements Management process in TOGAF are the Requirements Impact Assessment, the Updated Architecture Requirements Specification, and the Updated Requirements Repository. The Requirements Impact Assessment documents how proposed changes or new inputs affect existing architecture requirements and current architecture work. The Updated Architecture Requirements Specification reflects the current agreed-upon set of architecture requirements, revised as new information emerges throughout ADM phases. The Updated Requirements Repository captures all requirements across the ADM cycle and maintains traceability between requirements and architecture artifacts. The Architecture Vision Statement is a deliverable of Phase A. The Architecture Definition Document is produced across Phases B through D. The Architecture Roadmap is primarily a Phase E deliverable identifying transition architectures and project sequencing.