TOGAF® Enterprise Architecture Leader Practice Tests

Explanation

Business Transformation Readiness Assessment is the TOGAF ADM technique specifically designed to evaluate an organization's readiness and willingness to undergo architectural transformation. Applied during Phase A and referenced in Phase E, it identifies and assesses readiness factors — including leadership commitment, organizational change capacity, financial readiness, cultural alignment, and IT governance maturity — that will determine whether the transformation can succeed. Its primary output is a readiness factor assessment that rates each factor and, for those rated below an acceptable threshold, produces identified risks and mitigation actions to be incorporated into architecture planning and the Statement of Architecture Work. Business Scenarios is a technique for capturing and structuring business requirements in response to a business problem; it produces a scenario card and informs architecture requirements but does not assess organizational readiness to change. Gap Analysis is performed in Phases B, C, and D to compare baseline and target architecture states — it is not a Phase A tool and does not measure transformation readiness. Capability Assessment evaluates the EA team's own capability for running architecture programs, not the enterprise's capacity to absorb a specific transformation initiative.

Explanation

The TOGAF Standard, 10th Edition organizes its Fundamental Content into six core, stable documents. ADM Techniques is the dedicated document covering the portfolio of practical techniques and tools that support ADM phase execution — including stakeholder management, business scenarios, gap analysis, risk identification, the Business Transformation Readiness Assessment, and other analytical methods. Introduction and Core Concepts covers foundational definitions and framework orientation. Applying the ADM provides guidance on configuring and tailoring the ADM to different organizational contexts, delivery styles, and industry sectors — it addresses how to adapt the method, not which tools to use within phases. Enterprise Architecture Capability and Governance covers the organizational model, roles, skills, and governance structures required to operate an EA practice. EA Leaders must understand this document structure precisely so they can direct their teams to the authoritative source for each category of guidance.

Explanation

Level 2 iteration — also called across-phase or vertical iteration — is the correct approach when work in a later ADM phase reveals the need to revise deliverables in an earlier phase within the same ADM cycle. This is precisely its design purpose: rather than abandoning the current cycle or waiting for the next cycle, the team returns to Phase B, updates the affected business architecture artifacts to reflect the technology constraints, and then proceeds forward through the architecture development phases again before continuing to Phase E. Level 1 (Horizontal) iteration addresses architecture maturity over time by cycling through complete ADM passes in successive runs — it is not appropriate when an immediate revision is needed before the current cycle can proceed. Level 3 (Within-Phase) iteration elaborates detail within a single phase across multiple passes and does not address the cross-phase dependency between technology decisions and business architecture content. Restarting from the Preliminary Phase would be appropriate only if the fundamental EA governance capability or organizational context itself required revision, not when cross-phase architecture content needs refinement.

Explanation

Requirements Management is the central, continuous process of the TOGAF ADM that operates throughout all phases. When new or changed requirements emerge mid-cycle, the correct first actions are to log and baseline the requirements in the Requirements Repository to create a formal documented record of the change, and then conduct a Requirements Impact Assessment to systematically determine how these requirements affect current and previously completed ADM phases. The Requirements Impact Assessment is a critical sub-process of Requirements Management. It identifies which phases are affected, whether architecture work already completed must be revisited or refined, and what level of rework or re-scoping is necessary. This evidence-based assessment is the foundation for any subsequent governance decisions or change requests. Abandoning the current cycle and restarting from Phase A is disproportionate and wasteful — Requirements Management exists precisely to handle mid-cycle changes without discarding completed work. Deferring mandatory regulatory requirements to a separate future cycle creates compliance risk and conflicts with governance responsibilities when those requirements directly impact active architecture work. Submitting a Change Request to the Architecture Board may be an appropriate downstream step, but the EA Leader cannot make a credible governance submission without first completing the impact assessment. Acting without the assessment would result in a Change Request that lacks the technical rigor the Architecture Board requires to make an informed governance decision.

Explanation

The TOGAF Standard defines three recognized levels of ADM iteration. Horizontal iteration involves cycling through all ADM phases repeatedly over time as the architecture evolves, with each pass deepening and extending the architecture content. This is the macro-level iteration that reflects how architecture matures across multiple cycles. Vertical iteration involves moving between phases in a non-sequential direction, for example returning from a later phase such as Technology Architecture back to Business Architecture when technical findings surface new business implications or constraints requiring refinement. Within-phase iteration involves making multiple passes within a single phase to progressively elaborate detail, moving from high-level outlines to increasingly specific architecture descriptions without yet transitioning to the next phase. Cross-enterprise iteration, governance-only iteration, and requirements-only iteration are not defined iteration levels within the TOGAF ADM iteration model.