Overview
Stakeholder Management covers how an architect works with the people who can affect, or are affected by, an architecture. Three of its four outcomes are at the Applying level, which makes it one of the most practical areas on the Practitioner syllabus. You are expected to identify stakeholders, their concerns and the views they need, then decide how to communicate with them.
The TOGAF technique works in four steps: identify stakeholders, classify their positions, determine the management approach, and tailor engagement deliverables. A power and interest grid sorts stakeholders into groups that need close management, keeping satisfied, keeping informed or minimal effort. Stakeholder concerns then drive the choice of viewpoints, and therefore which views of the architecture are produced. The unit also covers managing engagement and requirements over the life of an ADM cycle, and using trade-offs so that competing concerns are resolved openly with the right people rather than by the architect alone.
How it's tested
Questions present a situation, often early in an ADM cycle or after a stakeholder complains, and ask what the architect should do. Best options follow the technique in order and tailor communication. Weaker options broadcast one document to everybody, skip classification, or let one powerful stakeholder dictate without analysis.
-
Missed stakeholder
A group with real power or a regulatory role was not consulted. The best answer adds them to the Stakeholder Map, captures concerns and adjusts views and the Communications Plan.
-
Wrong view for the audience
Executives receive detailed technical models, or engineers receive only slogans. Strong options select viewpoints that address each group's specific concerns.
-
Conflicting concerns
Two stakeholder groups want incompatible outcomes. Higher-scoring options analyse trade-offs, present them openly and escalate decisions through governance.
A logistics firm's finance director wants a cheaper shared platform, while the head of operations insists on regional systems for resilience. Picking either side outright earns little. The best option documents both concerns, models the cost and resilience trade-offs in views each stakeholder understands, and brings the decision to the sponsor and Architecture Board with clear consequences, so the choice is owned and recorded.
Learning outcomes 4
Official learning outcomes from the The Open Group outline, in outline order.
2.1 Apply stakeholder management: identify stakeholders, their concerns, views and communication needsBloom level 3. Running the four-step stakeholder management technique.
- What it means
- You identify everyone who can influence or is affected by the architecture, classify their positions by power and interest, decide how to manage each group, and tailor deliverables and communication. Results are recorded in a Stakeholder Map and reflected in the Communications Plan.
- What to understand
- The four steps are identify stakeholders, classify stakeholder positions, determine the stakeholder management approach, and tailor engagement deliverables. The power and interest grid gives four groups: key players to manage closely, keep satisfied, keep informed, and minimal effort. Stakeholders include corporate, project, system and external groups such as regulators or partners.
- How it shows up
- The best option usually completes identification and classification before choosing deliverables, and includes indirect or external stakeholders the scenario hints at.
- Common confusion
- Assuming the stakeholder list is just the project team and sponsor.
2.2 Explain how to use architecture viewsBloom level 2. Views and viewpoints address specific stakeholder concerns.
- What it means
- An architecture view is a representation of the system from the perspective of related concerns. A viewpoint defines the conventions for constructing and using a view. The TOGAF Standard follows the ISO/IEC/IEEE 42010 concepts: concerns drive viewpoints, viewpoints govern views.
- What to understand
- Selecting viewpoints starts from stakeholder concerns, not from the models already available. One architecture can be presented through many views, each simplified for its audience. Views help check that the architecture actually addresses each concern and help stakeholders give informed feedback and approval.
- How it shows up
- Look for options that build or select views from documented concerns, not options that send the whole architecture definition to every stakeholder.
- Common confusion
- Mixing up a view (the representation) with a viewpoint (the template or perspective it is built from).
2.3 Apply stakeholder engagement and requirements managementBloom level 3. Keeping stakeholders engaged and their requirements current.
- What it means
- Stakeholder engagement continues through the ADM cycle, not only at the start. As stakeholders refine or change their requirements, the architect captures them, assesses impact and records them through Requirements Management so the architecture and the Architecture Requirements Specification stay consistent.
- What to understand
- Engagement methods vary by group: workshops, reviews, briefings or simple updates. Formal stakeholder reviews happen in Phases B, C and D before an architecture is finalized. When stakeholders raise new requirements, they are prioritized and assessed for impact rather than added directly to the design.
- How it shows up
- Scenarios with late new requirements reward options that route them through Requirements Management and a Requirements Impact Assessment.
- Common confusion
- Treating engagement as a one-off kick-off event.
2.4 Apply trade-offs in architecture developmentBloom level 3. Balancing competing concerns transparently.
- What it means
- Architecture choices rarely satisfy every concern fully. Trade-off analysis makes the costs and benefits of alternatives explicit, for example cost against resilience or speed against standardization, so stakeholders with the right authority can decide.
- What to understand
- The architect identifies alternatives, evaluates them against stakeholder concerns, requirements, principles and constraints, and presents the consequences of each. Decisions are taken by sponsors or the Architecture Board and recorded. Trade-offs are revisited if conditions change. Hiding a trade-off, or resolving it by the architect's preference, undermines buy-in.
- How it shows up
- Prefer options that compare alternatives against agreed criteria and escalate decisions with evidence; avoid options that simply follow the most senior voice.
- Common confusion
- Thinking a trade-off means finding a compromise that partly satisfies everyone.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Four stakeholder management steps
Identify, classify positions, determine approach, tailor engagement deliverables.
- Remember
- Classification comes before choosing deliverables.
- Tested as
- Sequencing the architect's actions in scenarios.
- Trap
- Jumping straight to producing views.
-
Power and interest grid
Sorts stakeholders by influence and interest into four management groups.
- Remember
- High power, high interest are key players to manage closely.
- Tested as
- Choosing how intensively to engage a group.
- Trap
- Giving low-interest executives no attention.
-
Stakeholder Map
Artifact recording stakeholders, involvement, class, current and required support, and relevant views.
- Remember
- Created in Phase A and updated as needed.
- Tested as
- Correct place to record a missed stakeholder.
- Trap
- Thinking it is fixed once Phase A ends.
-
Concern
An interest a stakeholder has in the architecture, such as cost, security or performance.
- Remember
- Concerns drive the selection of viewpoints.
- Tested as
- Diagnosing why a deliverable failed.
- Trap
- Confusing a concern with a formal requirement.
-
View vs. viewpoint
A view is what the stakeholder sees; a viewpoint is where you are looking from and the conventions used.
- Remember
- Viewpoints are reusable; views are specific.
- Tested as
- Wording in options about tailoring communication.
- Trap
- Using the terms interchangeably.
-
Communications Plan
Phase A output describing how, when and to whom architecture information is communicated.
- Remember
- Built from the stakeholder analysis.
- Tested as
- Options that update it after stakeholder changes score well.
- Trap
- One generic newsletter for everyone.
-
Formal stakeholder review
Step in Phases B, C and D checking the proposed architecture against the original motivation and Statement of Architecture Work.
- Remember
- Happens before the architecture is finalized.
- Tested as
- Validating designs with stakeholders.
- Trap
- Skipping it to save time.
-
Trade-off analysis
Explicit comparison of alternatives against concerns, requirements and principles.
- Remember
- Decisions are made and recorded by the appropriate authority.
- Tested as
- Choosing between two partly good options.
- Trap
- Letting the architect decide silently.
-
Requirements Impact Assessment
Assessment of how a new or changed requirement affects the architecture and earlier phases.
- Remember
- Used whenever stakeholders change requirements mid-cycle.
- Tested as
- Late-change scenarios.
- Trap
- Adding the requirement directly to the design.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Power and interest grid groups
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Key players | High power and high interest | Manage closely and involve in decisions | Only sending them status reports |
| Keep satisfied | High power, lower interest | Consult enough to avoid surprises | Ignoring them until they block progress |
| Keep informed | Lower power, high interest | Regular, relevant updates | Overloading them with decisions |
| Minimal effort | Lower power and lower interest | Monitor and inform as needed | Never reassessing as positions change |
Concern vs. requirement vs. view
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Concern | A stakeholder interest in the architecture | Motivates what to show and analyse | Assuming every concern becomes a requirement |
| Requirement | A statement of need the architecture must meet | Managed through Requirements Management | Accepting it without impact assessment |
| View | Representation addressing a set of concerns | Communication and validation tool | Producing views with no stakeholder in mind |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
One deck for all
- What candidates pick
- Send the full Architecture Definition Document to every stakeholder for comment.
- Why it looks right
- It seems transparent and complete.
- Why it's wrong
- Different stakeholders have different concerns; tailored views get better feedback and buy-in.
Clue to watch for The scenario mentions confused or disengaged executives.
-
Loudest voice wins
- What candidates pick
- Adopt the most senior stakeholder's preferred option to keep the sponsor happy.
- Why it looks right
- Sponsor support matters.
- Why it's wrong
- Without trade-off analysis, other legitimate concerns are lost and the decision is not owned through governance.
Clue to watch for Two stakeholders want incompatible outcomes.
-
Direct insertion
- What candidates pick
- Add a stakeholder's new requirement straight into the target design.
- Why it looks right
- It is responsive.
- Why it's wrong
- Changed requirements need prioritization and an impact assessment through Requirements Management.
Clue to watch for A requirement appears after architecture work is well advanced.
-
Insiders only
- What candidates pick
- Limit stakeholder analysis to internal business and IT leaders.
- Why it looks right
- Internal people are easier to reach.
- Why it's wrong
- Regulators, customers and suppliers may have high power or legal concerns that change the architecture.
Clue to watch for Regulation, partners or customers are mentioned in passing.
-
Static map
- What candidates pick
- Keep the original Stakeholder Map after a reorganization.
- Why it looks right
- It was approved.
- Why it's wrong
- Positions and influence change; the map and Communications Plan should be updated.
Clue to watch for New executive, merger or restructuring mid-cycle.
Answer framework
Apply this sequence when a scenario turns on people, concerns or communication.
- List every stakeholder the stem mentions or implies, including external, operational and security groups, and note any that the organization has overlooked.
- Classify each by power and interest and note their current versus required level of support for the architecture work.
- Identify each group's key concerns and check whether the views and communication described actually address those concerns; unaddressed concerns are a common reason for losing support.
- For new or changed requirements, prefer options that capture, prioritize and assess impact through Requirements Management before changing the design.
- Where concerns conflict, choose the option that compares alternatives openly and takes the decision through sponsors or the Architecture Board.
Practice question
Want more like this? The TOGAF Practitioner practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Begin with the stakeholder management technique itself. Learn the four steps and the power and interest grid until you can apply them to any organization quickly. Practise on a familiar company: list ten stakeholders, place them on the grid and write one concern for each.
Then study views and viewpoints. Read how the TOGAF Standard links concerns to viewpoints and views, and look at the example stakeholder classes and the views they typically need. Make a two-column note matching common concerns, such as cost, security, operability or regulatory reporting, to suitable views.
Third, connect stakeholders to Requirements Management. Trace what happens when a stakeholder raises a new requirement during Phase C: capture, prioritize, assess impact, update the Architecture Requirements Specification. This is a frequent scenario pattern.
Finally, practise trade-offs. Take two alternatives, list the concerns each satisfies or harms, and decide who should make the call. In timed practice, train yourself to scan each scenario for stakeholders who have been missed or mis-classified; that single check often separates the best answer from the second best, which matters with 5, 3 and 1 point scoring.
FAQ
What share of OGEA-102 does Stakeholder Management carry?
The Open Group publishes no weight for Stakeholder Management. It is one of eight syllabus areas for the 8 scenario questions, and stakeholder issues also appear inside scenarios set in specific ADM phases.
Which outcomes are at the Applying level?
Three of the four: identifying stakeholders and their concerns and views, managing engagement and requirements, and using trade-offs. Using architecture views is at the Understanding level.
Where is the Stakeholder Map produced?
It is developed in Phase A as part of identifying stakeholders, concerns and business requirements, and it is updated during later phases when stakeholders or their positions change.
Is the power and interest grid mandatory?
It is the classification approach the TOGAF stakeholder technique describes, and scenarios often rely on it, so know the four groups and how each is managed.
How do views relate to ISO/IEC/IEEE 42010?
The TOGAF Standard uses the same concepts: stakeholders have concerns, viewpoints frame those concerns, and views conform to viewpoints. You do not need the ISO text itself.
Who decides a trade-off?
The architect analyses and presents alternatives; the decision belongs to the accountable stakeholders, typically the sponsor or the Architecture Board, and is recorded.
How can I spot stakeholder issues quickly in a long scenario?
Underline every role and organization mentioned, then ask who has power but has not been engaged. That gap often points to the best option.
Other Enterprise Architecture & IT Governance certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 2 knowledge
You have worked through stakeholder identification, classification, views and trade-offs. Test whether you can find the overlooked stakeholder in a timed scenario.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the TOGAF Practitioner AI tutor Get any concept explained your way