ScenarioCert
TOGAF 10 ยท Library, techniques, landscape and content framework (20-20%)

Using architecture levels to organize the Architecture Landscape

Practice questions and explanations for the "Using architecture levels to organize the Architecture Landscape" objective of the TOGAF Enterprise Architecture Practitioner (scenario questions) exam. Skills measured as of 2026-10-22.

Skills in this objective

  • Partitioning the Architecture Landscape into Strategic, Segment, and Capability architectures
  • Using the Enterprise Continuum and the Architecture Repository

Test yourself on this domain

Take the free 15-question test, or unlock all 150 questions and practice this domain on its own.

Sample questions

4 of the 9 questions we have for this objective, shown with the answer and the reasoning.

Using architecture levels to organize the Architecture Landscape

Larkspur Insurance's subsidiary in Canada has developed a claims-handling architecture that the group's two other subsidiaries also need. The group architect is starting Phase B for one of those subsidiaries and wants to accelerate the work while avoiding the mistake of copying another subsidiary's architecture without assessing fit.

How should the group architect use the Enterprise Continuum and the Architecture Repository?

  1. ABegin with the Foundation Architecture and specialize it step by step to a new Organization-Specific Architecture, ignoring existing subsidiary work to avoid bias.Starting from the most generic level and ignoring a closely related existing architecture throws away the reuse the Enterprise Continuum is designed to enable.
  2. BAdopt the Canadian architecture unchanged as the Target Architecture, because it is already approved.Approval for one subsidiary does not establish fit for another; reuse still requires assessing the asset against the new scope, requirements and constraints.
  3. CStore the Canadian architecture in the Solutions Landscape so that the subsidiary can deploy the same products.The Solutions Landscape holds solution-level deployments; placing an architecture there confuses architecture and solutions and skips Phase B assessment.
  4. DSearch the Architecture Repository for applicable assets, starting with the most specific, assess the Canadian architecture against the subsidiary's requirements, adapt it, and generalize the common parts into a reusable asset for the group.The Enterprise Continuum supports reuse by classifying assets by generality; the architect reuses the most specific relevant asset after assessing fit and contributes common elements back for other subsidiaries.
Why: The TOGAF Standard describes the Enterprise Continuum (TOGAF Standard, Introduction and Core Concepts, Enterprise Continuum and Architecture Repository) as a way to classify architecture and solution assets from generic to organization-specific so they can be found and reused, and the Architecture Repository as where they are stored. In Phases B to D, architects look for relevant existing assets, prefer the most specific applicable one, assess and adapt it to the current requirements, and feed improvements or generalized content back into the repository. The scenario explicitly warns against copying without assessment, while ignoring the existing asset would waste it. The deciding idea is reuse with assessment and contribution back.
Using architecture levels to organize the Architecture Landscape

At Calder Group, a central enterprise architecture team and the payments division team are each developing target architectures that cover payment processing. Their targets conflict on interfaces and timelines, and both claim authority over the same building blocks. The Architecture Board asks the lead architect to restructure the Architecture Landscape so the conflict does not recur, while still allowing both teams to work in parallel.

What should the lead architect recommend?

  1. ADefine architecture partitions with distinct scope by subject matter, level of detail and time period, assign each partition an owner, and require the payments Segment Architecture to conform to the enterprise Strategic Architecture.Partitioning gives each architecture a clear, non-overlapping scope and owner, and the hierarchy of levels ensures more detailed architectures conform to the broader ones, so teams can work in parallel without conflict.
  2. BMerge both efforts into a single enterprise-wide architecture owned by the central team.A single monolithic architecture removes the conflict but sacrifices the parallel working the board wants and is hard to keep current at enterprise scale.
  3. CLet each team keep its own target and reconcile differences through compliance reviews in Phase G.Deferring reconciliation to implementation governance lets conflicting targets drive projects; the conflict should be prevented in how the landscape is partitioned.
  4. DPartition the landscape only by time, assigning the central team the baseline and the payments team the target.Time is one partitioning characteristic, but splitting baseline and target between teams does not resolve overlapping subject-matter scope and adds hand-off risk.
Why: The TOGAF Standard guidance on partitioning the Architecture Landscape (TOGAF Standard, Applying the ADM Across the Architecture Landscape, and Architecture Partitioning) explains that a large enterprise cannot be described by one architecture, so the landscape is divided into partitions characterized by subject matter (breadth), viewpoint, level of detail (depth), time and maturity or volatility. Each partition should have a clear scope and owner, and architectures at the Segment and Capability levels must be consistent with the Strategic Architecture above them. The Architecture Content Framework and the Enterprise Continuum are then used to integrate the partitions. The deciding constraints are overlapping scope and the need for parallel work, which only clear partitions with ownership and conformance resolve.
Using architecture levels to organize the Architecture Landscape

The Architecture Board at Glenhurst University has approved an API design standard, including versioning and authentication rules, that every new integration must follow. Project architects must check their designs against it during Architecture Compliance reviews. The repository manager asks where the approved standard should be stored.

Where in the Architecture Repository should the approved standard be stored?

  1. AIn the Standards LibraryThe Standards Library holds the standards, such as legal, industry and organizational standards, with which new architectures and deployed services must comply.
  2. BIn the Reference LibraryThe Reference Library holds guidelines, templates, patterns and reference models used to accelerate work; mandatory standards belong in the Standards Library.
  3. CIn the Governance LogThe Governance Log records decisions, compliance assessments and dispensations; it would hold the approval decision and the review outcomes, not the standard itself.
  4. DIn the Architecture Requirements RepositoryThe Architecture Requirements Repository holds requirements agreed for specific architectures, not enterprise-wide standards that apply to all projects.
Why: The TOGAF Standard (TOGAF Standard, Architecture Repository) separates the repository into areas with different purposes. The Standards Library captures the standards with which architectures must comply; the Reference Library holds reusable guidance; the Governance Log records governance activity; and the Architecture Requirements Repository holds requirements. Because the API rules are mandatory and are checked in compliance reviews, they are a standard. The board's approval decision and later compliance results would be recorded in the Governance Log, which is why that distractor is tempting.
Using architecture levels to organize the Architecture Landscape

Brennick Health Group is setting up its Architecture Landscape with a Strategic Architecture for the group, Segment Architectures for hospitals and community care, and Capability Architectures for individual projects. New architects are confused about how the levels relate to each other and to the ADM, and the Head of Architecture is writing guidance for them.

Which two statements should the guidance include? Each correct answer presents a complete statement.

  1. AThe ADM can be applied at each level, and the architecture at a higher level provides direction and constraints for work at the levels below it.The TOGAF Standard describes iterating the ADM at different levels, with higher-level architectures setting context, direction and constraints for more detailed ones.
  2. BA Strategic Architecture typically covers a longer time horizon and has less detail than a Capability Architecture.Strategic Architecture gives a long-term, summary view across the enterprise, while Capability Architecture is detailed and focused on delivering a specific increment in a shorter period.
  3. CCapability Architectures must all be completed before work on the Strategic Architecture can start.Direction flows from the Strategic level downward; waiting for all project-level detail would leave projects without strategic direction.
  4. DEach architecture level requires its own separate Architecture Repository.The levels organize content within one Architecture Landscape; a single repository holds architectures at all levels and links them.
  5. ESegment Architectures are limited to the Technology Architecture domain.A Segment Architecture can cover all architecture domains for its area of the enterprise; levels describe breadth and depth, not domain.
Why: The TOGAF Standard (Applying the ADM, Applying Iteration to the ADM and Applying the ADM Across the Architecture Landscape) describes how the Architecture Landscape is organized into Strategic, Segment and Capability Architectures that differ in breadth, depth and time horizon. The ADM can be run at each level, and higher-level architectures provide the direction and constraints that more detailed architectures must conform to. All levels live in the same Architecture Landscape in the Architecture Repository, and each level can span the business, data, application and technology domains. The distractors invert the direction of governance or confuse levels with repositories or domains.

Written from the public documentation. Not affiliated with The Open Group. Official study guide.