OGEA-103 Practice Questions

According to the TOGAF Standard, 10th Edition, documents which are under development and have

not undergone any formal review and approval process are called draft documents, while documents

which have been reviewed and approved are called approved documents 1. Draft documents are

typically marked with a version number of 0.x, indicating that they are incomplete or provisional.

Approved documents are typically marked with a version number of 1.0 or higher, indicating that

they have been finalized and authorized. The other options are not correct, as they are not the terms

used by the TOGAF Standard to distinguish between documents under development and documents

that have been reviewed and approved. The terms “finalized”, “concept”, “deliverable”, and “Version

0.1” and “Version 1.0” are not specific to the TOGAF Standard, and they may have different meanings

or interpretations in different contexts. Reference: 1: TOGAF Standard, 10th Edition, Part II:

Architecture Development Method, Chapter 7: Applying Iteration to the ADM, Section 7.2.3

Document Categorization.

In the ADM documents which are under development and have not undergone any formal review

and approval process are called “draft”. This indicates that they are subject to change and refinement

as the architecture development progresses. Reference: The TOGAF® Standard | The Open Group

Website, Section 4.2.5 Architecture Deliverables.

Comprehensive and Detailed Step-by-Step Explanation

Context of the Scenario

The agency is initiating a strategic “AI-first” plan to transform processes using AI and improve

efficiency while ensuring service improvements for citizens. Several stakeholder concerns have been

raised, such as:

Job security for employees.

Skill development for adapting to new technologies.

Cybersecurity and resilience risks due to reliance on digital platforms.

TOGAF emphasizes the importance of stakeholder management, communication, and risk

management to ensure successful adoption and implementation of new architecture. These

concerns need to be addressed methodically by gathering requirements, analyzing stakeholder

positions, and ensuring proper communication of risks and benefits.

Option Analysis

Option A:

Strengths:

Proposes creating an Organization Map to identify the links between different parts of the agency

and the impact of the strategic change.

Suggests holding stakeholder meetings to address concerns.

Includes managing risks as part of Security Architecture development.

Weaknesses:

Focusing solely on creating business models and teaching stakeholders how to interpret them does

not directly address cultural and positional concerns about job loss, skill development, and security.

Risk management is addressed as part of Security Architecture development but lacks broader

integration into stakeholder requirements.

Conclusion: Incorrect, as it fails to systematically document stakeholder concerns and map them into

requirements and architecture decisions.

Option B:

Strengths:

Highlights the importance of formal stakeholder identification and creating a Communication Plan.

Suggests addressing stakeholder concerns through communication and risk management.

Weaknesses:

Does not go into detail on analyzing stakeholder concerns, cultural positions, or specific

requirements.

Lacks the inclusion of stakeholder feedback in architecture artifacts like the Architecture Vision or

Requirements Specification, which are critical TOGAF outputs.

Conclusion: Incorrect, as it does not include a systematic and structured approach for stakeholder

analysis and integration into architecture deliverables.

Option C:

Strengths:

Emphasizes conducting a thorough stakeholder analysis to document concerns, positions, and

cultural factors, which aligns with TOGAF’s approach in Phase A (Architecture Vision).

Ensures stakeholder views and requirements are recorded in the Architecture Vision document and

reflected in the Architecture Requirements Specification.

Includes continuous assessment and feedback, ensuring concerns are addressed and risks managed

effectively.

Aligns with TOGAF's principle of involving stakeholders in architecture development to ensure

alignment and success.

Weaknesses:

Could further detail how risk management is included across all phases, but this is implied through

integration into the Architecture Requirements Specification.

Conclusion: Correct, as it provides a structured and detailed approach for addressing stakeholder

concerns and managing risks within TOGAF’s framework.

Option D:

Strengths:

Suggests categorizing stakeholders into groups and creating models for each category.

Proposes arranging meetings to verify that concerns have been addressed.

Includes risk management as part of the process.

Weaknesses:

Dividing stakeholders into generic categories (e.g., corporate functions, project team) may not

adequately capture specific cultural factors and concerns raised in the scenario.

Lacks integration of stakeholder feedback into architecture deliverables such as the Architecture

Vision and Architecture Requirements Specification.

Conclusion: Incorrect, as it provides a generalized and less targeted approach to stakeholder

concerns compared to Option C.

TOGAF Reference

Stakeholder Management (Phase A): TOGAF emphasizes analyzing stakeholders’ positions, concerns,

and issues to shape architecture development and communication (TOGAF 9.2, Section 24.2).

Architecture Vision: Captures high-level requirements and stakeholder views to ensure alignment

with business goals (TOGAF 9.2, Section 6.2).

Architecture Requirements Specification: Records detailed requirements, including those related to

risk management, to guide the development of target architectures (TOGAF 9.2, Section 35.5).

Iterative Feedback: Regular assessments and feedback loops are critical to ensure stakeholder

concerns are addressed effectively throughout the ADM cycle.

By selecting Option C, the approach adheres to TOGAF's principles of stakeholder analysis,

communication, and integration of concerns into architecture development.

:

The Architecture Requirements Repository stores all the requirements that are output of the

architecture development cycle, as well as the requirements that are input to the architecture

development cycle1. The Architecture Requirements Repository includes the following types of

requirements1:

•Stakeholder Requirements: These are the high-level requirements and expectations of the

stakeholders, derived from the business drivers, goals, and objectives. They are captured and refined

in the Architecture Vision phase and the Requirements Management phase.

•Architecture Requirements: These are the detailed requirements that specify what the architecture

must do or deliver to meet the stakeholder requirements. They are derived and refined in the

Business, Information Systems, and Technology Architecture phases.

•Implementation and Migration Requirements: These are the detailed requirements that specify

what the implementation and migration projects must do or deliver to realize the architecture. They

are derived and refined in the Opportunities and Solutions and Migration Planning phases.

The Architecture Requirements Repository is used to manage the architecture requirements

throughout the architecture lifecycle, ensuring their traceability, consistency, and compliance1. The

Architecture Board is the authority that reviews and approves the architecture requirements, as well

as the architecture deliverables and artifacts, as part of the architecture governance process2.

Reference: 1: Architecture Requirements Repository 2: Architecture Board

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.

Strategy Portfolio Project Solution Delivery are the four purposes that typically frame the planning

horizon, depth and breadth of an Architecture Project, and the contents of the EA Repository. They

correspond to different levels of abstraction and granularity in the architecture development

process. Reference: The TOGAF® Standard, Version 9.2 - The Open Group, Section 2.4 Architecture

Repository.

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.

Implementation Governance

Architecture governance is the practice of ensuring compliance with the enterprise architecture and

its principles, standards, and goals. Architecture governance provides the means to establish,

monitor, and control the architecture development and implementation processes, and to resolve

any issues or conflicts that may arise. Architecture governance also ensures that all stakeholders are

represented and involved in the decision-making process, and that their interests and concerns are

balanced and aligned. Statements 1 and 2 highlight the value and necessity for architecture

governance to be adopted within organizations, as they emphasize the importance of responsibility,

accountability, fairness, and transparency in the architectural activities. Statements 3 and 4 are more

related to the benefits and outcomes of having a good enterprise architecture, rather than the

governance aspect.

The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 50:

Architecture Governance : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and

Techniques, Chapter 29: Architecture Governance

This statement about Requirements Management is most correct because it reflects the central role

of Requirements Management and stakeholder engagement in the ADM cycle. Requirements

Management is not a step of all ADM Phases, but rather an ongoing process that ensures that all

relevant requirements are elicited, analyzed, prioritized, and addressed throughout the architecture

development and transition. Stakeholder engagement is also a continuous activity that involves

identifying, communicating, and managing stakeholder expectations and concerns. Reference: The

TOGAF® Standard | The Open Group Website, Section 3.1 Introduction to the ADM.