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.