Free OGEA-101 Practice Test

Architecture partitioning is a technique used to manage the complexity of an enterprise architecture. Its primary purpose is to divide the architecture into smaller, more manageable segments. This simplification (Statement 1) allows for focused effort and clearer governance. A key benefit of this division is that it enables concurrent work, allowing different teams to develop different parts of the architecture simultaneously without significant interdependencies or conflicts (Statement 3). These two points represent the core purpose and a major advantage of partitioning within the TOGAF framework.

2 Partitions are equivalent to architecture levels: This is incorrect. Architecture levels (e.g., Strategic, Segment, Capability) define the scope and detail of an architecture, whereas partitioning is the technique used to divide the enterprise for management and development purposes. 4 Partitions reflect the organization's structure: This is not necessarily true. While an architecture can be partitioned along organizational lines, it can also be partitioned by other criteria such as subject matter (e.g., product lines, business domains) or time periods.

1. The TOGAF® Standard

10th Edition

Part II: Architecture Development Method (ADM)

Chapter 5

Section 5.5

"Architecture Partitioning": This section explicitly states

"Partitioning allows the architecture to be divided into a number of less complex

manageable 'partitions'." This directly supports Statement 1.

2. The TOGAF® Standard

10th Edition

Part II: Architecture Development Method (ADM)

Chapter 5

Section 5.5

"Architecture Partitioning": The standard also notes

"Partitioning enables different teams to work on different elements of the architecture at the same time." This directly supports Statement 3.

3. The TOGAF® Standard

10th Edition

Part II: Architecture Development Method (ADM)

Chapter 5

Section 5.5.2

"Creating Partitions": This section lists the characteristics for partitioning

which include "Subject matter"

"Time period"

and "Level of detail". It also mentions that partitions can be created for "major organizational sub-divisions"

but this is presented as one option among several

not a mandatory characteristic

thus refuting Statement 4. The distinction between levels and partitions is also implicit in this section

refuting Statement 2.

The Enterprise Continuum is a foundational concept in the TOGAF framework that provides a method for classifying architecture and solution assets. It acts as a "virtual repository" model, organizing assets as they evolve from generic foundational elements to highly specific organizational implementations. This classification helps architects to leverage existing materials, promote reuse, and understand the context of different architecture artifacts. It structures assets along a continuum, from Foundation Architectures, through Common Systems and Industry Architectures, to Organization-Specific Architectures, facilitating a systematic approach to architecture development.

A. Identifying and understanding business requirements is a core activity of the Requirements Management process and Phase B (Business Architecture), not the primary function of the Enterprise Continuum.
B. Coordinating with other management frameworks is typically addressed in the Preliminary Phase when tailoring the TOGAF framework and defining its relationship with other frameworks like ITIL or COBIT.
C. Describing how an architecture addresses stakeholder concerns is achieved through the creation of architecture views and viewpoints, which are tailored communication artifacts for different stakeholders.

1. The Open Group, "The TOGAF® Standard, 10th Edition," Van Haren Publishing, April 2022. In Part IV, Chapter 37, "The Enterprise Continuum," Section 37.1 states, "The Enterprise Continuum is a model for structuring an enterprise-specific virtual repository and provides methods for classifying architecture and solution artifacts..."

2. The Open Group, "The TOGAF® Standard, 10th Edition," Van Haren Publishing, April 2022. Part IV, Chapter 37, Figure 37-1, "Enterprise Continuum," visually represents this classification from generic to specific, reinforcing its role as a classification tool.

3. The Open Group, "The TOGAF® Standard, 10th Edition," Van Haren Publishing, April 2022. In Part II, Chapter 4, "ADM Overview," it is noted that the Enterprise Continuum is a key asset of the Architecture Repository, which provides a system for storing and classifying outputs.

In the TOGAF standard framework, the Architecture Repository is structured to manage different classes of architectural information. Based on the official reference model diagram, Box A represents the Solutions Landscape, which contains an architectural representation of Solution Building Blocks (SBBs) and explicitly "enables the enterprise." Box B is the Architecture Requirements Repository, responsible for capturing and holding authorized architectural requirements that act as "drivers for the enterprise." Finally, Box C is the Architecture Landscape, the central component where deployed and planned architectural artifacts are organized and structured according to the metamodel.

Option B: Incorrectly swaps the Architecture Landscape with the Solutions Landscape. The Architecture Landscape represents the central governed assets, not the enabler of the enterprise.

Option C: Introduces non-standard terminology such as "EA Landscape" and "Artifacts Landscape," which do not exist within the formal TOGAF Architecture Repository metamodel.

Option D: Reverses the accurate positions of the Solutions Landscape (referred to inaccurately as Solutions Repository) and Architecture Requirements Repository, directly contradicting the standard structure.

The Open Group, The TOGAF® Standard, Version 9.2, Part I: Introduction, Chapter 2 (Core Concepts), Figure 2-4: TOGAF Architecture Repository Structure.

The Open Group, The TOGAF® Standard, 10th Edition, Enterprise Architecture Capability, Section "Architecture Repository" (Document identifier: C220).

The Implementation Governance Model is the formal framework established to oversee the implementation of the architecture. It defines the roles, responsibilities, processes, and decision-making structures required to ensure the project adheres to the specified Target Architecture. A key function of this model is to manage the transition from project-specific governance to the enduring, operational Architecture Governance framework of the enterprise. This ensures that architectural compliance and control are maintained seamlessly as the project moves from development into its operational lifecycle.

A. Implementation Strategy: This outlines the high-level approach for the project but lacks the specific governance framework and handover procedures.
C. Transition Plan: This focuses on the sequence and dependencies of projects to achieve the Target Architecture, not the governance transition itself.
D. Migration Plan: This is a detailed technical plan for moving systems and data; it is a component of the overall transition, not the governance mechanism.

1. The Open Group, "TOGAF® Standard, 10th Edition," 2022. In Chapter 12, "Phase G: Implementation Governance," Section 12.1 Objectives states the goal is to "Ensure that the implementation project conforms to the Target Architecture" and "Perform appropriate Architecture Governance functions for the solution". This phase is where the governance transition is managed.

2. The Open Group, "TOGAF® Standard, 10th Edition," 2022. Chapter 12, "Phase G: Implementation Governance," Section 12.4 Outputs, lists the "Implementation Governance Model (validated)" as a key artifact. This artifact formally documents the governance structure for the implementation and its integration with ongoing governance.

3. The Open Group, "TOGAF® Standard, 10th Edition," 2022. Chapter 20, "Architecture Governance," Section 20.1 Introduction, describes the overarching framework. The Implementation Governance Model acts as the bridge, ensuring project-level activities align with and transition smoothly into this enterprise-wide framework.

The primary purpose of the ADM Preliminary Phase is to establish the Architecture Capability within the organization. This foundational work involves preparing the enterprise for a successful architecture practice. A key objective within this phase is to determine the necessary resources for the architecture team, which explicitly includes the selection and implementation of appropriate architecture tools. These tools are essential for creating, managing, and utilizing the architecture assets that will be developed in subsequent ADM phases.

A. To develop a vision of the business value to be delivered by the proposed enterprise architecture: This is a primary objective of Phase A: Architecture Vision, which follows the Preliminary Phase.
C. To obtain approval for the Statement of Architecture Work: The Statement of Architecture Work is a key deliverable created and approved during Phase A: Architecture Vision.
D. To create the initial version of the Architecture Roadmap: The Architecture Roadmap is initiated in Phase A and is incrementally developed and refined throughout Phases B through F, not in the Preliminary Phase.

1. The Open Group Standard

TOGAF® Standard

10th Edition (April 2022). Part II: Architecture Development Method (ADM)

Chapter 5: Preliminary Phase

Section 5.3 Steps. Step 6

"Implement Architecture tools"

states: "This step selects and implements the tools that will support the Architecture Capability."

2. The Open Group Standard

TOGAF® Standard

10th Edition (April 2022). Part II: Architecture Development Method (ADM)

Chapter 6: Phase A: Architecture Vision

Section 6.1 Objectives. This section lists "Develop a high-level aspirational vision of the capabilities and business value to be delivered" as an objective

invalidating option A.

3. The Open Group Standard

TOGAF® Standard

10th Edition (April 2022). Part II: Architecture Development Method (ADM)

Chapter 6: Phase A: Architecture Vision

Section 6.5 Outputs. This section lists the "Statement of Architecture Work" as a major deliverable to be approved

invalidating option C.

4. The Open Group Standard

TOGAF® Standard

10th Edition (April 2022). Part III: ADM Guidelines and Techniques

Chapter 21: Architecture Roadmap

Section 21.1. This section clarifies that the roadmap "is incrementally developed throughout Phases A to F"

invalidating option D.

The 'Implications' section of the TOGAF Architecture Principles template is specifically designed to detail the consequences and requirements of adopting a principle. This includes the necessary activities, tasks, resource commitments (both for business and IT), costs, and standards that must be implemented to ensure the principle is successfully carried out. It translates the high-level rule (the Statement) into actionable requirements and highlights the practical impact on the enterprise, making it the correct section for this purpose.

A. Rationale: This section explains the business justification and benefits of the principle (the "why"), not the implementation requirements.
B. Name: This is merely a unique, memorable title used to identify the principle.
C. Statement: This is the concise, unambiguous declaration of the fundamental rule itself, not the steps to execute it.

1. The Open Group Standard, TOGAF® Standard, 10th Edition. Part III: ADM Guidelines and Techniques, Chapter 17: Architecture Principles, Section 17.2, "Applying Architecture Principles". The documentation states: "Implications: Should highlight the requirements, both for the business and IT, for carrying out the principle – in terms of resources, costs, and activities/tasks." This directly confirms that the 'Implications' section contains the requirements for carrying out the principle.

The TOGAF® Standard specifies that architectures are developed for four distinct purposes which frame their scope, level of detail, and time horizon. These are:
1. Strategy: High-level architectures that support business strategy analysis and direction-setting.
2. Portfolio: Architectures that support the management of a portfolio of projects or programs.
3. Project: Architectures that support the implementation of a single, specific change initiative.
4. Solution Delivery: Detailed architectures that guide the implementation and delivery of a specific solution. These four purposes directly influence the planning horizon, the depth and breadth of the architecture project, and what is stored in the Enterprise Architecture Repository.

A. General Foundational Subordinate and Superior Architecture: These terms are not the standard classifications used within the TOGAF framework to define the purpose and scope of an architecture project.
B. Segment, Capability. Enterprise and End-to-end Target Architecture: While Segment and Capability are valid architecture partitioning criteria, this list does not represent the four specific purposes that frame the architecture's scope and detail.
C. Avant-Garde Big-Bang, Discreet and Cohesive: These terms describe potential characteristics or implementation approaches (e.g., "Big-Bang") rather than the fundamental purposes for which an architecture is developed.

1. The Open Group, "The TOGAF® Standard, 10th Edition," Part III: ADM Guidelines & Techniques, Chapter 18, Section 18.2.1 "Architecture for Different Purposes". This section explicitly states, "Architectures are developed for four purposes: ... Strategy architectures ... Portfolio architectures ... Project architectures ... Solution Delivery architectures".

2. The Open Group, "O-GEA™ 10 Study Guide (G213)," Section 3.3.1 "Architecture Partitioning". This guide, designed for the OGEA 101 exam, reiterates that the four purposes for which architectures are developed are Strategy, Portfolio, Project, and Solution Delivery.

The objectives listed correspond directly to the official definitions of Phases F, G, and H:

• Objective 1 (Phase F - Opportunities & Solutions): Focuses on generating the Implementation and Migration Plan by evaluating business value and costs of work packages and Transition Architectures.
• Objective 2 (Phase G - Implementation Governance): A primary goal is to ensure that implementation projects conform to the Target Architecture.
• Objective 3 (Phase G - Implementation Governance): Also aims to maintain the architecture development cycle by providing feedback from implementation.
• Objective 4 (Phase H - Architecture Change Management): Specifically focuses on executing the Architecture Governance Framework to manage changes in a cohesive manner.

Option B (1H-2F-3F-4G): Incorrect because Phase H manages change, not initial work package value (Phase F). Phase F does not govern implementation (Phase G).

Option C (1F-2G-3H-4H): Incorrect because ensuring the architecture development cycle is maintained (Objective 3) is a specific objective of Phase G, not Phase H.

Option D (1G-2H-3H-4F): Incorrect because cost/value understanding of work packages belongs to Phase F, not Phase G. Phase F does not execute the Governance Framework (Phase H).

The TOGAF® Standard, Version 9.2, Part II: Architecture Development Method (ADM)

Phase F: Opportunities & Solutions, Section 13.1 (Objectives): "To ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders."

Phase G: Implementation Governance, Section 14.1 (Objectives): "To ensure conformance with the Target Architecture by implementation projects" and "To ensure that the architecture development cycle is maintained."

Phase H: Architecture Change Management, Section 15.1 (Objectives): "To ensure that the Architecture Governance Framework is executed."

The Open Group Base Guide: The TOGAF Standard, 10th Edition - ADM Phase Reference

Phase F, Chapter 7.1: Confirms the focus on cost-benefit analysis and stakeholder understanding of migration packages.

Phase G, Chapter 8.1: Confirms the governance of the implementation process to maintain architectural integrity.

Phase H, Chapter 9.1: Confirms the role of change management in operating the governance framework.

The Open Group - TOGAF® Series Guide: Business Models (G18A)

Refers to the alignment of Phase F work packages with business value realization.

• The labels in the exhibit correspond to the standard components of the TOGAF ADM cycle. Label 1 represents the central, continuous process of Requirements Management, which interfaces with every ADM phase. Label 2 (corresponding to position G in the cycle) is Phase G: Implementation Governance, which ensures projects conform to the architecture. Label 3 is the Preliminary Phase, which sits outside and above the main cycle as it establishes the architecture footprint and capability before the first cycle begins.

Option A: "Continuous Improvement" is not a standard TOGAF phase name; Label 2 is Phase G (Implementation Governance), and Label 1 is Requirements Management.

Option C: Label 2 is Phase G (Implementation Governance), whereas Phase I is Architecture Change Management (Label H); "Strategy" is not an ADM phase name.

Option D: Label 1 is Requirements Management, not "Architecture Governance"; while Phase G involves governance, its specific name is Implementation Governance.

1. The TOGAF® Standard, Version 9.2, Part II: Architecture Development Method (ADM)

Section 5.2 (ADM Overview): Descriptions and visual diagrams of the ADM cycle identify the central circle (1) as Requirements Management and the top-most box (3) as the Preliminary Phase.

Section 14.1 (Phase G: Implementation Governance): Defines Phase G (Label 2/G) as Implementation Governance.

The Open Group Base Guide: The TOGAF Standard, 10th Edition - ADM Phase Reference

Chapter 1 (Preliminary Phase): Confirms its position at the top/start of the cycle.

Chapter 10 (Requirements Management): Confirms its central role as the driver for all other phases.

University of South Australia - Enterprise Architecture courseware (based on TOGAF 9.2)

Module 3 (ADM Cycle): Diagrams clearly label the core as Requirements Management and Phase G as Implementation Governance.

Architecture Principles are a set of fundamental rules and guidelines that govern how an enterprise's architecture is designed and evolved. Their primary purpose is to ensure that all architectural decisions are consistent and aligned with the enterprise's strategic business objectives. By establishing these principles, an organization creates a shared framework and common understanding for decision-making. This framework acts as a governance mechanism, effectively controlling the development of the architecture to ensure it consistently supports the business strategy and moves the enterprise toward its desired future state.

A. This describes business outcomes or the value proposition of an architecture, which are results derived from applying principles, not the purpose of the principles themselves.
C. While principles should be consistent with an enterprise's culture and values, their main purpose is to actively guide decision-making, not merely to describe the existing culture.
D. This describes the purpose of an Architecture Contract or a Statement of Architecture Work, which are specific agreements for a project, not general, enduring guiding principles.

1. The TOGAF® Standard

10th Edition

Part III: ADM Guidelines & Techniques

Chapter 17: Architecture Principles.

Section 17.1

Introduction: States that Architecture Principles "are developed in order to support the business goals and the strategic direction of the organization." This directly supports the "in pursuit of strategic objectives" part of the correct answer.

Section 17.1

Introduction: Also notes that principles "form the basis for making future ... decisions." This aligns with the concept of establishing control and a common understanding for governance.

2. The TOGAF® Standard

10th Edition

Part I: Introduction

Chapter 3: Core Concepts.

Section 3.11

Architecture Principles: Defines principles as "general rules and guidelines

intended to be enduring and seldom amended

that inform and support the way in which an organization sets about fulfilling its mission." This reinforces their role as a control mechanism for fulfilling strategic missions (objectives).