Stakeholder Map (TOGAF)
A TOGAF-specific stakeholder analysis that maps stakeholders to their architecture concerns and the architecture views that address those concerns, ensuring the architecture communication is tailored to each audience.
Purpose
The TOGAF Stakeholder Map ensures that architecture deliverables address the specific concerns of each stakeholder group. It guides the creation of architecture views and ensures that communication is effective and targeted.
When to Use
Create at the start of an architecture engagement (TOGAF Phase A) to guide the architecture development approach. Reference when creating architecture views to ensure they address stakeholder concerns.
How to Build
Identify all stakeholders of the architecture engagement — not just project stakeholders, but anyone who has concerns that the architecture must address.
For each stakeholder, identify their key concerns: what questions do they need the architecture to answer? What decisions do they need to make based on architecture information?
Map concerns to architecture viewpoints: which views (context, logical, deployment, data flow, etc.) address which concerns?
Define the communication approach for each stakeholder: what level of detail, what format, what frequency?
Validate with stakeholders that their concerns are correctly captured and will be addressed.
Tips
- Focus on concerns, not just interests — what specific questions does each stakeholder need answered?
- Map concerns to specific architecture views for traceability.
- Include both technical and non-technical stakeholders.
- Validate the mapping with stakeholders themselves.
- Use this to prioritise which architecture views to create first.
Common Mistakes
- Confusing project stakeholders with architecture stakeholders.
- Not identifying specific concerns, just listing generic interests.
- Not mapping concerns to views, making the analysis academic rather than practical.
- Ignoring non-technical stakeholders who have legitimate architecture concerns.
- Creating the map but not using it to guide architecture view creation.
Government Context
In UK government, architecture stakeholders include CDDO (for spend control), GDS (for service assessments), departmental architecture boards, security teams (for accreditation), and DPOs (for privacy). Each has specific concerns that the architecture must address. Cross-government stakeholders are often overlooked but have significant influence.