Free OGEA-10B Practice Test

Phase A: Architecture Vision is the initial phase of the Architecture Development Method (ADM) cycle. Its primary objectives are to establish the architecture project, define its scope, identify key stakeholders, and understand their concerns and business objectives. This phase culminates in the creation of an Architecture Vision document, which articulates the problem to be solved and provides a high-level aspirational view of the target architecture, ensuring it aligns with stakeholder requirements.

A. "Phase" is not a specific, valid name for any phase within the TOGAF ADM cycle.
B. The Preliminary Phase focuses on establishing the Architecture Capability within the organization, not on defining the scope and requirements for a specific architecture project.
C. "Phase" is not a specific, valid name for any phase within the TOGAF ADM cycle.

1. The Open Group, TOGAF® Standard, 10th Edition, The ADM. Chapter 5, "Phase A: Architecture Vision". Section 5.2, "Objectives", states the objectives are to "Develop a high-level aspirational vision of the capabilities and business value..." and "Identify key stakeholders, their concerns, and business requirements".

2. The Open Group, TOGAF® Standard, 10th Edition, The ADM. Chapter 4, "Preliminary Phase". This chapter describes the focus on preparing the organization for architecture work, such as defining principles and tailoring the framework.

Option C provides the most comprehensive TOGAF-aligned approach. It correctly uses an Implementation Factor Catalog to capture actions and constraints (critical for healthcare compliance), creates a Consolidated Gaps, Solutions and Dependencies Matrix, classifies solutions appropriately, groups similar activities into work packages, and explicitly factors in clinical trial schedules when identifying dependencies. Most importantly, it regroups work packages into Capability Increments scheduled through a series of Transition Architectures, which directly supports the incremental rollout requirement while minimizing disruption.

Option A: Starts with Solution Building Blocks rather than gaps analysis; uses incorrect terminology (Transition Architecture State Evolution Table).
Option B: Uses non-standard terminology (Architecture Definition Increments Table); lacks explicit dependency analysis between work packages.
Option D: Uses CRUD matrix inappropriately for grouping Solution Building Blocks; focuses on cost-effectiveness rather than minimizing disruption to trials.

1. TOGAF 9.2, Part IV: Architecture Content Framework, Chapter 36.2.8 "Implementation Factor Catalog" - describes capturing actions, issues and constraints

2. TOGAF 9.2, Part III: ADM Guidelines, Chapter 27.2 "Consolidated Gaps, Solutions, and Dependencies Matrix" - standard technique for gap analysis

3. TOGAF 9.2, Part II: Architecture Development Method, Chapter 13.3.1 "Transition Architectures" - defines incremental implementation approach

4. TOGAF 9.2, Part IV: Architecture Content Framework, Chapter 36.2.22 "Work Package" - defines grouping of activities for implementation

5. TOGAF 9.2, Part II: Architecture Development Method, Chapter 13.2.4 "Capability-Based Planning" - describes organizing work into capability increments

In Phase B the architect must define business-level security and privacy controls for data exchanged with multiple parties. TOGAF’s “Information Security Architecture” guide recommends (a) grouping assets with common sensitivity into Security Domains governed by a single policy, (b) creating a Security Federation when several organizations share data, clarifying contractual obligations and accountability, and (c) performing a risk assessment for each information asset. Option D applies all three recommendations, directly addressing stakeholder concerns over V2X privacy, cross-border data exchange, and partner responsibilities.

A – Limits attention to certificates and legal monitoring; does not provide a complete risk or domain model for shared data. B – Produces a qualitative risk list but omits federation governance and concrete security-domain policies required for multi-party sharing. C – Addresses data quality and classification only; ignores inter-organizational security governance and V2X privacy-risk treatment.

1. The TOGAF® Series Guide: “Information Security Architecture”, sec. 3.2 “Security Domains” & sec. 4.4 “Federated Security” (2019 edition).

2. The TOGAF® Standard, 10th Ed., ADM Phase B guideline: “Identify security and privacy requirements for business services” (Part II, sec. 19.2 step 7).

3. ISO/IEC 27005:2018 (referenced by TOGAF), sec. 8—Risk Assessment process for information assets.

4. The TOGAF® Standard, 10th Ed., Risk Management Technique (Part III, sec. 38.6).

When scoping an architecture engagement, the TOGAF framework recommends defining four key dimensions to establish clear boundaries. These are:
1. Breadth: The parts of the enterprise to be covered (e.g., specific business units, geographies).
2. Depth: The level of detail to which the architecture will be developed.
3. Time Period: The timeframe the architecture will address, including the number and duration of any intermediate Transition Architectures.
4. Architecture Domains: The specific domains to be included (Business, Data, Application, Technology). These dimensions ensure the scope is well-understood by all stakeholders before the work begins.

A. These are the architecture domains, which represent only one of the four scoping dimensions, not all four.
B. These are important business considerations but are not the formal dimensions used for scoping the architecture effort itself.
D. These terms relate to strategic planning and delivery lifecycles, not the specific dimensions for scoping an architecture.

- The TOGAF® Standard, 10th Edition, Part II: ADM, Chapter 2, "Applying the ADM", Section 2.3, "Scoping the Architecture". This section explicitly lists the four dimensions as Breadth, Depth, Time Period, and Architecture Domains.

- The TOGAF® Standard, 10th Edition, Part II: ADM, Chapter 5, "Phase A: Architecture Vision", Section 5.4.3, "Determine Scope".

The illustration shows the TOGAF Enterprise Continuum, which is a model for classifying architecture and solution artifacts. Item A represents the overall Enterprise Continuum itself, which provides the context for classification. Item B is the Architecture Continuum, which organizes reusable architecture assets (ABBs) from generic to specific. Item C is the Solutions Continuum, which organizes reusable implementation assets (SBBs), showing how architectures are realized as concrete solutions.

B. ABBs and SBBs are the contents of the continua (B and C, respectively), not the continua themselves. A represents the entire classification model.
C. Architecture Vision, Business Architecture, and Information Systems Architecture are domains or phases within the Architecture Development Method (ADM), not components of the Enterprise Continuum.
D. These terms describe different levels of architecture scope but do not correspond to the specific classification structure shown in the Enterprise Continuum diagram.

- The TOGAF® Standard, 10th Edition, Part V: Enterprise Continuum & Tools, Chapter 37, Enterprise Continuum. Figure 37-1, "Enterprise Continuum", explicitly labels the overall diagram (A), the Architecture Continuum (B), and the Solutions Continuum (C).

The TOGAF framework describes four common purposes or levels of detail for an Enterprise Architecture Capability, which frame the scope and content of architectural work. These four purposes create a hierarchy of detail, starting from the highest level of abstraction down to implementation. The correct sequence is Strategy, Portfolio, Project, and Solution Delivery. Each level addresses a different set of stakeholder concerns and has a different planning horizon.

B. Subordinate and Superior are general relational terms for architectures, not the specific four purposes defined in the TOGAF standard.
C. Discreet and Cohesive are qualitative attributes of an architecture, not categories that define its purpose or scope.
D. Segment Architecture is a type of architecture scope (often at the Portfolio or Project level), not one of the four distinct purposes.

- The TOGAF® Series Guide: The TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability, Section 4.2, "Purpose of the Enterprise Architecture Team". This section and its accompanying Figure 4-1 clearly identify the four purposes as Strategy, Portfolio, Project, and Solution Delivery.

The deliverable being referred to is an Architecture Contract. According to the TOGAF standard, Architecture Contracts are formal agreements between sponsors, architects, and implementation teams. They are the primary governance instrument used to ensure that implementation projects conform to the defined architecture. This includes continuous monitoring of the project against the architecture, managing changes, auditing for compliance, and facilitating decision-making throughout the implementation lifecycle. The contract ensures the integrity of the original Architecture Vision is maintained.

B. The Architecture Definition Document describes the architecture; it is the subject of governance, not the governance agreement or process itself.
C. The Architecture Vision is a high-level, aspirational document that guides the architecture work; it lacks the detail required for formal implementation governance and monitoring.
D. The Statement of Architecture Work is an internal project charter that authorizes the architecture team to proceed; it is not the contract that governs external or internal implementation partners.

1. The TOGAF® Standard, 10th Edition, Part V: Enterprise Architecture Capability and Governance, Chapter 6: Architecture Governance. Section 6.3.3, Architecture Contracts, explicitly describes their role in continuous monitoring, integrity checks, and audit.

2. The TOGAF® Standard, 10th Edition, Part IV: Architecture Content Framework, Section 4.2.4: Architecture Contract. This section defines the deliverable as a "joint agreement" used to "steer and govern the implementation".

The chart illustrates how the TOGAF Architecture Development Method (ADM) phases are planned over time in a program of work. It shows that while there is a logical sequence (Phase A, then B, then C, etc.), the phases can overlap. This demonstrates an iterative application of the ADM, where work on a subsequent phase can begin before the preceding phase is fully complete. The fundamental concept is that the ADM provides a structured, sequenced approach to developing an architecture, which is then tailored to the specific needs of the project, often involving iteration and overlapping phases for efficiency.

A. The chart is a tool for communication, but the core concept is the ADM process itself, not the mandatory use of a specific chart type like Gantt.
B. The chart shows phases, but it does not mandate a "limited fixed duration"; durations are determined by project context and can be variable.
D. The phases are overlapping, not running fully simultaneously. There is a clear precedence and sequential flow from one phase to the next.

1. The TOGAF® Standard, 10th Edition, The TOGAF® Standard — Architecture Development Method (ADM) (Document No. C220), Section 3.3, "Key Points of the ADM Cycle". This section emphasizes that the ADM has a set of architecture phases and is iterative.

2. The TOGAF® Standard, 10th Edition, The TOGAF® Standard — Architecture Development Method (ADM) (Document No. C220), Figure 3-3, "Example of a High-Level Program Plan". The question's chart is a representation of this concept, showing a sequenced but overlapping plan.

The problem is resolving incompatible stakeholder preferences during the development of a Target Architecture. The most structured and effective TOGAF-aligned approach is to use the previously agreed-upon Architecture Vision, Principles, and Requirements as a foundation for decision-making. These artifacts should be used to define objective criteria for evaluating different options. Developing alternative Target Architectures, illustrated with appropriate views, allows for a clear trade-off analysis of their strengths, weaknesses, and impacts. A formal stakeholder review can then be used to make an informed decision based on this analysis, ensuring the chosen path aligns with the strategic goals.

A: This is a reasonable approach, but it is less specific than C about using the established Vision and Principles as the basis for evaluation criteria. B: The architect should not unilaterally decide on business trade-offs; their role is to facilitate an informed decision by stakeholders by providing clear analysis. D: This focuses only on the communication process and stakeholder involvement, but lacks the core architectural technique of developing and analyzing alternatives to resolve the conflict.

1. The TOGAF® Standard, 10th Edition, Part III, Section 26.19 (Trade-Off Analysis): This section describes the technique of identifying and evaluating alternatives to resolve conflicting parameters, which is precisely what is needed.

2. The TOGAF® Standard, 10th Edition, Part II, Section 6.1 (Phase B: Business Architecture, Objectives): A key objective is to "Develop Target Business Architecture that addresses the stakeholder concerns". Creating alternatives is a method to achieve this.

3. The TOGAF® Standard, 10th Edition, Part III, Section 26.2.4 (Applying Architecture Principles): "Principles are a key element in a successful architecture governance strategy... they are used to guide the decision-making process".

The Architecture Repository is a central store for all architectural artifacts. It is logically partitioned into six classes of information. The Reference Library is the specific class that holds reference materials to assist in the creation of new architectures. This includes items like best practices, industry reference models, reusable patterns, templates, and guidelines. Its purpose is to accelerate development and improve the quality and consistency of architectural work by providing proven, reusable assets.

B. Specifications to which architectures must conform are stored in the Standards Information Base (SIB), another class within the repository.
C. A record of the governance activity across the enterprise is maintained in the Governance Log, a distinct part of the repository.
D. Processes to support governance of the Architecture Repository are part of the Architecture Capability, which defines how the EA function operates.

- The TOGAF® Standard, 10th Edition, ADM Techniques. (2022). Section 36.2.6, "Reference Library". The Open Group. This section explicitly states, "The Reference Library provides guidelines, templates, patterns, and other forms of reference material that can be leveraged...".

- The TOGAF® Standard, 10th Edition, Introduction and Core Concepts. (2022). Figure 36-1, "High-Level View of the Architecture Repository". The Open Group. This diagram visually separates the Reference Library from other components like the SIB and Governance Log.