OGEA-101 Questions and Answers

“There are two levels of risk that should be considered namely: Initial Level of Risk [and] Residual Level of Risk.” archive.opengroup.org

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

According to the TOGAF Standard, 10th Edition, a transformation readiness assessment is a technique that evaluates the preparedness of the organization to undergo a change, and identifies the actions needed to increase the likelihood of a successful outcome. A transformation readiness assessment can be conducted in Phase E: Opportunities and Solutions, and the actions resulting from it can be dealt with in Phase F: Migration Planning 1. In Phase E, the transformation readiness assessment can help to identify the major implementation challenges and risks, and to define the critical success factors and key performance indicators for the architecture project. In Phase F, the actions resulting from the transformation readiness assessment can help to develop a detailed and realistic migration plan, and to address the gaps, issues, and dependencies that may affect the transition to the target architecture 1. References: 1: TOGAF Standard, 10th Edition, Part III: ADM Guidelines and Techniques, Chapter 29: Business Transformation Readiness Assessment.

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.

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

In TOGAF, an Architecture View is defined as the representation of a system from the perspective of a related set of concerns. This means a view is created to address the interests of specific stakeholders by focusing on those aspects of the architecture that matter to them. For example, business stakeholders may need a view centered on processes and capabilities, while technical stakeholders may need a view showing applications, interfaces, or technology infrastructure.

The other options are not correct because they refer to specific forms of architectural content rather than the broader concept of stakeholder-oriented representation. A Catalog is a list of architectural elements. A Matrix shows relationships between items. A Diagram presents information graphically. All of these may be used to help construct or express an architecture view, but they are not themselves the formal TOGAF concept being asked about in the question.

The key phrase in the question is “from the perspective of a related set of concerns.” That wording matches the TOGAF definition of an Architecture View. It is specifically intended to communicate architecture in a way that is meaningful to stakeholders and their concerns. Therefore, the correct answer is Architecture View.

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

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

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.

Comprehensive and Detailed Explanation

Architecture Partitioning is an ADM technique in TOGAF that addresses how large and complex architectures can be broken down into manageable parts. The intent is to make architecture development more effective, especially in large enterprises with multiple teams, stakeholders, and domains.

Key points from TOGAF:

TOGAF does not mandate a partitioning model. It provides guidelines and techniques to help architects determine whether and how to partition. This means statement 1 is incorrect.

Statement 2: Correct. Architectures may be partitioned to allow different teams to work on different elements in parallel (e.g., by domain, line of business, geographic scope). Partitioning provides clear ownership and reduces overlap or conflict.

Statement 3: Correct. Partitions can be structured in a way that supports architecture re-use, since well-defined partitions (e.g., capability-based or domain-based) enable consistent re-use of architecture building blocks across projects.

Correct Mapping

Statement 1: Incorrect (partitioning is not required by ADM).

Statement 2: Correct.

Statement 3: Correct.

Correct answer is D (2 and 3).

Why the other options are incorrect

A (1, 2 and 3): Incorrect because TOGAF does not require partitioning.

B (1 and 3): Incorrect because 1 is not correct.

C (1 and 2): Incorrect because 1 is not correct.

References

The Open Group, TOGAF® Standard, Version 9.2, Part III: ADM Guidelines & Techniques — Architecture Partitioning.

The Open Group, TOGAF® 9 Certified Study Guide — coverage of partitioning and its uses in large-scale architecture development.

“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

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

Ensuring compliance with internal and external standards and regulatory obligations is one of the activities included as part of Architecture Governance. Architecture Governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It involves establishing processes, roles, responsibilities, policies, and standards to ensure that architectures are aligned with the enterprise’s strategy and objectives, and meet the quality and performance requirements. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.6 Architecture Governance.

When considering agile development, Architecture to Support Portfolio will identify the necessary products for the enterprise, define their boundaries, and outline the constraints for a product owner. This process directly relates to defining the enterprise ' s backlog, which in agile methodologies, is a prioritized list of work for the development team that is derived from the roadmap and its requirements.

The Enterprise Continuum provides a classification mechanism for artifacts, showing how they evolve from generic Foundation Architectures and Reference Models to organization-specific architectures.

Option A is about tools, not the Continuum.

Option B describes the Architecture Principles.

Option C describes the Architecture Repository.

In TOGAF, Phase E (Opportunities & Solutions) is the first phase that transitions from architecture models into actionable implementation. Within Phase E, architects identify candidate implementation projects or work packages, assess dependencies, cost/benefit, constraints, and derive a highlevel implementation and migration strategy and initial plans. That means the first planning around how to carry out the architecture begins in Phase E. Later phases refine and govern the implementation (e.g. in Phase F and G), but the initial planning belongs in Phase E. Thus Phase E includes the initial implementation planning.

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

Phase A: Architecture Vision is the first phase of the Architecture Development Method (ADM) cycle, which is the core of the TOGAF standard. The main purpose of this phase is to define the scope and approach of the architecture development, and to create the Architecture Vision, which is a high-level description of the desired outcomes and benefits of the proposed architecture. To achieve this purpose, this phase focuses on defining the problem to be solved, identifying the stakeholders, their concerns, and requirements, and establishing the business goals and drivers that motivate the architecture work. This phase also involves obtaining the approval and commitment of the sponsors and other key stakeholders, and initiating the Architecture Governance process.

The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 5: Introduction to the ADM : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18: Phase A: Architecture Vision : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18.3: Inputs : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18.4: Steps

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.

The correct answer is Risk Management because risk assessment and risk analysis are core parts of the risk management process. In TOGAF, risk management is used to support architectural and implementation decision-making by identifying risks, evaluating their likelihood and impact, and determining appropriate responses. This allows stakeholders and architects to make informed choices about architecture options, transition paths, implementation timing, and governance actions.

Risk assessment focuses on understanding the nature of identified risks and estimating their significance. Risk analysis examines those risks in more detail to determine consequences, priorities, and possible treatments. These activities are not stand-alone disciplines in TOGAF; they are applied as part of Risk Management, which provides the structured method for using risk information in decisions.

The other options are related but not as precise. Information Security Management focuses on managing security controls and policies. Security Governance is concerned with oversight and accountability. Security Architecture defines structural security capabilities and controls. While all may use risk-related information, the direct application of risk assessment and risk analysis in decision-making belongs to Risk Management. Therefore, according to TOGAF terminology and governance practice, the best answer is C.

===========

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.

This aligns with the TOGAF Architecture Repository model where:

A (Architecture Requirements Repository) contains requirements that drive architecture work.

B (Solutions Repository) stores the building blocks or solutions that support the architecture.

C (Architecture Landscape) represents the architecture assets that depict the current, transition, and target architecture states across the enterprise

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 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

Comprehensive and Detailed Explanation

When defining the scope of an architecture, TOGAF identifies four dimensions that need to be considered:

Breadth – This dimension addresses the extent of the enterprise that will be impacted by the architecture. It answers the question: How much of the enterprise is covered? For example, does the scope include the entire enterprise, a business unit, a division, or just a single organizational function?

Depth – This refers to the level of detail to be covered. For instance, will the architecture describe high-level capabilities, or will it go into detailed system design?

Time Period – This defines the planning horizon of the architecture. It could be short-term (tactical), medium-term, or long-term (strategic).

Architecture Domains – This refers to which domains are covered: Business, Data, Application, and Technology. The scope may include all or just a subset of these domains.

Project Scope (sometimes discussed separately) – Focuses on which specific programs, portfolios, or projects will be impacted.

Among these, the dimension that specifically relates to the extent of the enterprise is Breadth.

Why the other options are incorrect

A. Architecture Domains: Refers to the domains covered (Business, Data, Application, Technology), not the extent of the enterprise.

B. Depth: Refers to the level of detail, not the enterprise extent.

C. Project: Refers to the program or initiative focus, not enterprise coverage.

References

The Open Group, TOGAF® Standard, Version 9.2, Part II: ADM — Preliminary Phase (scope considerations).

The Open Group, TOGAF® 9 Certified Study Guide — discussion of the dimensions of architecture scope (Breadth, Depth, Time Period, Architecture Domains).

“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

In TOGAF, the Architecture Board is the key governance body responsible for ensuring that architecture practice is directed, controlled, and applied consistently across the enterprise. Its role is not to author project deliverables such as the Statement of Architecture Work, and it is not primarily a maturity assessment team. It also does not merely define the scope of individual compliance reviews. Its broader and more important purpose is to oversee the implementation of the Architecture Governance strategy.

This means the Architecture Board provides governance oversight, ensures adherence to architecture principles, resolves escalated architecture issues, reviews compliance with approved architectures, and supports decision-making where exceptions, dispensations, or governance judgments are needed. It acts as the authority that maintains consistency between business strategy, architecture intent, and implementation activity. In practice, the board ensures architecture work is aligned with enterprise goals and that governance processes are being followed properly across change initiatives.

Option B best matches this TOGAF role because it captures the Architecture Board’s enterprise-wide governance responsibility. The other options describe narrower activities that may occur within the governance environment, but they do not define the primary role of the Architecture Board itself. Therefore, B is the correct answer.

===========

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.

This statement best supports the need to govern Enterprise Architecture. Best practice governance enables the organization to control value realization by ensuring that architectures are aligned with the enterprise’s strategy and objectives, meet the quality and performance requirements, and deliver the expected benefits and outcomes. The Architecture Project does not mandate the governance of the target architecture, but rather follows the governance framework established by the enterprise. The TOGAF standard can be used without executive governance, but it is recommended that executive sponsorship and support are obtained for successful architecture development and transition. The Stakeholders preferences may go beyond the architecture project scope and need control, but this is not the primary reason for governing Enterprise Architecture. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.6 Architecture Governance.

This description matches Phase B: Business Architecture. In TOGAF, Phase B is the phase in which the architect develops the target Business Architecture and identifies the gaps between the baseline and target states. The phase is not limited to producing models only; it also ensures that the resulting domain architecture is reviewed and approved by stakeholders and that the implications of the gaps are understood. The wording in the question is characteristic of the domain architecture phases, and among the options provided, Phase B is the only domain architecture phase listed.

Phase A is concerned with developing the Architecture Vision, scope, constraints, and stakeholder consensus at a high level. The Preliminary Phase establishes the architecture capability and governance framework. Phase E is focused on Opportunities and Solutions, where solution building blocks, work packages, and transition approaches are identified. None of those primarily describe development of a domain architecture with stakeholder approval and identified gaps.

Because the question refers to a domain architecture, stakeholder approval, and a defined set of gaps to be addressed, the best answer is Phase B. It represents the ADM phase where the Business Architecture is formally developed and agreed.

===========

The Implementation Governance Model is a framework that defines the roles, responsibilities, processes, and standards for governing the implementation of the target architecture. It ensures that a project transitioning into implementation also smoothly transitions into appropriate Architecture Governance, which is the practice of ensuring compliance with the enterprise architecture and its principles, standards, and goals. The Implementation Governance Model is part of the Implementation and Migration Plan, which is the output of Phase F: Migration Planning of the Architecture Development Method (ADM)12 References: 1: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 21: Phase F: Migration Planning 2: The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 50: Architecture Governance

Phase A: Architecture Vision identifies stakeholders, their concerns, and defines the scope and objectives of the architecture engagement.

Defining enterprise strategy is outside ADM (it is a business planning activity).

Describing the target architecture happens in Phases B, C, and D.

Developing an EA Capability is done in the Preliminary Phase, not Phase A.

(Authoritative Open Group guidance distinguishes conceptual, logical, and physical concerns; at the logical level, component types are identified independently of implementation.) For example, the Open Group’s metamodel guidance emphasizes technology-agnostic structure to ensure consistency within an architecture description, which is precisely what the logical level captures before physical realization.

“The Content Metamodel defines a formal structure… to ensure consistency within the architecture description and also to provide guidance for organizations that wish to implement their architecture within an architecture tool.” Open Group Publications

The table describes the output, outcome, and essential knowledge of an ADM phase that oversees the implementation of changes necessary to reach the adjusted target state. This corresponds to Phase G, also known as Implementation Governance, which ensures that the architecture defined in earlier phases is realized, and it oversees the development and implementation of projects to align with this architecture. The essential knowledge required during this phase includes understanding constraints on the implementation team and adjusting stakeholder priority and preference in response to success, value, effort, and risk of change. References: TOGAF Version 9.1 - 1

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.

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

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.

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.

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.

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.

Deliverable 1 refers to Architecture Principles. In TOGAF, Architecture Principles are established as part of the Preliminary Phase, where the enterprise prepares the architecture capability, defines the framework and governance approach, and sets the foundational rules that will guide architecture work. These principles are intended to be enduring and stable, which matches the wording in the question exactly.

Deliverable 2 refers to Architecture Contracts. In TOGAF, Architecture Contracts are formal agreements between development partners and sponsors concerning the deliverables, quality expectations, and fitness-for-purpose of the architecture. These contracts are not limited to a single phase only. They may be initiated and refined at various stages of the ADM, especially wherever there is a need to formalize agreement between architecture and implementation organizations. Although they are strongly associated with implementation governance, the concept is broader and can appear across the ADM lifecycle depending on governance needs.

The other answer options are incorrect because Architecture Principles are not outputs of Phase A, and Architecture Contracts are not restricted only to Phase E or Requirements Management. Therefore, the correct completion is that deliverable 1 is from the Preliminary Phase, and deliverable 2 can occur at various stages of the ADM.

===========

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.