Section 1: Stakeholder Management in TOGAF
In TOGAF, a stakeholder is any individual, team, or organisation with an interest in, or concerns about, the outcome of an architecture. Stakeholder management is not a one-time activity — it runs across all ADM phases and is most heavily concentrated in Phase A (Architecture Vision), where the stakeholder map is first created and initial engagement is established.
An individual, team, or organisation (or classes thereof) with interests in, or concerns relative to, the outcome of the architecture. An architecture succeeds only when the right stakeholders accept and support it. — TOGAF Standard, 10th Edition
Architecture work that ignores stakeholders risks producing technically sound but politically unsupported solutions. The three key reasons stakeholder management matters are: acceptance (stakeholders must buy in to the Target Architecture), completeness (different stakeholders surface different concerns that must be addressed), and governance (stakeholders with authority can block or derail implementation).
Section 2: Stakeholder Identification
TOGAF groups stakeholders into broad categories. Architects must identify all relevant stakeholders early in Phase A to prevent concerns being raised late — when they are costly to address.
| Category | Examples | Primary Concern |
|---|---|---|
| Business Sponsors | CEO, Board, Executive Sponsor | Strategic alignment, ROI, risk |
| End Users | Operational staff, customers | Usability, reliability, change impact |
| IT Teams | Developers, infrastructure, security | Feasibility, standards, integration |
| Partners & Suppliers | System integrators, SaaS vendors | Interoperability, contractual obligations |
| Regulators | Data protection authority, auditors | Compliance, data handling, auditability |
| Operations | IT Ops, service desk, facilities | Maintainability, SLAs, support cost |
Power/Interest Grid
The Power/Interest grid (also called the stakeholder engagement matrix) is a 2×2 tool that maps stakeholders by their level of power (authority to affect outcomes) against their level of interest (how much they care). It determines the appropriate engagement strategy for each group.
The exam tests which quadrant maps to which strategy. Memorise: Manage Closely (high power, high interest) = your key players; Keep Satisfied (high power, low interest) = executives who can block you; Keep Informed (low power, high interest) = advocates; Monitor (low power, low interest) = watch only.
Section 3: Concerns and Viewpoints
TOGAF aligns with ISO/IEC/IEEE 42010 (Systems and software engineering — Architecture description) to define a precise vocabulary for communicating architecture to different audiences.
| Term | Definition | Example |
|---|---|---|
| Concern | An interest a stakeholder has in the system — what they care about | Security, cost, reliability, performance |
| Viewpoint | A template or pattern that frames how a particular set of concerns will be addressed; defined in advance | Security Viewpoint, Business Process Viewpoint |
| View | A representation of the system from the perspective of a related set of concerns; an instance of a viewpoint applied to a specific architecture | A security diagram for the Target Architecture |
The relationship flows in one direction: a Stakeholder has Concerns, which are addressed by selecting a Viewpoint, which when applied produces a View. Think of the viewpoint as the camera lens specification and the view as the photograph it produces.
Candidates frequently confuse these terms. A viewpoint is the template (reusable, defined in a library); a view is the result (specific to an architecture). You select a viewpoint, then produce a view. Never say "a stakeholder has a viewpoint" — stakeholders have concerns.
Section 4: Key Architecture Viewpoints
TOGAF defines several standard viewpoints that cover the BDAT domains. Architects select viewpoints based on which stakeholder concerns they must address. The following are most frequently tested:
A single architecture will typically include multiple views, each derived from a different viewpoint and targeted at a different audience. Executives receive a Business Architecture View; operations teams receive a Technology Architecture View; security officers receive a Security View.
Section 5: Creating Effective Architecture Views
Producing too many views is as harmful as producing too few. An over-documented architecture is ignored; an under-documented one leaves concerns unaddressed. The architect must:
- Match viewpoints to stakeholders: Identify each stakeholder's primary concerns first, then select the viewpoint that best addresses them. Never produce a view that no stakeholder has asked for.
- Calibrate presentation format: Executives need summary diagrams and narrative; technical teams need precise specifications. The same information rendered differently for each audience is more effective than one generic document.
- Avoid over-documentation: TOGAF explicitly warns against producing artefacts for their own sake. Deliverables should be produced only when they add value for a defined stakeholder audience.
Section 6: Communication Plan
A formal Architecture Communication Strategy is developed as part of Phase A to ensure the right information reaches the right people at the right time. It typically covers:
| Element | Description |
|---|---|
| Audience segmentation | Who receives what information; aligned to Power/Interest grid quadrants |
| Frequency and format | How often updates are issued (weekly, milestone, ad hoc) and in what format (dashboard, report, briefing) |
| Channels | Architecture repository, email distributions, steering committee presentations, wiki/portal |
| Escalation paths | When and how unresolved concerns escalate — typically to the Architecture Board, then to executive sponsor |
| Feedback loops | Mechanisms for stakeholders to raise concerns — review sessions, formal comment periods, issue logs |
Part 2 scenarios test whether you can select a proportionate communication approach. An architecture that will significantly impact a group requires proactive engagement, not just periodic updates. Escalation paths always lead to the Architecture Board first — not directly to the CIO or project sponsor — unless the Architecture Board is the point of conflict.
Section 7: Resistance Management
Resistance to an architecture is normal and expected. Common sources include: threat to existing power structures, fear of redundancy, scepticism about feasibility, disagreement with strategic direction, or lack of involvement in earlier phases.
TOGAF-recommended strategies for managing resistance:
- Early and inclusive engagement: Involve resistors early in Phase A. Stakeholders who shape the architecture are less likely to oppose it later.
- Acknowledge and document concerns: Unacknowledged concerns escalate into blocking behaviour. Logging concerns in a Stakeholder Map and addressing them through appropriate viewpoints demonstrates respect and builds trust.
- Trade-off transparency: Where the architecture cannot satisfy all concerns simultaneously, make trade-offs visible and documented. Stakeholders accept compromises they can see; hidden compromises generate distrust.
- Change management alignment: Architecture change must be coordinated with the enterprise's change management practice. An architectural transition that is not accompanied by communications, training, and process updates will fail regardless of technical quality.
- Architecture Board arbitration: If a stakeholder dispute cannot be resolved at the architecture team level, the Architecture Board is the formal body for arbitrating conflicts between stakeholder concerns and architecture principles.
Section 8: Part 2 Exam — Stakeholder Scenario Questions
Stakeholder scenarios are among the most frequently appearing Part 2 question types. They test your ability to apply TOGAF guidance — not just repeat definitions — under realistic conditions.
Scenario: A Key Stakeholder Disagrees With the Architecture Direction
This is the classic Part 2 stakeholder scenario. The correct response always follows this priority order:
- Engage directly: Meet with the stakeholder to understand the specific concern. Never dismiss or bypass resistance.
- Identify the concern and produce the appropriate view: Use the relevant viewpoint to demonstrate how the architecture addresses (or acknowledges) their concern.
- Assess the trade-off: Determine whether the concern can be accommodated without violating architecture principles. Document the trade-off analysis.
- Escalate if unresolved: If the stakeholder's position conflicts with approved architecture principles and cannot be resolved, escalate to the Architecture Board — not to the project manager or CIO.
- Record the outcome: Update the Stakeholder Map and Architecture Definition Document with the resolution or documented dispensation.
Part 2 scenarios often pit stakeholder satisfaction against architecture principles. TOGAF's position: architecture principles take precedence over individual stakeholder preferences unless a formal dispensation is approved by the Architecture Board. Never select an answer that compromises principles simply to satisfy a powerful stakeholder.
Revision Summary — Chapter 16
- A stakeholder is any individual, team, or organisation with concerns about the architecture outcome; management begins in Phase A and continues throughout all ADM phases.
- Stakeholder categories: Business Sponsors, End Users, IT Teams, Partners, Regulators, Operations — each with distinct primary concerns.
- Power/Interest grid: Manage Closely (high/high), Keep Satisfied (high power/low interest), Keep Informed (low power/high interest), Monitor (low/low).
- ISO/IEC/IEEE 42010 vocabulary: Concern (stakeholder interest) → Viewpoint (template) → View (architecture representation). Never reverse this chain.
- Key viewpoints: Business Architecture, Information Systems, Technology Architecture, Business Process, Application Communication, Security, Migration.
- Communication plan elements: audience segmentation, frequency, channels, escalation paths, and feedback loops — all defined in Phase A.
- Resistance is managed by: early engagement, documented concerns, transparent trade-offs, change management alignment, and Architecture Board arbitration.
- Part 2 trade-off rule: architecture principles take precedence over individual stakeholder demands unless the Architecture Board formally approves a dispensation.
Practice Questions
Five exam-style questions covering this chapter. Click a question to reveal the answer and explanation.
A. Preliminary Phase
B. Phase A — Architecture Vision
C. Phase B — Business Architecture
D. Requirements Management
Explanation: Option B is correct. The stakeholder map is a primary output of Phase A. While stakeholder management continues throughout all ADM phases, the initial identification, classification, and engagement strategy are established in Phase A. The Preliminary Phase sets up the architecture practice but does not yet engage project-specific stakeholders. Requirements Management is continuous and does not own stakeholder identification.
A. View, then Viewpoint
B. Concern, then View
C. Viewpoint, then View
D. Viewpoint, then Concern
Explanation: Option C is correct. Selecting a pattern for documenting how a set of concerns is addressed is choosing a Viewpoint (reusable template). Applying that viewpoint to produce the specific diagram is creating a View (the concrete architecture representation). The chain is always: Stakeholder has Concerns → Architect selects Viewpoint → Applies it to produce a View.
A. Keep Satisfied
B. Manage Closely
C. Keep Informed
D. Monitor
Explanation: Option A is correct. The regulatory body has high power (can block or mandate changes) but low interest (not deeply engaged in detail). This maps to the "Keep Satisfied" quadrant of the Power/Interest grid — engage periodically with summary updates and seek their endorsement at key milestones, but do not burden them with detailed architecture reviews. "Manage Closely" applies to high power AND high interest stakeholders.
A. Immediately escalate the dispute to the Architecture Board for resolution
B. Meet with the director to understand the specific operational continuity concern and produce a Migration Viewpoint view showing how the transition will be managed
C. Modify the architecture to retain both legacy systems to satisfy the director's concern
D. Ask the project sponsor to overrule the director's objection
Explanation: Option B is correct. The first step is always direct engagement — understand the concern, then produce the appropriate view (Migration Viewpoint) to demonstrate how the concern is addressed. Immediate escalation (A) is premature; modification without analysis (C) compromises architecture principles; bypassing governance (D) is inappropriate. Only if direct engagement fails and the concern cannot be resolved through views and trade-off documentation should the Architecture Board be involved.
A. TOGAF viewpoints replace the ISO/IEC/IEEE 42010 standard; architects should use TOGAF viewpoints exclusively
B. ISO/IEC/IEEE 42010 is only relevant for software architecture, not enterprise architecture
C. TOGAF viewpoints are identical to ISO/IEC/IEEE 42010 views and the terms can be used interchangeably
D. TOGAF aligns with ISO/IEC/IEEE 42010 by adopting its Stakeholder–Concern–Viewpoint–View vocabulary, providing a standards-based foundation for architecture description
Explanation: Option D is correct. TOGAF explicitly aligns its stakeholder management and viewpoint vocabulary with ISO/IEC/IEEE 42010 (Systems and software engineering — Architecture description). This alignment ensures that TOGAF architecture descriptions are internationally standardised and interoperable. The terms are not interchangeable (C is wrong) — viewpoints and views are distinct concepts. ISO 42010 applies broadly to systems architecture, not just software (B is wrong). TOGAF supplements but does not replace ISO 42010 (A is wrong).