OGEA-101 Questions and Answers

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"

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.

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

The four dimensions used to scope an architecture are Breadth, Depth, Time Period, and Architecture Domains1, p. 8.

Breadth refers to the extent of the enterprise covered by the architecture, which can range from a specific business unit to the entire organization1, p. 8.

Depth refers to the level of detail and completeness of the architecture, which can vary depending on the purpose, scope, and stakeholders of the architecture1, p. 8.

Time Period refers to the temporal aspects of the architecture, such as the current state, the target state, and the transition plan1, p. 8.

Architecture Domains refers to the classification of the architecture into four domains: Business, Data, Application, and Technology1, p. 8.

These four dimensions help define the scope and boundaries of the architecture and ensure that it meets the needs and expectations of the stakeholders.

1: The Open Group (2018). The TOGAF® Standard, Version 9.2. 1

Architecture Principles are general rules and guidelines that inform and support the way in which an organization sets about fulfilling its mission. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions. One of the purposes of Architecture Principles is to establish a common understanding of how to control the business in pursuit of strategic objectives, by providing a framework for evaluating and agreeing on the changes that affect the enterprise’s architecture3 References: 3: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 23: Architecture Principles : The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter 31: Architecture Principles

Statements 1 and 3 highlight the value and necessity for Architecture Governance to be adopted within organizations. Architecture Governance is the practice and orientation by which Enterprise Architectures and other architectures are managed and controlled at an enterprise-wide level12. It ensures that architectural decisions are aligned with the organization’s strategy, objectives, and standards. Architecture Governance also involves establishing and maintaining processes, decision-making, and mechanisms to avoid or minimize potential conflicts of interest, such as between different stakeholders, business units, or projects34. Moreover, Architecture Governance requires transparency and accountability for all actions implemented and their decision support, so that they can be inspected and evaluated by authorized parties, such as auditors, regulators, or customers5 . References:

•The TOGAF Standard, Version 9.2 - Architecture Governance - The Open Group

•Architecture Governance - The Open Group

•Tutorial: Governance in TOGAF’s Architecture Development Method (ADM)

•Architecture Governance in TOGAF: Ensuring Effective Management and Compliance

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

•[Architecture Governance in TOGAF: Ensuring Alignment and Control]

Comprehensive and Detailed Explanation

Gap Analysis is an ADM technique used in Phases B, C, and D of the TOGAF ADM (Business, Information Systems, and Technology Architectures).

Its main purpose is to validate the target architecture by comparing the Baseline Architecture with the Target Architecture and identifying:

Gaps (building blocks or capabilities present in the target but missing in the baseline).

Overlaps (building blocks duplicated across architectures).

Conflicts (inconsistencies between baseline and target).

The output of Gap Analysis provides:

A validated Target Architecture.

A set of identified gaps that must be addressed by future work packages in Phase E: Opportunities and Solutions.

Therefore, the purpose of Gap Analysis is best expressed as to validate the architecture (Answer D).

Why the other options are incorrect

A. Establish quality metrics for the architecture: This is part of performance management and governance, not Gap Analysis.

B. Identify non-functional requirements: Non-functional requirements are captured through requirements management and stakeholder analysis, not Gap Analysis.

C. Determine service levels: Service levels are typically defined in SLAs and operational models, not through Gap Analysis.

References

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

The Open Group, TOGAF® 9 Certified Study Guide — explains the role of Gap Analysis in validating architectures and identifying work package inputs.

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

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 forward‑looking the architecture effort will be. Thus “breadth, architecture domains” is the correct third dimension.

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. 

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.

Architecture Principles are general rules and guidelines that inform and support the way in which an organization sets about fulfilling its mission. They reflect a level of consensus among the various elements of the enterprise, and form the basis for making future IT decisions. One of the purposes of Architecture Principles is to establish a common understanding of how to control the business in pursuit of strategic objectives, by providing a framework for evaluating and agreeing on the changes that affect the enterprise’s architecture3 References: 3: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 23: Architecture Principles : The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter 31: Architecture Principles

Architecture partitioning is not the same as architecture levels (so 1 is incorrect).

It allows different teams of architects to work on different parts of the architecture in parallel (2 is correct).

TOGAF does not prescribe a fixed partitioning model; it provides guidance (so 3 is incorrect).

Partitioning is used to simplify management of Enterprise Architecture in large or complex organizations (4 is correct).

One of the key responsibilities of an Architecture Board within the context of TOGAF is to achieve consistency between sub-architectures. This board is typically responsible for overseeing the development and maintenance of the enterprise architecture, ensuring that it aligns with the organization's overall strategy and objectives. They play a critical role in ensuring that all sub-architectures (like Business Architecture, Data Architecture, Application Architecture, and Technology Architecture) work together cohesively and support the overall enterprise architecture vision and strategy.

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 planning horizon, depth, and breadth of an Architecture Project, along with the contents of the EA Repository, are typically framed by Strategy, Portfolio, Segment, and End-to-end Target Architecture. The 'Segment' refers to a part of the organization, typically addressed in a Segment Architecture, while 'End-to-end Target Architecture' encompasses the complete view of the planned architecture across the entire organization.

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.

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.

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

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

The TOGAF Content Framework defines a set of artifacts, deliverables, catalogs, matrices, and diagrams and describes how they relate to one another (i.e. their relationships and interactions), forming a structure by which architecture work is documented and integrated across domain areas. It captures the information architecture of architecture deliverables. While the Content Framework is guided by the ADM, it is not rigidly locked to phases but rather describes the content and relationships independent of timing. Its focus is not on process or lifecycle management per se, but on how architectural information is structured, interconnected, and traceable. Thus the best summary is that it shows the detailed relationships and interactions between information entities (artifacts, models, and content elements) across architecture work.

 According to the TOGAF template for Architecture Principles, the Rationale section should describe the relationship to other principles, as well as the business benefits and the intentions of adhering to the principle. The Rationale section should use business terminology and point to the similarity of information and technology principles to the principles governing business operations. The Rationale section should also explain how the principle supports the achievement of the business objectives and key architecture drivers. References:

Architecture Principles Template

The TOGAF Standard, Version 9.2 - Architecture Principles

The Open Group Exam OGEA-103 Topic 1 Question 4 Discussion

Architecture governance is the practice of ensuring compliance with the enterprise architecture and its principles, standards, and goals. Architecture governance provides the means to establish, monitor, and control the architecture development and implementation processes, and to resolve any issues or conflicts that may arise. Architecture governance also ensures that all stakeholders are represented and involved in the decision-making process, and that their interests and concerns are balanced and aligned. Statements 1 and 2 highlight the value and necessity for architecture governance to be adopted within organizations, as they emphasize the importance of responsibility, accountability, fairness, and transparency in the architectural activities. Statements 3 and 4 are more related to the benefits and outcomes of having a good enterprise architecture, rather than the governance aspect.

The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 50: Architecture Governance : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 29: Architecture Governance

A content metamodel is a formal structure that defines the types of entities and relationships that are used to capture, store, filter, query, and represent architectural information in a way that supports consistency, completeness, and traceability12.

A stakeholder map is a tool that identifies and analyzes the key stakeholders and their interests, influence, and expectations in relation to the architecture3. It is not used to structure architectural information, but rather to understand the stakeholder needs and concerns.

An architecture framework is a set of principles, guidelines, standards, and tools that provide a common structure and methodology for developing architectures4. It is not used to structure architectural information, but rather to guide the architecture development process and ensure alignment with the business strategy and objectives.

An EA library is a repository that stores and manages the architecture artifacts, deliverables, and other relevant information produced and consumed during the architecture development and governance. It is not used to structure architectural information, but rather to provide access, security, and version control for the architecture content.

 1: The TOGAF Standard, Version 9.2 - Content Metamodel 2: TOGAF 9.2 Content Metamodel Framework - A Quick Guide - KnowledgeHut 3: The TOGAF Standard, Version 9.2 - Stakeholder Management 4: The TOGAF Standard, Version 9.2 - Architecture Framework : The TOGAF Standard, Version 9.2 - Architecture Repository

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.

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.

Comprehensive and Detailed Explanation

TOGAF defines an Architecture Principle as a qualitative statement of intent that should be met by the architecture. To ensure clarity and consistent application, TOGAF provides a standard template for documenting each principle. The template includes four parts:

Name – A clear, precise, and easy-to-remember name for the principle.

Answers the question: What is this principle called?

Statement – A short, unambiguous sentence that communicates the essence of the principle.

Answers the question: What does this principle mean?

Rationale – Explains why the principle is important, the benefits of adopting it, and how it supports the enterprise’s goals.

Answers the question: Why should we adopt this principle?

Implications – Highlights the consequences of adopting the principle, including the impact on business processes, technology, governance, and resources.

Answers the question: How does this affect me?

Therefore, the correct section where the reader would find the answer to “How does this affect me?” is Implications.

Why the other options are incorrect

A. Statement: Defines the essence of the principle but does not address consequences.

B. Rationale: Explains the reasoning and justification for the principle but not its practical effects.

C. Name: Only provides the identifier or title of the principle.

References

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

The Open Group, TOGAF® 9 Certified Study Guide — description of the Architecture Principles template and the purpose of each section.

Within the TOGAF framework, assessments are used to ensure that architecture work is conformant with governance parameters. A compliance assessment (sometimes called architecture compliance or compliance review) is the evaluation of a project’s architectural artifacts—its design, architecture decisions, progress status—against the established architecture standards, principles, and constraints. The content of a compliance assessment typically includes reviewing the project status, the architectural design alignment, and identifying non‑compliance issues or deviations. Because it focuses on how well the project matches the architecture, rather than on capabilities, organizational structure, or risk per se, the described contents correspond to a compliance assessment. The compliance assessment helps governance bodies enforce architectural consistency and correct deviations during implementation.

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

Phase B of the ADM cycle is the Business Architecture phase. It describes the development of a Business Architecture to support an agreed Architecture Vision. The objectives of this phase are to describe the baseline and target Business Architecture, identify candidate Architecture Roadmap components based on gaps between the baseline and target, and determine whether an incremental approach is required. Reference: The TOGAF® Standard | The Open Group Website, Section 3.2.2 Phase B: Business Architecture.

Gap Analysis in TOGAF is a technique used to compare the baseline architecture (current state) with the target architecture (future desired state). The output is a set of gaps, representing what is missing or what must change to move from baseline to target. These gaps help validate that the target architecture is adequate: by identifying what is not addressed, architects can ensure that all required functionality, constraints, and transformation paths are captured. In effect, Gap Analysis validates the architecture by exposing omissions, inconsistencies, or unmet requirements between what is and what should be. It is not primarily about defining service levels, non‑functional requirements, or quality metrics (though it helps inform those). Rather, its main role is in validating and guiding closure of architectural gaps.

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.

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.

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.

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.