The TOGAF 9.2 Combined Part 1 and Part 2 (OG0-093)

The best answer is D .

The scenario is mainly about stakeholder concern, organizational change risk, and the Chief Information Officer’s preference for architecting with agility. The concerns include management uncertainty, staff fear about performance measurement, local regulatory obligations, and whether the AI-based system will achieve the business goals. TOGAF addresses this type of situation through Stakeholder Management , Architecture Vision , architecture views , and iterative or progressive architecture development.

Option D is the strongest answer because it follows the TOGAF stakeholder management approach. TOGAF recommends identifying stakeholders, understanding and documenting their concerns, grouping stakeholders where they have common concerns, developing a Stakeholder Map, and defining architecture views that address those concerns. In this case, different stakeholder groups will have different concerns: senior managers are concerned about business performance and successful change; staff are concerned about how the system may be used to measure them; local offices are concerned about regulatory compliance; and the Chief Information Officer is concerned about managing risk while progressing with agility.

The answer also correctly records concerns and relevant views in the Architecture Vision . In TOGAF Phase A, the Architecture Vision establishes the high-level aspiration, scope, stakeholder concerns, business requirements, constraints, and value proposition for the architecture work. Since the Request for Architecture Work has already been approved, this is the correct stage to identify stakeholders and concerns clearly and ensure the Architecture Vision reflects them.

The final part of Option D is also important: progressive development of the Target Architecture to obtain regular feedback. This aligns with the Chief Information Officer’s preference for architecting with agility. In TOGAF, the ADM is iterative and can be adapted. Progressive development helps reduce risk by validating assumptions early, checking stakeholder concerns regularly, and avoiding a large late-stage surprise. For an AI-based legal and financial process system, this is especially important because the risks include business change adoption, staff trust, regulatory compliance, and operational impact.

Option A is not the best answer. Business models and consensus-building may help, but the answer focuses too narrowly on business models and top managers. It does not adequately address the wider stakeholder concerns, especially staff concerns and local regulatory concerns. It also incorrectly pushes risk management mainly into Security Architecture, whereas the scenario’s risks are broader than security; they include organizational change, adoption, governance, compliance, and stakeholder acceptance.

Option B is also not the best answer. Architecture models for Business, Application, and Technology Architectures are useful, and regulatory compliance is important for a law firm operating in many countries. However, this option focuses mainly on creating models and holding a formal review. It does not provide the stronger TOGAF stakeholder management structure of stakeholder analysis, grouping, Stakeholder Map, stakeholder concerns, relevant views, and progressive feedback.

Option C is a reasonable answer, but it is weaker than D . It correctly identifies stakeholders, documents concerns, creates a Communications Plan, and checks with stakeholders. However, it does not explicitly include grouping stakeholders with common concerns, developing a Stakeholder Map, defining relevant views for each stakeholder group, or using progressive development to reduce risk. These points make D more complete and better aligned with TOGAF guidance and the CIO’s preference for architecting with agility.

Therefore, D is the best answer because it uses TOGAF Stakeholder Management, records concerns and views in the Architecture Vision, and reduces risk through progressive development and regular stakeholder feedback.

The best answer is C .

The scenario states that the security resource plan and security-specific Architecture Vision have already been completed. That places the work after the early security planning and vision activities and into the development of security-related architecture content. The scenario also emphasizes that data will be shared across third-party cloud services and V2X service providers in many countries. This makes security federation , security domains , responsibility boundaries , security policy , and risk assessment especially relevant.

Option C is the best answer because it matches the TOGAF security guidance most directly. The TOGAF security guidance explains that a security domain groups assets with the same security level under the jurisdiction of one security policy. It also states that the security domain model helps define responsibility areas where responsibility is exchanged with external parties. In this scenario, the company is exchanging and processing vehicle and journey-related data across external V2X and cloud service providers, so defining those responsibility areas is essential.

Option C also correctly addresses security federation . The TOGAF security guidance states that, where the business model includes federation with other organizations and where organizations have data objects or activities in common, the extent of the security federation should be established. It also states that contractual federation agreements should be examined for their security implications. This aligns closely with the scenario because the driver assistance system must operate with multiple third-party service providers and across multiple regulatory jurisdictions.

Option C further includes carrying out a risk assessment for the relevant data assets. TOGAF security guidance defines risk assessment as the activity of determining risks relevant to an asset or objective. In this scenario, the data assets are highly sensitive because they may reveal drivers’ journeys and raise privacy and regulatory concerns. Therefore, the architecture work must identify the relevant risks to those assets and define appropriate security controls and governance.

Option A is not the best answer. It focuses mainly on data quality, dataset ownership, and classification. These are relevant topics, and TOGAF security guidance does recognize data quality and classification as part of security requirements. However, this option does not sufficiently address the key scenario issue: multiple external service providers sharing data through a federated security environment.

Option B is not the best answer. A trust framework is relevant because the scenario involves third parties, but the option overstates the role of digital certificates. The TOGAF security guidance specifically notes that technology such as digital certificates cannot create trust; it can only convey trust that already exists through real-world business relationships, legal agreements, and security policy consistency. For that reason, Option B is weaker than Option C.

Option D is partially correct because qualitative risk assessment and the Business Risk Model are valid TOGAF security concepts. However, it is too narrow for this scenario because it focuses mainly on risk assessment and risk strategy. It does not address the important federated security structure, contractual responsibility boundaries, external service provider relationships, and shared security-policy domains that are central to the problem described.

Therefore, the correct answer is C .

The best answer is C .

The scenario is focused on the sponsors’ concern that the major AI and machine learning reorganization may fail. They want assurance before approving the detailed Implementation and Migration Plan. In TOGAF terms, this points directly to the Business Transformation Readiness Assessment and related risk assessment activities. TOGAF Phase E, Opportunities and Solutions, is concerned with identifying major work packages, transition states, dependencies, implementation constraints, and the enterprise’s readiness for business transformation. Phase E takes the full set of gaps between Baseline and Target Architectures and groups changes into work packages to form a best-fit roadmap based on stakeholder requirements, business transformation readiness, opportunities, solutions, and implementation constraints.

Option C is correct because it directly addresses the request from the sponsors. It proposes assessing the organization’s readiness to change, identifying and classifying transformation risks, defining mitigation approaches, identifying dependencies between changes, gaps, and work packages, and incorporating improvement actions into the Implementation and Migration Plan. This is the strongest alignment with TOGAF’s Business Transformation Readiness Assessment technique and with the Phase E and Phase F concern of ensuring that transformation risk is understood before implementation planning is finalized. The approach also identifies business value, effort, and risk for each transformation, which is necessary when deciding how to sequence and govern a multi-year transformation roadmap.

Option A contains several valid TOGAF activities, including consolidating gap analysis results from Phases B to D, identifying required transformations, assessing readiness, and planning Transition Architectures. However, it is not the best answer because it places more emphasis on gap consolidation and state evolution than on the sponsors’ central request: assurance that the organization is ready for the transformation and that the risks are identified, classified, mitigated, and included in the Implementation and Migration Plan.

Option B is too vague and introduces wording that is not the best match for the TOGAF guidance. It mentions a matrix showing organizational requirements and alignment with the corporate operating model, but it does not clearly describe the Business Transformation Readiness Assessment, dependency analysis, improvement actions, or business value, effort, and risk assessment for each transformation.

Option D focuses mainly on Architecture Alternatives and Trade-offs, alternative Transition Architectures, state evolution, and value realization. These can be useful techniques, but the scenario is not primarily asking how to select between alternative architectures. It is asking how to respond to sponsors who need confidence that a large organizational transformation can succeed and that risks are addressed before the detailed Implementation and Migration Plan is approved.

Therefore, C is the best answer because it most directly applies TOGAF’s readiness and risk assessment approach to a major business transformation and connects the results to the Implementation and Migration Plan.

Option A correctly addresses the issue by focusing on understanding customer value through Business Architecture modeling and value stream mapping. These approaches, supported by TOGAF’s ADM Phase B, help ensure that the architecture aligns with customer needs and improves revenue generation.

Options B, C, and D either neglect customer-focused modeling or emphasize unnecessary phases like complete ADM cycles, which would delay actionable insights for the product manager.

Business Value Technique usually follows BTRA, and will fulfil the requirement to phase approach by prioritizing projects and listing their execution using ADI table.

Reference https://pubs.opengroup.org/architecture/togaf91-doc/arch/chap06.html

Analysis of Scenario and TOGAF Guidance

In this scenario, the Lead Enterprise Architect must address concerns from senior management regarding the risks of an ambitious five-year transformation strategy. Senior management is uncertain if the architecture can deliver enough value to justify the risks. The CIO has requested an assessment of these risks before approving the detailed Implementation and Migration Plan.

The TOGAF ADM (Architecture Development Method) provides guidance for risk and readiness assessments as part of Phases E (Opportunities and Solutions) and F (Migration Planning). Specifically, TOGAF encourages readiness assessments to evaluate an organization’s capability for change and Business Value Assessments to gauge the potential value and risks associated with proposed changes.

Explanation of Option B and Why It is the Best Answer

Readiness Assessment :

A Readiness Assessment helps in evaluating whether the organization is prepared to undertake the transformations. This assessment will identify any gaps in the organization’s capabilities, culture, or resources needed to support the change. Addressing these gaps helps mitigate the risks of transformation.

TOGAF’s ADM Phase F includes readiness assessment as a critical activity, as it provides insights into how prepared the organization is for the changes and identifies required improvement actions, which can be integrated into the Implementation and Migration Plan.

Business Value Assessment :

TOGAF recommends using a Business Value Assessment Technique to determine the value and associated risks of the transformation. This technique provides a structured approach to assess whether the anticipated business benefits are likely to be realized and at what level of risk. It helps ensure that all stakeholders have a clear understanding of the expected outcomes, costs, and risks.

This assessment would address the senior management ' s concerns about whether the proposed architecture changes would deliver sufficient value to justify the risks, which aligns with TOGAF’s guidance in Phases E and F.

Aligns with TOGAF ADM Phases E and F :

In Phase E (Opportunities and Solutions) , TOGAF specifies the identification of business transformation risks and readiness for change as part of creating the Architecture Roadmap.

In Phase F (Migration Planning) , these analyses help in finalizing the Implementation and Migration Plan. By addressing risks early, the EA team can incorporate risk mitigation strategies and align the plan with the organization’s readiness to adopt changes.

Why Options A, C, and D Are Less Suitable

Option A : Although gathering information from the Architecture Repository and performing a state evolution analysis are useful steps, this option lacks a readiness assessment and a value assessment, which are specifically relevant to evaluating the feasibility and value of ambitious transformations. Without these assessments, senior management’s concerns regarding risks and value remain insufficiently addressed.

Option C : Interoperability analysis primarily addresses integration between system components, not the broader organizational readiness or the risk and value concerns raised by senior management. While interoperability is important, it is a technical aspect that does not directly address readiness for change or business value.

Option D : Consolidating gap analysis results is a relevant step for determining necessary changes, but it does not specifically address the need to evaluate the organizational readiness or to assess the business value and associated risks. This approach also omits the Business Value Assessment, which is crucial for justifying the transformations.

TOGAF References Supporting Option B

TOGAF Section 31.3.5 : Recommends using Readiness Assessment to determine the capability of an organization to support transformation efforts.

TOGAF Section 31.3.8 : Describes the Business Value Assessment Technique as a way to assess the potential value and risks of proposed transformations.

TOGAF ADM Phases E and F : Emphasize the importance of readiness assessments and risk analysis for the creation of the Architecture Roadmap and Implementation and Migration Plan, ensuring that plans align with the organization’s ability to adopt and benefit from the changes.

In summary, Option B is the best answer as it aligns with TOGAF ' s guidance on performing readiness and value assessments to address management’s concerns regarding the risk and value of the transformation.