The Open Group OGEA-103 Practice Test - Questions Answers, Page 6

The Architecture Landscape is a class of information within the Architecture Repository that shows an architectural view of the building blocks that are in use within the organization today (the Baseline Architecture), as well as those that are planned for the future (the Target Architecture). The Architecture Landscape typically contains a list of the applications in use within the enterprise, along with their relationships and dependencies, as well as other relevant architectural information. The Architecture Landscape helps to identify opportunities for re-use, consolidation, or retirement of existing applications, as well as gaps or overlaps in the current or future architecture.

Reference: : The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter 34: Architecture Landscape : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 47: Architecture Repository

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)12Reference:1: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 21: Phase F: Migration Planning2: The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 50: Architecture Governance

The objectives in the table are related to the development of target architectures and the architecture vision, which are the outputs of the following ADM phases:

Phase A: Architecture Vision, which develops a high-level aspirational vision of the capabilities and business value to be delivered as a result of the proposed Enterprise Architecture3

Phase B: Business Architecture, which develops the Target Business Architecture that describes how the enterprise needs to operate to achieve the business goals.

Phase C: Information Systems Architectures, which develops the Target Data Architecture and the Target Application Architecture that enable the Business Architecture and the Architecture Vision, in a way that addresses the Statement of Architecture Work and stakeholder concerns.

Phase D: Technology Architecture, which develops the Target Technology Architecture that enables the logical and physical application and data components, addressing the Statement of Architecture Work and stakeholder concerns.

Therefore, the correct match is 1C-2B-3A-4C, as shown below:

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.Reference: : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 24: Applying Iteration to the ADM

Risk is defined as the effect of uncertainty on objectives, according to the ISO 31000 standard, which provides principles and guidelines for risk management1Risk 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 implementation2Reference:1: ISO 31000:2018, Risk management --- Guidelines, Clause 3.12: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 32: Risk Management

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 Vision3Reference:3: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 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

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.

* Phase A: Architecture Vision

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

o Define the scope and boundaries of the architecture engagement

o Identify the key stakeholders and their concerns and expectations

o Define the Architecture Vision statement and the Architecture Definition Document

o Obtain approval and commitment from the sponsors and stakeholders

* Phase B: Business Architecture

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

o Define the Baseline Business Architecture, if not available

o Perform a gap analysis between the Baseline and Target Business Architectures

o Define candidate roadmap components for the Business Architecture

o Resolve impacts across the Architecture Landscape

* Phase C: Information Systems Architecture

o Develop the Target Data Architecture that enables the Business Architecture and the Architecture Vision

o Develop the Target Application Architecture that supports the Business Architecture and the Architecture Vision

o Define the Baseline Data and Application Architectures, if not available

o Perform a gap analysis between the Baseline and Target Data and Application Architectures

o Define candidate roadmap components for the Information Systems Architecture

o Resolve impacts across the Architecture Landscape

* Phase D: Technology Architecture

o Develop the Target Technology Architecture that enables the Information Systems Architecture and the Architecture Vision

o Define the Baseline Technology Architecture, if not available

o Perform a gap analysis between the Baseline and Target Technology Architectures

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

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

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

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

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

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