OGEA-103 TOGAF Enterprise Architecture Combined Part 1 and Part 2 Exam Questions and Answers

The illustration shows an architecture development cycle based on the TOGAF ADM (Architecture Development Method), which is a method for developing and managing an enterprise architecture1.

The ADM consists of nine phases, each with a specific purpose and output. The phases are1:

Preliminary Phase: To prepare and initiate the architecture development cycle, including defining the architecture framework, principles, and governance.

Phase A: Architecture Vision: To define the scope, vision, and stakeholders of the architecture initiative, and to obtain approval to proceed.

Phase B: Business Architecture: To describe the baseline and target business architecture, and to identify the gaps between them.

Phase C: Information Systems Architectures: To describe the baseline and target data and application architectures, and to identify the gaps between them.

Phase D: Technology Architecture: To describe the baseline and target technology architecture, and to identify the gaps between them.

Phase E: Opportunities and Solutions: To identify and evaluate the opportunities and solutions for implementing the target architecture, and to define the work packages and transition architectures.

Phase F: Migration Planning: To finalize the implementation and migration plan, and to ensure alignment with the enterprise portfolio and project management.

Phase G: Implementation Governance: To provide architecture oversight and guidance for the implementation projects, and to manage any architecture change requests.

Phase H: Architecture Change Management: To monitor the changes in the business and technology environment, and to assess the impact and performance of the architecture.

In addition to these phases, there is a central process called Requirements Management, which is labeled as item 1 in the illustration. This process operates throughout the ADM cycle, and its purpose is to manage the architecture requirements throughout the architecture development, ensuring that they are aligned with the business requirements and the stakeholder concerns2.

Therefore, the description that matches the phase of the ADM labeled as item 1 is C. Operates the process of managing architecture requirements.

1: The TOGAF Standard, Version 9.2, Chapter 5: Architecture Development Method (ADM)

2: The TOGAF Standard, Version 9.2, Chapter 17: Requirements Management

Business scenarios are a technique for capturing, clarifying, and communicating the functional and non-functional requirements of a system. Business scenarios describe the business environment, the actors involved, the desired outcomes, and the processes or rules that govern the behavior of the system. Business scenarios are useful for ensuring that the architecture addresses the real needs and concerns of the stakeholders, and for validating and testing the architecture against expected situations. Business scenarios are developed in Phase A: Architecture Vision of the ADM cycle, and refined and updated throughout the other phases3 References: 3: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 26: Business Scenarios : The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18: Phase A: Architecture Vision

The Preliminary Phase is the preparatory phase of the Architecture Development Method (ADM) cycle, which sets the context and direction for the architecture work. One of the objectives of this phase is to select and implement tools to support the Architecture Capability, which is the ability of an organization to perform enterprise architecture effectively and efficiently. Tools can include software applications, methods, techniques, standards, and frameworks that assist the architecture development and governance processes. The selection and implementation of tools should be based on the requirements and constraints of the organization, and the alignment with the Architecture Principles and the Architecture Vision3 References: 3: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 6: Preliminary Phase : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 45: Establishing and Maintaining an Enterprise Architecture Capability : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 46: Tools for Architecture Development

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

OptionCaligns best withTOGAF Phase F: Migration Planning, which deals with developing adetailed Implementation and Migration Plan, ensuringalignment with other enterprise frameworks, and assigningbusiness valueto work packages and projects.

????TOGAF Phase F Activities (from the standard):

Confirm Management Framework Interactions:

Per TOGAF,Phase Fensures that the migration planning isaligned with the business planning, portfolio/project management, and operations management frameworksused by the enterprise (which are mentioned in the scenario).

TOGAF emphasizes coordination between EA and other enterprise governance processes.

Prioritize Projects:

TOGAF recommends usingbusiness value, resource availability, and strategic alignmentto prioritize the various work packages and projects for implementation.

This is directly referenced in option C:"assign a business value to each project, considering the available resources and how well they align with the strategy."

Update Roadmaps and Implementation Plan:

After coordination and prioritization, theArchitecture Roadmapand theImplementation and Migration Planare updated.

This is essential before formal governance (Phase G).

❌Why the Other Options Are Incorrect:

A: Incorrect focus on updating the Architecture Definition Document and lessons learned.

The Architecture Definition Document is mostly finalized in Phases B–E.

Lessons learned and governance modeling are more relevant toPhase G(Implementation Governance) andPhase H(Architecture Change Management), not Phase F.

B: Although it mentions theBusiness Value Assessment Technique(a valid tool in TOGAF), it includesArchitecture Definition Increments Table, which isnot a standard TOGAF artifact.

Also, "document the lessons learned" isprematurein Phase F; these are more applicable inPhase H.

D: Focuses onCompliance Assessment, which is part ofPhase G(Implementation Governance),not Phase F.

Changing performance requirements based on monitoring tools is handled duringoperations and change management, not during migration planning.

????Source References from TOGAF:

TOGAF 9.2 – Section 11.3 (Phase F: Migration Planning)

"Activities include confirming the enterprise's capability for transition, prioritizing projects, identifying dependencies and resource availability, and co-ordinating with other management frameworks."

TOGAF 9.2 – Section 11.4 Outputs:

Architecture Roadmap (updated)

Implementation and Migration Plan (updated)

Business Value Assessment

Consolidated Gaps, Solutions, and Dependencies

Phase B of the ADM cycle is the Business Architecture phase. It describes the development of a Business Architecture to support an agreed Architecture Vision. The objectives of this phase are to describe the baseline and target Business Architecture, identify candidate Architecture Roadmap components based on gaps between the baseline and target, and determine whether an incremental approach is required. Reference: The TOGAF® Standard | The Open Group Website, Section 3.2.2 Phase B: Business Architecture.

The description provided aligns with Phase F: Migration Planning in the TOGAF ADM. This phase focuses on finalizing and implementing the projects necessary to reach the adjusted target state.

Phase F Objective:

Ensures projects and work packages are well-defined and align with stakeholder priorities.

Translates architecture changes into actionable implementation projects.

Assesses risk, value, and effort in implementation.

Establishes the Implementation and Migration Plan.

Key Outputs of Phase F:

Architecture Roadmap (Updated)

Implementation and Migration Plan

Governance Model for Change Implementation

Why Other Options Are Incorrect:

Option A (Phase E: OpportunitiesandSolutions): Focuses on defining projects and high-level solutions, but does not complete their implementation planning.

Option B (Phase A: Architecture Vision): Establishes high-level goals but does not involve migration planning.

Option C (Phase G: Implementation Governance): Ensures the execution aligns with architecture, but does not define projects for migration.

According to the TOGAF Standard, Version 9.2, the ADM phases and their objectives are as follows1:

Preliminary Phase: To prepare and initiate the architecture development cycle, including defining the architecture framework, principles, and governance.

Phase A: Architecture Vision: To define the scope, vision, and stakeholders of the architecture initiative, and to obtain approval to proceed.

Phase B: Business Architecture: To describe the baseline and target business architecture, and to identify the gaps between them.

Phase C: Information Systems Architectures: To describe the baseline and target data and application architectures, and to identify the gaps between them.

Phase D: Technology Architecture: To describe the baseline and target technology architecture, and to identify the gaps between them.

Phase E: Opportunities and Solutions: To identify and evaluate the opportunities and solutions for implementing the target architecture, and to define the work packages and transition architectures.

Phase F: Migration Planning: To finalize the implementation and migration plan, and to ensure alignment with the enterprise portfolio and project management.

Phase G: Implementation Governance: To provide architecture oversight and guidance for the implementation projects, and to manage any architecture change requests.

Phase H: Architecture Change Management: To monitor the changes in the business and technology environment, and to assess the impact and performance of the architecture.

Requirements Management: To manage the architecture requirements throughout the ADM cycle, and to ensure alignment with the business requirements.

Based on the above definitions, we can match each objective with the corresponding phase as follows:

Objective 1: Ensure that the business value and cost of work packages and transition architectures is understood by key stakeholders. This objective is achieved in Phase H: Architecture Change Management, where the value realization and cost-benefit analysis of the architecture are performed2.

Objective 2: Ensure conformance with the Target Architecture by implementation projects. This objective is achieved in Phase F: Migration Planning, where the conformance requirements and criteria for the implementation projects are defined3.

Objective 3: Ensure that the architecture development cycle is maintained. This objective is achieved in Phase F: Migration Planning, where the architecture roadmap and iteration cycle are maintained3.

Objective 4: Ensure that the Architecture Governance Framework is executed. This objective is achieved in Phase G: Implementation Governance, where the architecture governance processes and procedures are applied to the implementation projects4.

1: The TOGAF Standard, Version 9.2, Chapter 5: Architecture Development Method (ADM)

2: The TOGAF Standard, Version 9.2, Chapter 21: Architecture Change Management

3: The TOGAF Standard, Version 9.2, Chapter 20: Migration Planning

4: The TOGAF Standard, Version 9.2, Chapter 19: Implementation Governance

The Architecture Landscape is a class of information within the Architecture Repository that shows an architectural view of the building blocks that are in use within the organization today (the Baseline Architecture), as well as those that are planned for the future (the Target Architecture). The Architecture Landscape typically contains a list of the applications in use within the enterprise, along with their relationships and dependencies, as well as other relevant architectural information. The Architecture Landscape helps to identify opportunities for re-use, consolidation, or retirement of existing applications, as well as gaps or overlaps in the current or future architecture.

The TOGAF Standard, Version 9.2, Part IV: Architecture Content Framework, Chapter 34: Architecture Landscape : The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 47: Architecture Repository

Ensuring compliance with internal and external standards and regulatory obligations is one of the activities included as part of Architecture Governance. Architecture Governance is the practice and orientation by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level. It involves establishing processes, roles, responsibilities, policies, and standards to ensure that architectures are aligned with the enterprise’s strategy and objectives, and meet the quality and performance requirements. Reference: The TOGAF® Standard | The Open Group Website, Section 3.3.6 Architecture Governance.

According to the TOGAF standard, the objectives of each ADM phase are as follows1:

•Phase E: Opportunities and Solutions

oDetermine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value

oIdentify and group major work packages within the Architecture Roadmap

oIdentify and group major implementation projects to realize the Architecture Roadmap

oIdentify dependencies between increments and projects

oEstimate cost, benefit, and risk at a high level for each increment and project

oConduct initial prioritization and sequencing of the Architecture Roadmap and projects

•Phase F: Migration Planning

oGenerate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D

oConfirm the Transition Architectures with relevant stakeholders

oCreate the Implementation and Migration Plan, including Transition Architectures, work packages, projects, and other activities

oConfirm and agree the Architecture Roadmap and Implementation and Migration Plan with relevant stakeholders

•Phase G: Implementation Governance

oFinalize the Architecture Roadmap and the supporting Implementation and Migration Plan

oEnsure conformance with the Target Architecture by implementation projects

oPerform appropriate Architecture Governance functions for the solution and any implementation-driven architecture Change Requests

oEnsure that the architecture lifecycle is maintained

oEnsure that the Architecture Governance Framework is executed

•Phase H: Architecture Change Management

oEnsure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders

oManage risks and issues related to the Architecture Roadmap and Implementation and Migration Plan

oMonitor the implementation projects and Transition Architectures

oManage changes to the architecture baseline

oManage changes to the Architecture Capability

Therefore, the correct matching of the objectives and the phases is:

•1G: Determine whether an incremental approach is required, and if so identify Transition Architectures that will deliver continuous business value

•2E: Generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D

•3F: Finalize the Architecture Roadmap and the supporting Implementation and Migration Plan

•4F: Ensure that the business value and cost of work packages and Transition Architectures is understood by key stakeholders

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.

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

Enterprises are examples of the scope of an architecture according to the TOGAF Standard. An enterprise is defined as any collection of organizations that has a common set of goals and/or asingle bottom line. Enterprises can be whole corporations or divisions of a corporation, government agencies or single government departments, partnerships and alliances of businesses working together, etc. Reference: The TOGAF® Standard | The Open Group Website, Section 2.1 Core Concepts.

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.

According to the TOGAF Standard, 10th Edition, architecture governance is “the practice by which enterprise architectures and other architectures are managed and controlled at an enterprise-wide level” 1. Architecture governance ensures that the architecture development and implementation are aligned with the strategic objectives, principles, standards, and requirements of the enterprise, and that they deliver the expected value and outcomes. Architecture governance also involves establishing and maintaining the architecture framework, repository, board, contracts, and compliance reviews 1. The other options are not correct, as they are not the term used by the TOGAF Standard to describe the practice by which the enterprise architecture is managed and controlled at an enterprise-wide level. Corporate governance is “the system by which an organization is directed and controlled” 2, and it covers aspects such as leadership, strategy, performance, accountability, and ethics. IT governance is “the system by which the current and future use of IT is directed and controlled” 2, and it covers aspects such as IT strategy, policies, standards, and services. Technology governance is “the system by which the technology decisions and investments are directed and controlled” 3, and it covers aspects such as technology selection, acquisition, deployment, and maintenance. References: 1: TOGAF Standard, 10th Edition, Part VI: Architecture Governance, Chapter 44: Introduction. 2: TOGAF Standard, 10th Edition, Part I: Introduction, Chapter 3: Definitions. 3: TOGAF Series Guide: Using the TOGAF Framework to Define and Govern Service-Oriented Architectures, Part II: Using the TOGAF Framework to Define and Govern Service-Oriented Architectures, Chapter 5: Technology Governance.

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.

This question asks:

What needs to be done to make sure the company succeeds with the transformation and how should risks be managed?

The scenario involves:

Large-scalebusiness transformation

Integration of acquired companies

Significant organizational change

Need to assessrisk,readiness, andobstacles

This strongly aligns with TOGAF’sBusiness Transformation Readiness AssessmentandRisk Managementguidance (primarily in the Preliminary Phase, Phase A, and Phase F).

✅Why Option D Is Correct

✔Matches TOGAF’s Business Transformation Readiness Assessment

TOGAF explicitly states that before undertaking major business change, the architecture team must assess:

Readiness factors

Obstacles

Risks

Degree of organizational preparedness

OptionDdescribes exactly this process:

“identify obstacles that could hinder the project … determine the readiness level … understand urgency, readiness, and degree of difficulty … evaluate initial risks and areas needing attention.”

That wording maps directly to theTOGAF Readiness Assessment steps, including:

Readiness Factor Evaluation

Risk Identification

Mitigation Strategy Development

✔Addresses Success Factors of Transformation

TOGAF emphasizes that large transformations succeed when:

Readiness factors are understood

Organizational obstacles are identified early

Appropriate preparation is made for people, processes, and systems

Option D describes these success actions.

❌Why the Other Options Are Incorrect

A – Implementation Factor Catalog

The catalog helps consider implementation constraints, but it isnotthe primary mechanism for evaluating overalltransformation readiness.

It is more relevant later (Phase F), not at the strategic transformation level described in the scenario.

B – Business Scenarios

Business Scenarios help define requirements and validate the architecture.

They do NOT cover readiness assessment, organizational preparedness, or comprehensive transformation risk management.

Too narrow for the scale of change described.

C – Develop Business Architecture Views + Maturity Model

While views can expose stakeholder concerns, TOGAF doesnotprescribe evaluating transformation readiness via a “maturity model” in this context.

This is partially correct butnot the TOGAF‑aligned methodfor ensuring change success.

????Relevant TOGAF Sources

TOGAF 9.2 — Business Transformation Readiness Assessment

Includes evaluation of:

Organizational readiness

Barriers and obstacles

Culture and motivation

Dependencies and risks

Readiness factors scoring

TOGAF ADM Guidance

Readiness assessment is required when conductinglarge-scale transformation.

Helps ensurerisks are identified, understood, and mitigated.

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.

The scenario clearly states that:

Theoverall objective is known,

BUT the EA team is expected todefine the scope, shared vision, and requirements,

The company uses aniterative approach,

The CEO wantsrepurpose and reuse rather than replace,

This is amajor strategic shift(new markets, new products, new crop mix).

According to the TOGAF standard, whenthe problem must be understood, andscope, vision, and requirements are not yet defined, the correct starting point isPhase A: Architecture Vision, using aniteration cycle.

This is also consistent with the “baseline-first” approach recommended in the TOGAF Series Guides for situations where:

the business direction is known but high-level,

detailed impacts must be discovered,

and the organization wants to reuse existing capabilities rather than replace them.

OptionBis the only answer that:

Begins byunderstanding the problem,

Definesthe structure of the change,

Usesiteration cyclesstarting with abaseline-first approach,

Leads intotransition planning,

Supports clarification of theshared visionandrequirements,

Fits the CIO’s instruction to “define the scope, shared vision, and requirements.”

This matches exactly what TOGAF prescribes in early-cycleArchitecture Vision and initial iterations.

The correct answer is B, as it aligns with TOGAF's stakeholder management approach, ensuring that stakeholder concerns are captured and addressed iteratively throughout the architecture development process.

Analysis of the Correct Answer (Option B):

Stakeholder Analysis and Mapping

The scenario highlights that top managers and staff are worried about the changes AI will bring.

TOGAF recommends stakeholder analysis early in the ADM process to ensure that concerns, expectations, and risks are documented.

Creating a Stakeholder Map groups stakeholders by common concerns, allowing architects to develop tailored viewpoints.

Recording Concerns in the Architecture Vision Document

The Architecture Vision (ADM Phase A) serves as a high-level guiding document.

Capturing stakeholder concerns in the Vision document ensures alignment between business goals and technology implementation.

Iterative Development and Regular Feedback

The scenario describes an AI-powered system with major business impacts, so incremental validation is necessary.

TOGAF emphasizes progressive development to manage risk and validate requirements continuously.

Regular feedback loops help mitigate resistance from top managers and staff.

Why Other Options Are Incorrect?

Option A: Creating Models for Business, Application, and Technology Architectures

Incorrect because while compliance is important, it does not address stakeholder concerns directly.

The scenario is about ensuring buy-in from top managers and employees, not just regulatory compliance.

Option C: Using Uniform Business Models Across AI Projects

Incorrect because a one-size-fits-all model does not allow for regional and functional differences within the company.

The scenario emphasizes the need to address specific concerns of top managers and different locations, which requires stakeholder-specific customization.

Option D: Creating a Communications Plan

Incorrect because communication alone does not resolve stakeholder concerns.

While communication is useful, the architecture development process should include stakeholder engagement and progressive validation, not just reporting.

Context of the Scenario

The organization is currently in the Migration Planning phase, which corresponds to Phase F of the TOGAF ADM (Architecture Development Method). The key activities for this phase involve:

Evaluating dependencies and impacts on other organizational frameworks.

Aligning the roadmap and migration plan with strategic objectives and available resources.

Addressing the risks of transitioning from the current architecture to the target architecture using a phased approach.

The deliverables (Architecture Roadmap, Capability Assessment, etc.) and assessments (Gap Analysis, Risk Assessment, Transformation Readiness) have already been developed. The next step is to refine and finalize the migration planning.

Option Analysis

Option A:

While updating the Architecture Definition Document could ensure alignment, this step was completed in earlier phases (B, C, D). At this stage, further changes to the architecture must go through a formal governance review, and applying lessons learned without review contradicts TOGAF principles.

Producing an Implementation Governance Model is more relevant in Phase G (Implementation Governance), not in Phase F.

Conclusion: Incorrect, as it suggests revisiting earlier steps and does not align with the current phase.

Option B:

Conducting Compliance Assessments ensures the architecture is implemented correctly, but this is a task for Phase G (Implementation Governance) after migration planning has been finalized and implementation begins.

Deployment of monitoring tools is also part of implementation and governance activities, not migration planning.

Conclusion: Incorrect, as it focuses on tasks belonging to a later phase.

Option C:

Examining how the Implementation and Migration Plan affects other organizational frameworks is critical in Phase F, as TOGAF emphasizes alignment with business planning, project/portfolio management, and operations management.

Assigning business value to each project ensures prioritization and optimal allocation of resources.

Updating the Architecture Roadmap and the Implementation and Migration Plan based on this analysis ensures strategic alignment and readiness for implementation.

Conclusion: Correct, as it addresses the key objectives of the Migration Planning phase comprehensively.

Option D:

Applying the Business Value Assessment Technique is valid for prioritizing initiatives but is a limited aspect of Migration Planning.

Planning Transition Architecture phases and documenting lessons learned are valid, but this does not address broader organizational impacts or dependencies as effectively as Option C.

Conclusion: Narrow focus; less comprehensive than Option C.

References to TOGAF

Phase F (Migration Planning): The focus is on aligning the migration plan with business objectives, considering organizational dependencies, and prioritizing projects (TOGAF 9.2, Chapter 12).

Architecture Roadmap and Implementation Plan: Updated to reflect changes in priorities and alignment with business frameworks (TOGAF 9.2, Section 12.4).

Framework Integration: Collaboration with other frameworks (e.g., business planning, portfolio management) ensures alignment across the organization (TOGAF 9.2, Section 6.5.2).

Business Value Assessment Technique: Used to prioritize initiatives based on return on investment and performance criteria (TOGAF 9.2, Section 24.4).

The question focuses onaddressing stakeholder concerns and mitigating riskswhen introducingAI-based systemsin a law firm, while also reflecting the CIO’s preference forarchitecting with agility.

OptionCis the best fit according to TOGAF.

✅Why Option C Is Correct

1. TOGAF Emphasizes Stakeholder Identification and Stakeholder Mapping (Phase A)

TOGAF requires:

Identifyingstakeholders

Analyzing theirconcerns, interests, and influence

Grouping stakeholders intocategories

Producing aStakeholder Mapand defining neededviews

Option C precisely describes this process.

2. Document Concerns in the Architecture Vision

The TOGAF Architecture Vision must include:

Stakeholder concerns

Relevant viewpoints

Business goals and drivers

High-level requirements

C describes documenting concerns and viewsin the Architecture Vision, which aligns perfectly with TOGAF Phase A.

3. Supports Agility / Progressive Development

The CIO promotesarchitecting with agility.

Option C includes:

“a requirement that there beprogressive developmentof the target architecture to get regular feedback.”

This is consistent with:

TOGAF’s support foriterative,incremental, andrisk-reducingdevelopment cycles

Agile architecture principles

Thus, C aligns both with TOGAFandthe CIO’s preference for agile adoption.

❌Why the Other Options Are Incorrect

A:

Communication planning is valid, but the answer istoo focused on reportingandlocation-specific summaries, which are not part of TOGAF Phase A.

Does not address the CIO’s need foragility.

Risk mitigation is described vaguely and incorrectly tied to later phases.

B:

Focuses on "business models" and "security architecture" — not the right emphasis for early stakeholder engagement.

Does not address fear of job performance monitoring or behavior change, which requires stakeholder-sensitive treatment.

D:

Proposes creatinghigh-level Business, Application, and Technology models in Phase A, which is inappropriate — such models belong inPhases B, C, D, not Vision.

Focuses on regulatory compliance rather than stakeholder concerns.

????TOGAF References

TOGAF 9.2 – Phase A: Architecture Vision

Defines stakeholder identification, concerns, and stakeholder map.

Encourages iterative, agile approaches.

Requires capturing concerns in the Architecture Vision.

TOGAF ADM Guidance for Agile

Supports incremental, feedback-driven development to reduce risk.

Key aspects of the scenario:

Objective:

Integrating Artificial Intelligence (AI) into healthcare delivery, with a focus on improving patient care, enhancing workplace efficiency, and enabling seamless experiences.

Challenges:

Stakeholder concerns about risk management, adaptability to change, and ensuring alignment with regulations and policies.

Addressing the concerns of staff and top management about AI integration and achieving the desired goals.

CIO's Perspective:

Encouraging an agile approach to architecture development.

Addressing risks and ensuring stakeholder concerns are managed.

Areas for Evaluation:

AI usage by staff and impact on workflows.

Patient experience enhancement via AI.

New workplace platforms and tools powered by AI.

Option Analysis:

Option 1: Analysis of stakeholders and development of a Stakeholder Map

Pros:

Stakeholder analysis is critical for identifying concerns, viewpoints, and requirements.

TOGAF emphasizes stakeholder engagement early in the process to mitigate risks and align expectations.

Developing a Stakeholder Map ensures clear alignment with their interests and creates a foundation for regular feedback loops.

Cons:

Does not explicitly address the creation of architecture models or policies upfront.

Option 2: Creation of a Communications Plan

Pros:

A communications plan fosters effective stakeholder engagement by addressing their concerns and ensuring transparent reporting.

Risk mitigation as part of communication aligns with TOGAF’s stakeholder management practices.

Cons:

This focuses more on communication mechanics rather than advancing architectural development directly.

Option 3: Models for Draft Business, Data, Application, and Technology Architectures

Pros:

Aligns with the Architecture Development Method (ADM), ensuring compliance with requirements and regulations.

Helps formalize stakeholder feedback by verifying their concerns against tangible models.

Cons:

Developing detailed models early on may delay immediate resolution of stakeholder concerns and risk mitigation.

Option 4: Set of reusable business models for AI-related projects

Pros:

Standardized models ensure consistency and portability across the organization’s AI-related efforts.

Cons:

Too narrow in focus for the initial architecture development phase; does not address risk management or stakeholder concerns adequately.

Recommended Answer:

Option 1: You recommend that an analysis of the stakeholders is undertaken.

Reasoning:

The scenario highlights stakeholder concerns about risks, adaptability, and compliance. Addressing these concerns requires stakeholder analysis as the first step.

A Stakeholder Map aligns with TOGAF’s emphasis on stakeholder engagement, providing a structured way to manage their concerns and expectations.

Identifying concerns early and integrating feedback into the Architecture Vision document ensures alignment with goals and smooth progress.

Option 1 sets the foundation for collaboration and risk management, making it the best fit for the current phase.

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 References

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 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

A Request for Architecture Work is a document that describes the scope, approach, and expected outcomes of an architecture project. A Request for Architecture Work is usually initiated by the sponsor or client of the architecture work, and approved by the Architecture Board, which is a governance body that oversees the architecture work and ensures compliance with the architecture principles, standards, and goals. A Request for Architecture Work triggers a new cycle of the Architecture Development Method (ADM), which is the core process of the TOGAF standard that guides the development and management of the enterprise architecture12

An Architecture Vision is a high-level description of the desired outcomes and benefits of the proposed architecture. An Architecture Vision is the output of Phase A: Architecture Vision of the ADM cycle, which is the first phase of the architecture development. An Architecture Vision defines the scope and approach of the architecture work, and establishes the business goals and drivers that motivate the architecture work. An Architecture Vision also involves obtaining the approval and commitment of the sponsors and other key stakeholders, and initiating the Architecture Governance process3

A trade-off analysis is a technique that can be used to evaluate and compare different architecture alternatives and select the most suitable one. A trade-off analysis involves identifying the criteria and factors that are relevant to the decision, such as costs, benefits, risks, and opportunities, and assessing the strengths and weaknesses of each alternative. A trade-off analysis also involves balancing and reconciling the multiple, often conflicting, requirements and concerns of the stakeholders, and ensuring alignment with the Architecture Vision and the Architecture Principles.

Therefore, the best answer is D, because it proposes the best approach for architecture development to realize the CEO’s change in direction for the company. The answer covers the Request for Architecture Work, the Architecture Vision, and the trade-off analysis techniques that are relevant to the scenario.

 1: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 7: Request for Architecture Work 2: The TOGAF Standard, Version 9.2, Part VI: Architecture Capability Framework, Chapter 50: Architecture Governance 3: 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 30: Trade-Off Analysis

In this scenario, the enterprise is undergoing significant transformation due to a merger and the adoption of new technology (hand-held devices). Several key principles from TOGAF's ADM Techniques—particularly those focused on promoting enterprise-wide standardization, adaptability, and data utilization—are pertinent here:

Maximize Benefit to the Enterprise:This principle emphasizes that all architectural decisions should deliver maximum business value. Given that the company is integrating systems to cut costs and improve offerings, maximizing the benefit is crucial. Ensuring that the EA efforts align with enterprise-wide benefits supports the goal of optimizing costs and enhancing offerings, which aligns with the CEO’s vision for the merger.

Common Use Applications:Standardizing applications across the merged entity will be essential to achieve cost savings and to simplify operations. The goal of reducing the number of applications fits with this principle, ensuring that reusable and widely adopted applications support business functions across the organization. Adopting this principle will also aid in harmonizing the systems from both organizations and avoiding unnecessary diversity.

Data is an Asset:Data plays a central role in the company's operations, especially with the use of AI-driven inventory management and the integration of systems. Treating data as an asset is essential for reliable and accurate decision-making. This principle ensures that data is viewed as a critical enterprise resource and is managed with care, maintaining integrity, accuracy, and value.

Responsive Change Management:The organization’s ability to adapt quickly and effectively to changes, such as integrating new handheld devices and merging systems, is essential. This principle will facilitate the smooth transition required for integrating the new handheld devices and the merger-related system updates while minimizing disruption to store operations.

Technology Independence:Since the enterprise will likely encounter varied technologies from the merger, it is crucial to maintain flexibility. This principle advocates for using technology solutions that are adaptable and not bound to a single vendor or specific technology. This ensures that the enterprise can integrate various technological components from both organizations and evolve with minimal constraints.

These principles align well with TOGAF's broader recommendations for guiding architectural changes, as found in Section 2.6 of the TOGAF ADM Techniques. They ensure that the EA practice is aligned with business objectives while maintaining flexibility, data integrity, and a focus on enterprise-wide benefits. These guiding principles are critical for the successful execution of the integration and adoption of new technologies while achieving cost efficiencies and improving service delivery.

For reference, TOGAF's ADM Techniques highlight the importance of architectural principles in guiding transformational initiatives, ensuring that decisions are made consistently across the enterprise. Each principle supports organizational agility, system integration, and the efficient use of technology resources, all of which are vital for the enterprise's stated objectives.

According to the TOGAF Standard, Version 9.2, an Architecture Contract is a joint agreement between development partners and sponsors on the deliverables, quality, and fitness-for-purpose of an architecture1. It defines the scope, responsibilities, and governance of the architecturework, and ensures the alignment and compliance of the architecture with the business goals and objectives1.

In the scenario, the Lead Enterprise Architect has asked you to review the draft Architecture Contracts and recommend the best approach to address the Chief Engineer’s concern about the consistency and quality of the deployment of the new processes for the battery pack production at each location.

The best answer is C, because it follows the guidelines and best practices for defining and using Architecture Contracts as described in the TOGAF Standard, Version 9.22. It ensures that the contracts cover the essential aspects of the project objectives, effectiveness metrics, acceptance criteria, and risk management, and that they are legally enforceable for third-party contractors. It also recommends a schedule of compliance reviews at key points in the implementation process, and a mechanism for handling any deviations from the Architecture Contract, involving the Architecture Board and the possibility of granting a dispensation to allow the process to be customized for local needs.

The other options are not correct because they either23:

A. For changes requested by an internal team, you recommend a memorandum of understanding between the Architecture Board and the implementation organization. For contracts issued to third-party contractors, you recommend that it is a fully enforceable legal contract. You recommend that the Architecture Board reviews all deviations from the Architecture Contract and considers whether to grant a dispensation to allow the implementation organization to customize the process to meet their local needs.: This option does not address the need to review the contracts to ensure that they address the project objectives, effectiveness metrics, acceptance criteria, and risk management. It also does not recommend a schedule of compliance reviews at key points in the implementation process. Moreover, it suggests that a memorandum of understanding is sufficient for internal teams, which may not be legally binding or enforceable.

B. For changes undertaken by internal teams, you recommend a memorandum of understanding between the Architecture Board and the implementation organization. If a contract is issued to a contractor, you recommend that it is a fully enforceable legal contract. If a deviation from the Architecture Contract is found, you recommend that the Architecture Board grant a dispensation to allow the implementation organization to customize the process to meet their local needs.: This option has the same problems as option A, and also implies that the Architecture Board should always grant a dispensation for any deviation, which may not be appropriate or desirable in some cases.

D. You recommend that the Architecture Contracts be used to manage the architecture governance processes across the locations. You recommend deployment of monitoring tools to assess the performance of each completed battery pack at each location and develop change requirements if necessary. If a deviation from the contract is detected, the Architecture Board should allow the Architecture Contract to be modified meet the local needs. In such cases they should issue a new Request for Architecture Work.: This option does not address the need to review the contracts to ensure that they address the project objectives, effectiveness metrics,acceptance criteria, and risk management. It also does not recommend a schedule of compliance reviews at key points in the implementation process. Moreover, it suggests that the Architecture Board should always allow the Architecture Contract to be modified for any deviation, which may not be appropriate or desirable in some cases. It also implies that a new Request for Architecture Work should be issued for each deviation, which may not be necessary or feasible.

1: The TOGAF Standard, Version 9.2, Chapter 3: Definitions and Terminology, Section 3.1: Terms and Definitions

2: The TOGAF Standard, Version 9.2, Chapter 43: Architecture Contracts

3: The TOGAF Standard, Version 9.2, Chapter 44: Architecture Governance

Based on the TOGAF standard, this answer is the best approach for architecture development to realize the CEO’s change in direction for the company. The reason is as follows:

The scenario describes a major business transformation that requires a clear understanding of the current and future states of the enterprise, as well as the gaps and opportunities for change. Therefore, the priority is to understand and bring structure to the definition of the change, rather than focusing on the implementation details or the technology aspects.

The team should use the TOGAF ADM as the method and guiding framework for architecture development, and adapt it to suit the specific needs and context of the enterprise. The team should also leverage the existing Architecture Capability and the Architecture Repository to reuse and integrate relevant architecture assets and resources.

The team should focus iteration cycles on a baseline first approach to architecture development, which means starting with the definition of the Baseline Architecture in each domain (Business, Data, Application, and Technology), and then defining the Target Architecture in each domain. This will help to identify the current and desired states of the enterprise, and to perform a gap analysis to determine what needs to change in order to achieve the business goals and objectives.

The team should then focus on transition planning, which involves identifying and prioritizing the work packages, projects, and activities that will deliver the change. The team should also create an Architecture Roadmap and an Implementation and Migration Plan that will guide the execution and governance of the change.

The team should use the Architecture Vision phase and the Requirements Management phase to work out in detail what the shared vision is for the change, and to capture and validate the stakeholder requirements and expectations. The team should also use the Architecture Governance framework to ensure the quality, consistency, and compliance of the architecture work.

 The TOGAF Standard, Version 9.2 - Architecture Development Method : The TOGAF Standard, Version 9.2 - Architecture Vision : The TOGAF Standard, Version 9.2 - Requirements Management : [The TOGAF Standard, Version 9.2 - Architecture Governance]

Comprehensive and Detailed Step-by-Step Explanation

Context of the Scenario

The scenario highlights significant risks due to ransomware attacks and the need to strengthen the company’s Enterprise Architecture to improve data protection and resilience. TOGAF emphasizes the Architecture Compliance Review as a mechanism for ensuring the architecturemeets its objectives and addresses specific concerns such as security, resilience, and compliance with organizational goals.

The organization has already conducted a risk assessment but requires actionable steps to:

Address ransomware attack risks.

Increase the resilience of the Technology Architecture.

Ensure proper alignment with governance and compliance frameworks.

Option Analysis

Option A:

Strengths:

Highlights the need for up-to-date processes for managing changes in the Enterprise Architecture.

Recognizes the importance of governance through the Architecture Board and change management techniques.

Weaknesses:

The approach focuses solely on the Technology Architecture baseline but does not address the need for specific steps such as compliance review, gap analysis, or tailored resilience measures for ransomware risks.

It provides a broad and generic approach rather than a targeted plan for ransomware and data protection issues.

Conclusion: Incorrect. While it adheres to governance processes, it lacks specific actions to improve resilience and address the immediate security concerns.

Option B:

Strengths:

Proposes an Architecture Compliance Review, which is a core TOGAF process used to evaluate architecture implementation against defined objectives, ensuring it is fit for purpose.

Involves identifying stakeholders (departments) and tailoring checklists specific to ransomware resilience.

Emphasizes issue identification and resolution through structured review processes.

Weaknesses:

Does not explicitly address longer-term updates to the Enterprise Architecture, but this can be inferred as a next step following compliance recommendations.

Conclusion: Correct. This is the most suitable approach based on TOGAF principles, as it uses an established process to evaluate and improve the architecture's resilience.

Option C:

Strengths:

Includes monitoring for updates from suppliers to enhance detection and recovery capabilities, which is relevant to addressing ransomware risks.

Proposes a gap analysis to identify shortcomings in the current Enterprise Architecture and recommends addressing gaps through change requests.

Incorporates disaster recovery planning exercises, which are useful for testing resilience.

Weaknesses:

While thorough, the approach lacks the Architecture Compliance Review process, which is a more structured way to ensure the architecture meets resilience requirements.

Monitoring suppliers and running disaster recovery exercises are operational steps rather than strategic architectural improvements.

Conclusion: Incorrect. While it includes valid activities, it does not adhere to TOGAF’s structured approach for architecture assessment and compliance.

Option D:

Strengths:

Proposes analyzing business continuity requirements and assessing the architecture for gaps, which is relevant to the scenario.

Suggests initiating an ADM cycle to address gaps, which aligns with TOGAF principles.

Weaknesses:

Focusing on initiating a new ADM cycle may be premature, as the immediate priority is to evaluate the existing architecture and address specific resilience concerns.

Does not mention compliance review or tailored resilience measures for ransomware attacks, which are central to the scenario.

Conclusion: Incorrect. It proposes a broader approach that may not adequately address the immediate concerns highlighted by the CSO.

TOGAF References

Architecture Compliance Review: A structured process used to evaluate whether an architecture meets the stated goals, objectives, and requirements (TOGAF 9.2, Chapter 19). It is particularly useful for identifying and addressing resilience requirements in scenarios involving security risks.

Stakeholder Engagement: Identifying and involving stakeholders (e.g., departments) is a critical part of architecture governance and compliance review (TOGAF 9.2, Section 24.2).

Change Management: The Architecture Compliance Review supports identifying necessary changes, which are then managed through governance and change management processes (TOGAF 9.2, Section 21.6).

By choosing Option B, you align with TOGAF’s structured approach to compliance, resilience, and addressing security concerns.

A Stakeholder Map is a technique that can be used to identify and classify the stakeholders of the architecture work, and to document their key interests, requirements, and concerns. A stakeholder is any person, group, or organization that has a stake in the outcome of the architecture work, such as the sponsor, the client, the users, the suppliers, the regulators, or the competitors. A Stakeholder Map can help to understand the needs and expectations of the stakeholders, and to communicate and engage with them effectively1

The steps for creating a Stakeholder Map are:

Identify the stakeholders of the architecture work, using various sources and methods, such as interviews, surveys, workshops, or existing documents.

Classify the stakeholders according to their roles, responsibilities, and relationships, using various criteria and dimensions, such as power, influence, interest, attitude, or impact.

Define the concerns and relevant views for each stakeholder group, using various techniques, such as business scenarios, use cases, or value propositions. A concern is a key interest or issue that is relevant to the stakeholder, such as a goal, a problem, a need, or a risk. A view is a representation of the system of interest from the perspective of one or more stakeholders and their concerns.

Record the stakeholders and their concerns in a Stakeholder Map, which shows the mapping between the stakeholder groups, the concerns, and the views. The Stakeholder Map also shows the dependencies, assumptions, and issues related to each stakeholder and concern.

Therefore, the best answer is B, because it recommends the approach that would enable the development of an architecture that addresses the concerns of the CIO and the partners, using the Stakeholder Map technique. The answer covers the following aspects:

An analysis of the stakeholders is undertaken, which involves identifying, classifying, and defining the stakeholders and their concerns.

The stakeholders and their concerns are documented in a Stakeholder Map, which provides a clear and comprehensive picture of the stakeholder landscape and their interests.

The concerns and relevant views are recorded in the Architecture Vision document, which is the output of Phase A: Architecture Vision of 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 Architecture Vision defines the scope and approach of the architecture work, and establishes the business goals and drivers that motivate the architecture work. The Architecture Vision also involves obtaining the approval and commitment of the sponsors and other key stakeholders, and initiating the Architecture Governance process2

The requirements include risk mitigation through regular assessments, which involves identifying, analyzing, and evaluating the risks that may affect the architecture, and determining the appropriate measures or actions to prevent, reduce, or mitigate the risks. Risk mitigation can also involve monitoring and reviewing the risk situation, and communicating and reporting the risk status and actions3

This approach also allows a supervised agile implementation of the continuous Machine Learning, which involves applying agile principles and practices to the architecture development and implementation, such as iterative and incremental delivery, frequent feedback, collaboration, and adaptation. A supervised agile implementation can help to ensure the quality, value, and alignment of the architecture, and to respond to the changing needs and expectations of the stakeholders.

 1: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 24: Stakeholder Management 2: The TOGAF Standard, Version 9.2, Part II: Architecture Development Method (ADM), Chapter 18: Phase A: Architecture Vision 3: The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 32: Risk Management : The TOGAF Standard, Version 9.2, Part III: ADM Guidelines and Techniques, Chapter 29: Applying Iteration to the ADM

OptionAbest aligns withTOGAF Phase A: Architecture Vision, which is thestarting phasefor an architecture development cycle in TOGAF. This phase sets the foundation for the architecture engagement and ensuresalignment with stakeholders and their concerns, especially when evaluating a major transformation like moving to acloud-based planning and scheduling system.

????Key TOGAF Concepts Supporting Option A:

1. Phase A: Architecture Vision Objectives

Establish thehigh-level scope, constraints, and expectations.

Identify stakeholdersand define theirconcerns and business requirements.

Create theArchitecture Vision, which includes:

Summary-levelBaseline and Target Architectureviews (business, data, application, and technology).

Initialrequirementsandkey concerns.

Stakeholder buy-inand approval for moving forward.

2. Engagement with Stakeholders

In this case, theplant managers and local supply chain partnershave concerns regarding safety and dependability.

TOGAF emphasizes early engagement withbusiness stakeholdersto ensure concerns are identified and incorporated into the vision.

3. Creating Architecture Vision Document

A deliverable of Phase A.

Includeshigh-level descriptionsof the baseline and target architectures, initialbusiness goals, andstakeholder viewpoints.

Used tobuild agreement and obtain formal approvalto proceed with detailed architecture work in later phases (B–D).

❌Why Other Options Are Incorrect:

B: Focuses onsuppliersand not theactual stakeholdersimpacted by the architecture — i.e.,plant managers and internal operations. This diverts from TOGAF’s stakeholder-driven approach in Phase A.

C: This reflectsPhases B–Dof the ADM (Business, Information Systems, and Technology Architecture). It istoo detailed and prematurefor the start of the project. In Phase A, you don’t yet develop full baseline and target architectures or conduct a consolidated gap analysis.

D: While interviewing stakeholders is valid in Phase A, this option lacks aholistic view of the Architecture Vision development, and skips the TOGAF requirement to producesummary views of the baseline and target architecturesand to use them to drive stakeholder buy-in. It istactically correct, butstrategically incomplete.

????TOGAF Source References:

TOGAF 9.2 – Section 6.2 (Phase A: Architecture Vision)

"The Architecture Vision describes how the proposed architecture support the business goals, and the strategic direction. It also provides a high-level description of the baseline and target architectures and identifies key stakeholders and concerns."

TOGAF 9.2 – Part IV, Architecture Content Framework

"The Architecture Vision includes the scope, constraints, and expectations. It forms the basis for approval to proceed with further architecture development."

In this scenario you are right at thestart of an ADM cycle: aRequest for Architecture Workhas been approved to investigate AI, and there are strongstakeholder concerns and risk questions. According to the TOGAF standard, the correct place to start isPhase A: Architecture Vision, with a strong focus onstakeholder managementand capturing theirconcerns and required views.

OptionAis 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 aStakeholder Mapto understand their influence, interest, and required engagement

Determine whichviews/viewpointsare needed to address their concerns in the architecture descriptioncoe.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 theArchitecture VisiondeliverableVisual Paradigm TOGAF+1

Concerns, views, and Architecture VisionTOGAF emphasizes thatarchitecture viewsare constructed to addressspecific stakeholder concerns; you do not just build generic models.opengroup.org+1

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

Capturing this in theArchitecture Visionprovides 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 encouragedarchitecting 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 thechange in the way of workingand whetherrisk management and responsible AI policiesare adequate: these become explicit stakeholder concerns and requirements that are iteratively refined.

Why the other options are weaker / not TOGAF-aligned as astartingpoint

Option B

Focuses mainly on aCommunications Planand powerful stakeholders.

While TOGAF does expect a stakeholder communications plan, it isderived froma 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 addressedearlythrough stakeholder concerns, principles, and iteration.

Option C

Jumps straight to asolution concept diagramandbenefits diagramand defers risk evaluation to when theArchitecture Roadmapis 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 draftBusiness, Data, Application, and Technologymodels and putting them into theArchitecture Vision.

This is too detailed for the starting point: Phase A is abouthigh-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 Ais the best and TOGAF-consistent way tobegin:

Start inPhase A: Architecture Vision

Performstakeholder analysisand create aStakeholder Map

Define stakeholderconcernsandrelevant views

Record them in theArchitecture Vision

Add an explicit requirement forprogressive (iterative) developmentof the target architecture for continuous feedback and risk mitigation

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 preferences, 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. References:

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 correct answer is C, as it aligns with the key TOGAF principles necessary for guiding enterprise architecture in a merger scenario where retail operations and systems are being consolidated.

Analysis of the Principles in Option C:

Common Use Applications

Since the two companies are merging, it is essential to standardize applications across the enterprise.

Using common applications ensures consistency, reduces costs, and improves efficiency.

TOGAF emphasizes this principle to prevent duplicate or redundant systems, which aligns with the CIO’s goal of reducing the number of applications used.

Data is an Asset

In the scenario, a central inventory management system is a core business function.

Treating data as an asset ensures it is managed properly, shared efficiently, and used strategically across the merged organization.

This principle supports the company’s ability to predict demand, adjust stock levels, and automate reordering.

Common Vocabulary and Data Definitions

The merger requires integrating different systems and data structures.

Having a common vocabulary ensures that all stakeholders (stores, fulfillment centers, and digital platforms) use consistent terminology and data definitions.

This minimizes confusion and ensures interoperability across business functions.

Maximize Benefit to the Enterprise

Every architectural decision should focus on the overall benefit to the business.

By consolidating IT systems and reducing redundancies, the company achieves cost savings, which directly supports this principle.

Business Continuity

The stores operate seven days a week, so system changes must ensure uninterrupted service.

Business continuity ensures that customers are not affected during the transition and that critical retail operations (sales, inventory tracking, and fulfillment) remain functional.

Why Other Options Are Incorrect?

Option A: Control Technical Diversity, Interoperability, Data is an Asset, Data is Shared, Business Continuity

Control Technical Diversity is not the primary concern here. The focus is on system consolidation, not necessarily on limiting technology diversity.

Interoperability is important but not as critical as defining a common system and data structure.

Option B: Service Orientation, Compliance with the Law, Requirements-Based Change, Responsive Change Management, Data Security

While service orientation and compliance are valuable, they are not the most relevant to this specific business transition.

Change management and data security are important but do not address the primary enterprise-wide architectural concerns of system consolidation.

Option D: Ease of Use, Common Use Applications, Data is an Asset, Technology Independence, Business Continuity

Ease of Use is beneficial but is not a core architecture principle in this case.

Technology Independence is useful but does not align directly with the scenario’s priority, which is consolidating applications and data structures.