The TOGAF Enterprise Architecture Part 2 Exam (English) (OGEA-102)

The correct answer is C, as it aligns with the TOGAF ADM approach and best practices for organizing architecture work in a phased and structured manner.

Analysis of the Correct Answer (Option C):

Identifying Projects, Dependencies, and Synergies

The scenario describes a phased approach to vehicle development over five years.

Identifying dependencies ensures a logical and structured rollout of technology and business capabilities.

Developing High-Level Architecture Descriptions

Since Business Architecture is already defined, it is now time to develop high-level descriptions of Information Systems and Technology Architectures.

TOGAF emphasizes incremental and iterative refinement, meaning that starting with high-level descriptions is a logical first step.

Determining Workload and Resource Allocation

TOGAF ADM Phase B, C, and D involve creating architecture descriptions.

Understanding how much work is required ensures efficient resource planning and allocation.

Identifying Reference Architectures and Building Blocks

Using reference architectures and reusable architecture building blocks (ABBs) is a key best practice in TOGAF.

This enables efficiency and consistency in architecture development.

Evaluating Costs, Risks, and Feasibility

TOGAF emphasizes a risk-aware approach to enterprise architecture.

Documenting options, risks, and control measures ensures feasibility before execution.

Why Other Options Are Incorrect?

Option A: Initiating ADM Phase A Again

Incorrect because the scenario states that the Architecture Vision has already been completed.

Phase A is used for initial vision-setting, but at this point, the focus is on executing defined architectures.

Option B: Researching Data Companies for Target Architecture Development

Incorrect because the focus should be on defining internal architectures rather than external research.

While benchmarking best practices can be useful, it is not the primary activity at this stage.

Option D: Studying Other Companies and Performing Readiness Assessment

Incorrect because the focus should be on leveraging the organization ' s existing architecture and resources.

Solution provider readiness assessments are typically part of procurement, not enterprise architecture development.

In this scenario you are right at the start of an ADM cycle: a Request for Architecture Work has been approved to investigate AI, and there are strong stakeholder concerns and risk questions. According to the TOGAF standard, the correct place to start is Phase A: Architecture Vision, with a strong focus on stakeholder management and capturing their concerns and required views.

Option A is the only answer that correctly reflects this:

Stakeholder analysis & Stakeholder Map (Phase A core task)TOGAF explicitly states that in Phase A you must:

Identify stakeholders

Analyze and group them by common concerns

Use a Stakeholder Map to understand their influence, interest, and required engagement

Determine which views/viewpoints are needed to address their concerns in the architecture description coe.qualiware.com+1

Option A says:

“analysis of the stakeholders … define groups of stakeholders who have common concerns and include development of a Stakeholder Map. The concerns and relevant views should then be defined for each group and recorded in the Architecture Vision document.”

This is exactly how TOGAF describes stakeholder management and views in Phase A:

Stakeholder Map to classify and prioritize stakeholders

Concerns and required views captured and traced

These elements feeding into the Architecture Vision deliverable Visual Paradigm TOGAF+1

Concerns, views, and Architecture VisionTOGAF emphasizes that architecture views are constructed to address specific stakeholder concerns; you do not just build generic models. opengroup.org+1

Option A explicitly links concerns → views → Architecture Vision, which aligns with TOGAF guidance for early phases.

Capturing this in the Architecture Vision provides a high-level, shared understanding of what the AI initiative is trying to achieve and how stakeholder issues (e.g., responsible AI, risk processes, change in way of working) will be addressed.

Risk management and “architecting with agility”In the scenario, the CIO has encouraged architecting with agility. TOGAF is compatible with incremental and iterative development of the target architecture, especially when there is high uncertainty and risk. conexiam.com

Option A includes:

“a requirement that there be progressive development of the target architecture to ensure there is regular feedback.”

This “progressive development” and frequent feedback loop is exactly how you mitigate risk in an AI-heavy, change-sensitive initiative:

Frequent stakeholder feedback

Early validation of assumptions

Ability to adjust scope, constraints, and principles as risk and understanding evolve

This directly addresses management’s worry about the change in the way of working and whether risk management and responsible AI policies are adequate: these become explicit stakeholder concerns and requirements that are iteratively refined.

Why the other options are weaker / not TOGAF-aligned as a starting point

Option B

Focuses mainly on a Communications Plan and powerful stakeholders.

While TOGAF does expect a stakeholder communications plan, it is derived from a proper stakeholder analysis and Stakeholder Map, not a substitute for it.

It also treats risk as a “component of the architecture” rather than something to be addressed early through stakeholder concerns, principles, and iteration.

Option C

Jumps straight to a solution concept diagram and benefits diagram and defers risk evaluation to when the Architecture Roadmap is defined (Phase E).

In TOGAF, risk and stakeholder concerns must be addressed already in Phase A and refined throughout, not postponed to roadmap development.

Option D

Proposes creating draft Business, Data, Application, and Technology models and putting them into the Architecture Vision.

This is too detailed for the starting point: Phase A is about high-level vision, not full draft core architecture models (those belong in Phases B, C, D).

It also doesn’t emphasize Stakeholder Mapping and grouping by concerns, which is central to resolving the worries about way of working, risk, and responsible AI.

In summary, Option A is the best and TOGAF-consistent way to begin:

Start in Phase A: Architecture Vision

Perform stakeholder analysis and create a Stakeholder Map

Define stakeholder concerns and relevant views

Record them in the Architecture Vision

Add an explicit requirement for progressive (iterative) development of the target architecture for continuous feedback and risk mitigation

Key aspects of the scenario:

Business Objective:

A merger is happening to combine offerings, reduce costs, and achieve operational efficiency.

The goal includes fully integrating retail operations and systems, replacing duplicated systems, and reducing the number of applications used.

Technological Improvements:

A central AI-based inventory system is in place.

Hand-held devices for stores have improved customer and staff satisfaction and increased efficiency.

Scope of Architecture Work:

Integrating the merged systems.

Managing retail architecture to optimize operations.

TOGAF Alignment:

TOGAF principles aim to ensure the architecture supports business transformation effectively while aligning with governance and best practices.

Best answer analysis:

Option 1:

Maximize Benefit to the Enterprise: Aligns with the merger goals of cost reduction and efficiency.

Common Use Applications: Matches the goal to reduce duplicated systems.

Data is an Asset: Central AI system depends on accurate and reliable data.

Responsive Change Management: Necessary to support the transition and manage organizational impacts.

Technology Independence: Encourages selecting flexible, scalable solutions post-merger.

This option comprehensively aligns with the scenario.

Option 2:

Control Technical Diversity: Important but less emphasized than cost reduction and application unification.

Interoperability: Relevant, but less critical compared to principles addressing business value.

Data is an Asset: Relevant.

Data is Shared: Implied in centralized inventory but not directly stated.

Business Continuity: Important but not the main focus here.

This option partially fits but lacks emphasis on business outcomes.

Option 3:

Common Vocabulary and Data Definitions: Indirectly helpful but not central to the transformation.

Compliance with the Law: Always critical, but no explicit legal issues are mentioned.

Requirements-Based Change: General principle but not transformation-specific.

Responsive Change Management: Relevant.

Data Security: Important but not a central concern in the scenario.

This option focuses more on governance and less on merger goals.

Option 4:

Common Use Applications: Relevant to reducing duplicate systems.

Data is an Asset: Relevant.

Data is Accessible: Fits with AI system and handheld devices but is a subset of " Data is an Asset. "

Ease of Use: Relevant to handheld devices but not a core transformation principle.

Business Continuity: Important but secondary to cost and efficiency.

This option focuses more on usability and accessibility rather than transformation objectives.

B is the best answer because the security problem is federated and cross-boundary. The architecture must support vehicle data, V2X providers, third-party cloud services, multiple jurisdictions, privacy regulation, and data volumes at platform scale. A purely internal data-quality approach is insufficient. At this point, after the security resource plan and security-specific architecture vision have been completed, the architect must define how security responsibilities, policies, and controls operate across participating organizations. Security federation is the most appropriate concept because data is exchanged across organizational and technical trust boundaries. It requires contractual arrangements, definition of responsibility areas, and explicit treatment of the security implications of exchanged data. Grouping assets with common security criteria under one policy also aligns with security architecture practice because controls can be consistently applied to classes of assets rather than individually improvised. A is valuable for data governance but too narrow. C jumps to a trust mechanism and certificate-based implementation detail before defining policy domains and responsibilities. D addresses qualitative risk but lacks the federated operating model required by V2X and cloud participation. References: Security Architecture; Risk Management; Data Security; Security Federation; ADM integration of security concerns.

A is the best answer because it maps precisely to the healthcare constraints in the scenario. Common Vocabulary and Data Definitions is directly relevant because the organization shares electronic health records with multiple providers and uses standardized medical coding for billing and reporting. AI-based healthcare solutions depend on consistent clinical meaning; ambiguous terminology could cause incorrect interpretation of diagnoses, procedures, or outcomes. Data Security is also central because patient information must remain private, protected against breaches, and available for clinical use. In healthcare architecture, security is not only confidentiality; it also supports integrity and availability of clinical data during care delivery. Requirements-Based Change is the third critical principle because stakeholders explicitly state that changes must improve patient outcomes and preserve life-critical operations. The architecture must therefore be driven by validated clinical and business requirements, not by technology enthusiasm for AI. B contains relevant concepts but misses the explicit requirements-based control needed for life-critical change. C underplays security and clinical change control. D emphasizes change responsiveness, but not the data semantics and patient-data protection that dominate the scenario. References: ADM Techniques, Architecture Principles; Data Principles; Application Principles; Requirements Management.

The Target Architecture is a description of the future state of the architecture that addresses the business goals and drivers, and satisfies the stakeholder requirements and concerns. The Target Architecture is developed through the Architecture Development Method (ADM), which is the core process of the TOGAF standard that guides the development and management of the enterprise architecture. The Target Architecture is typically divided into four domains: Business, Data, Application, and Technology. The Target Architecture also includes a roadmap for change, which defines the Transition Architectures, the Capability Increments, and the work packages that enable the transition from the Baseline Architecture to the Target Architecture12

The best answer is B, because it describes the approach that should be taken to determine and organize the work to deliver the requested architectures, which are the Information Systems and Technology Architectures. The answer covers the following steps:

Refer to the end-to-end Target Architecture for guidance and direction. The end-to-end Target Architecture provides the overall vision, scope, and objectives of the architecture work, and the alignment with the business strategy and goals. The end-to-end Target Architecture also provides the high-level definitions and principles for the four architecture domains, and the roadmap for change that outlines the major milestones and deliverables.

Identify projects, dependencies and synergies, then prioritize before initiating the projects. Projects are the units of work that implement the architecture work packages, which are the sets of actions or tasks that are required to implement a specific part of the architecture. Dependencies are the relationships and constraints that affect the order or priority of the projects, such as logical, temporal, or resource dependencies. Synergies are the benefits or advantages that result from the combination or coordination of the projects, such as cost savings, efficiency gains, or innovation opportunities. Prioritization is the process of ranking the projects according to their importance, urgency, or value, and assigning resources and schedules accordingly.

Develop high-level architecture descriptions. High-level architecture descriptions are the outputs of the architecture development phases (B, C, and D) of the ADM cycle, which describe the Business, Data, Application, and Technology Architectures in terms of the Architecture Building Blocks (ABBs) and the Solution Building Blocks (SBBs), which are reusable components of business, IT, or architectural capability. High-level architecture descriptions also include the Architecture Views, which are representations of the system of interest from the perspective of one or more stakeholders and their concerns.

For each project, estimate effort size, identify reference architectures, and candidate building blocks. Effort size is the measure of the amount of work, time, or resources required to complete a project. Effort size can be estimated using various techniques, such as analogy, expert judgment, parametric, or bottom-up. Reference architectures are standardized architectures that provide a common framework and vocabulary for a specific domain or industry. Reference architectures can be used as a source of best practices, patterns, and models for the architecture development. Candidate building blocks are the potential ABBs or SBBs that can be used to implement the architecture. Candidate building blocks can be identified from the Architecture Repository, which is a collection of architecture assets, such as models, patterns, principles, standards, and guidelines.

Identify the resource needs considering cost and value. Resource needs are the specifications and criteria that define the acceptable level and quality of the resources required to complete the project, such as human, financial, physical, or technological resources. Resource needs can be identified by analyzing the scope, complexity, and dependencies of the project, and the availability, capability, and suitability of the resources. Cost and value are the factors that influence the allocation and utilization of the resources, such as the budget, the return on investment, the benefits, or the risks.

Document options, risks, and controls to enable viability analysis and trade-off with the stakeholders. Options are the alternative ways of achieving the project objectives, such as different solutions, technologies, vendors, or approaches. Risks are the effects of uncertainty on the project objectives, such as threats or opportunities. Controls are the measures or actions that are taken to prevent, reduce, or mitigate the risks, such as policies, procedures, or standards. Viability analysis is the process of evaluating and comparing the options, risks, and controls, and determining the feasibility, suitability, and desirability of each option. Trade-off is the decision outcome that balances and reconciles the multiple, often conflicting, requirements and concerns of the stakeholders, and ensures alignment with the Architecture Vision and the Architecture Principles.

 1: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 5: Introduction to the ADM 2: The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter 36: Building Blocks : 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 19: Phase B: Business Architecture : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 20: Phase C: Information Systems Architectures : 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 III: ADM Guidelines and Techniques, Chapter 23: Architecture Principles : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 30: Trade-Off Analysis : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 46: Tools for Architecture Development : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 47: Architecture Board : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 48: Architecture Compliance : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 49: Architecture Contract : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 50: Architecture Governance : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 51: Architecture Maturity Models : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 52: Architecture Skills Framework

The Business Value Assessment Technique is a technique that can be used to estimate and compare the business value of the projects and project increments that implement the architecture work packages, which are the sets of actions or tasks that are required to implement a specific part of the architecture. The business value is the measure of the benefits or advantages that the project or project increment delivers to the business, such as increased revenue, reduced costs, improved quality, or enhanced customer satisfaction1

The steps for applying the Business Value Assessment Technique are:

Identify the criteria and factors that are relevant to the business value assessment, such as costs, benefits, risks, and opportunities. The criteria and factors should be aligned with the business goals and drivers that motivate the architecture work, and the stakeholder requirements and concerns that influence the architecture work.

Assign weights and scores to the criteria and factors, using various methods, such as expert judgment, historical data, or analytical models. The weights and scores should reflect the importance and performance of the criteria and factors, and the trade-offs and preferences of the stakeholders.

Calculate the business value for each project or project increment, using various techniques, such as net present value, return on investment, or balanced scorecard. The business value should indicate the expected or actual outcomes and impacts of the project or project increment on the business.

Prioritize the implementation projects and project increments, based on the business value and other considerations, such as dependencies, resources, or risks. The prioritization should determine the order or sequence of the projects and project increments, and the allocation and utilization of the resources.

Therefore, the best answer is C, because it describes the next steps for the migration planning, which are the activities that support the transition from the Baseline Architecture to the Target Architecture. The answer covers the Business Value Assessment Technique, which is relevant to the scenario.

 1: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 28: Business Value Assessment Technique : 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 21: Phase F: Migration Planning : The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter 36: Building Blocks

In the TOGAF framework, understanding and addressing stakeholder concerns is crucial, particularly for complex projects with high stakes like the AI-first initiative described in the scenario. This approach aligns well with TOGAF’s ADM (Architecture Development Method) and its emphasis on effective stakeholder management and risk assessment. Here’s why this is the best course of action:

Stakeholder Analysis and Documentation:Conducting a stakeholder analysis is foundational in the early stages of any TOGAF project, particularly during the Preliminary and Architecture Vision phases. This process involves identifying the different stakeholders, understanding their positions, documenting their concerns, and considering any cultural factors that might influence their perspective on the AI-first initiative. Given the diverse concerns raised (such as job security, skill requirements, and cybersecurity), it’s essential to have a clear understanding of each stakeholder group’s priorities and fears.

Recording Concerns in the Architecture Vision Document:The Architecture Vision phase in TOGAF focuses on defining the high-level scope and objectives of the architecture project. By documenting stakeholder concerns and the corresponding views in the Architecture Vision document, the EA team ensures that these concerns are transparently acknowledged and addressed as part of the strategic direction. This step not only aligns with TOGAF best practices but also helps in building stakeholder buy-in and trust.

Architecture Requirements Specification and Risk Management:Risk management is a key aspect of TOGAF’s ADM, particularly in the Requirements Management and Implementation Governance phases. Documenting the requirements for addressing specific risks in the Architecture Requirements Specification provides a structured way to ensure that identified risks are acknowledged and managed throughout the transformation. Regular assessments and feedback loops ensure ongoing alignment and adaptability to emerging risks, which is particularly important given the dynamic nature of AI and its associated challenges.

Alignment with TOGAF ADM Phases:This approach follows the prescribed flow of TOGAF’s ADM, starting with stakeholder engagement in the Preliminary and Architecture Vision phases and progressing to risk assessment in the Requirements Management phase. By maintaining a focus on stakeholder needs and formalizing these into architecture requirements, the EA team can ensure that the architecture not only meets business objectives but also mitigates stakeholder concerns.

TOGAF Reference on Stakeholder Management Techniques:TOGAF places significant emphasis on managing stakeholder concerns through its stakeholder management techniques, which highlight the need to systematically identify, analyze, and address the concerns of all involved parties. This practice helps ensure that the architecture is viable and accepted across the organization.

By conducting a thorough stakeholder analysis and integrating the findings into both the Architecture Vision and the Architecture Requirements Specification, the EA team can proactively address stakeholder concerns, manage risks, and align the AI-first initiative with the agency’s strategic objectives. This approach is consistent with TOGAF’s guidance and provides a structured framework for addressing both business and technical challenges in the context of an AI-first transformation.

The scenario states that:

A strategic architecture and roadmap already exist.

Business Architecture is complete, so the work now shifts to Information Systems and Technology Architectures (ADM Phases B–D).

The CTO requires use of the purpose-based EA Capability model (from the TOGAF Series Guide: A Practitioner’s Approach to Developing Enterprise Architecture Following the TOGAF ADM).

The EA team has to plan, organize, and manage the next stage of architecture development, including re-use of existing hardware/software platform components, candidate solutions, feasibility, risks, and prioritization.

Under the purpose-based EA approach, when moving from strategy into defining the next layers of architecture, TOGAF emphasizes:

Using the superior (already-approved) architecture to guide the next ADM cycles– This corresponds to the strategic architecture that is already completed.

Analyzing project dependencies, overlaps, and sequencing

Defining high-level architecture descriptions for the next iteration

Identifying reference architectures and candidate building blocks (especially when reusing existing platform components)

Assessing feasibility, value, cost, and risk for each project

Preparing for stakeholder trade-offs before formalizing the roadmap

These tasks map directly to Option A.

Why Option A is correct

Option A includes exactly what the purpose-based EA approach prescribes at this stage:

“The superior architecture should be used to guide the approach.”✔ Correct — strategic architecture guides the work.

“Review the identified projects, dependencies, and potential overlaps, then decide the order…”✔ Correct — sequencing and dependency assessment are core early tasks in Phases B–D planning.

“Develop high-level architecture descriptions.”✔ Correct — Business Architecture is done; now high-level IS/Tech Architecture descriptions are needed.

“Identify reference architectures and candidate building blocks.”✔ Correct — aligns with TOGAF building-block approach, and specifically fits the scenario where existing platform components will be reused.

“Identify resource needs, considering cost and value.”✔ Correct — mandatory for feasibility and planning.

“Document options, risks, and ways to control them to enable feasibility analysis and trade-off with stakeholders.”✔ Correct — this matches ADM guidelines for preparing options and addressing complexity before deeper development.

This is precisely how TOGAF expects the architecture team to plan, organize, and manage an ADM cycle after strategy is set.