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

Phase A: Architecture Vision is the initial phase of an architecture development cycle. Its primary objectives are to establish the scope of the architecture project, secure stakeholder buy-in, and create a high-level vision of the target state. A critical part of this phase involves identifying the key stakeholders, understanding their concerns, and defining the business problem and requirements that the architecture must address. This phase sets the foundation for all subsequent architecture work by ensuring a clear, shared understanding of the project's goals and constraints, which are documented in the Statement of Architecture Work.

B. Preliminary Phase: This phase focuses on establishing the organization's Architecture Capability, not on defining the problem for a specific architecture project.

C. Phase C: This phase develops the Information Systems Architectures (Data and Application), which occurs after the problem and vision have been defined.

D. Phase B: This phase develops the detailed Business Architecture based on the vision and requirements that were established and defined in Phase A.

1. The Open Group. (2022). TOGAF® Standard, 10th Edition. Van Haren Publishing.

Part II, Chapter 6, Section 6.1 (Objectives): "The objectives of Phase A are to: ... Identify the key stakeholders, their concerns, and objectives."

Part II, Chapter 6, Section 6.4 (Steps), Step 2: The step is explicitly named "Identify Stakeholders, Concerns, and Business Requirements". This step details the process of engaging with stakeholders to understand the business problem and elicit requirements.

Part II, Chapter 6, Section 6.2 (Approach): "Phase A starts with receipt of a Request for Architecture Work from the sponsoring organization... A key part of this phase is to identify the stakeholders and their concerns and objectives, and to define the key business requirements to be addressed..."

The provided exhibit displays the standard diagram for The Open Group Architecture Framework (TOGAF) Architecture Development Method (ADM).

1. The central circle, labeled '1', represents Requirements Management. This is a dynamic and continuous process that runs through all phases of the ADM cycle.

2. The phase labeled '2' is Phase G, which is Implementation Governance. This phase ensures that the implementation projects conform to the defined architecture.

3. The phase labeled '3', which precedes Phase A (Architecture Vision), is the Preliminary phase. This phase focuses on preparing the organization for a successful architecture project, including defining the architecture principles and framework.

A. Label 1 is Requirements Management. Architecture Governance is a broader concept that oversees the entire architecture practice, not just the central ADM process.

B. Label 2 is Implementation Governance (Phase G), not Change Management, which is the focus of Phase H. Label 3 is the Preliminary phase, not Strategy.

D. Label 2 is Implementation Governance (Phase G), not Migration Planning (Phase F). Label 3 is the Preliminary phase, not Architecture Vision (Phase A).

1. The Open Group. (2022). TOGAF® Standard, 10th Edition. Van Haren Publishing. Part II, Chapter 3, Figure 3-1 "The ADM Cycle" explicitly shows the central process as "Requirements Management".

2. The Open Group. (2022). TOGAF® Standard, 10th Edition. Van Haren Publishing. Part II, Chapter 4, Section 4.1 "Objectives" describes the Preliminary phase as preparing the organization for architecture development.

3. The Open Group. (2022). TOGAF® Standard, 10th Edition. Van Haren Publishing. Part II, Chapter 12, Section 12.1 "Objectives" defines the purpose of Phase G as ensuring conformance for implementation projects.

4. The Open Group. (2022). TOGAF® Standard, 10th Edition. Van Haren Publishing. Part II, Chapter 17, Section 17.1 "Objectives" details the Requirements Management process as central to the ADM.

Risk Management is the overarching discipline that involves the coordinated activities to direct and control an organization with regard to risk. It is the direct application of the outputs from risk assessment and risk analysis to the decision-making process. Specifically, risk management uses the understanding of potential losses and their probabilities (from analysis and assessment) to decide on appropriate actions, such as accepting, mitigating, transferring, or avoiding the risk, in order to achieve organizational objectives.

B. Security Governance: This is a broader framework of policies, roles, and processes for oversight and accountability; it is not the direct application of risk analysis in decision-making itself.

C. Information Security Management: This is a specific management domain focused on protecting information assets. While it heavily utilizes risk management, the question describes the core process, not its application to a single domain.

D. Security Architecture: This refers to the design of security controls. It is an output or result of decisions made through risk management, not the decision-making process itself.

1. The Open Group Standard, "Risk Taxonomy (O-RT), Version 3.0," Document No. C20A, January 2020. Section 2.1, "Definitions," defines Risk Management as the "coordinated activities to direct and control an organization with regard to risk," which inherently includes decision-making based on the inputs of Risk Assessment.

2. The Open Group Standard, "Open FAIR™ Body of Knowledge," Document No. C197, October 2019. Section 1.2, "What is Risk Management?", describes it as "the set of processes and structures that an organization uses to manage the uncertainties it faces in achieving its objectives," which is fundamentally a decision-making process.

3. ISO/IEC 31000:2018, "Risk management — Guidelines." The Open Group standards are aligned with this international standard. Clause 6, "Process," outlines the risk management process where Risk Assessment (Clause 6.4) directly informs Risk Treatment (Clause 6.5), which is the selection and implementation of options for addressing risk (i.e., decision-making).

The quality of Robustness ensures an architecture principle is unambiguous, clear, and enables high-quality decisions. A robust principle is sufficiently definitive and precise to support consistent decision-making, especially in complex or potentially controversial situations. It ensures that any decisions made can be demonstrably compliant with the principle. This precision is crucial for guiding architects and stakeholders effectively when navigating intricate trade-offs and unforeseen circumstances, thereby maintaining the integrity of the architecture.

A. Consistency: This criterion means that principles should not contradict each other, focusing on the relationship between principles rather than the quality of a single one.

B. Completeness: This ensures a principle covers all relevant situations and is at the right level of detail, but does not specifically address its precision for complex decision-making.

C. Stability: This refers to the enduring nature of a principle over time, indicating it should not be subject to frequent, trivial changes.

The Open Group Standard, TOGAF® Standard, 10th Edition. (2022). Part III: ADM Guidelines & Techniques, Chapter 19, Section 19.2, "Qualities of Architecture Principles". The standard defines Robustness as: "A principle will be robust if it is unambiguous and clear. It should be sufficiently definitive and precise to support consistent decision-making in complex, potentially controversial situations."

Within the TOGAF framework, the term "ratified" is used to denote the formal approval of a deliverable following a comprehensive review process. This action is typically performed by a governing body, such as an Architecture Board. Ratification signifies that the deliverable has been officially sanctioned and accepted as a baseline or standard for the enterprise. While terms like "approved" or "final" are related, "ratified" specifically implies endorsement through a formal governance structure, which is a core concept in the Architecture Development Method (ADM).

A. approved: This is a general term; "ratified" is more specific to the formal sanctioning by a governance body within the TOGAF framework.

B. version 0.9: This typically denotes a draft or candidate version of a deliverable that is still under review, not one that has been completed and approved.

D. final: This term indicates the end of development for a version but lacks the specific connotation of formal governance approval implied by "ratified".

---

1. The Open Group Standard, TOGAF® Standard, Version 9.2 (April 2018). In Part VII, Section 49.2.2, "Architecture Board", it states: "The Architecture Board is typically made responsible for the governance of the architecture, and has the responsibility for approving/ratifying architecture deliverables." This directly links the term "ratifying" to the formal approval of deliverables by the governance board.

2. The Open Group Standard, TOGAF® Standard, 10th Edition (April 2022). In Part VI, Section 44.4.3, "Architecture Compliance", the process of formal review is described: "The compliance review is a formal review of the architecture... The review will determine whether the architecture is compliant and, if not, what the remedial actions are... The outcome of the review is a formal sign-off." The state following this formal sign-off by a board is best described as "ratified".

3. The Open Group Standard, TOGAF® Standard, 10th Edition (April 2022). Part VI, Section 44.2.2, "Architecture Board", outlines the board's responsibilities, which include the formal approval of deliverables, a process culminating in ratification.

The relationship between a business model and business architecture is complementary. A business model provides a high-level, conceptual view of how an organization creates, delivers, and captures value. Business architecture operationalizes this model by deconstructing it into a more detailed, multi-dimensional blueprint. It breaks the business model down into its core functional elements—such as capabilities, value streams, and organizational structures—to provide a clear and detailed understanding of how the business actually works to execute the strategy defined in the business model.

A. This statement reverses the roles. Business models provide the conceptual summary, while Business Architecture offers the detailed, in-depth analysis of the business's operational components.

C. This creates a false distinction. Both business models and Business Architecture are valuable for impact and scenario analysis, though they are applied at different levels of detail.

D. While developing a business model before the architecture is a common approach, it is not a strict prerequisite. The relationship is symbiotic; an existing architecture can be used to analyze and inform a new business model.

1. The Open Group. (2021). Open Business Architecture (O-BA) Standard, Part I, Version 1.0.1 (Document No. C212). The Open Group. In Section 2.3, "Relationship between Business Models and Business Architecture," it states, "A Business Architecture breaks a business model down into its constituent parts, showing how the business works... A business model provides a high-level, often conceptual view of a business... A Business Architecture provides a more detailed, multi-dimensional view of the same business." This directly supports option B and refutes option A. The same section also notes the relationship is complementary, which refutes the "prerequisite" claim in option D.

The TOGAF® Standard explicitly identifies the Business Scenarios technique as a crucial tool for the early phases of the Architecture Development Method (ADM). It is used in the Preliminary Phase to frame the business context and in Phase A (Architecture Vision) to identify, understand, and prioritize business requirements. The resulting Architecture Vision and requirements, shaped by these scenarios, are then fundamental inputs for developing the Target Business Architecture in Phase B. This makes its application central to these initial, vision-setting phases.

A. Resolving impacts across the landscape in Phases B, C, and D is primarily addressed by gap analysis and impact assessment techniques, not the business scenario technique itself.

C. The lessons learned activity is a general project management practice to capture knowledge and is not a specific application of the business scenario technique.

D. Business transformation readiness assessment in Phase E evaluates an organization's capacity for change, a distinct activity from using scenarios to define architectural requirements.

1. The Open Group Standard, TOGAF® Standard, 10th Edition, (2022). Part III: ADM Guidelines and Techniques, Chapter 25, Section 25.1 Introduction. This section states, "Business scenarios are an important technique to use in the early phases of the ADM (specifically the Preliminary Phase and Phase A) to ensure that the business requirements are clearly understood...".

2. The Open Group Standard, TOGAF® Standard, 10th Edition, (2022). Part II: Architecture Development Method (ADM), Chapter 5: Phase A: Architecture Vision, Section 5.4.3 Business Scenarios. This section details the application of the technique within Phase A to create the Architecture Vision.

3. The Open Group Standard, TOGAF® Standard, 10th Edition, (2022). Part II: Architecture Development Method (ADM), Chapter 6: Phase B: Business Architecture, Section 6.2 Inputs. This section lists the Architecture Vision and Statement of Architecture Work (outputs from Phase A, developed using business scenarios) as key inputs to Phase B.

The TOGAF® Architecture Development Method (ADM) is fundamentally iterative. Phase A (Architecture Vision) establishes a high-level, aspirational view, including initial versions of key artifacts like business capability maps and value streams to define the scope. Phase B (Business Architecture) is dedicated to developing a detailed and validated baseline and target Business Architecture. This process inherently involves refining, detailing, and validating the preliminary artifacts created in Phase A. Therefore, the need to update these descriptions is a direct consequence of the iterative progression from a high-level vision to a detailed architectural model.

A. Phase B requires that all Architecture Descriptions be updated.

This statement is too absolute. While key artifacts are refined, not every single description from Phase A necessarily requires an update; the focus is on detailing and validating what is needed for the Business Architecture.

C. Phase B is an ADM Architecture Development phase.

This is a true statement but does not explain why the updates are necessary. It describes the classification of the phase, not the underlying process or reason for the work performed within it.

D. A new value stream was assessed as in the project scope.

This describes a specific event that could trigger an update, but it is not the fundamental, procedural reason. The iterative nature of the ADM is the core principle that mandates refinement, regardless of specific scope changes.

---

1. The Open Group Standard, TOGAF® Standard, 10th Edition, The TOGAF ADM, Part II, Section 4.3, "The ADM, Iteration, and Levels": This section explicitly states, "The ADM is iterative, over the whole process, between phases, and within phases." This supports the principle that artifacts from an earlier phase (A) are refined in a later phase (B).

2. The Open Group Standard, TOGAF® Standard, 10th Edition, The TOGAF ADM, Part II, Section 6.2, "Phase B: Business Architecture - Objectives": The objectives for Phase B include developing the Target Business Architecture that addresses stakeholder concerns. This implies a more detailed and validated output than the high-level vision from Phase A, necessitating the refinement of initial artifacts.

3. The Open Group Standard, TOGAF® Standard, 10th Edition, The TOGAF ADM, Part II, Section 5.4.3, "Phase A: Architecture Vision - Steps": Step 7 involves developing the Architecture Vision, which includes creating "high-level" views of the Baseline and Target Architectures. The term "high-level" confirms these are preliminary and intended for later refinement in Phases B, C, and D.

When initiating the Business Architecture phase (Phase B) of the Architecture Development Method (ADM), any existing architectural descriptions of the enterprise are leveraged as the primary input. These descriptions represent the current state of the business. The TOGAF® Standard explicitly states that if an existing Business Architecture is in place, it should be used as the starting point for developing the Baseline Business Architecture Description. This practice ensures that the architecture work is grounded in the current reality and avoids redundant effort by building upon previously completed work.

A. Identifying work packages for portfolio planning is a primary activity of Phase E (Opportunities & Solutions) and Phase F (Migration Planning), not the initial use of existing descriptions in Phase B.

B. The Governance Repository stores governance artifacts like compliance assessments and logs, not the descriptive content of the Architecture Landscape itself.

D. Business principles are typically defined in the Preliminary Phase or Phase A (Architecture Vision) and serve as constraints that guide the architecture development, not something validated by existing descriptions.

1. The Open Group, "The TOGAF® Standard, 10th Edition," Van Haren Publishing, 2022. In Part II, Chapter 7: Phase B: Business Architecture, Section 7.4.2 "Develop Baseline Business Architecture Description" states: "If an existing Business Architecture is in place, it will be used as the starting point, and then validated and enhanced as necessary."

2. The Open Group, "The TOGAF® Standard, 10th Edition," Van Haren Publishing, 2022. In Part II, Chapter 7: Phase B: Business Architecture, Section 7.3 "Inputs" lists "Existing architecture documentation (when available)" as a key input to the phase, reinforcing its use as a foundational element.

3. The Open Group, "The TOGAF® Standard, 10th Edition," Van Haren Publishing, 2022. In Part IV, Chapter 35: Architecture Repository, Section 35.2.4 "Governance Repository" describes its contents as governance-related information, which is distinct from the architectural descriptions found in the Architecture Landscape.

The diagram illustrates a hierarchical decomposition of what a business does to fulfill its purpose, which is the definition of a Business Capability Map. It organizes the enterprise's capabilities into logical groupings, starting from high-level functions (e.g., "Manage Enterprise") and breaking them down into more granular abilities (e.g., "Manage Human Resources" -> "Recruit & Hire"). This artifact provides a stable, business-centric view of the organization's functions, independent of the specific processes, organizational structure, or IT systems used to execute them. It is a foundational artifact in business architecture for strategic planning and analysis.

B. Business Capabilities Layer diagram: While the diagram does represent the business capabilities layer, "Business Capability Map" is the specific and formally recognized name for this type of artifact within the business architecture discipline.

C. Business Capability/Value Stream Mapping: This is incorrect because the diagram does not depict a value stream. A value stream map illustrates the end-to-end sequence of activities required to deliver value to a stakeholder, which is not represented here.

D. Business Relationships diagram: This is incorrect as the diagram does not show the relationships or interactions between different business entities, partners, or stakeholders. It shows a functional decomposition of abilities.

1. The Open Group, The O-BA Standard, Version 1.0, A Pocket Guide (Document G212), January 2021.

Section 4.2, Business Capability Mapping: "A business capability map is a visual representation of the business capabilities that exist within an organization... Business capability maps are typically depicted in a hierarchy, with Level 1 capabilities at the top and lower-level capabilities nested underneath." The diagram in the question directly matches this description and the example provided in Figure 4-2.

2. The Open Group, The O-BA Standard, Version 1.0, A Pocket Guide (Document G212), January 2021.

Section 4.3, Value Stream Mapping: This section defines a value stream as "an end-to-end view of how value is delivered to a stakeholder". The example in Figure 4-4 shows a linear flow of stages, which is structurally different from the hierarchical map in the question, confirming that option C is incorrect.