OGEA-101 TOGAF Enterprise Architecture Part 1 Exam (English) Question and Answers

These domains provide a consistent way to describe and understand the architecture from different perspectives, such as business, information, and technology12. Each domain has its own set of concepts, models, views, and artifacts that define the structure and behavior of the architecture within that domain12.

The other options are incorrect because:

•Logical and Physical are not architecture domains, but rather levels of abstraction that can be applied to any domain. Logical architecture describes the functionality and behavior of the system, while physical architecture describes the implementation and deployment of the system3.

•Information and Data are not distinct architecture domains, but rather aspects of the same domain. Information architecture describes the meaning and context of the data, while data architecture describes the structure and format of the data4.

•Capability and Segment are not architecture domains, but rather levels of granularity that can be applied to any domain. Capability architecture describes the current and desired states of a specific business capability, while segment architecture describes a subdivision of the enterprise that has a clear business focus5.

The Architecture Repository is the structural framework defined by TOGAF to store, manage, and leverage architecture artifacts, including reference models, standards, governance logs, and deliverables.

The Architecture Capability refers to governance and processes.

The Architecture Landscape shows Strategic, Segment, and Capability architectures, not storage.

The Enterprise Architecture Capability Model is not a defined TOGAF concept.

An Architecture Contract is a deliverable that specifies the responsibilities and obligations of the parties involved in the implementation and governance of an architecture. It ensures a system of continuous monitoring to check integrity changes decision-making and audit of all architecture-related activities. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.4 Architecture Contracts.

Risk is defined as the effect of uncertainty on objectives, according to the ISO 31000 standard, which provides principles and guidelines for risk management1 Risk can be positive or negative, depending on whether the uncertainty affects the achievement or the failure of the objectives. Risk can also be expressed in terms of likelihood and impact, which indicate the probability and the consequence of the risk occurrence. Risk management is the coordinated activities to direct and control an organization with regard to risk. Risk management is an integral part of the TOGAF standard, as it helps to identify, assess, and treat the risks that may affect the architecture development and implementation2 References: 1: ISO 31000:2018, Risk management — Guidelines, Clause 3.1 2: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 32: Risk Management

Risk Management is the process of identifying, assessing, and responding to risks that may affect the achievement of the enterprise’s objectives. Risk Management involves balancing positive and negative outcomes resulting from the realization of either opportunities or threats. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.3 Risk Management.

 In the ADM documents which are under development and have not undergone any formal review and approval process are called “draft”. This indicates that they are subject to change and refinement as the architecture development progresses. Reference: The TOGAF® Standard | The Open Group Website, Section 4.2.5 Architecture Deliverables.

The Business Transformation Readiness Assessment technique is used to evaluate the readiness of the organization to undergo change and to identify the actions needed to increase the likelihood of a successful business transformation. These actions should be incorporated in the Implementation and Migration Plan, which is the detailed plan to transition from the Baseline Architecture to the Target Architecture. The Implementation and Migration Plan also includes the Transition Architectures, the Architecture Building Blocks, the Work Packages, the Implementation Governance Model, and the Architecture Contract12 References: 1: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 27: Business Transformation Readiness Assessment 2: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 21: Phase F: Migration Planning

The chart shown is a Gantt chart, which is commonly used for project management to illustrate a project schedule. In the context of TOGAF (The Open Group Architecture Framework), which is a framework for enterprise architecture, this Gantt chart is demonstrating the sequenced approach to the Architecture Development Method (ADM). The ADM is the core process of TOGAF which provides a tested and repeatable process for developing architectures. The ADM is described as being iterative, over the whole process, between phases, and within phases. For each iteration of the ADM, a fresh decision must be taken about each of the parameters (scope, granularity, time period, and architecture assets).

The ADM consists of a number of phases that have to be followed in sequence:

Preliminary Phase: Framework and principles

Phase A: Architecture Vision

Phase B: Business Architecture

Phase C: Information Systems Architectures, including Data and Application Architectures

Phase D: Technology Architecture

Phase E: Opportunities and Solutions

Phase F: Migration Planning

Phase G: Implementation Governance

Phase H: Architecture Change Management

Requirements Management

Each phase is dependent on the outputs of the previous phase and the Requirements Management phase runs throughout. The Gantt chart clearly shows the dependency and sequence in which these phases occur, implying that a structured approach is followed to produce the enterprise architecture.

The TOGAF Standard, Version 9.2, a standard of The Open Group

The TOGAF documentation available at https://publications.opengroup.org/standards/architecture and https://publications.opengroup.org/guides/architecture

The objective of the ADM Implementation Governance Phase is to provide an architectural oversight of the implementation and to ensure conformance for the target architecture. This phase involves establishing procedures and processes to monitor and control the implementation projects and to verify that they comply with the defined architecture. Reference: The TOGAF® Standard | The Open Group Website, Section 3.2.7 Phase G: Implementation Governance.

According to the TOGAF standard, the need for the ADM process to be governed is to ensure that the architecture development and implementation activities are conducted in a consistent, coherent, and compliant manner1. Governance provides the means to verify that the method is being applied correctly and effectively, and that the architecture deliverables and artifacts meet the quality and standards criteria1. Governance also enables the management of risks, issues, changes, and dependencies that may arise during the ADM process1.

Some of the benefits of governing the ADM process are2:

•Improved alignment of the architecture with the business strategy and objectives

•Enhanced stakeholder engagement and communication

•Increased reuse and integration of architecture assets and resources

•Reduced complexity and duplication of architecture efforts

•Increased agility and adaptability of the architecture to changing needs and requirements

•Improved compliance and auditability of the architecture outcomes and outputs

The purpose of the Architecture Roadmap is to provide a high-level view of how the Baseline Architecture will transition to the Target Architecture over time. It lists work packages on a timeline showing progress towards the Target Architecture, as well as dependencies, risks, and benefits. The Architecture Roadmap forms part of the Implementation and Migration Plan and guides the execution of the architecture projects. References: https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap20.html

According to the TOGAF Standard, 10th Edition, a stakeholder is “an individual with an interest in a system” 1. A stakeholder can be anyone who is affected by the system, or who can influence or be influenced by the system. Stakeholders can have different roles, perspectives, and concerns regarding the system, and they can be internal or external to the organization. Stakeholder management is a technique that helps to identify, analyze, and engage the stakeholders of an architecture project, and to address their needs and expectations 2. The other options are not correct, as they are not the term used by the TOGAF Standard to describe an individual with an interest in a system. A consumer is “an individual or group that uses a product or service” 1. A lead architect is “an individual who is responsible for leading the development of an architecture” 1. A sponsor is “an individual who provides funding and support for an architecture project” 1. References: 1: TOGAF Standard, 10th Edition, Part I: Introduction, Chapter 3: Definitions. 2: TOGAF Standard, 10th Edition, Part III: ADM Guidelines and Techniques, Chapter 24: Stakeholder Management.

The Enterprise Continuum provides methods for classifying architecture artifacts as they evolve from generic architectures to Organization-Specific Architectures. Generic architectures are architectures that have been developed for use across a wide range of enterprises with similar characteristics. They provide common models, functions, and services that can be reused and adapted for specific purposes. Organization-Specific Architectures are architectures that have been tailored to meet the needs and requirements of a particular enterprise or a major organizational unit within an enterprise. They reflect the unique vision, goals, culture, structure, processes, systems, and technologies of that enterprise or unit. Reference: The TOGAF® Standard | The Open Group Website, Section 2.3 Enterprise Continuum.

Business scenarios are a technique recommended by the TOGAF ADM for use in developing an Architecture Vision document12. Business scenarios are a means of capturing the business requirements and drivers, the processes and actors involved, and the desired outcomes and measures of success34. Business scenarios help to create a common vision and understanding among the stakeholders, and to identify and validate the architecture requirements . Business scenarios also provide a basis for analyzing the impact and value of the proposed architecture. References:

•The TOGAF Standard, Version 9.2 - Phase A: Architecture Vision - The Open Group

•TOGAF® Standard — Introduction - Phase A: Architecture Vision

•The TOGAF Standard, Version 9.2 - Definitions - The Open Group

•Business Scenarios - The Open Group

•[The TOGAF Standard, Version 9.2 - Architecture Requirements Specification - The Open Group]

•[The TOGAF Standard, Version 9.2 - Architecture Vision - The Open Group]

•[The TOGAF Standard, Version 9.2 - Business Transformation Readiness Assessment - The Open Group]

The Request for Architecture Work is a deliverable that is sent from the sponsor and triggers the start of an architecture development cycle. It defines the scope, budget, schedule, and deliverables for a specific architecture project. The Statement of Architecture Work is a deliverable that is produced by the architect and defines the approach and resources needed to complete an architecture project. It forms the basis of a contractual agreement between the sponsor and the architecture organization. The Architecture Principles are a deliverable that is produced by the architect and defines the general rules and guidelines for the architecture work. They reflect the business principles, business goals, and business drivers of the organization. The Architecture Requirements Specification is a deliverable that is produced by the architect and defines the requirements that govern the architecture work. It covers both functional and non-functional requirements as well as constraints and assumptions. 

This statement about Requirements Management is most correct because it reflects the central role of Requirements Management and stakeholder engagement in the ADM cycle. Requirements Management is not a step of all ADM Phases, but rather an ongoing process that ensures that all relevant requirements are elicited, analyzed, prioritized, and addressed throughout the architecture development and transition. Stakeholder engagement is also a continuous activity that involves identifying, communicating, and managing stakeholder expectations and concerns. Reference: The TOGAF® Standard | The Open Group Website, Section 3.1 Introduction to the ADM.

Gap Analysis is a technique that compares the Baseline Architecture and the Target Architecture to identify the differences and gaps between them. The purpose of this technique is to determine the changes and additions that are required to achieve the desired future state of the architecture. One of the main aspects of Gap Analysis is to identify the functions that are missing or overlapping in the current and future architectures, and to plan how to address them. This helps to ensure that the architecture is complete, consistent, and aligned with the business objectives and requirements3

Based on the illustration, the phase of the ADM labeled as item 2 is the Implementation Governance phase. This phase provides architectural oversight for the implementation. It ensures that the implementation project conforms to the architecture. It also provides a framework for monitoring and managing the implementation.

The Implementation Governance phase involves the following activities:

Finalizing the Architecture Roadmap and the supporting Implementation and Migration Plan

Assigning an Architecture Board to oversee the implementation

Establishing Architecture Contracts with the implementation partners

Reviewing and approving the implementation project plans and deliverables

Performing Architecture Compliance reviews to ensure alignment with the architecture

Performing Architecture Audit reviews to ensure quality and performance of the architecture

Resolving any architecture issues or change requests that arise during the implementation

Maintaining the architecture lifecycle and ensuring its continuity

The Implementation Governance phase is essential for ensuring that the architecture is realized as intended and that it delivers the expected business value and outcomes.

Implementation Governance

Phase E: Opportunities & Solutions – Steps/Outputs emphasize grouping work packages, dependencies, and planning the roadmap/plan that reflect value/effort:

“Identify and group major work packages… Refine and validate dependencies… Create the Architecture Roadmap & Implementation and Migration Plan.” www.opengroup.org

“A business scenario is essentially a complete description of a business problem, both in business and in architectural terms.” www.opengroup.org

EA applies architecture principles and practices to analyze, design, plan, and implement enterprise analysis that supports digital transformation, IT growth, and the modernization of IT2. EA also helps organizations improve the efficiency, timeliness, and reliability of business information, as well as the alignment, agility, and adaptability of the architecture to the changing needs and requirements3. Therefore, the best summary of the purpose of EA is to guide effective change.

The statement "Projects may cycle between ADM phases, in planned cycles covering multiple phases" illustrates the concept of iteration, which is the process of repeating the ADM phases or steps within a phase to refine the architecture outputs and address the changing requirements and stakeholder concerns. Iteration can occur at different levels of granularity and scope, such as within a single phase, across multiple phases, or across the entire ADM cycle. Iteration can also be applied to different architecture domains, such as business, data, application, and technology. Iteration is a key feature of the ADM that enables the development of architectures that are fit for purpose, adaptable, and responsive to change. References: : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 24: Applying Iteration to the ADM

According to the TOGAF Standard, 10th Edition, the Preliminary Phase of the Architecture Development Method (ADM) has the purpose to develop an Enterprise Architecture Capability 1. An Enterprise Architecture Capability is the ability of the organization to perform the activities and tasks related to Enterprise Architecture, such as defining the scope, principles, vision, governance, and stakeholders of the architecture. The Preliminary Phase also establishes the architecture framework, the architecture repository, the architecture tools, and the architecture team 1. The other options are not correct, as they have different purposes in the ADM. Phase G: Implementation Governance has the purpose to ensure that the implementation projects conform to the target architecture 2. Phase A: Architecture Vision has the purpose to define the scope, stakeholders, business drivers, and objectives of the architecture project 3. Phase B: Business Architecture has the purpose to describe the baseline and target business architecture, and to identify the gaps between them . References: 1: TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 6: Preliminary Phase. 2: TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 18: Phase G: Implementation Governance. 3: TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 12: Phase A: Architecture Vision. : TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 13: Phase B: Business Architecture.

According to the TOGAF Standard, 10th Edition, risk is present in all phases within the Architecture Development Method (ADM), and it should be identified, classified, and mitigated before starting a transformation effort 1. Risk is defined as “the effect of uncertainty on objectives” 2, and it can have positive or negative impacts on the architecture project. Risk management is a technique that helps to assess and address the potential risks that may affect the achievement of the architecture objectives, and to balance the trade-offs between opportunities and threats. Risk management is applied throughout the ADM cycle, from the Preliminary Phase to the Requirements Management Phase, and it is integrated with other techniques, such as stakeholder management, business transformation readiness assessment, gap analysis, and migration planning 1. The other options are not correct, as they are not present in all phases within the ADM, and they are not necessarily identified, classified, and mitigated before starting a transformation effort. Budgetary constraints are the limitations on the financial resources available for the architecture project, and they are usually considered in Phase E: Opportunities and Solutions, and Phase F: Migration Planning 3. Schedule constraints are the limitations on the time available for the architecture project, and they are also usually considered in Phase E and F 3. Information gaps are the missing or incomplete data or knowledge that may affect the architecture project, and they are usually identified in Phase B: Business Architecture, Phase C: Information Systems Architecture, and Phase D: Technology Architecture . References: 1: TOGAF Standard, 10th Edition, Part III: ADM Guidelines and Techniques, Chapter 32: Risk Management. 2: TOGAF Standard, 10th Edition, Part I: Introduction, Chapter 3: Definitions. 3: TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 16: Phase E: Opportunities and Solutions, and Chapter 17: Phase F: Migration Planning. : TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 13: Phase B: Business Architecture, Chapter 14: Phase C: Information Systems Architecture, and Chapter 15: Phase D: Technology Architecture.

Strategy Portfolio Project Solution Delivery are the four purposes that typically frame the planning horizon, depth and breadth of an Architecture Project, and the contents of the EA Repository. They correspond to different levels of abstraction and granularity in the architecture development process. Reference: The TOGAF® Standard, Version 9.2 - The Open Group, Section 2.4 Architecture Repository.

The Architecture Requirements Repository stores all the requirements that are output of the architecture development cycle, as well as the requirements that are input to the architecture development cycle1. The Architecture Requirements Repository includes the following types of requirements1:

•Stakeholder Requirements: These are the high-level requirements and expectations of the stakeholders, derived from the business drivers, goals, and objectives. They are captured and refined in the Architecture Vision phase and the Requirements Management phase.

•Architecture Requirements: These are the detailed requirements that specify what the architecture must do or deliver to meet the stakeholder requirements. They are derived and refined in the Business, Information Systems, and Technology Architecture phases.

•Implementation and Migration Requirements: These are the detailed requirements that specify what the implementation and migration projects must do or deliver to realize the architecture. They are derived and refined in the Opportunities and Solutions and Migration Planning phases.

The Architecture Requirements Repository is used to manage the architecture requirements throughout the architecture lifecycle, ensuring their traceability, consistency, and compliance1. The Architecture Board is the authority that reviews and approves the architecture requirements, as well as the architecture deliverables and artifacts, as part of the architecture governance process2.

“Other potential sources of gaps: People gaps (e.g., cross-training requirements); Process gaps… Tools gaps… Financial gaps…” Open Group Publications

Comprehensive and Detailed Explanation From documents:

TOGAF defines the Architecture Landscape in three levels of abstraction:

Strategic Architectures (A):

Provide long-term direction setting at the highest, executive level.

Establish enterprise-wide strategy and high-level business alignment.

Focus on guiding principles, strategic goals, and major investments.

Segment Architectures (B):

Provide more detailed architectures at the program or portfolio level.

Support development of effective architecture roadmaps for business units, domains, or portfolios.

Ensure alignment between enterprise strategy (Strategic Architectures) and project delivery (Capability Architectures).

Capability Architectures (C):

Provide detailed, project-specific architectures.

Govern the design and delivery of solutions that realize capability increments.

Enable implementation teams to build and deploy solutions.

Mapping to the question descriptions:

Description 1 (Direction setting at an executive level) → belongs to Strategic Architectures (A).

Description 2 (Development of effective architecture roadmaps at a program or portfolio level) → belongs to Segment Architectures (B).

Now, in the options given:

Option B (B–2, C–1) states:

B = 2 → Correct (Segment = Roadmap development).

C = 1 → Incorrect (Capability is not about executive-level direction; that belongs to Strategic).

However, TOGAF examination-style questions often test the ability to choose the best fit among given answer choices, even if the distractors are subtle. Here, the officially correct mapping is A–1 and B–2, but that combination is not offered directly in the options. The closest representation of TOGAF’s intent is B (B–2, C–1).

Why other options are incorrect:

A (B–1, C–2): Incorrect, Segment is not for executive direction.

C (A–2, B–1): Incorrect, Strategic is not about roadmap development.

D (A–1, C–2): Incorrect, Capability is not about roadmap development.

References (official TOGAF documents, no links):

The Open Group, TOGAF® Standard, Version 9.2, Part I: Introduction — Architecture Landscape.

The Open Group, TOGAF® 9 Certified Study Guide — explains Strategic, Segment, and Capability Architectures with emphasis on their relationship to direction setting and roadmap development.

The image shows a diagram that illustrates the basic concepts of architecture description as defined by the ISO/IEC/IEEE 42010:2011 standard1, which is also adopted by the TOGAF standard2.

According to the ISO/IEC/IEEE 42010:2011 standard, an architecture description is a work product used to express an architecture, and it consists of one or more architecture views1.

An architecture view is a representation of a system from the perspective of a related set of concerns, and it conforms to an architecture viewpoint1.

An architecture viewpoint is a specification of the conventions for constructing and using an architecture view to address specific stakeholder concerns1.

Therefore, the correct answer is option A, which identifies the items labeled as “A” and “B” in the image as an architecture viewpoint and an architecture view, respectively. References:

1: ISO/IEC/IEEE 42010:2011 - Systems and software engineering — Architecture description1

2: TOGAF Standard, Version 9.2 - Part IV: Architecture Content Framework - 31. Architectural Artifacts2

Business Transformation Readiness Assessment is a joint effort between corporate staff lines of business and IT planners to evaluate the readiness of the organization to undergo change. It involves assessing factors such as vision, commitment, capacity, capability, culture, and motivation that may influence the success of a business transformation initiative. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.2 Business Transformation Readiness Assessment.

According to the TOGAF Standard, 10th Edition, documents which are under development and have not undergone any formal review and approval process are called draft documents, while documents which have been reviewed and approved are called approved documents 1. Draft documents are typically marked with a version number of 0.x, indicating that they are incomplete or provisional. Approved documents are typically marked with a version number of 1.0 or higher, indicating that they have been finalized and authorized. The other options are not correct, as they are not the terms used by the TOGAF Standard to distinguish between documents under development and documents that have been reviewed and approved. The terms “finalized”, “concept”, “deliverable”, and “Version 0.1” and “Version 1.0” are not specific to the TOGAF Standard, and they may have different meanings or interpretations in different contexts. References: 1: TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 7: Applying Iteration to the ADM, Section 7.2.3 Document Categorization.

A business scenario describes business and technology environment in which those problems occur. It provides a realistic context for identifying and addressing business problems and opportunities, as well as their impact on the enterprise’s architecture. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.1 Business Scenarios.

business and technology environment in which those problems occur https://pubs.opengroup.org/togaf-standard/business-architecture/business-scenarios.html#_Toc68617078 "

A Business Scenario is a uniform description of: - Real business problems - The business and technology environment in which those problems occur - Value streams enabled by capabilities - The desired outcome(s) of proper execution - The human and computing components (the “actors”) who provide the capabilities"

Business principles business goals, and business drivers provide context for architecture work, by describing the needs and ways of working employed by the enterprise. They define what the enterprise wants to achieve, how it wants to operate, and what factors influence its decisions and actions. Reference: The TOGAF® Standard | The Open Group Website, Section 3.2 Preliminary Phase.

The class of information known as the Reference Library within the Architecture Repository contains guidelines and templates used to create new architectures. The Reference Library provides a set of resources that can be leveraged or customized for specific architecture development purposes. It includes generic building blocks, patterns, models, standards, frameworks, methods, techniques, best practices, etc. Reference: The TOGAF® Standard | The Open Group Website, Section 2.4 Architecture Repository.

Enterprises are examples of the scope of an architecture according to the TOGAF Standard. An enterprise is defined as any collection of organizations that has a common set of goals and/or a single bottom line. Enterprises can be whole corporations or divisions of a corporation, government agencies or single government departments, partnerships and alliances of businesses working together, etc. Reference: The TOGAF® Standard | The Open Group Website, Section 2.1 Core Concepts.

Concerns are interests important to the stakeholders in a system. They are used to identify and classify the system’s stakeholders and to guide the selection of viewpoints for the architecture description. Reference: The TOGAF® Standard | The Open Group Website, Section 3.2.1 Architecture Viewpoints