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

According to the TOGAF Standard, 10th Edition, an architecture contract is “a formal agreement between a service provider and a service consumer that defines the mutual commitments and expectations for the delivery of an architecture” 1. An architecture contract is a governed approach of a particular deliverable that will ensure adherence to the principles, standards, and requirements of the existing or developing architectures, as it specifies the roles, responsibilities, deliverables, quality criteria, and acceptance criteria for the architecture work 1. The other options are not correct, as they are not governed approaches of a particular deliverable, but rather different types of deliverables within the architecture development process. An architecture vision is “a high-level, aspirational view of the target architecture” 1. A statement of architecture work is “a document that defines the scope and approach that will be used to complete an architecture project” 1. An architecture definition document is “a document that describes the baseline and target architectures for one or more domains” 1. References: 1: TOGAF Standard, 10th Edition, Part I: Introduction, Chapter 3: Definitions.

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 TOGAF Architecture Development Method (ADM) is best described as a repeatable process for developing architectures. It provides the step-by-step method used to create, evolve, govern, and manage enterprise architectures in a consistent and structured way. The ADM is the core of TOGAF and defines how architecture work progresses from preparation and vision through business, data, application, and technology architecture, then into opportunities, migration planning, implementation governance, and change management.

Option A is incorrect because a classification mechanism is not the purpose of the ADM. Option B is too narrow, since requirements management is only one supporting aspect of the ADM, not its full definition. Option C is also incorrect because readiness assessment may be used as a technique within architecture practice, but it is not what the ADM itself is.

The strength of the ADM is that it is iterative, adaptable, and repeatable. It can be tailored for different enterprises and change scenarios while still preserving a consistent method. This makes it suitable for both large transformation efforts and more focused architecture initiatives. Therefore, the best description is option D, a repeatable process for developing architectures.

•Phase A: Architecture Vision

oDevelop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture

oDefine the scope and boundaries of the architecture engagement

oIdentify the key stakeholders and their concerns and expectations

oDefine the Architecture Vision statement and the Architecture Definition Document

oObtain approval and commitment from the sponsors and stakeholders

•Phase B: Business Architecture

oDevelop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals

oDefine the Baseline Business Architecture, if not available

oPerform a gap analysis between the Baseline and Target Business Architectures

oDefine candidate roadmap components for the Business Architecture

oResolve impacts across the Architecture Landscape

•Phase C: Information Systems Architecture

oDevelop the Target Data Architecture that enables the Business Architecture and the Architecture Vision

oDevelop the Target Application Architecture that supports the Business Architecture and the Architecture Vision

oDefine the Baseline Data and Application Architectures, if not available

oPerform a gap analysis between the Baseline and Target Data and Application Architectures

oDefine candidate roadmap components for the Information Systems Architecture

oResolve impacts across the Architecture Landscape

•Phase D: Technology Architecture

oDevelop the Target Technology Architecture that enables the Information Systems Architecture and the Architecture Vision

oDefine the Baseline Technology Architecture, if not available

oPerform a gap analysis between the Baseline and Target Technology Architectures

oIdentify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures

oResolve impacts across the Architecture Landscape

Therefore, the correct matching of the objectives and the phases is:

•1C: Develop the Target Data Architecture that enables the Business Architecture and the Architecture Vision

•2B: Develop the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals

•3A: Develop a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture

•4D: Identify candidate Architecture Roadmap components based upon gaps between the Baseline and Target Technology Architectures

The purpose of the Gap Analysis technique is similar to the previous question, but with a focus on the Target Architecture. The technique helps to identify the items that are not included or specified in the Target Architecture, such as capabilities, services, components, standards, or technologies. These items may be essential for achieving the vision and goals of the enterprise, or for addressing the stakeholder concerns and requirements. By identifying the items omitted from the Target Architecture, the technique helps to ensure that the architecture is comprehensive, feasible, and realistic.

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. 

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 "

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

The TOGAF standard covers the development of four architecture domains: Business, Data, Technology and Application. These domains represent different aspects of an enterprise’s architecture and provide a consistent way of describing, analyzing, and designing them. Reference: The TOGAF® Standard | The Open Group Website, Section 2.2 Architecture Development Method (ADM).

Building blocks are reusable components of business, IT, or architectural capability that can be combined to deliver architectures and solutions. Building blocks can be defined at various levels of detail, depending on the stage of architecture development. In the earlier phases of the ADM cycle (A to D), building blocks are defined in generic terms, such as logical or physical, to provide a high-level view of the architecture. In Phase E: Opportunities and Solutions, building blocks become implementation-specific, meaning that they are linked to specific products, standards, technologies, and vendors that are available in the market. This phase also identifies the delivery vehicles, such as projects, programs, or portfolios, that will realize the building blocks12 References: 1: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 23: Phase E: Opportunities and Solutions 2: The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter 36: Building Blocks

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.

According to the TOGAF Standard, an architecture view is a representation of a system from the perspective of a related set of concerns1. An architecture viewpoint is a specification of the conventions for a particular kind of architecture view1. Presenting different architecture views and architecture viewpoints to stakeholders helps architects to extract hidden agendas, principles, and requirements that could impact the final target architecture. This is because different stakeholders may have different concerns and interests in the system, and by showing them how the system addresses their concerns from different perspectives, the architects can elicit more feedback and validation from them2. For example, a business stakeholder may be interested in the business architecture view, which focuses on the business processes, functions, and capabilities of the system3. A security stakeholder may be interested in the enterprise security view, which addresses the security aspects of the system, such as confidentiality, integrity, and availability3. By presenting these views to the respective stakeholders, the architects can ensure that the system meets their expectations and needs, and also identify any potential issues or gaps that may affect the target architecture. References: 1: The TOGAF Standard, Version 9.2 - Architectural Artifacts - The Open Group1; 2: Understanding TOGAF Views and Viewpoints in Enterprise Architecture2; 3: Developing Architecture Views - The Open Group4

The Implications section describes the impact of adhering to the principle on the organization, the processes, the information systems, and the technology23. It also identifies the changes, costs, and risks that may result from applying the principle23. The Implications section helps to communicate the benefits and consequences of the principle to the stakeholders and to guide the implementation and governance of the architecture23.

The other sections of the TOGAF template for Architecture Principles are1:

•Name: This section provides a short and memorable name for the principle that represents its essence and purpose23. The name should not mention any specific technology or solution23.

•Statement: This section provides a concise and formal definition of the principle that expresses the fundamental rule or constraint that the principle imposes23. The statement should be clear, unambiguous, and testable23.

•Rationale: This section provides the reasoning and justification for the principle, explaining why it is important and how it supports the business goals and drivers23. The rationale should also link the principle to the higher-level enterprise or IT principles that it elaborates on23.

The illustration shows the relationship between the Enterprise Continuum, the Architecture Continuum, and the Solutions Continuum, which are key concepts in the TOGAF framework. The Enterprise Continuum is a view of the Architecture Repository that shows how generic foundation architectures can be leveraged and specialized to support the requirements of an individual organization. The Architecture Continuum specifies a structured classification for architectural artifacts, such as models, patterns, and descriptions, that can be reused and adapted across different domains and levels of abstraction. The Solutions Continuum identifies implemented solutions that support various stages of business and IT capability evolution, such as common systems, industry solutions, and organization-specific solutions. The illustration also shows how the architecture context and requirements are influenced by external factors, such as business drivers, stakeholders, and standards, and how they shape the generic and specific architectures and solutions. The illustration also shows how the deployed solutions become part of the architecture context for future iterations of the architecture development cycle. References:

•TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 6: Architecture Repository, Section 6.2 Enterprise Continuum.

•TOGAF Standard, 10th Edition, Part IV: Architecture Content Framework, Chapter 35: Enterprise Continuum and Tools, Section 35.1 Introduction.

According to the TOGAF standard, the two statements provided refer to different scopes within which architecture can be developed:

Groups of countries, governments, or governmental organizations working together typically align with broader, often international, scopes of architecture that transcend individual enterprise boundaries.

Partnerships and alliances of businesses working together, such as a consortium or supply chain, refer to collaborative efforts that can define architecture at a scope involving multiple enterprises.

In both cases, the term " Architectures Scopes " is appropriate because it reflects the varying levels and contexts in which architectures can be defined, ranging from single business units to collaborative inter-organizational efforts.

In the TOGAF Standard, the concept of an Enterprise Architecture is broken into several primary architecture domains. These domains provide a structured way to describe the enterprise from multiple perspectives that collectively support transformation and governance. TOGAF specifies four core architecture domains: Business Architecture, Data Architecture, Application Architecture, and Technology Architecture. These domains, when combined, form a comprehensive view of how the enterprise functions, how information flows, how systems interact, and what technologies support the organization.

Among the choices provided, only Business and Technology are officially recognized architecture domains in TOGAF. The Business Architecture describes business strategy, governance, organization, and key processes. The Technology Architecture defines the logical and physical technology infrastructure necessary to support mission-critical applications and data. The other answer options do not represent TOGAF architecture domains; for example, “Strategy,” “Vision,” “Target,” or “Digital” are not formal architecture domains in TOGAF. Thus, the pair that correctly identifies subsets of an enterprise architecture according to the TOGAF framework is Business and Technology Architecture.

In TOGAF, draft deliverables are those that are not yet finished or approved. They are work-in-progress versions that may have version numbers like 0.1, 0.5, or 0.9.

Once reviewed and approved, they become final deliverables.

According to the TOGAF Standard, Version 9.2, an architecture view is a representation of a system from the perspective of a related set of concerns1. It consists of one or more architecture models that demonstrate how the system addresses the stakeholder concerns1.

An architecture viewpoint is a specification of the conventions for constructing and using an architecture view to address specific stakeholder concerns1. It defines the perspective, scope, notation, and techniques for creating an architecture view of a system1.

Architects can present architecture views and viewpoints to stakeholders to extract hidden agendas, principles, and requirements that could impact the final Target Architecture, because23:

Architecture views and viewpoints help to communicate and visualize the architecture in a way that is meaningful and relevant to different stakeholders, addressing their specific interests and needs.

Architecture views and viewpoints help to elicit and validate the stakeholder concerns and requirements, ensuring that they are aligned with the business goals and objectives, and that they are consistent and feasible within the architecture context.

Architecture views and viewpoints help to identify and resolve any conflicts, gaps, or trade-offs among the stakeholder concerns and requirements, ensuring that they are balanced and prioritized in the architecture design and decision-making.

Architecture views and viewpoints help to demonstrate and verify the value and benefits of the architecture to the stakeholders, ensuring that they are satisfied and committed to the architecture outcome and governance.

1: The TOGAF Standard, Version 9.2, Chapter 22: Architecture Views, Viewpoints, and Stakeholders

2: The TOGAF Standard, Version 9.2, Chapter 4: Introduction to Part II, Section 4.2: What is an Architecture Framework?

3: The TOGAF Standard, Version 9.2, Chapter 31: Architectural Artifacts, Section 31.1: Basic Concepts

Business scenarios are a technique for capturing, clarifying, and communicating the functional and non-functional requirements of a system. Business scenarios describe the business environment, the actors involved, the desired outcomes, and the processes or rules that govern the behavior of the system. Business scenarios are useful for ensuring that the architecture addresses the real needs and concerns of the stakeholders, and for validating and testing the architecture against expected situations. Business scenarios are developed in Phase A: Architecture Vision of the ADM cycle, and refined and updated throughout the other phases3 References: 3: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 26: Business Scenarios : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18: Phase A: Architecture Vision

In TOGAF’s ADM, the Request for Architecture Work is the deliverable issued by the sponsoring organization (or stakeholder) to formally request that the architecture team perform a full architecture development cycle. That corresponds to your “deliverable 3.” Then, the architecture team responds by producing a Statement of Architecture Work (in Phase A), which defines the scope, constraints, approach, and highlevel tasks for the architecture development. That is your “deliverable 4” (the scope and approach). Thus deliverable 3 is the Request for Architecture Work, and deliverable 4 is generated in Phase A. The Request triggers the cycle; the Statement of Architecture Work (in Phase A) lays down how the architecture work will proceed, including scoping and approach.

In TOGAF, each deliverable within the Architecture Development Method (ADM) has a specific role within the architecture lifecycle. Deliverable 3 in the question refers to the Request for Architecture Work, which is the formal document sent from the sponsoring organization to the architecture team to initiate an architecture development cycle. In practice, this request is associated with the organization’s established architecture capability and governance framework, which are created during the Preliminary Phase. The Preliminary Phase establishes how architecture work is requested, initiated, and governed across the enterprise. Therefore, the Request for Architecture Work is closely tied to outputs of the Preliminary Phase.

Deliverable 4 refers to the Architecture Requirements Specification, which contains quantitative and measurable statements that define what implementation projects must do to comply with the approved architecture. This specification becomes a key reference during implementation governance and serves as a major component guiding implementation projects, ensuring that solution delivery aligns with the architecture.

Thus, the correct completion of the sentence is that deliverable 3 originates from the Preliminary Phase, and deliverable 4 becomes a major component of an implementation project used to enforce architectural compliance during execution.

According to the TOGAF Standard, 10th Edition, architecture governance is “the practice by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level” 1. Architecture governance ensures that the architecture development and implementation are aligned with the strategic objectives, principles, standards, and requirements of the enterprise, and that they deliver the expected value and outcomes. Architecture governance also involves establishing and maintaining the architecture framework, repository, board, contracts, and compliance reviews 1. The other options are not correct, as they are not the term used by the TOGAF Standard to describe the practice by which the enterprise architecture is managed and controlled at an enterprise-wide level. Corporate governance is “the system by which an organization is directed and controlled” 2, and it covers aspects such as leadership, strategy, performance, accountability, and ethics. IT governance is “the system by which the current and future use of IT is directed and controlled” 2, and it covers aspects such as IT strategy, policies, standards, and services. Technology governance is “the system by which the technology decisions and investments are directed and controlled” 3, and it covers aspects such as technology selection, acquisition, deployment, and maintenance. References: 1: TOGAF Standard, 10th Edition, Part VI: Architecture Governance, Chapter 44: Introduction. 2: TOGAF Standard, 10th Edition, Part I: Introduction, Chapter 3: Definitions. 3: TOGAF Series Guide: Using the TOGAF Framework to Define and Govern Service-Oriented Architectures, Part II: Using the TOGAF Framework to Define and Govern Service-Oriented Architectures, Chapter 5: Technology Governance.

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.

“TOGAF defines **‘enterprise’ as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.” www.opengroup.org

Architecture Requirements Specification: “provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture.” Open Group Publications

Statement of Architecture Work (Phase A output): “The Statement of Architecture Work defines the scope and approach that will be used to complete an architecture project.” (Produced in Phase A per the Phase A outputs list.) Open Group Publications

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

The Enterprise Continuum consists of two complementary concepts: the Architecture Continuum and the Solutions Continuum1. The Architecture Continuum provides a consistent way to describe and understand the generic and reusable architecture building blocks, such as models, patterns, and standards, that can be applied and tailored to specific situations2. The Solutions Continuum provides a consistent way to describe and understand the specific and implemented solution building blocks, such as products, services, and components, that realize the architecture building blocks3. The Enterprise Continuum enables the reuse and integration of architecture and solution assets across different levels of abstraction, scope, and detail, ranging from foundation architectures to organization-specific architectures1.

The Enterprise Continuum is used when developing an enterprise architecture to support the following activities1:

•Selecting relevant architecture and solution assets from the Architecture Repository or other sources, based on the business drivers, goals, and requirements

•Adapting and customizing the architecture and solution assets to suit the specific needs and context of the enterprise

•Defining and developing the target architecture and the architecture roadmap, based on the gaps and opportunities identified between the baseline and the target states

•Defining and developing the implementation and migration plan, based on the architecture roadmap and the solution building blocks

•Governing and managing the architecture and solution assets throughout the architecture lifecycle, ensuring their quality, consistency, and compliance

Based on the web search results, architecture partitioning is a technique that divides the Enterprise Architecture into smaller and manageable segments or groups, based on various classification criteria, such as subject matter, time, maturity, volatility, etc.12 Architecture partitioning is used to simplify the development and management of the Enterprise Architecture, by reducing complexity, improving governance, enhancing reusability, and increasing alignment and agility12. Therefore, the statement that partitions are used to simplify the management of the Enterprise Architecture is correct.

The other statements are incorrect because:

•Partitions are not equivalent to architecture levels. Architecture levels are different layers of abstraction that describe the Enterprise Architecture from different perspectives, such as strategic, segment, and capability3. Partitions are subsets of architectures that are defined within or across the levels, based on specific criteria1.

•Partitions do not necessarily reflect the organization’s structure. The organization’s structure is one possible criterion for partitioning the architecture, but it is not the only one. Other criteria, such as business function, product, service, geography, etc., can also be used to partition the architecture12.

•Partitions are not defined and assigned to agile Enterprise Architecture teams. Agile Enterprise Architecture is an approach that applies agile principles and practices to the architecture work, such as iterative development, frequent feedback, adaptive planning, and continuous delivery4. Partitions are not a specific feature of agile Enterprise Architecture, but a general technique that can be applied to any architecture method or framework, including TOGAF12.

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.

When scoping an architecture in TOGAF, three key axes (dimensions) are used to frame the extent of the architecture work. The first is time period (how far into the future or over what timeframe to plan). The second is depth—how detailed or granular the architecture models will be (e.g., high level, mid level, very detailed). The third is breadth, which refers to which parts (domains, business units, functions) of the enterprise will be included, and which architecture domains (business, data, application, technology) will be in scope. This triple‐dimension model helps architects, stakeholders, and governance bodies understand how wide, deep, and forwardlooking the architecture effort will be. Thus “breadth, architecture domains” is the correct third dimension.

The following activities are part of Risk Management:

Initial risk assessment

Risk mitigation and residual risk assessment

Risk monitoring

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 TOGAF, an Architecture Principle is defined using a structured template that includes several key elements such as Name, Statement, Rationale, and Implications. Each element serves a distinct purpose to ensure clarity, usability, and governance effectiveness.

The Rationale specifically explains why the principle exists and why it is important to the organization. It provides the business justification for the principle and describes the benefits of applying it. This includes outlining how adopting the principle supports business objectives, improves operations, reduces risk, or enables strategic outcomes. Therefore, the Rationale is closely tied to business impact and value , making option C the correct answer.

Option B is incorrect because communicating the fundamental rule is the role of the Statement , not the Rationale. Option A refers more to implementation guidance, which belongs to the Implications section, where the consequences and actions required to follow the principle are described. Option D is not part of the standard TOGAF template for principles.

By clearly stating the business impact, the Rationale helps stakeholders understand the importance of adhering to the principle and ensures alignment between architecture governance and business strategy. Therefore, the correct answer is C .

===========

“In addition to the method itself being iterative, there is also iteration within the ADM cycle, both among the individual phases and among the steps within a phase.” www.opengroup.org

“The Content Metamodel defines a formal structure for these terms to ensure consistency within the architecture description…” A metamodel used across the enterprise enables consistency and completeness checking of the architecture description against the defined structure. Open Group Publications

 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.

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.

The Architecture Landscape is divided into levels known as Segment Strategic and Capability Architectures. These levels correspond to different scopes and purposes of architectures within an enterprise. Segment Architectures are architectures that address specific business units, functions, or processes within an enterprise. Strategic Architectures are architectures that provide a high-level view of the enterprise’s vision, goals, and direction. Capability Architectures are architectures that address specific business capabilities or services that span multiple segments or domains. Reference: The TOGAF® Standard | The Open Group Website, Section 2.4 Architecture Repository.

Risk management is a generic technique that can be applied across all phases of the Architecture Development Method (ADM), as well as in the Preliminary Phase and the Requirements Management Phase2. Risk management involves the following steps1:

•Risk identification: This step involves identifying the potential risks that may affect the architecture project, such as technical, business, organizational, environmental, or legal risks. The risks can be identified through various sources, such as stakeholder interviews, workshops, surveys, checklists, historical data, or expert judgment.

•Risk classification: This step involves categorizing the risks based on their nature, source, impact, and priority. The risks can be classified according to different criteria, such as time, cost, scope, quality, security, or compliance. The classification helps in prioritizing the risks and allocating resources and efforts to address them effectively.

•Initial risk assessment: This step involves assessing the likelihood and impact of each risk, and determining the initial level of risk. The likelihood is the probability of the risk occurring, and the impact is the severity of the consequences if the risk occurs. The initial level of risk is the product of the likelihood and impact, and it indicates the urgency and importance of the risk. The initial risk assessment helps in identifying the most critical risks that need immediate attention and mitigation.

“Modeling these items would help the clarification process, and in particular would highlight any ambiguities or conflicts that involved trade-offs and/or prioritization… the architecture principles… likewise help clarify ambiguities or conflicts that involve trade-offs.” Open Group Publications

Comprehensive and Detailed Explanation

The TOGAF ADM defines distinct objectives for Phase E (Opportunities and Solutions) and Phase F (Migration Planning).

Phase E: Opportunities and Solutions

Focuses on generating the initial Architecture Roadmap.

Identifies major work packages, Transition Architectures, and projects.

Determines if an incremental approach is needed, and defines Transition Architectures to ensure delivery of continuous business value.

Therefore:

Statement 1 (incremental approach and Transition Architectures) belongs to Phase E.

Statement 2 (initial Architecture Roadmap based on gap analysis) also belongs to Phase E.

Phase F: Migration Planning

Finalizes the Architecture Roadmap.

Develops the detailed Implementation and Migration Plan.

Ensures stakeholders understand the business value and cost of work packages and Transition Architectures.

Therefore:

Statement 3 (finalizing the Roadmap and Plan) belongs to Phase F.

Statement 4 (ensuring value and cost are understood by stakeholders) belongs to Phase F.

Correct Mapping

Phase E Objectives = Statements 1 and 2

Phase F Objectives = Statements 3 and 4

Thus the correct answer is A (1 & 2).

References

The Open Group, TOGAF® Standard, Version 9.2, Part II: ADM — Phase E: Opportunities and Solutions (objectives include generating the initial Architecture Roadmap, identifying major work packages, determining incremental approach and Transition Architectures).

Phase F: Migration Planning (objectives include finalizing the Architecture Roadmap and Implementation & Migration Plan, and confirming business value and costs with stakeholders).

The Open Group, TOGAF® 9 Certified Study Guide — comparison of Phase E vs. Phase F objectives.

===========

The Preliminary Phase establishes the Organization Model for Enterprise Architecture, defines principles, and sets up the Architecture Capability.

The Architecture Vision is developed in Phase A.

The Architecture Roadmap comes from Phase E and Phase F.

The Implementation Governance Model is part of Phase G.

Comprehensive and Detailed Explanation

In TOGAF, Architecture Contracts are agreements between development partners and sponsors that define:

The deliverables to be produced.

The quality expectations.

The fitness-for-purpose of the architecture.

The responsibilities of each party and the governance arrangements.

Architecture Contracts are a key part of Phase G: Implementation Governance, where they are used to manage and control architecture implementation. They help ensure that implementation projects remain aligned with the approved Target Architecture and business objectives.

They serve as the formal mechanism for:

Validating that architecture deliverables meet stakeholder expectations.

Providing a measurable basis for conformance assessment.

Supporting architecture governance by linking architectural intent with project execution.

Why the other options are incorrect

B. The Statement of Architecture Work: This defines the scope, approach, resources, and schedule for architecture work, but it is not a joint agreement on deliverables and fitness-for-purpose.

C. Service Level Agreements (SLAs): These are agreements about operational service levels (e.g., availability, performance), not architecture deliverables.

D. Non-disclosure Agreement (NDA): This protects confidentiality of information but does not address deliverables, quality, or fitness-for-purpose of an architecture.

References

The Open Group, TOGAF® Standard, Version 9.2, Part II: ADM — Phase G: Implementation Governance, Architecture Contracts.

The Open Group, TOGAF® 9 Certified Study Guide — explanation of Architecture Contracts as a governance tool.