THE-OPEN-GROUP-OG0-092 Practice Questions

The scenario presents a complex environment with diverse stakeholders (CCO, legal, auditors, local companies) who have distinct and potentially conflicting concerns regarding global compliance and local operations. The most effective initial approach, according to the TOGAF standard, is to perform a thorough stakeholder analysis. This involves identifying all stakeholders, understanding their influence and interests, and mapping their specific concerns. By grouping stakeholders with common concerns, appropriate viewpoints can be defined to ensure the architecture addresses their needs effectively. This entire process is a core part of Phase A: Architecture Vision, and its outputs, including the Stakeholder Map and documented concerns, are foundational to the success of the entire architecture effort.

B: This is incorrect because it prematurely jumps to a specific modeling solution (ArchiMate) and imposes a rigid, uniform set of models. The TOGAF framework emphasizes selecting viewpoints based on stakeholder concerns, not enforcing a fixed set of models for everyone.

C: This option is too narrow and tactical. While creating models and holding reviews are valid activities, this approach lacks the initial strategic analysis of who the stakeholders are and what their fundamental concerns are, which is the necessary first step.

D: A Communications Plan is an important output of stakeholder management, but it is not the starting point. This option focuses only on communication, whereas the primary task is to develop an architecture that addresses stakeholder needs, which requires the deeper analysis described in option A.

1. The TOGAF® Standard

Version 9.2

Part II: Architecture Development Method (ADM)

Chapter 5

Phase A: Architecture Vision. Section 5.4.3

"Identify Stakeholders

Concerns

and Business Requirements"

states that a key step is to "Identify the key stakeholders and their concerns/objectives

and define the key business requirements to be addressed in the architecture engagement". Table 5-2 lists the Stakeholder Map as a key output of this phase.

2. The TOGAF® Standard

Version 9.2

Part III: ADM Guidelines and Techniques

Chapter 24

Stakeholder Management. Section 24.2 outlines the steps in stakeholder management

which include identifying stakeholders

classifying their positions

and determining how to manage their expectations. This chapter emphasizes that "The first step in this process is to identify the key stakeholders in the architecture engagement".

3. The TOGAF® Standard

Version 9.2

Part IV: Architecture Content Framework

Chapter 35

Architecture Viewpoints and Views. Section 35.2 explains the relationship: "The architect will identify stakeholders and classify them in terms of their concerns... The viewpoints that will be used to describe the architecture are determined by the stakeholders and their concerns." This directly supports the process described in answer A.

The scenario outlines concerns regarding responsibility, time to manage change, and the alignment of information management with the business, a point specifically stressed by senior management. Option D provides the most suitable set of principles to address these issues.

"Information Management is Everybody's business" directly addresses the senior management's key concern for business alignment.

"IT Responsibility" and "Data Trustee" clarify roles and ownership, directly mitigating the "responsibility" concern in the new centralized model.

"Responsive Change Management" directly addresses the concern about the "time to manage change".

This combination provides a robust governance framework for the new centralized ERP system, targeting the most critical stakeholder concerns.

A: This option lists general principles but fails to address the specific, critical concerns raised about reliability, responsibility, and responsive change management.

B: While addressing reliability ("Business Continuity") and change, this option completely misses the stressed senior management concern about business alignment and responsibility.

C: This is the weakest choice, as its principles are either too generic or do not map to the primary concerns of security, reliability, and responsibility.

1. The Open Group Standard

TOGAF® Version 9.2

Chapter 23

Architecture Principles. This chapter details the role and characteristics of architecture principles.

2. The Open Group Standard

TOGAF® Version 9.2

Section 23.6.1

Business Principles. This section lists "Information Management is Everybody's Business" as an example principle

stating its rationale is that information is a business resource

not just an IT one.

3. The Open Group Standard

TOGAF® Version 9.2

Section 23.6.2

Data Principles. This section includes "Data Trustee" (Principle D4)

which assigns the responsibility for data quality to a business-side trustee.

4. The Open Group Standard

TOGAF® Version 9.2

Section 23.6.3

Application Principles. This section includes "IT Responsibility" (Principle A6)

which clarifies the scope of the IT function's duties.

5. The Open Group Standard

TOGAF® Version 9.2

Section 23.6.4

Technology Principles. This section lists "Responsive Change Management" (Principle T4)

which emphasizes that changes must be manageable and timely.

The scenario describes the initiation of an architecture project following the approval of a Request for Architecture Work. According to the TOGAF Architecture Development Method (ADM), the next step is Phase A: Architecture Vision. A primary objective of this phase is to establish the scope, constraints, and expectations for the project by engaging with key stakeholders to understand their concerns and business requirements. The Business Scenario technique is a core TOGAF method specifically designed for this purpose. It helps to articulate the business problem, identify key requirements, and ensure the resulting architecture is fit-for-purpose. Option A accurately describes this process of stakeholder identification and the use of business scenarios to elicit high-level requirements, which is the correct initial step.

B. This approach is solution-driven, defining the vision based on vendor literature rather than business requirements. TOGAF advocates for a business-driven approach where requirements define the solution, not the other way around.

C. This describes activities from later ADM phases (B, C, D, and E), such as developing detailed Baseline/Target Architectures and performing gap analysis. These actions are premature before a clear Architecture Vision is established.

D. Conducting a pilot project to define requirements is also a solution-driven approach. A pilot should be used to test a proposed solution against established requirements, not to generate them.

1. The TOGAF® Standard

Version 9.2

Chapter 6

Phase A: Architecture Vision: The objectives of Phase A include ensuring that the architecture development cycle has a "documented scope" and "identified stakeholders

their concerns

and objectives".

2. The TOGAF® Standard

Version 9.2

Chapter 23

Business Scenarios: Section 23.1 states

"A business scenario is a technique used to help identify and understand business requirements

and thereby to derive the architecture requirements that the architecture development has to deliver." This directly supports the method described in option A.

3. The TOGAF® Standard

Version 9.2

Chapter 6

Section 6.4

Step 1: Identify Stakeholders

their Concerns

and Business Requirements: This step explicitly details the initial activities of Phase A

which involve identifying and documenting stakeholder concerns. The Business Scenario technique is a recommended tool for this step.

This option provides the most comprehensive and direct set of architectural artifacts to address all four stakeholder concerns.

1. Business Process Changes: The Process/Event/Control/Product catalog is the specific TOGAF artifact designed to list and describe business processes, making it ideal for identifying changes.

2. Shared Data Entities: The Data Entity/Data Component catalog lists the data entities, while the System/Data matrix shows the relationship between data and systems, effectively identifying what can be shared.

3. Data Security: The Data Security diagram is the designated artifact for modeling security controls and access permissions on data.

4. Application Integration: The Interface catalog is used to list the interfaces between applications, directly addressing the need to identify integrations.

B: This option includes several irrelevant artifacts for the stated concerns, such as the Location catalog, Data Migration diagram, and Software Engineering diagram, which do not address process changes, data sharing, or application integration.

C: This option incorrectly proposes using a Data Migration diagram and Business Footprint diagram, which are not the primary tools for analyzing data sharing/security or business process changes in this context.

D: While strong in the Data and Application domains, this option lacks a specific artifact for analyzing business process changes. A Role catalog alone is insufficient to detail process modifications, making it less complete than option A.

1. The Open Group Standard

TOGAF® Version 9.2

Part IV: Architecture Content Framework

Chapter 35

Architecture Artifacts.

Process/Event/Control/Product Catalog (Section 35.2.19): "A list of the processes

events

controls

and products of the business. A process is a flow of interactions between roles and functions that achieves a business objective." This directly addresses the concern about identifying changes to business processes.

Data Entity/Data Component Catalog (Section 35.2.10): "A catalog of the data entities and/or data components that are relevant to the architecture." This directly addresses the need to identify data entities.

System/Data Matrix (Section 35.2.25): "A matrix that shows the relationship between systems and data entities in the enterprise." This helps identify where data is stored and how it can be shared.

Data Security Diagram (Section 35.2.11): "A view of the data entities and/or data components that are relevant to the architecture

annotated with the security and access controls that are to be applied to the data." This directly addresses the data security concern.

Interface Catalog (Section 35.2.16): "A list of the interfaces in the enterprise. An interface is a boundary across which two or more systems

subsystems

or other components exchange information." This directly addresses the application integration concern.

The scenario indicates a forward-looking project to replace existing systems with a new COTS solution, and the CIO is not concerned with preserving the current state. This justifies focusing on the Target Architecture rather than the Baseline. The chosen artifacts in option B directly address the specific stakeholder concerns for the Business and Application Architecture phases.

1. Concern 1 (People): An Organization/Actor catalog is the correct artifact to identify the groups of people involved in business processes.

2. Concern 2 (Object Lifetimes): Data Lifecycle diagrams are designed to show the management of data entities (like a Purchase Order) from creation to destruction.

3. Concern 3 (Integration): Application Communication diagrams and the Application Interaction matrix are the primary artifacts for showing how different applications will be integrated and exchange information.

A. This option incorrectly focuses on the Baseline Architecture. The project sponsor has explicitly stated that preserving the existing systems is not a concern, making a detailed baseline analysis unnecessary.

C. This option incorrectly suggests a Product Lifecycle diagram. This artifact is used for the lifecycle of a company's products, not for the lifecycle of business data objects like a "Request for Proposal".

D. This option incorrectly focuses on the Baseline Architecture. It also includes a Technology Portfolio catalog, which is an artifact created during the Technology Architecture (Phase D), not the Application Architecture phase.

1. The TOGAF® Standard

Version 9.2

Part IV

Section 34.2.18

Organization/Actor Catalog: "The Organization/Actor catalog provides a list of the actors and roles that are involved in the architecture... It can be used to understand the actors and roles involved in business processes..." This directly supports addressing stakeholder concern #1.

2. The TOGAF® Standard

Version 9.2

Part IV

Section 34.2.11

Data Lifecycle Diagram: "A Data Lifecycle diagram is used to show how the data in the enterprise is managed through its life cycle from creation to destruction." This directly supports addressing stakeholder concern #2 regarding the lifetimes of business objects.

3. The TOGAF® Standard

Version 9.2

Part IV

Section 34.2.4

Application Communication Diagram: "An Application Communication diagram shows the key application components and the communication flows between them." This

along with the Application Interaction Matrix

directly supports addressing stakeholder concern #3 about integration.

4. The TOGAF® Standard

Version 9.2

Part IV

Section 34.2.6

Application Interaction Matrix: "The Application Interaction matrix shows the communication and interaction patterns between applications in the enterprise." This also directly supports addressing stakeholder concern #3.

5. The TOGAF® Standard

Version 9.2

Part II

Section 8.1

Phase B: Business Architecture - Approach: The standard notes that the extent to which the baseline is modeled depends on its intended use. Given the CIO's statement

a focus on the Target Architecture is the most appropriate approach.

The scenario indicates that the preliminary strategic work, equivalent to TOGAF ADM Phase A (Architecture Vision), is already complete. A strategic architecture with detailed requirements has been approved, the CEO's vision is well-understood, and a solution type (packaged suite) has been chosen. This implies a revolutionary change, replacing the fragmented legacy systems. In such cases, the most effective approach is to focus on defining the target architectures (Phases B, C, D) that realize the strategic vision. This "target-first" emphasis ensures the new architecture directly addresses the business goals and avoids carrying forward the known inefficiencies of the baseline. Following the target definition, the next logical step is Transition Planning (Phase E).

B. This option is incorrect because it proposes re-doing the strategic analysis and requirements gathering, which the scenario explicitly states have already been completed and approved.

C. While correctly identifying the need to go through the architecture definition phases (B-D), its justification is too generic and less compelling than option A's context-specific rationale.

D. This option is incorrect because it starts with the Technology Architecture (Phase D) rather than the Business Architecture (Phase B) and improperly skips defining the target architectures.

1. The Open Group Standard

TOGAF® Version 9.2

Part II: Architecture Development Method

Chapter 6

Phase A: Architecture Vision. The scenario describes the completion of activities central to Phase A

such as defining scope

identifying stakeholders

and securing approval for a vision and requirements. The "approved strategic architecture" is a key output

setting the stage for subsequent phases.

2. The Open Group Standard

TOGAF® Version 9.2

Part II: Architecture Development Method

Chapter 7

Phase B: Business Architecture

Section 7.4 Approach. This section states

"It is good practice to understand the baseline architecture... However

it is important to document the baseline architecture to the level of detail necessary to support the target...". This supports a target-focused approach where the baseline is not the primary driver

which is appropriate for the revolutionary change described.

3. The Open Group Standard

TOGAF® Version 9.2

Part III: ADM Guidelines and Techniques

Chapter 19

Applying Iteration to the ADM. This chapter emphasizes that the ADM is flexible. The scenario warrants an iteration that prioritizes the development of the target architecture to meet a clear

top-down strategic mandate

rather than a lengthy baseline-first analysis.

The most appropriate recommendation is to establish a formal, structured approach to skills management. Option C proposes adapting the TOGAF Architecture Skills Framework to the agency's specific context. This involves defining roles, the skills required for those roles, and the desired proficiency levels. This tailored framework then serves as an objective basis for evaluating all team members, identifying specific gaps, and creating targeted professional development plans, which may include training or staffing adjustments. This systematic approach directly addresses the core problem of inconsistent proficiency and artifact quality across the team, aligning perfectly with the guidance provided in the TOGAF standard for building and managing an architecture capability.

A. This option is too narrow, focusing only on team leaders. The problem statement indicates that "many EA staff members" are affected, not just the leadership. A comprehensive solution must address the entire team.

B. An architecture maturity assessment evaluates the overall capability and processes, not primarily individual staff competencies. While related, it is less direct for solving a specific skills proficiency problem than using the Architecture Skills Framework.

D. This option repeats strategies (mentoring, training) that have already proven insufficient in the scenario. It also reacts to the symptom (bad artifacts) without addressing the root cause (lack of a structured skills framework).

1. The Open Group

"TOGAF® Standard

Version 9.2

" Document No. C182

April 2018.

Section 47.1

Introduction: States that the Architecture Skills Framework "provides a set of roles

skills

and proficiency levels for staff within an enterprise architecture team". This directly supports the approach in option C of defining roles

skills

and proficiency levels.

Section 47.2.3

Using the Framework: Explains that the framework can be used to "construct a competency assessment for the enterprise architecture team" and that "once the skills are identified

the architect manager can then identify a training and development plan for the team". This validates the process of evaluation and making necessary training adjustments as described in option C.

Section 45.3.2

Architecture Capability: Notes that a key element of architecture governance and capability is a "comprehensive Architecture Skills Framework"

reinforcing that this is the correct TOGAF tool for the situation.

The Preliminary Phase in TOGAF is focused on establishing the Enterprise Architecture (EA) capability, not on developing specific architectures. Option B correctly outlines the key activities for this phase in response to the Board's concerns. It begins by understanding the business context ("evaluate the implications... on business goals, business drivers and objectives"). It then addresses governance by updating policy and defining Architecture Principles, which are core outputs of the Preliminary Phase. Finally, it establishes the necessary capability by allocating a security architect to ensure security is a cross-cutting concern, which is the correct TOGAF approach for handling security architecture.

A: Developing a "comprehensive security architecture" is an activity for the subsequent ADM Phases (B, C, D), not the preparatory Preliminary Phase.

C: Identifying detailed requirements and constraints is a primary activity of Phase A (Architecture Vision), which follows the Preliminary Phase.

D: Issuing a "Request for Architecture Work" is an output of Phase A, and overseeing implementation is the focus of Phase G (Implementation Governance).

1. Defining Architecture Principles: The TOGAF® Standard

Version 9.2

Chapter 5

Section 5.3

Step 5

"Define and Establish Architecture Principles"

explicitly lists this as a key step in the Preliminary Phase.

2. Establishing EA Capability and Governance: The TOGAF® Standard

Version 9.2

Chapter 5

Section 5.3

Steps 2 and 4

cover confirming the governance framework (which includes policies) and establishing the architecture capability by understanding the business environment.

3. Allocating Security Resources: The TOGAF® Standard

Version 9.2

Chapter 36

"Security Architecture"

describes security as a cross-cutting concern that must be addressed in all architecture domains

supporting the role described in option B. Establishing the team to do this is part of the Preliminary Phase (Chapter 5

Section 5.3

Step 3).

4. Distinction from Phase A: The TOGAF® Standard

Version 9.2

Chapter 6

"Phase A: Architecture Vision"

details the creation of the Request for Architecture Work (Section 6.6) and the identification of business requirements (Section 6.4.3)

confirming that activities in options C and D occur after the Preliminary Phase.

This option provides the most accurate and complete description of the activities required to design the architecture across TOGAF ADM Phases B, C, and D. It correctly sequences the domains: Business, followed by Data and Application, and then Technology. It correctly identifies the key iterative steps within each of these phases: selecting reference models/viewpoints, developing Baseline and Target Architectures, and performing Gap Analysis. Crucially, it includes the consolidation step of assessing roadmap impacts, which synthesizes the findings from all domains before finalizing the Architecture Definition Document for the board review at the end of Phase D.

A. The order of the architecture domains is incorrect. Technology Architecture (Phase D) should not be addressed before Data and Application Architectures (Phase C).

B. This option incorrectly includes activities from Phase E (Implementation and Migration Planning), which occurs after the design phases (B, C, and D) are complete.

D. This option is less complete than the correct answer. It omits the important initial step of selecting reference models and viewpoints and the final consolidation of roadmap impacts.

1. The Open Group Standard

TOGAF® Version 9.2

Part II: Architecture Development Method (ADM)

Figure 5-1 "The ADM Cycle". This figure clearly shows the sequence of phases as Business Architecture (B)

Information Systems Architectures (C)

and Technology Architecture (D).

2. The Open Group Standard

TOGAF® Version 9.2

Part II: ADM

Chapters 7

8

and 9. Each of these chapters (for Phases B

C

and D respectively) lists "Select reference models

viewpoints

and tools" as the first step (e.g.

Section 7.1

8.1

9.1).

3. The Open Group Standard

TOGAF® Version 9.2

Part II: ADM

Section 9.5

"Phase D: Technology Architecture - Step 5: Resolve impacts across the Architecture Landscape". This step involves validating that the business

data

application

and technology architectures are consistent and that their combined roadmap components are understood. This aligns with "assess the roadmap impacts".

4. The Open Group Standard

TOGAF® Version 9.2

Part II: ADM

Section 9.8

"Phase D: Technology Architecture - Step 8: Create Architecture Definition Document". This step describes the finalization and consolidation of all architecture artifacts into the Architecture Definition Document

which is the primary output requested by the board.

The scenario describes a situation where the CIO, the project sponsor, has made a strategic decision to accept a non-standard technology after considering the risks. The task is to execute Phase G (Implementation Governance) based on this decision. The correct course of action is to govern the implementation of the approved solution, not to challenge or reverse the CIO's decision.

Option B correctly reflects the necessary governance activities. It formalizes the CIO's decision by updating the company's standards (Standards Information Base) to include the new technology. It establishes formal oversight through an Architecture Contract, plans for necessary assurance activities like performance testing (to meet KPIs) and compliance reviews, and confirms operational parameters (SLAs) with the business. This approach respects the sponsor's authority while ensuring the project is governed correctly according to TOGAF principles.

A. This option incorrectly challenges the CIO's explicit decision by asking the supplier to modify the solution to meet the old standards. The architect's role here is to implement the approved decision, not reverse it.

C. This option directly contradicts the CIO's directive. The CIO has already approved the non-standard solution, overruling the Architecture Board's initial recommendation. Eliminating the component is not an option.

D. This option proposes re-doing work, such as risk and impact analysis, that should have informed the CIO's decision. While some activities are correct (Architecture Contract), it misses the crucial step of formalizing the standards exception, which is a key governance action in this context.

1. The TOGAF® Standard

Version 9.2

Chapter 14: Phase G - Implementation Governance:

Section 14.2

Objectives: The objectives of Phase G include ensuring conformance with the Target Architecture. When a deviation is approved by a sponsor

the governance function's role is to manage that deviation.

Section 14.4

Step 4: Perform Enterprise Architecture Compliance Review: This step is central to Phase G. The review assesses compliance

and in this case

would confirm the CIO's approved dispensation for the non-standard technology. Option B's plan for a compliance review aligns with this.

Section 14.5

Outputs: Key outputs include a signed Architecture Contract and Compliance Assessments

both of which are mentioned or implied in option B.

2. The TOGAF® Standard

Version 9.2

Chapter 36: Architecture Governance:

Section 36.2.6

Dispensation: "The dispensation process is a formal record of an agreement to deviate from the standard for a given period of time or on a specific project or system." The CIO's approval is a dispensation. The follow-on action in option B

updating the Standards Information Base

is the correct way to manage this approved change.

3. The TOGAF® Standard

Version 9.2

Chapter 35: Architecture Contracts:

Section 35.2

Contents of an Architecture Contract: This section details that contracts should cover conformance requirements

including SLAs. Option B correctly identifies the need to create an Architecture Contract and agree on SLAs with the business.