The Open Group OGEA-101 - Questions & Answers

The Preliminary Phase is the preparatory phase of the Architecture Development Method (ADM) cycle, which sets the context and direction for the architecture work. One of the objectives of this phase is to select and implement tools to support the Architecture Capability, which is the ability of an organization to perform enterprise architecture effectively and efficiently. Tools can include software applications, methods, techniques, standards, and frameworks that assist the architecture development and governance processes. The selection and implementation of tools should be based on the requirements and constraints of the organization, and the alignment with the Architecture Principles and the Architecture Vision.
References:
3: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM),
6: Preliminary Phase : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 45:Establishing and Maintaining an Enterprise Architecture Capability : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter
46: Tools for Architecture Development

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

Gap analysis is a technique that is used to validate an architecture by highlighting the shortfall between the Baseline Architecture and the Target Architecture. One of the purposes of gap analysis is to identify missing functions that are either deliberately omitted, accidentally left out,or not yet defined in the Target Architecture. Missing functions are marked as gaps that need to be filled by developing or procuring the building blocks.

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
2: TOGAF Standard, 10th Edition, Part I: Introduction, Chapter
3: Definitions.
3: TOGAF
16: Phase E: Opportunities and Solutions, and Chapter
17: PhaseF: 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.

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

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.
References:
The TOGAF. Standard | The Open Group Website, Section 3.2 Preliminary Phase.

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

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

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.
References:
The TOGAF?Standard | The Open Group Website, Section 2.1 Core Concepts.

The illustration shows the relationship between the Enterprise Continuum, the Architecture Continuum, and the Solutions Continuum, which are key concepts in the TOGAF framework. TheEnterprise 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:
OGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 6:
Architecture Repository, Section 6.2 Enterprise Continuum. OGAF Standard, 10th Edition, Part IV:
Architecture Content Framework, Chapter 35:
Enterprise Continuum and Tools, Section 35.1 Introduction.