OGEA-10B Practice Questions

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.

Reference: : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM),

Chapter 5: Introduction to the ADM : The TOGAF Standard, Version 9.2, Part II: Architecture

Development Method (ADM), Chapter 18: Phase A: Architecture Vision : The TOGAF Standard,

Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18.3: Inputs : The TOGAF

Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18.4: Steps

A Consolidated Gaps, Solutions and Dependencies Matrix is a technique that can be used to create

work packages for an incremental rollout of the architecture. A work package is a set of actions or

tasks that are required to implement a specific part of the architecture. A work package can be

associated with one or more Architecture Building Blocks (ABBs) or Solution Building Blocks (SBBs),

which are reusable components of business, IT, or architectural capability. A work package can also

be associated with one or more Capability Increments, which are defined, discrete portions of the

overall capability that deliver business value. A Capability Increment can be realized by one or more

Transition Architectures, which are intermediate states of the architecture that enable the transition

from the Baseline Architecture to the Target Architecture123

The steps for creating work packages using this technique are:

For each gap between the Baseline Architecture and the Target Architecture, identify a proposed

solution and classify it as new development, purchased solution, or based on an existing product. A

gap is a difference or deficiency in the current state of the architecture that needs to be addressed by

the future state of the architecture. A solution is a way of resolving a gap by implementing one or

more ABBs or SBBs.

Group similar solutions together to define the work packages. Similar solutions are those that have

common characteristics, such as functionality, technology, vendor, or location.

Identify dependencies between work packages, such as logical, temporal, or resource dependencies.

Dependencies indicate the order or priority of the work packages, and the constraints or risks that

may affect their implementation.

Regroup the work packages into a set of Capability Increments to transition to the Target

Architecture. Capability Increments should be defined based on the business value, effort, and risk

associated with each work package, and the schedule and objectives of the clinical trials. Capability

Increments should also be aligned with the Architecture Vision and the Architecture Principles.

Document the work packages and the Capability Increments in an Architecture Definition Increments

Table, which shows the mapping between the work packages, the ABBs, the SBBs, and the Capability

Increments. The table also shows the dependencies, assumptions, and issues related to each work

package and Capability Increment.

Therefore, the best answer is B, because it describes the approach to identify the work packages for

an incremental rollout meeting the requirements, using the Consolidated Gaps, Solutions and

Dependencies Matrix as a planning tool.

Reference: 1: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 30:

Gap Analysis 2: The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter

36: Building Blocks 3: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques,

Chapter 31: Architecture Change Management : The TOGAF Standard, Version 9.2, Part II:

Architecture Development Method (ADM), Chapter 23: Phase E: Opportunities and Solutions : The

TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 21: Phase F:

Migration Planning : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method

(ADM), Chapter 18: Phase A: Architecture Vision : The TOGAF Standard, Version 9.2, Part III: ADM

Guidelines and Techniques, Chapter 23: Architecture Principles

A security domain model is a technique that can be used to define the security requirements and

policies for the architecture. A security domain is a grouping of assets that share a common level of

security and trust. A security policy is a set of rules and procedures that govern the access and

protection of the assets within a security domain. A security domain model can help to identify the

security domains, the assets within each domain, the security policies for each domain, and the

relationships and dependencies between the domains1

Since the data is being shared across partners, a security federation is needed to establish a trust

relationship and a common security framework among the different parties. A security federation is

a collection of security domains that have agreed to interoperate under a set of shared security

policies and standards. A security federation can enable secure data exchange and collaboration

across organizational boundaries, while preserving the autonomy and privacy of each party. A

security federation requires contractual arrangements, and a definition of the responsibility areas for

the data exchanged, as well as security implications2

A risk assessment is a process that identifies, analyzes, and evaluates the risks that may affect the

architecture. A risk assessment can help to determine the likelihood and impact of the threats and

vulnerabilities that may compromise the security and privacy of the data assets. A risk assessment

can also help to prioritize and mitigate the risks, and to monitor and review the risk situation3

Therefore, the best answer is D, because it describes the risk and security considerations that would

be included in the current phase of the architecture development, which is focused on the Business

Architecture. The answer covers the security domain model, the security federation, and the risk

assessment techniques that are relevant to the scenario.

Reference: 1: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 35:

Security Architecture and the ADM 2: The TOGAF Standard, Version 9.2, Part IV: Architecture Content

Framework, Chapter 38: Security Architecture 3: The TOGAF Standard, Version 9.2, Part III: ADM

Guidelines and Techniques, Chapter 32: Risk Management

The four dimensions used to scope an architecture are Breadth, Depth, Time Period, and Architecture

Domains1, p. 8.

Breadth refers to the extent of the enterprise covered by the architecture, which can range from a

specific business unit to the entire organization1, p. 8.

Depth refers to the level of detail and completeness of the architecture, which can vary depending

on the purpose, scope, and stakeholders of the architecture1, p. 8.

Time Period refers to the temporal aspects of the architecture, such as the current state, the target

state, and the transition plan1, p. 8.

Architecture Domains refers to the classification of the architecture into four domains: Business,

Data, Application, and Technology1, p. 8.

These four dimensions help define the scope and boundaries of the architecture and ensure that it

meets the needs and expectations of the stakeholders.

Reference:

1: The Open Group (2018). The TOGAF® Standard, Version 9.2. 1

The illustration shows the relationship between the Enterprise Continuum, the Architecture

Continuum, and the Solutions Continuum, which are key concepts in the TOGAF framework. The

Enterprise 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. Reference:

•

TOGAF Standard, 10th Edition, Part II: Architecture Development Method, Chapter 6:

Architecture Repository, Section 6.2 Enterprise Continuum.

•

TOGAF Standard, 10th Edition, Part IV: Architecture Content Framework, Chapter 35:

Enterprise Continuum and Tools, Section 35.1 Introduction.

The planning horizon, depth, and breadth of an Architecture Project, along with the contents of the

EA Repository, are typically framed by Strategy, Portfolio, Segment, and End-to-end Target

Architecture. The 'Segment' refers to a part of the organization, typically addressed in a Segment

Architecture, while 'End-to-end Target Architecture' encompasses the complete view of the planned

architecture across the entire organization.

An Architecture Contract is a deliverable that specifies the responsibilities and obligations of the

parties involved in the implementation and governance of an architecture. It ensures a system of

continuous monitoring to check integrity changes decision-making and audit of all architecture-

related activities. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.4

Architecture Contracts.

The chart shown is a Gantt chart, which is commonly used for project management to illustrate a

project schedule. In the context of TOGAF (The Open Group Architecture Framework), which is a

framework for enterprise architecture, this Gantt chart is demonstrating the sequenced approach to

the Architecture Development Method (ADM). The ADM is the core process of TOGAF which

provides a tested and repeatable process for developing architectures. The ADM is described as

being iterative, over the whole process, between phases, and within phases. For each iteration of the

ADM, a fresh decision must be taken about each of the parameters (scope, granularity, time period,

and architecture assets).

The ADM consists of a number of phases that have to be followed in sequence:

Preliminary Phase: Framework and principles

Phase A: Architecture Vision

Phase B: Business Architecture

Phase C: Information Systems Architectures, including Data and Application Architectures

Phase D: Technology Architecture

Phase E: Opportunities and Solutions

Phase F: Migration Planning

Phase G: Implementation Governance

Phase H: Architecture Change Management

Requirements Management

Each phase is dependent on the outputs of the previous phase and the Requirements Management

phase runs throughout. The Gantt chart clearly shows the dependency and sequence in which these

phases occur, implying that a structured approach is followed to produce the enterprise architecture.

Reference:

The TOGAF Standard, Version 9.2, a standard of The Open Group

The TOGAF documentation available at https://publications.opengroup.org/standards/architecture

and https://publications.opengroup.org/guides/architecture

According to the TOGAF standard, the Target Architecture is the description of a future state of the

architecture being developed for an organization. It should be aligned with the Architecture Vision,

Principles, and Requirements that have been agreed with the stakeholders. To address the

incompatibilities between key stakeholder p

, the TOGAF standard recommends creating

and evaluating multiple alternative Target Architectures that meet different sets of criteria. These

criteria should reflect the value preferences and priorities of the stakeholders, as well as the business

drivers and objectives. The alternative Target Architectures should be illustrated using a set of

architecture views that show the impact of each alternative on the business, data, application, and

technology domains. The impact on planned projects should also be identified and analyzed. The

strengths and weaknesses of each alternative should be understood and documented. A formal

stakeholder review should then be conducted to decide which alternative is the most fit for purpose

and should be moved forward with. The funding required for implementing the chosen alternative

should also be determined and secured. Reference:

The TOGAF Standard, Version 9.2 - Phase B: Business Architecture - The Open Group

The TOGAF Standard, Version 9.2 - Phase C: Information Systems Architectures - The Open Group

[The TOGAF Standard, Version 9.2 - Phase D: Technology Architecture - The Open Group]

[The TOGAF Standard, Version 9.2 - Phase E: Opportunities and Solutions - The Open Group]

[The TOGAF Standard, Version 9.2 - Phase F: Migration Planning - The Open Group]

The class of information known as the Reference Library within the Architecture Repository contains

guidelines and templates used to create new architectures. The Reference Library provides a set of

resources that can be leveraged or customized for specific architecture development purposes. It

includes generic building blocks, patterns, models, standards, frameworks, methods, techniques,

best practices, etc. Reference: The TOGAF® Standard | The Open Group Website, Section 2.4

Architecture Repository.