Which stakeholders in an architecture decision do architects most often overlook, and what does each care about?
Show the full answer Hide the answer
What is being tested
Whether you engage the audiences whose objections arrive late and expensively.
The consistently overlooked
Operations and on-call. They live with the design for years. Their concern is "can I understand and fix this at 3am", and it is entirely legitimate. A design nobody can operate is a bad design regardless of its elegance, and they are the only people who can tell you before it is built.
Security. Engaged at the end, they object when the design is finished and are perceived as blockers. Engaged at the start, they shape the design cheaply and become allies. The cost difference is enormous and entirely determined by timing.
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 — and they are the ones who will question your utilisation targets later.
Support. Handles the consequences of every degraded mode and every ambiguous error message. They know which parts of the current system generate contacts, which is data nobody else has.
Compliance and legal. Their concerns are hard constraints — residency, retention, auditability — discovered late at enormous cost.
The engineers who will build it. Whether the design is buildable and maintainable by the actual team, with its actual skills.
What to determine for each
Not what they want, but what would make them object. That is far more actionable and it surfaces the constraint rather than the preference.
The technique that saves the most time
Find the objections before the review. Circulate the design to likely objectors individually, ask what would worry them, and address it in the document.
A design review where every stakeholder sees the design for the first time will not conclude. It becomes a negotiation rather than a decision, and it will need a second meeting.
Communicating to each
The same architecture needs several presentations, and presenting the engineering view to all of them is the most common communication failure in the discipline:
| 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 |
What a strong answer adds
Distinguishing decision-makers from influencers. Persuading someone with strong opinions and no authority, while the actual decision-maker was never engaged, is a common and avoidable failure.