This option describes the core TOGAF 9 methodology for addressing stakeholder needs. The process begins with stakeholder identification and analysis, often captured in a stakeholder map (as recommended in ADM Phase A). By grouping stakeholders with shared concerns (e.g., legal, research, board), the architect can then select or define appropriate viewpoints. Each viewpoint prescribes the models, conventions, and language to be used in a view that addresses that specific set of concerns. This structured approach ensures that the resulting architecture is relevant to all parties and that their specific requirements, such as regulatory compliance or research suitability, are explicitly addressed and can be easily verified.

A. Depending on the nature of the architecture, a set of models should be created that can be used to ensure that the system will be compliant with the local regulations. Stakeholders should be able to view the models to see that their concerns have been properly addressed.

This is too generic. It fails to describe the systematic TOGAF process of linking specific stakeholders and their concerns to the selection of views and models, which is the core of the correct approach.

B. Each architecture activity should be developed using a consistent modeling approach that is uniform across all architecture projects. Each architecture should be defined based on this fixed set of models so that all concerned parties can examine the models to ensure that their issues and concerns have been addressed,

This is incorrect. TOGAF advocates for tailoring views and viewpoints to the specific needs of the stakeholders for a given engagement, not using a rigid, one-size-fits-all set of models for all projects.

D. For those groups that have sufficient power and level of interest, a special report should be created that summarizes the key features of the architecture with respect to the particular location. Each of these reports should reflect the stakeholders' requirements.

This focuses on a communication artifact (a report) for a subset of stakeholders, not the fundamental process for developing an architecture that addresses the concerns of all relevant parties as requested.

1. The Open Group Standard

TOGAF® Version 9.2

Section 35.4

Views

Viewpoints

and Stakeholders: "The choice of which specific views to create is a key decision for the architect... The architect must choose a set of views that will enable the architecture to be communicated to

and understood by

all the stakeholders

and that will enable them to verify that the system will address their concerns." This supports the linkage in option C.

2. The Open Group Standard

TOGAF® Version 9.2

Section 22.4

Steps in the Stakeholder Management Process: This section outlines the process of identifying

classifying

and determining the concerns of stakeholders

which is the foundation of the approach described in option C. The creation of a stakeholder map is a key artifact of this process.

3. The Open Group Standard

TOGAF® Version 9.2

Section 7.5

Phase A: Architecture Vision

Step 3: "Identify the key stakeholders and their concerns/objectives

and define the key business requirements to be addressed in the architecture engagement. This will be used to create a stakeholder map." This directly validates the initial step mentioned in option C.

4. The Open Group Standard

TOGAF® Version 9.2

Section 3.13

Concerns: "Concerns are the key interests that are crucially important to the stakeholders in a system... The architect will identify and classify the concerns of the stakeholders and create views of the architecture that address those concerns." This reinforces the entire chain of logic presented in option C.

According to the TOGAF 9 framework, the Architecture Design and Development Contract is a crucial artifact for governing the implementation of an architecture. It establishes a joint agreement between the development partners and the architecture function. Option A provides the most complete and accurate list of contents for this contract as specified in the TOGAF 9 standard. This includes foundational elements like scope and requirements, conformance criteria, and specific project management details such as deliverables, workplans, and metrics, ensuring the implementation project adheres to the defined Target Architecture.

B: This option incorrectly includes "Baseline Architecture definition". The Architecture Contract focuses on the implementation of the Target Architecture, not documenting the baseline.

C: This is an incomplete list. It omits critical foundational sections of the contract, such as the introduction, scope, and conformance requirements, which are essential for the agreement.

D: This option incorrectly lists various outputs from different ADM phases (e.g., Gap Analysis, Baseline Architecture) rather than the specific contents of an Architecture Contract.

1. The Open Group. (2018). TOGAF® Version 9.2. Van Haren Publishing.

Part VII

Chapter 50

Section 50.2

"Architecture Contracts": This section explicitly lists the typical contents of an Architecture Contract

which directly aligns with the components listed in option A. It includes "Introduction and background"

"Scope"

"Strategic requirements"

"Conformance requirements"

"Target architecture measures"

"Defined phases of deliverables"

"Prioritized joint workplan"

"Time window(s)"

and "Architecture delivery and business metrics".

Part IV

Chapter 36

Section 36.2.4

"Architecture Contract": This section describes the Architecture Contract as an artifact

confirming its purpose is to be "the joint agreement between development partners and sponsors on the deliverables

quality

and fitness-for-purpose of an architecture".

This answer provides the most comprehensive and accurate description of the activities conducted during the Architecture Vision (Phase A) of the TOGAF ADM. Phase A is focused on establishing the scope, constraints, and expectations for the architecture project. This includes identifying stakeholders and their concerns (captured in a Stakeholder Map), defining high-level business requirements, evaluating current business capabilities, assessing the organization's readiness for transformation, and developing a high-level vision of the Baseline and Target Architectures. The Business Scenarios technique is a key tool used in this phase to articulate the vision and ensure it addresses the primary business problem.

B: This option is incomplete. While applying the Business Scenarios technique is a core part of Phase A, this answer omits other critical foundational activities like stakeholder identification, capability evaluation, and readiness assessment.

C: This option is too simplistic and incorrect. Phase A involves creating a vision for both the Baseline and Target Architectures to understand the gap, not just the Target. It also omits all other required steps.

D: This option is incorrect because Phase A produces a high-level vision, not a detailed view of the architectures. Detailed architecture work occurs in Phases B, C, and D, and the primary deliverable is the Architecture Definition Document (ADD), not the Architecture Vision.

1. The Open Group Standard

TOGAF® Version 9.2

Chapter 6

Phase A: Architecture Vision. This chapter outlines the objectives and steps of Phase A. Section 6.3

"Steps

" explicitly lists: "Identify stakeholders

their concerns

and business requirements" (Step 2)

"Evaluate capabilities" (Step 4)

"Assess readiness for business transformation" (Step 5)

and "Develop Architecture Vision" (Step 8)

which includes creating high-level views of the Baseline and Target Architectures.

2. The Open Group Standard

TOGAF® Version 9.2

Chapter 24

Business Scenarios. This chapter describes the Business Scenarios technique and notes its importance in Phase A for helping to "identify and understand business requirements" and "articulate an Architecture Vision that responds to those requirements".

3. The Open Group Standard

TOGAF® Version 9.2

Part IV

36.2.21

Stakeholder Map. This section defines the Stakeholder Map as a key artifact created during Phase A to document stakeholder positions and concerns.

4. The Open Group Standard

TOGAF® Version 9.2

Part IV

36.2.4

Architecture Definition Document. This section clarifies that the ADD contains the detailed descriptions of the architecture and is typically created across Phases B

C

and D

confirming that it is not the primary output of the high-level Architecture Vision phase.

The scenario describes a transformational project focused on creating a new "Just-in-time" supply chain system, with the CIO explicitly stating no concern for preserving existing systems. This indicates the primary focus should be on the Target Architecture, not the Baseline. Option C correctly proposes artifacts for the Target state.

Furthermore, the selected artifacts directly address the three stakeholder concerns:

1. People involved: The Business Interaction matrix shows relationships between organizational units and business functions.

2. Application integration: The Application Communication diagrams and Application Interaction matrix detail how applications connect and exchange data.

3. Data sharing: The Data Entity/Business Function matrix and Application/Data matrix map data to business functions and applications, clarifying data usage and sharing requirements.

A: This option is incorrect because it focuses on describing the Baseline Architecture, which is being replaced and is not a priority according to the project sponsor (the CIO).

B: This option incorrectly assigns a Data Architecture artifact (Data Entity/Data Component catalog) to the description of the Target Application Architecture, demonstrating a misunderstanding of the TOGAF Content Metamodel.

D: This option is incorrect because it focuses on the Baseline Architecture and wrongly includes an Environments and Locations diagram, which is a Technology Architecture artifact, in the Application Architecture description.

1. The TOGAF® Standard

Version 9.2

Section 31.6.2

Architectural Artifacts: This section details the purpose of each artifact mentioned in option C.

Business Interaction Matrix (31.6.2.10): "depicts the relationships between organization units

business functions

and business services"

addressing stakeholder concern #1.

Application Communication Diagram (31.6.2.3): "depicts the communication relationships between applications"

addressing stakeholder concern #2.

Application Interaction Matrix (31.6.2.6): "shows the communication and interoperability between applications"

also addressing stakeholder concern #2.

Data Entity/Business Function Matrix (31.6.2.16): "shows the relationship between data entities and business functions"

addressing stakeholder concern #3.

Application/Data Matrix (31.6.2.5): "shows the relationship between applications and the data entities that are accessed and updated by them"

also addressing stakeholder concern #3.

2. The TOGAF® Standard

Version 9.2

Section 5.2.2

Architecture Development Cycle: The scenario's focus on a new target state ("Just-in-time" supply chain) with little regard for the current state aligns the work with defining a Target Architecture (Phases B

C

D) rather than extensively documenting a Baseline Architecture that will be discarded.

This set of viewpoints directly addresses all stakeholder concerns outlined in the scenario. The Goal/Objective/Service Diagram helps analyze the roles and value of revenue-earning services. The System/Functions Catalog and System/Technology Matrix are used to diagnose the slow HR application by identifying the system, its functions, and the underlying technology causing performance issues. The Product Lifecycle Diagram is the most appropriate tool for tracking revenue from products and the progress of new launches over time. Finally, the Data Security Diagram is essential for analyzing and strengthening access controls to address the concerns about unauthorized access to critical information. This combination provides a comprehensive approach to investigating the operational aspects as requested.

A: This option lacks a viewpoint to address the tracking of product revenue and new launches over time, a key stakeholder concern. The Product Lifecycle Diagram is missing.

B: This option incorrectly suggests a Data Life Cycle Diagram, which tracks data entities, not the lifecycle and revenue of products as required by the scenario.

C: This option is the least suitable as it includes an irrelevant Location Catalog and fails to address the critical security and product lifecycle concerns mentioned by the stakeholders.

1. Goal/Objective/Service Diagram: The Open Group Standard

TOGAF® Version 9.2

Section 36.2.11. This diagram shows how services contribute to achieving business goals and objectives

which is essential for analyzing revenue-earning services.

2. System/Technology Matrix: The Open Group Standard

TOGAF® Version 9.2

Section 36.2.28. This matrix links logical applications and application components to the underlying technology

which is critical for diagnosing performance issues like the slow HR application.

3. Product Lifecycle Diagram: The Open Group Standard

TOGAF® Version 9.2

Section 36.2.18. This diagram is used to "show the business value of products over time" and manage the "timescale of a product from its introduction to the market until it is phased out"

directly addressing the revenue tracking and new launch concerns.

4. Data Security Diagram: The Open Group Standard

TOGAF® Version 9.2

Section 36.2.21. This diagram is used to show "the data assets that are of value to the organization and the security classification that is applied to these data assets"

making it the correct tool for analyzing and securing access to critical information.

5. System/Functions Catalog: The Open Group Standard

TOGAF® Version 9.2

Section 36.2.27. This catalog helps in "understanding the systems in a landscape and the functions that they provide"

which is a necessary first step in diagnosing the problematic HR application.