OGEA-101 Practice Questions

Architecture partitioning is a technique used to manage the complexity of an enterprise. By dividing the architecture into smaller, more manageable segments, or "partitions", it simplifies governance and management (Statement 1). This division also allows for the delegation of architectural work, enabling different teams to work concurrently on different parts of the overall architecture, which improves efficiency and allows for specialization (Statement 3). The primary drivers for partitioning are to simplify the development and management of the Enterprise Architecture and to facilitate parallel work streams.

2. Partitions are equivalent to architecture levels: This is incorrect. Architecture levels (e.g., Strategic, Segment, Capability) define the scope and detail, whereas partitions are a method of dividing the enterprise for management purposes. A partition can exist at a specific level.

4. Partitions reflect the organization's structure: This is not necessarily true. While partitions can be based on organizational units, they can also be defined by other criteria such as subject matter (e.g., Business, Data), time periods, or architectural domains.

1. The Open Group Standard

TOGAF® Version 9.2

Part V

Chapter 35.1 (Introduction): This section states

"Partitioning is a technique used to manage complexity. In the context of Enterprise Architecture

partitioning allows specific groups of architects to work on their own specific elements of the architecture while maintaining a view of the overall architecture." This supports the correctness of statements 1 and 3.

2. The Open Group Standard

TOGAF® Version 9.2

Part V

Chapter 35.4 (Characteristics of a Partition): This chapter discusses the criteria for partitioning. It notes that partitions are defined by characteristics such as "Subject matter area"

"Level of detail"

and "Time". While an organizational unit could be a basis

it is not the only one

making statement 4 an oversimplification and not a universally correct rule.

3. The Open Group Standard

TOGAF® Version 9.2

Part V

Chapter 35.3 (Architecture Partitioning): This section illustrates how partitions relate to the Enterprise Continuum and different levels of architecture. It shows them as distinct but related concepts

where partitions are applied within the context of different levels

thus invalidating the claim that they are equivalent (Statement 2).

The Enterprise Continuum is a core concept in the TOGAF framework that provides a method for classifying architecture and solution assets. It acts as a "virtual repository" that structures these assets as they evolve from generic foundation architectures (like the TOGAF Technical Reference Model) to industry-specific, and finally to organization-specific architectures. Its primary purpose is to encourage the reuse of existing assets and to provide a context for positioning new architectural work, thereby accelerating the development process and improving consistency. It is fundamentally a classification and contextualization model for all architecture-related artifacts.

A. To identify and understand business requirements: This is incorrect. While assets from the Continuum may inform the process, techniques like Business Scenarios are specifically used in ADM Phase B to identify and understand business requirements.

B. To coordinate with the other management frameworks in use: This is incorrect. Coordinating with other frameworks (e.g., ITIL, COBIT) is a key activity of the Preliminary Phase, where the architecture practice is established and tailored to the enterprise.

C. To describe how an architecture addresses stakeholder concerns: This is incorrect. Architecture Views and Viewpoints are the specific TOGAF concepts used to frame, present, and communicate the architecture in a way that addresses specific stakeholder concerns.

1. The Open Group

TOGAF® Standard

10th Edition

TOGAF Fundamental Content (2022).

Section 16.1

Introduction: "The Enterprise Continuum is a model for classifying architecture and solution artifacts

both internal and external to the Architecture Repository

as they evolve from generic to specific." This directly supports the correct answer (D).

Section 16.2

Enterprise Continuum: "The Enterprise Continuum provides a consistent language to communicate the differences between architectures so that architectures and their components can be re-used." This reinforces the classification and reuse purpose.

2. The Open Group

TOGAF® Standard

10th Edition

The ADM (2022).

Section 4.3

Phase A: Architecture Vision: This section details stakeholder management and the creation of Architecture Views to address their concerns

showing why option (C) is incorrect.

Section 5.4.2

Business Scenarios: This section describes the Business Scenarios technique as a primary method "to identify and understand business requirements"

which refutes option (A).

Section 3.1

Preliminary Phase: This section explains that a key objective is to "Define the relationships between management frameworks"

which shows why option (B) describes a different part of the TOGAF framework.

The illustration depicts the relationship between key repositories within the TOGAF Architecture Content Framework. Item 'A' is the Architecture Requirements Repository, which stores and manages all requirements generated throughout the Architecture Development Method (ADM) cycles. Item 'B' is the Solutions Repository, which holds the descriptions of implemented Solution Building Blocks (SBBs). Item 'C' is the Architecture Landscape, representing the state of the architecture at specific points in time, showing what building blocks are currently in use within the organization. The diagram shows how requirements drive the creation of solutions, which then populate the landscape.

A. This option incorrectly identifies 'A' as the Solution Landscape and 'B' as the Architecture Requirements Repository, reversing their actual roles in the information flow.

B. This option incorrectly identifies 'A' as the Architecture Landscape. The landscape ('C') is a result of the process, not the starting point of requirements.

C. This option uses imprecise and non-standard terminology. The correct terms are "Architecture Requirements Repository" and "Architecture Landscape", not "EA Landscape" or "Artifacts Landscape".

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

Version 10. Van Haren Publishing. Part IV: Content Framework

Chapter 36

"Architecture Repository". The diagram is shown in Figure 36-2

"Relationships between the Architecture Repository and the Solutions Repository"

which explicitly labels the components as A: Architecture Requirements Repository

B: Solutions Repository

and C: Architecture Landscape. (Available at: https://pubs.opengroup.org/architecture/togaf-standard/content-framework/ch-architecture-repository.html)

The Implementation Governance Model is a specific artifact created during the Migration Planning phase (Phase F) of the TOGAF Architecture Development Method (ADM). Its primary purpose is to define the governance structure, processes, roles, and responsibilities for the implementation phase. This model ensures that as the project transitions into implementation, there is a clear framework to provide architectural oversight, manage compliance, and handle any required changes. It directly facilitates a smooth handover from the architecture development team to the implementation and operational teams, embedding the principles of Architecture Governance into the project's execution and subsequent operation.

A. Implementation Strategy: This is a high-level approach describing how the Target Architecture will be delivered, but it lacks the specific governance details for oversight and control.

C. Transition Plan: This is a broader term for the overall plan to move to the new architecture; the Implementation Governance Model is a specific, crucial component within it.

D. Migration Plan: This details the technical sequence and activities for moving from the baseline to the target state, focusing on the "how" of migration, not the governance "oversight".

1. The Open Group Standard

TOGAF® Standard

10th Edition. (2022). Part IV: ADM Content

Section 4.10

"Implementation and Migration Plan". This section explicitly lists the "Implementation Governance Model" as a key component of the plan

which is designed to "outline the governance of the implementation".

2. The Open Group Standard

TOGAF® Standard

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

Chapter 12

"Phase F: Migration Planning"

Section 12.3.5

"Outputs". This section identifies the Implementation and Migration Plan (which contains the Implementation Governance Model) as a primary output.

3. The Open Group Standard

TOGAF® Standard

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

Chapter 13

"Phase G: Implementation Governance"

Section 13.1

"Objectives". The objective to "Ensure that the implementation projects conform to the architecture" is achieved by executing the framework established in the Implementation Governance Model.

The Preliminary Phase of the Architecture Development Method (ADM) focuses on establishing the Architecture Capability within the organization. A key objective of this phase is to prepare the enterprise for a successful architecture project. This preparation includes defining the organizational context, tailoring the TOGAF framework, establishing governance structures, and crucially, selecting and implementing the tools that will support the architecture function. These tools are essential for modeling, repository management, and communication, thereby enabling the entire Architecture Capability.

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, not the Preliminary Phase.

C. To obtain approval for the Statement of Architecture Work: This is a key objective and output of Phase A: Architecture Vision, which formally initiates the architecture development cycle.

D. To create the initial version of the Architecture Roadmap: The initial Architecture Roadmap is a key deliverable from Phase A: Architecture Vision and is further detailed in Phases E and F.

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

10th Edition. Van Haren Publishing.

Correct Answer B: Part II

Section 5.3

Step 6

"Define and establish the Architecture Capability"

explicitly lists "Select and implement tools that support the Architecture Capability" as a key activity.

Incorrect Option A & C: Part II

Section 6.2

"Objectives"

states that Phase A is to "develop a high-level aspirational vision of the capabilities and business value" and to "secure approval for a Statement of Architecture Work".

Incorrect Option D: Part III

Chapter 25

"Architecture Roadmap"

describes this artifact as being initiated in Phase A and refined in Phases E and F.

The 'Implications' section of the TOGAF Architecture Principle template is specifically designed to detail the consequences and requirements of adopting the principle. This includes highlighting the necessary resources, costs, activities, tasks, and changes to standards or processes. It essentially spells out what must be done to successfully implement and adhere to the principle, thereby addressing the "requirements for carrying out the principle." This section provides a realistic view of the effort and impact involved, which is crucial for decision-making and planning.

A. Rationale: This section explains the business justification and benefits of the principle, answering why it is important, not what is required to implement it.

B. Name: The name is simply a unique, memorable identifier for the principle and contains no detail about its implementation requirements.

C. Statement: The statement is a concise declaration of the principle itself, defining the fundamental rule, not the practical steps or requirements for its execution.

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

10th Edition

Series Guide: The TOGAF Leader’s Guide to Establishing and Evolving an EA Capability. Van Haren Publishing. Section 10.3

"Developing Architecture Principles"

describes the template. The entry for "Implications" states: "Should highlight the requirements for carrying out the principle

in terms of resources

costs

and activities/tasks."

2. The Open Group. (2018). The TOGAF® Standard

Version 9.2. Van Haren Publishing. Chapter 23

"Architecture Principles"

Section 23.3

"Template for Architecture Principles". The description for "Implications" reads: "Should highlight the requirements for carrying out the principle... This will spell out the impact of adopting the principle

both in the short and long term..."

The Open Group's TOGAF framework specifies four distinct purposes for which an enterprise architecture is developed. These purposes directly influence the planning horizon, the level of detail, and the scope of an architecture project, as well as the organization of the EA Repository. The four purposes are:

1. Strategy: To support high-level strategic decision-making and align business and IT.

2. Portfolio: To manage and govern the portfolio of projects and investments.

3. Project: To provide architectural guidance and constraints for specific projects.

4. Solution Delivery: To support the detailed design, implementation, and deployment of a solution.

Each purpose requires a different view and level of abstraction from the architecture.

A. These terms (General, Foundational, Subordinate, Superior) describe hierarchical relationships or types of architecture within a federated model, not the purposes for creating them.

B. These terms describe the scope (Segment, Enterprise) or a specific focus (Capability) of an architecture, but they are not the four standard framing purposes for an architecture project.

C. These terms describe potential implementation approaches (Big-Bang) or qualitative attributes (Cohesive) and are not part of the standard TOGAF classification of architecture purposes.

1. The Open Group

The TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability

(ISBN: 978-94-018-0249-8)

Chapter 2

Section 2.2

"The Purpose of an EA Capability". This section explicitly lists and details the four purposes: "Support Strategy"

"Support Portfolio"

"Support Project"

and "Support Solution Delivery".

2. The Open Group

TOGAF® Standard

Version 9.2

(ISBN: 1-947754-29-7)

Part VI

Chapter 39

"Architecture Partitioning". This chapter discusses how architectures are partitioned for different purposes and levels of detail

which aligns directly with the concepts of supporting strategy

portfolios

and projects. Section 39.4.1 notes that partitioning allows for specific focus on "portfolios and projects".

• Phase H (Architecture Change Management) is concerned with “establishing an architecture monitoring and change process so that the architecture continues to meet business needs” – exactly the intent of objective 1.

• Phase F (Migration Planning) has two closely-related objectives: (a) complete the Architecture Roadmap and Implementation & Migration Plan and (b) align that plan with enterprise change priorities. These match objectives 2 and 3.

• Phase G (Implementation Governance) “oversees and ensures solution implementation conforms to the Target Architecture”, which is the focus of objective 4.

A 1F misplaces change-management intent; 3G duplicates governance instead of migration planning.

C Lists 3H, 4H but Phase H has no objectives on implementation governance.

D 1G and 2H invert governance and change-management purposes; Phase F never appears although two migration objectives exist.

1. The Open Group. “TOGAF® Standard

Version 9.2”

Part II ADM –

• Chap 15 §15.1 Objectives (Phase H) – pp. 425-426 (continual monitoring & change).

• Chap 13 §13.1 Objectives (Phase F) – pp. 399-400 (finalize roadmap; coordinate Implementation & Migration Plan).

• Chap 14 §14.1 Objectives (Phase G) – p. 413 (ensure conformance of implementation projects).

2. The Open Group. “TOGAF® Standard

10th Edition”

Fundamental Content –

• Section 37.3.1 (Phase H objectives)

• Section 35.3.1 (Phase F objectives)

• Section 36.3.1 (Phase G objectives)

(confirms identical objective wording across editions).

The exhibit displays the standard diagram for the TOGAF Architecture Development Method (ADM) cycle.

1. Requirements Management: The central circle (labeled '1') represents the Requirements Management phase. This is a continuous process that occurs throughout all phases of the ADM, ensuring that all requirements are identified, stored, and managed consistently.

2. Change Management: The arrow pointing outwards from the cycle (labeled '2') represents the Architecture Change Management process. This is a key part of Phase H, which handles changes to the architecture after it has been implemented and is in operation.

3. Strategy: The arrow pointing into the cycle (labeled '3') represents the initial trigger for an architecture engagement. This is typically a Request for Architecture Work, which originates from business drivers, goals, and strategy.

A: Label 1 is Requirements Management, not Continuous Improvement. Migration Planning is Phase F of the ADM, not an overarching process.

B: Label 2 represents Architecture Change Management, not Implementation Governance. Implementation Governance is the title of Phase G.

D: Label 1 is Requirements Management, not Architecture Governance. Architecture Governance is a broader capability that oversees the entire architecture practice.

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

10th Edition. Van Haren Publishing. Part II: Architecture Development Method (ADM)

Section 3.1

Figure 3-1: The ADM Cycle. This official diagram explicitly labels the central process (1) as "Requirements Management".

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

10th Edition. Van Haren Publishing. Part II

Chapter 12: Phase H: Architecture Change Management. This chapter details the process for managing changes (2) to the established architecture.

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

10th Edition. Van Haren Publishing. Part II

Chapter 4: Preliminary Phase

Section 4.1 Objectives. This section explains that the ADM is initiated by a Request for Architecture Work

which is driven by business strategy (3).

Architecture Principles are fundamental statements of intent that guide architecture decision-making. According to the TOGAF standard, they provide a framework of rules and guidelines to ensure that architecture work consistently supports the enterprise's strategic objectives and business goals. By establishing a shared basis for decisions, they create a common understanding among stakeholders on how to govern and control the evolution of the enterprise architecture in pursuit of its strategy. This ensures that all architectural choices are coherent, consistent, and aligned with the desired business outcomes.

A. This describes the benefits or outcomes documented in a Business Case, not the guiding purpose of the principles themselves.

C. While principles reflect culture, their primary function is to actively guide and govern decisions, not merely to describe organizational values.

D. This is the explicit purpose of an Architecture Contract or Statement of Architecture Work, which formalizes an agreement for a specific engagement.

1. The Open Group Standard

TOGAF® Standard

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

Chapter 20

Section 20.2

"What is an Architecture Principle?". This section states that principles "provide a basis for decision-making" and govern the way the enterprise approaches architecture.

2. The Open Group Standard

TOGAF® Standard

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

Chapter 20

Section 20.1

"Introduction". This section clarifies that principles "provide a framework and a set of rules and guidelines" for architecture work

which aligns with the concept of control.

3. The Open Group Standard

TOGAF® Standard

10th Edition (April 2022). Part IV: Architecture Content Framework

Chapter 32

Section 32.2.4

"Architecture Contract". This section defines the Architecture Contract as the agreement between development partners and sponsors

distinguishing its purpose from that of principles.