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

A set of architecture principles that cover every situation perceived meets the recommended criteria of completeness. Completeness is one of the six criteria that should be applied when developing or assessing architecture principles. Completeness means that there are no gaps or overlaps in the coverage of principles across all relevant aspects of the enterprise's architecture.

Reference: The TOGAF Standard | The Open Group Website, Section 3.3.7 Architecture Principles.

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.

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.

Phase A: Architecture Vision is the first phase of the Architecture Development Method (ADM) cycle, which is the core of the TOGAF standard. The main purpose of this phase is to define the scope and approach of the architecture development, and to create the Architecture Vision, which is a high-level description of the desired outcomes and benefits of the proposed architecture. To achieve this purpose, this phase focuses on defining the problem to be solved, identifying the stakeholders, their concerns, and requirements, and establishing the business goals and drivers that motivate the architecture work. This phase also involves obtaining the approval and commitment of the sponsors and other key stakeholders, and initiating the Architecture Governance process.

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.

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

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