skip to content

How do you identify a system's stakeholders and elicit their concerns, and how should those concerns determine which architecture views you actually produce?

level: middleimportance: must knowfreq 40%

answer

  1. stakeholder class checklist: assessors, support, maintainers too
  2. power/interest grid + named proxy for absent stakeholders
  3. vague wish → 6-part scenario (source, stimulus, artifact, env, response, measure)
  4. utility tree: business importance × architectural difficulty
  5. closure both ways; record what you deliberately skipped

basics

~20 s

List stakeholder classes (users, operators, developers, testers, support, acquirers, auditors), interview or workshop each to capture what worries them, turn vague wishes into measurable scenarios, then produce only the views that answer a real, prioritized concern — and skip the rest.

solid answer

~50 s

Start from a stakeholder *class* checklist so you do not forget the quiet ones: acquirers/sponsors, assessors (auditors, regulators, security), communicators, developers, maintainers, suppliers, support staff, system administrators/operators, testers, users. Map each on a power/interest grid and name a proxy for anyone absent (regulators, future maintainers, mass consumer users). Elicit concerns through interviews, a facilitated workshop such as a Quality Attribute Workshop, existing incident and support data, and by walking the current pain. Then *sharpen* each concern: "it must be fast" becomes a quality-attribute scenario — source, stimulus, artifact, environment, response, response measure — e.g. "at 2x peak load, a checkout request returns in under 400 ms at p99". Prioritize with a utility tree by (business importance × architectural difficulty). Finally apply the ISO/IEC 42010 closure rule in both directions: every prioritized concern must be framed by at least one viewpoint you produce, and any view framing no live concern gets dropped. Aim for minimum yet sufficient documentation, and record explicitly which concerns you chose not to address.

code

text · 20 lines
text
Concern (raw)        : "the system must be fast"

Sharpened scenario:
  source           : 10k concurrent shoppers
  stimulus         : checkout submit burst, 3x normal rate
  artifact         : order service + payment gateway adapter
  environment      : Black Friday peak, one AZ degraded
  response         : order accepted and confirmation shown
  response measure : p99 <= 400 ms, error rate < 0.1%

  importance = HIGH , architectural difficulty = HIGH   -> address now

Framed by:
  Concurrency view  (thread/queue model, backpressure)
  Deployment view   (node count, autoscale, AZ topology)
  Performance & Scalability perspective (applied across both)

Not produced: Development view in depth -- single team, no
              stakeholder raised a build-structure concern. Recorded
              as a deliberate omission, revisit at 3+ teams.

go deeper

for a junior

Show you know stakeholders go well beyond users and the product owner, that you would ask each group what worries them, and that views exist to answer those worries rather than to fill a template.

for a middle

Name a stakeholder class checklist, describe interviews plus a workshop, convert a vague concern into a measurable scenario, and apply the rule that each produced view must frame a live concern.

for a senior

Add prioritization (utility tree, importance × difficulty), per-audience notation and depth, explicit recording of deferred concerns and their re-trigger conditions, and cross-cutting quality concerns handled as perspectives rather than extra views.

for a principal

Talk about governance and scale: proxying regulators and future maintainers, reconciling conflicting concerns across business units, re-elicitation cadence tied to milestones and incidents, retiring stale views, and keeping the whole practice proportionate so it does not become documentation theatre.

## Why elicitation comes before drawing The cost of an architecture description is not writing it — it is *keeping it true*. Every view you produce becomes a maintenance liability and a source of drift. So the discipline is: produce a view only when a named stakeholder has a concern that the view answers. ISO/IEC 42010 encodes this as a two-way rule — every identified concern must be framed by at least one viewpoint, and (in practice) a viewpoint framing no concern is waste. ## Step 1 — find the stakeholders, especially the invisible ones Work from a **class checklist**, because the ones who bite you are the ones nobody invited. Rozanski & Woods' classes are a good default: - **Acquirers / sponsors** — pay for it, own scope and budget. - **Assessors** — auditors, regulators, security reviewers, safety certifiers; conformance to standards and law. - **Communicators** — trainers, technical writers, sales engineers; need explainable models. - **Developers** — build it; care about modularity, build times, testability. - **Maintainers** — live with it for years; care about evolvability and comprehensibility. - **Suppliers** — provide hardware, platforms, third-party components; constraints and licensing. - **Support staff** — first line; care about diagnosability and run-books. - **System administrators / operators** — deploy, monitor, upgrade, back up. - **Testers** — need testable seams, environments, data. - **Users** — several distinct sub-classes usually (power vs occasional, internal vs external). Add context-specific ones: data protection officer, finance (cost per transaction), partner integrators, downstream teams consuming your APIs, and the *future* team that inherits the system. Techniques: an org-chart and value-stream walk, a **power/interest (or influence/interest) grid** to decide who you manage closely versus merely inform, and an explicit **proxy assignment** for stakeholders who cannot participate — regulators, mass consumer users, and future maintainers almost never attend a workshop, so someone must be named to represent them and that fact belongs in the architecture description. ## Step 2 — elicit concerns Good sources, in rough order of signal: 1. **Incident and support history** — what has actually hurt. Hard to argue with. 2. **Structured interviews** — one class at a time; ask "what would make you say this system failed?" and "what change do you expect to make in the next 18 months?" rather than "what are your requirements?". 3. **Facilitated workshops** — the SEI **Quality Attribute Workshop (QAW)** is the canonical form: present business drivers and the system plan, brainstorm quality-attribute scenarios, consolidate, vote to prioritize, refine the top ones. 4. **Existing artifacts** — SLAs and contracts, regulatory obligations, procurement constraints, capacity forecasts, roadmap. 5. **Constraint hunting** — mandated platforms, existing skill sets, budget ceilings, deadlines. Constraints are concerns you cannot negotiate. The standard itself says you must at minimum consider concerns of system purpose, suitability for purpose, feasibility of construction and deployment, potential risks and impacts to stakeholders, and maintainability/evolvability. ## Step 3 — sharpen vague concerns into testable scenarios "It must be fast / secure / reliable" is unarchitectable. Convert each into a **quality-attribute scenario** with six parts: - **Source** of the stimulus (a user, an attacker, an ops engineer, a clock) - **Stimulus** (a burst of 5,000 requests/s; a credential-stuffing attempt; a region outage) - **Artifact** (the whole system, or a specific element) - **Environment** (normal load, peak, degraded, during deploy) - **Response** (what the system does) - **Response measure** (the number that makes it falsifiable) Example: *"During a full availability-zone loss (environment) the checkout service (artifact) continues to accept orders (response) with p99 latency under 800 ms and zero confirmed-order loss (measure), recovering full capacity within 10 minutes."* Now it can drive design and be tested. Prioritize with a **utility tree**: quality attributes → refinements → scenarios, each tagged with (business importance, architectural difficulty), typically High/Medium/Low each. The (H,H) scenarios are where architecture effort goes. ## Step 4 — let the concerns select the views Now map concerns to viewpoints. Using the Rozanski & Woods set as an example: | Concern raised | View that frames it | |---|---| | "What is in scope, who do we integrate with?" | Context | | "What does it do and how is responsibility divided?" | Functional | | "Where does PII live, how long is it kept, who owns the master copy?" | Information | | "Will it deadlock / can we saturate the CPU?" | Concurrency | | "How do we build, test, and evolve this with 4 teams?" | Development | | "How many nodes, which regions, what network and licences?" | Deployment | | "How do we upgrade at 3 a.m. without downtime, and diagnose incidents?" | Operational | And cross-cutting quality concerns (security, performance, availability, evolution) are applied as **perspectives** across several of those views instead of getting a view each. The selection decisions are the interesting part: - A single-threaded, stateless request/response service with one database usually needs **no Concurrency view** — nobody has that concern. - An internal tool with two users needs a Context and Functional view and little else. - A regulated payments platform will need Information and Operational views in depth because assessors and operators are first-class stakeholders with sharp concerns. - Conversely, if you find yourself producing a view because "the template has one", delete it. Also choose **notation and depth per audience**: the same deployment content might be a one-page diagram for the sponsor and a node/port/firewall table for operators. And record **what you deliberately did not address** — an explicitly deferred concern is a managed risk; a silently dropped one is a landmine. ## Step 5 — keep it alive Concerns are elicited at a point in time. Re-elicit at major milestones, after significant incidents, and when the stakeholder set changes (new regulator, new consuming team, hand-off to a maintenance org). Views whose framing concern has died should be retired, not lovingly maintained. ## Trade-offs and edge cases - **Loudest-voice bias.** The stakeholder with the most meeting time is not the one with the most risk. The power/interest grid plus explicit proxies is the counterweight. - **Concerns disguised as solutions.** "We need Kafka" is a proposed solution; the concern beneath it might be "replay after downstream failure" or "decouple deploy cadence". Always dig one level down. - **Over-elicitation.** A three-week stakeholder study on a two-month project is itself a failure. Timebox: a half-day workshop plus five interviews gets most of the value. - **Conflicting concerns are normal and are the point** — they produce the trade-off decisions that constitute the architecture, and each one deserves recorded rationale. - **Agile fit.** None of this requires big up-front documentation. The lightweight version is: a stakeholder list on a wiki page, a prioritized scenario backlog, and two or three living diagrams — still derived by exactly the same rule.

  • A stakeholder says "the system must be highly available". What do you do with that statement before it can influence the architecture?
    Turn it into a falsifiable quality-attribute scenario: which failure (node, AZ, region, dependency), in which environment, what the system must still do, and the measured target — availability percentage over what window, recovery time objective, recovery point objective, and whether degraded read-only mode counts as available. Then check who else is affected (ops, support, finance) and price the tactics, because the difference between 99.9% and 99.99% is often an order of magnitude of cost.
  • How do you decide to *not* produce a view that the standard template includes?
    Check whether any prioritized concern is framed only by that view. If none is, the view is waste — drop it and record the omission and the trigger that would bring it back (for example, "no Concurrency view: the service is stateless and single-database; revisit if we introduce background workers or shared mutable caches"). Recording the trigger is what makes it a decision rather than an oversight.
  • Which stakeholders are most often missed, and what goes wrong when they are?
    Operators and support staff (you ship something undeployable, unmonitorable, or undiagnosable), assessors and regulators (a late compliance finding forces rework of data handling), testers (no seams or environments, so verification is manual and slow), and future maintainers (a design nobody can safely change). Each maps to concerns that surface late and expensively, which is why a class checklist plus named proxies beats an ad-hoc invite list.

An architect designing a house does not draw every plan in the drafting textbook. They ask who will live in, build, inspect, and eventually rewire the house, find out what each of them fears — "will the inspector pass the stairs?", "can I get a piano up there?" — and then draw exactly the drawings that answer those questions. Drawing a sprinkler plan for a house with no sprinklers is billable time nobody wanted.

saying these in an interview costs you the question

  • Equating stakeholders with "the customer" or "the product owner" and skipping operators, support, testers, assessors, and future maintainers.
  • Accepting unquantified concerns like "must be fast/secure/scalable" and treating them as actionable.
  • Producing the full standard view set by habit and back-filling justification, instead of deriving views from prioritized concerns.
  • Recording a proposed solution ("we need a message queue") as if it were a concern, without digging out the underlying worry.
  • Eliciting once at project start and never re-visiting, so the view set fossilizes.
  • Silently dropping concerns you cannot address rather than recording them as accepted, deferred risks.
  • Letting the loudest or most senior voice set priority instead of business importance combined with architectural difficulty.

context

resolving links…