Free OGEA-101 Practice Test Questions and Answers (2026)

The Architecture Requirements Repository is a specific component within the broader Architecture Repository. Its primary function is to store and manage the output of the Requirements Management phase. This includes all architecture requirements that have been formally reviewed, processed, and approved by the relevant governance body, such as the Architecture Board. It serves as the definitive, single source of truth for the requirements that the architecture must address, including a history of changes and decisions.

A. Guidelines, templates, and patterns are stored in the Reference Library, which contains reference materials that can be used to develop architectures.

B. The parameters and structures for governance are part of the Architecture Capability, which defines the processes and resources for managing the architecture function.

C. A log of governance activity is maintained in the Governance Log, which records all governance decisions and actions related to the architecture.

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

10th Edition. Van Haren Publishing.

For Correct Answer (D): Part IV

Section 31.2.4

"Requirements Repository"

states: "The requirements repository will contain the current approved requirements as well as a history of the requirements for the various projects."

For Incorrect Option (A): Part V

Section 36.2.5

"Reference Library"

describes this component as providing "guidelines

templates

patterns

and other forms of reference material".

For Incorrect Option (B): Part V

Section 36.2.2

"Architecture Capability"

explains that this area defines "the parameters

structures

and processes that support governance of the Architecture Repository".

For Incorrect Option (C): Part V

Section 36.2.6

"Governance Log"

specifies that this log "provides a record of governance activity across the enterprise".

The TOGAF framework emphasizes that effective communication with stakeholders is crucial for the success of an architecture project. Architecture Views and Viewpoints are the primary mechanisms for this communication. A viewpoint defines the perspective and conventions for constructing a view (e.g., a security viewpoint). A view is the actual representation of the architecture presented to a stakeholder to address their specific concerns (e.g., a diagram showing data flows and security controls). By presenting different views, tailored to different stakeholder viewpoints, architects can ensure the architecture is understood and validated, which is essential for eliciting feedback and uncovering previously unstated requirements, principles, or hidden agendas.

A. Alternatives, Trade-offs: While presenting alternatives and their trade-offs is an important activity, it is a specific technique often facilitated through architecture views, not a replacement for them.

B. Solutions, Applications: These terms are too specific. "Solutions" are addressed in later ADM phases, and "applications" are only one component of an architecture. This pair does not represent the fundamental communication concept.

D. Business Scenarios, Business Models: Business Scenarios are a technique used to elicit and document requirements, which then drive the architecture work, rather than a method for presenting the architecture to get feedback.

1. The TOGAF® Standard

10th Edition

Part IV: Architecture Content Framework

Chapter 33

Architecture Views and Viewpoints: This chapter states

"The concept of views and viewpoints is fundamental to the TOGAF Architecture Framework... A view is what you see. A viewpoint is where you are looking from – the perspective that determines what you see." This highlights their role in tailoring communication.

2. The TOGAF® Standard

10th Edition

Part III: ADM Guidelines and Techniques

Chapter 22

Stakeholder Management

Section 22.4: "The architect must identify the key stakeholders and their concerns/objectives

and define key views that will be used to communicate the architecture to them." This directly links the use of views to addressing stakeholder concerns

which is the process that uncovers hidden requirements.

3. The TOGAF® Standard

10th Edition

The TOGAF Standard (Core Concepts)

Chapter 3

Core Concepts

Definitions 3.30 and 3.31: Defines an Architecture View as "a representation of a system from the perspective of a related set of concerns" and an Architecture Viewpoint as "a specification of the conventions for a particular kind of architecture view". This confirms that presenting different views from different viewpoints is the formal method for addressing varied stakeholder concerns.

The Implementation Governance Model is a key artifact produced during the TOGAF Architecture Development Method (ADM). Its primary purpose is to define the framework, processes, roles, and responsibilities for governing the implementation of the architecture. This model ensures that the implementation projects conform to the defined Target Architecture and provides a structured mechanism for the project to transition from the implementation phase into the ongoing, operational Architecture Governance framework established by the enterprise.

A. Migration Plan: This plan details the sequence of projects and activities required to transition from the Baseline to the Target Architecture, focusing on the "how-to" of migration, not the governance structure.

B. Transition Plan: This is a general term, often part of the Migration Plan, that outlines the steps for moving to the new state. It does not specifically define the governance handover process.

D. Implementation Strategy: This is a high-level approach that outlines the overall method for implementing the architecture (e.g., phased rollout, big bang), but it is not the detailed governance model itself.

1. The Open Group Standard

TOGAF® Standard

10th Edition (April 2022). Part III: ADM Phases

Chapter 14

"Phase G – Implementation Governance"

Section 14.4

Outputs. This section lists "Implementation Governance Model (validated)" as a key output of this phase

which is responsible for ensuring conformance and governing the transition.

2. The Open Group Standard

TOGAF® Standard

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

Chapter 26

"Architecture Deliverables"

Section 26.2.13

"Implementation Governance Model". This section explicitly defines the deliverable as providing "a high-level view of the governance of the implementation of the Target Architecture".

The TOGAF Architecture Development Method (ADM) is visually represented as a cycle with Requirements Management at its core. This central placement signifies that it is a continuous, dynamic process that underpins all phases of architecture development. It ensures that every stage of the ADM is aligned with business needs and that requirements are consistently managed from initial identification through to implementation and governance. Stakeholder engagement is intrinsically linked to this, as stakeholders are the primary source of requirements, concerns, and business goals that the architecture must address. Therefore, both are central to successful architecture development.

A. This is only a subset of the purpose. Requirements Management covers the entire lifecycle of requirements, not just processing changes to them.

B. Requirements are not captured only once. They are identified, elaborated, and refined iteratively throughout all relevant phases of the ADM cycle.

C. Requirements Management is a continuous process that interacts with all ADM phases; it is not a discrete step within each phase.

1. The Open Group Standard

TOGAF® Standard

10th Edition

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

Section 4.3

Figure 4-1 – The ADM Cycle. This figure explicitly places "Requirements Management" in the center of the ADM phases

visually confirming its central and continuous role.

2. The Open Group Standard

TOGAF® Standard

10th Edition

(April 2022). Part III: ADM Phases

Chapter 16: Requirements Management

Section 16.1. This section states

"The Requirements Management process is a dynamic process that manages all requirements throughout the ADM."

3. The Open Group Standard

TOGAF® Standard

10th Edition

(April 2022). Part III: ADM Phases

Chapter 5: Phase A: Architecture Vision

Section 5.4.3. This section details how stakeholder engagement is critical for defining business goals and strategic drivers

which are foundational to requirements.

The statement describes the concept of iteration within the TOGAF Architecture Development Method (ADM). The ADM is not a rigid, one-time, sequential process. It is designed to be flexible and is almost always applied in an iterative manner. This allows architects to cycle through phases, or groups of phases, in planned cycles to progressively detail the architecture, address specific stakeholder concerns, or manage large, complex projects. The ability to cycle between phases, such as moving back and forth between Business, Information Systems, and Technology Architecture phases (B, C, and D), is a fundamental application of iteration.

A. Requirements management: This is a continuous process that occurs throughout all ADM phases to manage architecture requirements, not the act of cycling between the phases themselves.

C. Implementation governance: This is a specific activity, primarily in Phase G, that ensures implementation projects conform to the defined architecture, rather than the development process of cycling through phases.

D. Enterprise Architecture: This is the overall discipline and the resulting set of artifacts. The statement describes a specific method (iteration) used within the practice of Enterprise Architecture.

1. The TOGAF® Standard

10th Edition

Part II: Architecture Development Method (ADM)

Section 3.3

Applying Iteration to the ADM. This section explicitly states

"The TOGAF ADM is an iterative method... The ADM supports a number of levels of iteration..." It further details different iteration cycles

including "Cycling between phases"

which directly matches the scenario in the question.

2. The TOGAF® Standard

10th Edition

Part II: Architecture Development Method (ADM)

Section 3.3.2

The Iteration Cycles. This section provides diagrams and descriptions of various iteration patterns. Figure 3-2 illustrates "Iteration Between ADM Phases

" showing cycles between Phases B

C

and D

which is a common example of the concept described in the question.

3. The TOGAF® Standard

10th Edition

Part II: Architecture Development Method (ADM)

Chapter 2

ADM Phase: Requirements Management. This chapter describes Requirements Management as a dynamic and continuous process that runs in parallel with the ADM phases

distinguishing it from the iterative cycling of the phases.

A Business Transformation Readiness Assessment is a comprehensive evaluation of an organization's preparedness to undergo significant change. This assessment is inherently a collaborative process. It requires input and analysis from various parts of the enterprise to gain a holistic view of readiness. Corporate staff provide insights into governance and finance, lines of business contribute knowledge of operational processes and user capabilities, and IT planners assess the technological infrastructure and systems. This joint effort ensures all dimensions of the organization—business, IT, and overall organizational culture—are evaluated for their capacity to successfully implement and adopt the transformation.

B. This is an objective or desired outcome of the assessment and stakeholder management activities, not the definition of the assessment itself. The assessment measures support, it doesn't ensure it.

C. This describes the function of the Architecture Continuum and the use of Architecture Building Blocks (ABBs) within the TOGAF framework, which is a distinct concept from readiness assessment.

D. This describes architecture governance reviews or technical validation processes. A readiness assessment is broader, focusing on the organization's business and cultural capacity for change, not just technical architecture validation.

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

Version 9.2. Van Haren Publishing.

Section 24.4

"Technique": This section details the dimensions to be assessed

which include IT Readiness

Business Readiness

and Organization Readiness. The breadth of these dimensions (e.g.

"Business process readiness"

"IT infrastructure readiness"

"Governance readiness") necessitates a joint effort from the respective groups (lines of business

IT planners

corporate staff).

Section 24.1

"Introduction": States the assessment is used to "define the readiness of an organization to accept change". This broad scope implies a multi-disciplinary

collaborative approach.

The fundamental purpose of Enterprise Architecture (EA) governance is to ensure that the architecture and its subsequent implementations align with business strategy and deliver intended value. Best practice governance provides the framework of controls, processes, and decision-making authority to direct and manage the architecture throughout its lifecycle. This control mechanism is crucial for linking strategic goals to implementation projects, thereby ensuring that the organization can effectively monitor, manage, and ultimately realize the value promised by the architecture.

A. An architecture project is subject to governance; it does not create the overarching organizational need for it. Governance is a prerequisite for controlling projects, not a mandate from them.

B. While highly recommended for effectiveness, the TOGAF standard is a framework, not a mandated law. An organization can use its components without a formal executive governance structure, albeit ineffectively.

D. Managing stakeholder preferences is a function of governance, but it is a specific activity. The primary need for governance is the broader goal of controlling overall value realization.

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

10th Edition. Van Haren Publishing.

Part VI

Section 46.2.1

Key Concepts: "Effective governance is a key factor in ensuring that the organization can realize the benefits of its architecture." This section explicitly links governance to the realization of benefits (value).

Part VI

Section 46.1

Introduction: States that governance provides a "control mechanism" to ensure compliance and a "feedback mechanism from implementation to architecture"

which are essential for managing value.

2. The Open Group. (2018). The TOGAF® Leader’s Guide to Establishing and Evolving an EA Capability (G184).

Chapter 5

Governance: "Governance is the mechanism for ensuring that the EA Capability is operating effectively and efficiently to deliver value to the enterprise." This directly supports the idea that governance's role is to control the delivery of value.

The primary purpose of Enterprise Architecture (EA) is to guide effective change. EA provides a holistic, enterprise-wide view that aligns strategic objectives with tactical demands. By creating a coherent framework and set of principles, EA ensures that business and IT changes are implemented in a coordinated and optimal manner, supporting the business strategy and delivering value. This guidance helps the organization navigate complexity and transform effectively, moving from a current state to a desired future state in a structured way.

A. EA informs and supports major improvement decisions, but the act of taking the decisions rests with business and IT leadership.

B. "Guide" is a more accurate term than "control". EA enables and directs change rather than imposing rigid, top-down control.

D. EA governs the architecture and the change process, not the stakeholders. Stakeholder management is a critical activity within EA, but not its core purpose.

1. The Open Group

The Open Group Standard for Enterprise Architecture (O-EA)

Version 1.0

Standard No. C20A

December 2020. Section 1.2

"What is Enterprise Architecture?"

Page 2. The document states: "The purpose of Enterprise Architecture is to guide effective change."

2. The Open Group

Open Group Enterprise Architecture Foundation Study Guide

1st Edition

Document No. X211

February 2021. Section 1.2

"What is Enterprise Architecture?"

Page 2. This guide explicitly states the same definition: "The purpose of Enterprise Architecture is to guide effective change."

3. The Open Group

The TOGAF® Standard

Version 9.2

Document No. C182

April 2018. Chapter 2

"What is an Enterprise and What is an Enterprise Architecture?"

Page 7. This section notes that EA's purpose is to create an "integrated environment that is responsive to change and supportive of the delivery of the business strategy"

which aligns with the concept of guiding effective change.

The primary purpose of the Gap Analysis technique, as defined within the TOGAF® Standard, is to compare the Baseline Architecture (the current state) with the Target Architecture (the future state). This comparison is used to validate the architecture by identifying any elements that have been overlooked or are missing. The analysis highlights building blocks that need to be newly developed, those that should be carried over, and those that will be eliminated, thereby identifying missing, redundant, or overlapping functions and capabilities required to meet the business objectives.

A. Quality parameters, or non-functional requirements, are inputs used to define the Target Architecture, not an output of the gap analysis itself.

C. While the analysis may reveal issues related to non-functional requirements, its core purpose is not their validation but identifying the delta between states.

D. Identifying specific commercial solutions occurs in the Opportunities and Solutions phase (Phase E), which follows the gap analysis performed in Phases B, C, and D.

E. Required service levels are part of the Target Architecture definition and serve as a benchmark for the gap analysis, not something determined by it.

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

10th Edition. Van Haren Publishing.

Section 21.1

Introduction to Gap Analysis: "A key step in validating an architecture is to consider what may have been forgotten. The architecture is checked against the business requirements to ensure all the requirements have been met. A gap is a statement of difference between two states. In the context of the TOGAF ADM

gap analysis is the technique of identifying the gaps between the Baseline and Target Architectures."

Section 21.2

Gap Analysis Matrix: This section details how the matrix is used to identify building blocks that are "New"

"Eliminated"

or "Included" (both existing and to be modified)

which directly relates to identifying missing or overlapping functions.

2. Pennsylvania State University. (n.d.). EA 871: Enterprise Architecture Foundations I

Lesson 8: Phase B: Business Architecture. Penn State College of Information Sciences and Technology.

In the courseware discussing TOGAF Phase B

it is stated: "The purpose of the gap analysis is to highlight services and/or functions that are to be carried over

services and/or functions that are to be eliminated

and services and/or functions that are new." This supports the identification of missing (new) or overlapping (to be eliminated) functions.

The objectives listed directly correspond to the official objectives of specific phases within the TOGAF Architecture Development Method (ADM).

- Objective 3, developing a high-level vision, is the primary purpose of Phase A: Architecture Vision.

- Objective 2, developing the Target Business Architecture, is the explicit goal of Phase B: Business Architecture.

- Objectives 1 and 4, developing the Target Data and Application Architectures respectively, are the two distinct sub-phases that constitute Phase C: Information Systems Architectures.

Therefore, the correct mapping is 1C, 2B, 3A, and 4C.

B. 1A-2B-3C-4D: Incorrectly assigns the Data Architecture objective to Phase A, the Vision objective to Phase C, and the Application Architecture objective to Phase D.

C. 1B-2D-3A-4C: Incorrectly assigns the Data Architecture objective to Phase B and the Business Architecture objective to Phase D.

D. 1C-2D-3B-4A: Incorrectly assigns the Business Architecture objective to Phase D, the Vision objective to Phase B, and the Application Architecture objective to Phase A.

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

10th Edition. Van Haren Publishing.

Phase A Objective (Objective 3): Part II

Chapter 6

Section 6.2

"Objectives". This section states the objective is to "Develop a high-level aspirational vision of the capabilities and business value...".

Phase B Objective (Objective 2): Part II

Chapter 7

Section 7.2

"Objectives". This section states the objective is to "Develop the Target Business Architecture...".

Phase C Objectives (Objectives 1 & 4): Part II

Chapter 8

Section 8.2

"Objectives". This section lists the objectives to "Develop the Target Data Architecture..." and "Develop the Target Application Architecture...".

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.

The TOGAF Content Metamodel provides a formal, structured definition for all architectural information and work products created during the Architecture Development Method (ADM). It defines the types of entities (e.g., building blocks, artifacts), their attributes, and the relationships between them. This structured approach ensures that architectural information is organized in an orderly and consistent way, allowing it to be effectively stored, analyzed, and processed to address the specific needs and concerns of various stakeholders.

A. A Stakeholder Map: This is a tool used to identify and analyze stakeholders and their concerns; it does not structure the architectural information itself.

B. An Architecture Framework: This is a broad set of tools, methods, and a common vocabulary for creating architectures. The Content Metamodel is a specific component within the framework.

D. An EA Library: An EA Library, or Architecture Repository, is the storage location for architectural assets. It holds the information that is structured by the Content Metamodel, but it is not the structure itself.

1. The Open Group Standard

TOGAF® Standard

10th Edition (April 2022)

Part IV: Content Framework

Chapter 23

Content Metamodel Overview

Section 23.1

Introduction: "The TOGAF Content Metamodel provides a formal definition of the architecture content

ensuring that all the information that is produced and consumed in the ADM is defined in a structured way."

2. The Open Group Standard

TOGAF® Standard

10th Edition (April 2022)

Part III: ADM Guidelines and Techniques

Chapter 21

Stakeholder Management

Section 21.3.1

Steps in the Stakeholder Management Process: Describes the stakeholder map as a matrix for categorizing stakeholders based on power and interest.

3. The Open Group Standard

TOGAF® Standard

10th Edition (April 2022)

Part V: Enterprise Metamodel and Repository

Chapter 32

Architecture Repository

Section 32.1

Introduction: "The Architecture Repository is used to store different classes of architectural output at different levels of abstraction."

The primary purpose of the Gap Analysis technique, as defined within the TOGAF framework, is to compare the Baseline (current state) Architecture with the Target (future state) Architecture. This comparison highlights the differences, or "gaps", between the two states. These gaps often manifest as functions, processes, components, or capabilities that need to be created, developed, or procured to realize the Target Architecture. Therefore, identifying these missing elements is a core objective of the technique, forming the basis for the subsequent implementation and migration planning.

A. Validating non-functional requirements is a requirements management activity, not the primary purpose of comparing two architectural states.

B. Quality metrics are established during the Architecture Vision phase to define the target state, not as a result of the gap analysis.

C. Service levels are requirements that are defined for the Target Architecture; gap analysis checks if they are met, but does not determine them.

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

10th Edition. Van Haren Publishing.

Part III

Chapter 25

Gap Analysis: This chapter explicitly defines the technique. Section 25.1 states

"Gap analysis is a technique used to compare two states of an architecture... The gaps identified form the basis for the definition of a roadmap...".

Part II

Chapter 8

Phase B: Business Architecture

Section 8.5

Step 5: This step involves performing a gap analysis to identify missing business capabilities

functions

and processes between the baseline and target.

Part II

Chapter 10

Phase C: Information Systems Architectures — Application Architecture

Section 10.5

Step 5: This step details using gap analysis to identify "Application components to be developed or procured"

which are essentially missing functions.

The question requires matching descriptions to specific TOGAF ADM deliverables.

1. The Request for Architecture Work is the initial document from a sponsoring organization that formally triggers an architecture cycle.

2. The Statement of Architecture Work is the response that outlines the scope, plan, and approach for the engagement.

3. Architecture Principles are high-level, enduring rules that guide all architecture decisions to ensure alignment with the business mission.

4. The Architecture Requirements Specification is a dynamic document that details the specific, often quantitative, requirements that the architecture must fulfill and that subsequent implementation projects must comply with.

A: This option incorrectly maps all four deliverables, for example, identifying the initial trigger document as the Architecture Requirements Specification.

B: This option misidentifies the initial trigger as the Statement of Architecture Work and the scope definition as Architecture Principles, reversing their roles.

C: This option incorrectly identifies the trigger document as Architecture Principles and the requirements list as the Statement of Architecture Work.

1. The TOGAF® Standard

10th Edition

Part III: ADM Guidelines and Techniques

Chapter 23: Architecture Content Framework.

Section 23.6.15 Request for Architecture Work: "A Request for Architecture Work is a document that is sent from the sponsoring organization to the architecture organization to trigger the start of an architecture development cycle." (Matches description 1)

Section 23.6.18 Statement of Architecture Work: "The Statement of Architecture Work is a document that defines the scope and approach that will be used to complete an architecture development cycle." (Matches description 2)

Section 23.6.6 Architecture Requirements Specification: Describes this deliverable as providing "a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture." (Matches description 4)

2. The TOGAF® Standard

10th Edition

Part III: ADM Guidelines and Techniques

Chapter 16: Architecture Principles.

Section 16.2 What is an Architecture Principle?: 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." (Matches description 3)

Risk Management is the discipline concerned with identifying, assessing, and controlling the effects of uncertainty on objectives. According to the TOGAF® standard, this uncertainty can result in deviations from the expected, which can be either positive (opportunities) or negative (threats). The core practice of Risk Management involves a continuous process of evaluating these potential outcomes and implementing strategies to mitigate threats while capitalizing on opportunities, thereby striking a balance to achieve the most favorable result for the enterprise.

A. Agile development: This is an iterative approach to software development and project management, not a strategic discipline for balancing enterprise-level opportunities and threats.

B. Architecture Security: This is a specialized area of risk management focused exclusively on protecting assets from negative security-related threats, not on balancing them with positive opportunities.

C. Transition Management: This process focuses on planning and executing the move from a baseline to a target architecture, managing the specific risks of the migration, not the broader enterprise risk landscape.

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

Version 9.2. Van Haren Publishing.

Section 33.1

Introduction: "Risk is the effect of uncertainty on objectives. An effect is a deviation from the expected — positive and/or negative." This establishes that risk encompasses both opportunities (positive) and threats (negative). The entire chapter describes the process of managing this

which is the act of "striking a balance".

2. The Open Group. (2023). Open Group Enterprise Architecture Foundation Study Guide

10th Edition (for OGEA 101).

Chapter 10

Section 10.4.3

Risk Management: This section describes risk management as a key aspect of Implementation Governance. It references the TOGAF standard's approach

which involves identifying

classifying

and mitigating risks throughout the architecture lifecycle

implicitly covering the balance between threats and opportunities defined in the core standard.

An Enterprise Architecture (EA) Capability is the organizational function responsible for effectively carrying out architectural activities. It is defined by the combination of structures, roles, responsibilities, skills, and processes that an organization puts in place. This capability enables the enterprise to establish, maintain, and leverage its architecture. The question directly describes the constituent elements that form the definition of an EA Capability as outlined in the TOGAF standard.

B. An Enterprise Architecture: This is the output or result of the architectural activity, not the organizational function or ability that creates and manages it.

C. An EA framework: This is a structured set of methods, tools, and processes (like TOGAF) used by the EA Capability to develop an Enterprise Architecture.

D. An EA repository: This is a tool or system used by the EA Capability to store, manage, and analyze architectural artifacts and information.

1. The TOGAF® Standard

10th Edition

The Open Group Standard (C220).

Part VI

Section 44.1

Establishing an Architecture Capability: "In order to carry out architectural activity effectively

it is necessary to put in place an appropriate organization

processes

roles

responsibilities

and skills to create an Architecture Capability." This statement directly aligns with the question's phrasing.

Part I

Section 3.41

Definitions: Defines Enterprise Architecture Capability as "The organization

processes

skills

and roles required to establish and operate an architecture function."

2. The Open Group Guide

A Leader’s Guide to Establishing and Evolving an EA Capability (G183).

Section 2

What is an Enterprise Architecture Capability?: This guide explains that an EA Capability is the "combination of people

process

and information that is required to deliver architecture." This reinforces that the capability is the sum of these organizational parts.

Phase E, Opportunities and Solutions, is the specific phase within the TOGAF Architecture Development Method (ADM) where the gaps identified in the preceding architecture development phases (B, C, and D) are consolidated. During this phase, potential solutions are identified, and the necessary changes are grouped into logical work packages. This process forms the basis of the initial Implementation and Migration Plan and the Architecture Roadmap, directly associating the identified architectural gaps with the work required to address them.

A. Phases G and H: These phases occur after work packages are defined. Phase G governs the implementation of the work packages, and Phase H manages changes to the architecture post-implementation.

B. Phase F: Phase F, Migration Planning, finalizes the detailed Implementation and Migration Plan and prioritizes the work packages that were initially created and grouped in Phase E.

C. Phases B, C, and D: These are the core architecture development phases where gap analysis is performed to identify the differences between the Baseline and Target Architectures, not to group them into work packages.

1. The Open Group

TOGAF® Standard

10th Edition

The TOGAF ADM.

Section 8.3

Phase E: Steps: Step 5 explicitly states

"Consolidate the gaps

solutions

and dependencies from Phases B

C

and D

and group the migration actions into work packages." This directly confirms that the association of gaps to work packages is a primary activity of Phase E.

Section 8.4

Phase E: Outputs: The "Implementation and Migration Plan" is a key output of Phase E. The description of this plan includes the "Work package portfolio

" which is the result of the grouping activity.

2. The Open Group

TOGAF® Standard

10th Edition

ADM Techniques.

Section 3.4

Gap Analysis: This section describes gap analysis as a technique used primarily in Phases B

C

D

and E. It notes that while gaps are identified in B

C

and D

they are consolidated in Phase E to form the basis for the Implementation and Migration Plan

which is structured around work packages.

The TOGAF® Standard defines four key dimensions to establish the boundaries and scope of an architecture engagement. These dimensions ensure a clear understanding of the effort's focus and limitations.

1. Breadth: The extent of the enterprise covered, from the entire enterprise to specific Lines of Business or cross-functional units.

2. Depth: The level of detail to be captured in the architecture, ranging from high-level conceptual models to detailed specifications.

3. Time Period: The timeframe the architecture will address, typically including baseline, transition, and target states.

4. Architecture Domains: The specific domains to be included, selected from Business, Data, Application, and Technology.

A. Business Data Application Technology

These are the four architecture domains themselves, which constitute only one of the four dimensions used for scoping, not the complete set of dimensions.

B. Strategy Segment Capability Budget

These are important business context and constraint elements that influence the architecture's focus, but they are not the formal dimensions defined by TOGAF for scoping the work.

D. Strategy Portfolio Project Solution Delivery

These terms describe different levels or types of architectural activity within an organization, not the specific dimensions used to scope a single architecture engagement.

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

10th Edition. Van Haren Publishing. Part III: ADM Guidelines & Techniques

Chapter 6

Section 6.3

"Scoping the Architecture". This section explicitly states

"The scope of the architecture is defined by its breadth

depth

and the time period it will cover. The scope is also dependent on which of the Architecture Domains are being covered."

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

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

Chapter 5

Section 5.4.6

"Phase A: Architecture Vision - Steps". Step 5 involves confirming and elaborating the architecture scope

which is defined by these four dimensions.

According to the TOGAF® Standard, a "concern" is explicitly defined as an interest in a system relevant to one or more of its stakeholders. Concerns are the key drivers for the creation of an architecture, as they represent the interests that need to be addressed. These interests can relate to any aspect of the system, such as performance, security, cost, or usability. The entire process of creating architecture views and viewpoints is centered around identifying and addressing these stakeholder concerns.

A. Requirements: Requirements are specific, quantifiable statements of need that are derived from broader stakeholder concerns, not the interests themselves.

B. Principles: Principles are high-level, guiding rules and constraints for the architecture, which are not the same as the fundamental interests of stakeholders.

D. Architecture views: Views are representations of the architecture created specifically to address and communicate about stakeholder concerns; they are not the concerns themselves.

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

10th Edition. Van Haren Publishing.

Part I

Chapter 3

Definitions: Defines "Concern" as "An interest in a system relevant to one or more of its stakeholders."

Part I

Chapter 3

Definitions: Defines "Stakeholder" as "An individual

team

organization

or class thereof

having an interest in

or concerns relative to

a system."

Part III

Section 24.3

Steps in the Stakeholder Management Process: Step 2 is "Identify Stakeholders' Concerns

and Key Issues".

2. ISO/IEC/IEEE. (2011). Systems and software engineering — Architecture description (Standard No. 42010:2011).

Section 3.5: Defines "concern" as an "interest in a system relevant to one or more of its stakeholders". This international standard is a normative reference for the TOGAF Standard.

• 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).