Free OGEA-103 Practice Test

According to the TOGAF standard's document versioning conventions, deliverables that are currently under development and have not yet been subjected to a formal review and approval process are designated as "Version 0.1" (or 0.x for subsequent drafts). Once these documents have successfully passed the formal review process and are approved by the relevant stakeholders or the Architecture Board, they are officially designated as "Version 1.0". This convention ensures clear tracking of a deliverable's maturity and governance state.

- A ("draft"- "finalized"): While these terms are commonly used in general business, they are not the formal versioning nomenclature specified in the TOGAF ADM guidelines.
- B ("draft" - "approved"): These describe the state of the document but do not match the specific numerical versioning convention (0.1 and 1.0) defined by TOGAF.
- C ("concept" - "deliverable"): A deliverable is a formal output, but "concept" is not the standard TOGAF terminology for an unapproved document.

- The Open Group. (2022). The TOGAF® Standard

10th Edition - Architecture Development Method (ADM). Chapter 2: Introduction to the ADM

Section 2.6 ADM Document Versioning.

In the TOGAF Architecture Development Method (ADM), document management and versioning conventions dictate that documents which are currently under development and have not yet undergone any formal review and approval process are officially called "draft". This terminology ensures clear communication among stakeholders regarding the maturity and reliability of architecture artifacts. Once a draft undergoes review, it may progress to higher version numbers (e.g., Version 0.9 for final review, and Version 1.0 for formally approved documents).

B. "Invalid" is incorrect because draft documents are legitimate, valid work-in-progress artifacts necessary for the architecture development process.
C. "In between phases" is incorrect because documents are actively developed and drafted during the execution of ADM phases, not just between them.
D. "Version 0.1" refers to a specific milestone (usually a high-level outline), whereas "draft" is the overarching term for any unapproved document under development.

The Open Group. (2022). The TOGAF® Standard, 10th Edition - Architecture Development Method. Section: ADM Document Versioning / Introduction to the ADM.

According to the TOGAF standard, addressing stakeholder concerns begins in Phase A with a thorough Stakeholder Analysis. This involves identifying stakeholders, documenting their positions, concerns, and cultural factors, and developing a Stakeholder Map. The architect then defines relevant views to address these concerns, recording them in the Architecture Vision. To manage risks, especially in an agile environment ("architecting with agility"), risk mitigation requirements are documented in the Architecture Requirements Specification and validated through regular assessments and iterative feedback loops.

A: Creating an Organization Map and multiple business models does not directly address the specific stakeholder concerns or follow the TOGAF stakeholder management process. B: While a Communication Plan is useful, it skips the crucial step of defining specific views to address documented stakeholder concerns as required by TOGAF Phase A. D: Grouping stakeholders into arbitrary categories and creating models for each does not align with TOGAF's method of defining specific viewpoints based on identified stakeholder concerns.

- The Open Group

TOGAF Standard

10th Edition

Architecture Development Method (ADM)

Phase A: Architecture Vision

Section 4.3 and 4.4.

- The Open Group

TOGAF Standard

10th Edition

Enterprise Architecture Capability and Governance

Stakeholder Management

Section 3.2.

The diagram illustrates the TOGAF classification model for Architecture Landscapes, which organizes architectures by their level of detail and scope. 'A' represents the Enterprise Strategic Architecture, which provides a high-level, long-range view of the entire enterprise. 'B' represents Segment Architectures, which provide more detailed views for specific parts of the enterprise, such as a line of business or business unit. 'C' represents Capability Architectures, which describe the specific capabilities required to deliver business value, often in the context of a particular project or change initiative.

A. While related concepts, "Tactic" and "Operational" are not the specific terms used in the standard TOGAF classification model for architecture landscapes.
B. These are names of ADM phases or architecture domains, not levels of detail in the Architecture Landscape classification model.
C. This option uses incorrect terminology; the standard model uses "Strategic", "Segment", and "Capability" architectures, not these capability-focused labels.

- The TOGAF® Standard

10th Edition

Part III: ADM Guidelines and Techniques

Chapter 21

"Applying the ADM". Section 21.2

"Architecture Landscape"

explicitly defines these three levels.

- The TOGAF® Standard

10th Edition

Part III: ADM Guidelines and Techniques

Figure 21-1

"A Classification Model for Architecture Landscapes". This figure is the source of the diagram in the question and labels the levels as Strategic

Segment

and Capability Architectures.

In the TOGAF standard, the Architecture Repository includes the Architecture Requirements Repository. This specific component stores all authorized architecture requirements that have been formally agreed upon with the Architecture Board. It acts as a centralized repository to manage, store, and track requirements throughout the Architecture Development Method (ADM) cycle, ensuring that the evolving architecture remains aligned with business objectives and governance mandates.

A. The Reference Library provides guidelines, templates, patterns, and other forms of reference material, not the agreed-upon architecture requirements.
B. Architecture Capability defines the parameters, structures, and processes that support governance of the repository, not the requirements themselves.
D. The Governance Log records governance activity across the enterprise (e.g., decisions, compliance assessments), not the specific architecture requirements.

1. The Open Group. (2022). The TOGAF® Standard, 10th Edition - Architecture Content. Section 4.1 (The Architecture Repository).

2. The Open Group. (2022). The TOGAF® Standard, 10th Edition - Introduction and Core Concepts. Section 4.2 (Architecture Repository).

According to the TOGAF guidelines for establishing architecture principles, "Completeness" is one of the recommended criteria for quality. A complete set of principles ensures that every potentially important principle governing the management of information and technology for the enterprise is defined. This means the principles are comprehensive enough to cover every situation perceived by the enterprise, leaving no critical architectural decision without guiding tenets.

A. Consistency means that principles must not contradict one another, ensuring that adhering to one does not violate another.
B. Robustness means that principles are definitive and precise enough to enable good quality, predictable decisions about architectures and plans.
C. Stability means that principles should be enduring and rarely amended, able to accommodate changes without requiring constant revision.

- The Open Group. TOGAF® Series Guide: Architecture Principles. Section 3.3: Criteria for Quality (Completeness).

- The Open Group. The TOGAF® Standard, 10th Edition - Enterprise Architecture Capability. Section 6: Architecture Principles.

The TOGAF 10th Edition introduces four distinct Architecture Purposes that frame the planning horizon, depth, breadth, and contents of the Enterprise Architecture Repository. These four purposes are: Architecture to Support Strategy, Architecture to Support Portfolio, Architecture to Support Project, and Architecture to Support Solution Delivery. Identifying the correct purpose is a critical first step in the ADM, as it dictates the level of detail, the stakeholders involved, and the specific deliverables required for the architecture effort.

A. General, Foundational, Subordinate, and Superior are not recognized architecture purposes in the TOGAF standard.
B. Segment, Capability, and Enterprise refer to the levels of architecture landscape scope, not the purposes that frame the architecture project.
C. Avant-Garde, Big-Bang, Discreet, and Cohesive are fabricated terms and hold no meaning within the TOGAF framework's scoping guidelines.

The Open Group. (2022). The TOGAF® Standard

10th Edition - Introduction and Core Concepts. Section: Architecture Purpose.

The Open Group. (2022). The TOGAF® Standard

10th Edition - Architecture Development Method. Phase A: Architecture Vision.

The exhibit shows the TOGAF ADM cycle. Item 2 is positioned after Phase F (Migration Planning) and before Phase H (Architecture Change Management), which corresponds to Phase G: Implementation Governance. The primary objective of Phase G is to provide architectural oversight for the implementation of the Target Architecture. This involves ensuring that implementation projects conform to the architecture specifications, managing architecture contracts, and performing governance functions for the solution.

A. This describes Phase F (Migration Planning), which precedes Phase G (item 2) in the ADM cycle.
B. This describes Phase H (Architecture Change Management), which follows Phase G (item 2) in the ADM cycle.
C. This describes the Requirements Management process, which is a central, continuous activity that runs through all phases, not a specific sequential phase like item 2.

The TOGAF® Standard

Version 10 (C220)

Part II: Architecture Development Method (ADM)

Chapter 5

"ADM Phases"

Figure 5-1 The ADM Cycle. This figure visually places Phase G after F and before H.

The TOGAF® Standard

Version 10 (C220)

Part II: Architecture Development Method (ADM)

Chapter 13

"Phase G: Implementation Governance"

Section 13.1 Objectives. This section states the objective is to "Ensure conformance with the Target Architecture by implementation projects".

Statements 1 and 2 directly reflect two of the key benefits/values that architecture governance provides, as described in the TOGAF Standard. Governance ensures accountability — each contracted party acts responsibly to the organization and its stakeholders (Statement 1) — and fairness/equity — decisions, processes, and their implementation do not create unfair advantage to any one party (Statement 2). These map to the governance characteristics of "Accountability," "Responsibility," and "Fairness" cited in the TOGAF Architecture Governance chapter, which explicitly lists these among the values and necessity for adopting architecture governance.

B (2 and 3): Statement 3 (more effective/efficient digital transformation) is a generic outcome, not one of the listed governance value characteristics. C (3 and 4): Both are generalized benefit claims, not the specific governance value statements defined in the TOGAF governance characteristics. D (1 and 4): Statement 4 (effective C-Level decision-making) is not among the defined governance characteristics; it is a broad business claim.

1. The Open Group

TOGAF Standard

10th Edition — Architecture Governance (Document G184)

Section on "Characteristics of Architecture Governance." Lists Discipline

Transparency

Independence

Accountability

Responsibility

and Fairness as the values/necessity for governance adoption.

2. The Open Group

TOGAF Standard (10th Edition)

Applying the ADM — Architecture Governance chapter

subsection "Nature of Governance" and "Benefits of Architecture Governance."

3. The Open Group

TOGAF Standard 10th Edition

Introduction and Core Concepts

definitions of governance principles (Accountability and Fairness align to Statements 1 and 2 respectively).

Note: The specific mapping (Statement 1 → Accountability/Responsibility; Statement 2 → Fairness) corresponds directly to the governance characteristics enumerated in the TOGAF Architecture Governance chapter

confirming option A as the most directly applicable answer.

In the TOGAF 10th Edition, Requirements Management is not a static, one-time phase but a continuous, dynamic process. The Architecture Development Method (ADM) places Requirements Management and stakeholder engagement at the absolute center of architecture development. This central positioning ensures that all architecture phases are continuously driven by, and validated against, evolving business requirements and stakeholder needs throughout the entire architecture lifecycle.

A. Processing architecture change requests is the primary purpose of Phase H (Architecture Change Management), not the Requirements Management phase.
B. Stakeholder requirements are not captured just once in Phase A; they are continuously gathered, updated, and managed throughout the entire ADM cycle.
C. Requirements Management is a continuous central phase of the ADM, not a specific "step" executed within the other individual ADM phases.

- The Open Group

TOGAF Standard

10th Edition - Introduction and Core Concepts

Section 3.3 "Architecture Development Method (ADM) Overview".