The Open Group OGEA-10B Practice Test - Questions Answers, Page 7

According to the TOGAF standard, the objectives of each ADM phase are as follows1:

* Phase E: Opportunities and Solutions

o Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value

o Identify and group major work packages within the Architecture Roadmap

o Identify and group major implementation projects to realize the Architecture Roadmap

o Identify dependencies between increments and projects

o Estimate cost, benefit, and risk at a high level for each increment and project

o Conduct initial prioritization and sequencing of the Architecture Roadmap and projects

* Phase F: Migration Planning

o Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D

o Confirm the Transition Architectures with relevant stakeholders

o Create the Implementation and Migration Plan, including Transition Architectures, work packages, projects, and other activities

o Confirm and agree the Architecture Roadmap and Implementation and Migration Plan with relevant stakeholders

* Phase G: Implementation Governance

o Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan

o Ensure conformance with the Target Architecture by implementation projects

o Perform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests

o Ensure that the architecture lifecycle is maintained

o Ensure that the Architecture Governance Framework is executed

* Phase H: Architecture Change Management

o Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders

o Manage risks and issues related to the Architecture Roadmap and Implementation and Migration Plan

o Monitor the implementation projects and Transition Architectures

o Manage changes to the architecture baseline

o Manage changes to the Architecture Capability

Therefore, the correct matching of the objectives and the phases is:

* 1G: Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value

* 2E: Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D

* 3F: Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan

* 4F: Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders

EA applies architecture principles and practices to analyze, design, plan, and implement enterprise analysis that supports digital transformation, IT growth, and the modernization of IT2. EA also helps organizations improve the efficiency, timeliness, and reliability of business information, as well as the alignment, agility, and adaptability of the architecture to the changing needs and requirements3. Therefore, the best summary of the purpose of EA is to guide effective change.

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.

Risk management is a generic technique that can be applied across all phases of the Architecture Development Method (ADM), as well as in the Preliminary Phase and the Requirements Management Phase2. Risk management involves the following steps1:

* Risk identification: This step involves identifying the potential risks that may affect the architecture project, such as technical, business, organizational, environmental, or legal risks. The risks can be identified through various sources, such as stakeholder interviews, workshops, surveys, checklists, historical data, or expert judgment.

* Risk classification: This step involves categorizing the risks based on their nature, source, impact, and priority. The risks can be classified according to different criteria, such as time, cost, scope, quality, security, or compliance. The classification helps in prioritizing the risks and allocating resources and efforts to address them effectively.

* Initial risk assessment: This step involves assessing the likelihood and impact of each risk, and determining the initial level of risk. The likelihood is the probability of the risk occurring, and the impact is the severity of the consequences if the risk occurs. The initial level of risk is the product of the likelihood and impact, and it indicates the urgency and importance of the risk. The initial risk assessment helps in identifying the most critical risks that need immediate attention and mitigation.

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.

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

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.