Stakeholder Analysis
Identifying who has a stake in a decision, what each cares about, and what would make each object — before the design review rather than during it.
Definition
Stakeholder analysis maps the people whose concerns the architecture must satisfy, or whose objection can stop it. Both categories matter and they are not the same.
The stakeholders architects consistently under-serve
- Operations and on-call. They live with the design for years and are rarely consulted. Their concern is "can I understand and fix this at 3am", and it is legitimate.
- Security. Engaged late, they object at the end and are perceived as blockers. Engaged early, they shape the design cheaply.
- Finance. Cares about total cost over time and about predictability. An architecture with an unpredictable cost curve is a problem for them regardless of its technical merit.
- Support. Handles the consequences of every degraded mode and every ambiguous error message.
- Compliance and legal. Concerns are hard constraints, discovered late at enormous cost.
- The engineers who will build it, whose concern is whether the design is buildable and maintainable by the actual team.
What to determine for each
- What they care about, in their own terms. Not what you think they should care about.
- What would make them object, which is more actionable than what they want.
- Their influence and their interest, which determines how much effort engagement warrants.
- Their preferred medium. A finance director wants a cost model, not a component diagram; an SRE wants failure modes; a product manager wants capability and timeline.
The technique that saves the most time
Find the objections before the review. Circulate the design to the likely objectors individually, ask what would worry them, and address it in the document. A design review where every stakeholder is seeing the design for the first time is a review that will not conclude, and it converts what should be a decision into a negotiation.
Communicating to each
The same architecture needs several presentations:
| Audience | What they need |
|---|---|
| Executive | Business outcome, cost, risk, timeline |
| Product | Capabilities enabled, constraints imposed, sequencing |
| Engineering | Structure, contracts, trade-offs, what to build first |
| Operations | Failure modes, degradation, runbooks, alerting |
| Security | Trust boundaries, data flows, controls |
| Finance | Cost model, unit economics, commitment implications |
Presenting the engineering view to all six is the most common communication failure in architecture.
Failure scenarios
- Security and compliance engaged at the end, producing late expensive objections.
- Operations never consulted, producing a design nobody can run.
- One artefact for every audience.
- Confusing decision-makers with influencers, so the wrong person is persuaded.
Interview question
"Who are the stakeholders in an architecture decision, and which do architects most often overlook?"