The Open Group OGEA-103 - Questions & Answers

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.
References:
The TOGAF Standard | The Open Group Website, Section 2.2 Architecture Development Method (ADM).

Explanation: The Architecture Requirements Repository stores all the requirements that are output of the architecture development cycle, as well as the requirements that are input to the architecture development cycle 1. The Architecture Requirements Repository includes the following types of requirements1: Stakeholder Requirements: These are the high-level requirements and expectations of the stakeholders, derived from the business drivers, goals, and objectives. They are captured and refined in the Architecture Vision phase and the Requirements Management phase.
Architecture Requirements: These are the detailed requirements that specify what the architecture must do or deliver to meet the stakeholder requirements. They are derived and refined in the Business, Information Systems, and Technology Architecture phases.
Implementation and Migration Requirements: These are the detailed requirements that specify what the implementation and migration projects must do or deliver to realize the architecture. They are derived and refined in the Opportunities and Solutions and Migration Planning phases.
The Architecture Requirements Repository is used to manage the architecture requirements throughout the architecture lifecycle, ensuring their traceability, consistency, and compliance 1. The Architecture Board is the authority that reviews and approves the architecture requirements, as well as the architecture deliverables and artifacts, as part of the architecture governance process 2.
References:
1: Architecture Requirements Repository
2: Architecture Board

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

The scope of an architecture is the extent and level of detail of the architecture work. The scope of an architecture can be defined along four dimensions: project, breadth, depth, and architecture domains. The project dimension considers the boundaries and objectives of the architecture project, such as the time frame, budget, resources, and deliverables. The breadth dimension considers the coverage and completeness of the architecture across the enterprise, such as the organizational units, business functions, processes, and locations. The depth dimension considers the level of detail and specificity of the architecture, such as the granularity, abstraction, and precision of the architectural elements and relationships. The architecture domains dimension considers the aspects or segments of the architecture, such as the business, data, application, and technology domains.
Therefore, the depth dimension is the one that considers to what level of detail the architecting effort should go.
References:
: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 25:
Architecture Scope : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 25.2: Scope Dimensions : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 25.2.1: Project, Breadth, Depth, and Architecture Domains

1E: To identify delivery vehicles (projects programs portfolios) that will deliver the Target Architecture 2F: To confirm readiness and ability to undergo change 3E: To determine whether an incremental approach is required and if so identify Transition Architectures that will deliver continuous business value 4G: To perform appropriate governance functions while the solution is being implemented Reference: The TOGAF-Standard | The Open Group Website, Section 3.2 ADM Phases.

https://pubs.opengroup.org/architecture/togaf9-doc/arch/chap41.html

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

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

Explanation: According to the TOGAF standard, the need for the ADM process to be governed is to ensure that the architecture development and implementation activities are conducted in a consistent, coherent, and compliant manner 1. Governance provides the means to verify that the method is being applied correctly and effectively, and that the architecture deliverables and artifacts meet the quality and standards criteria 1. Governance also enables the management of risks, issues, changes, and dependencies that may arise during the ADM process 1.
Some of the benefits of governing the ADM process are2: Improved alignment of the architecture with the business strategy and objectives Enhanced stakeholder engagement and communication Increased reuse and integration of architecture assets and resources Reduced complexity and duplication of architecture efforts Increased agility and adaptability of the architecture to changing needs and requirements Improved compliance and auditability of the architecture outcomes and outputs

References:
1: Architecture Governance
2: Architecture Governance Benefits

References:
1: Preliminary Phase
2: Enterprise Architecture Capability