Stakeholders, their concerns and how architecture serves them

Who the stakeholders are

A stakeholder is anyone with a legitimate interest in a system: people who use it, pay for it, build it, run it, regulate it or are affected by it. ISO/IEC/IEEE 42010:2022, the international standard for architecture description, defines the term broadly as a role, position, individual, organisation or class of these that has an interest, right, share or claim in the thing being described. Two features of that definition matter in practice. First, a stakeholder is often a class rather than a person: "patients" or "the on-call engineers" rather than a named individual. Second, a claim or a right is enough: a regulator who never logs in to your system is still a stakeholder because it can stop you operating.

The list is longer than most teams expect. For a typical commercial system it includes:

Users (the people who operate the software day to day, often several distinct groups); customers (whoever pays, who may not be a user at all); the product owner or product manager who decides what gets built; the sponsor who funds the work and answers for its success; developers who must understand and change the code; testers who must be able to set up data and observe behaviour; operations staff and site reliability engineers (SREs) who deploy, monitor and recover it at three in the morning; the security team; the data protection officer where personal data is processed (under the UK and EU GDPR some organisations must appoint one); legal and procurement, who care about licences, contracts and liability; finance, who care about running costs as much as build costs; regulators and auditors; and third-party integrators, the other teams and companies whose software calls yours or is called by it.

Some stakeholders are absent from every meeting: the developers who will maintain the system in five years, the support desk that takes the complaints, people with disabilities who will use the interface, and members of the public affected by its decisions. Part of an architect's job is to speak for the ones who are not in the room.

Concerns: what stakeholders care about

In 42010 a concern is any matter of relevance or importance to a stakeholder. The word is deliberately wide. A concern can be a quality ("will the booking page stay fast on Monday mornings?"), a cost ("what will this cost to run per month?"), a risk ("what happens if the SMS provider goes down?"), a constraint ("must patient data stay in the UK?"), a feasibility question ("can our team build this with the skills we have?") or an organisational matter ("which team owns the integration with the GP system?").

Concerns are not yet requirements. They are usually expressed vaguely, in the stakeholder's own vocabulary, and they are often worries rather than specifications. "I don't want another outage like last winter" is a concern; "the booking service is available 99.9% of each calendar month, measured at the load balancer" is a requirement derived from it. Capturing the concern in the stakeholder's words first, and only then sharpening it, keeps you honest about where a requirement came from and why it matters.

One concern is often shared by several stakeholders, and one stakeholder usually has many concerns. Security is a concern of the security team, the data protection officer, the sponsor (who fears headlines) and patients (who fear their records leaking). That many-to-many relationship is exactly why 42010 treats concerns as the hinge between people and architecture: decisions answer concerns, and views are organised around the concerns they address.

Mapping stakeholders: the power/interest grid

With twenty or more stakeholder groups you cannot give each the same attention. A widely used tool is the power/interest grid, usually attributed to Aubrey Mendelow, whose paper on stakeholders and environmental scanning dates from 1981 (it is often cited as 1991). Each stakeholder is placed according to how much power they have over the system (to fund, approve, block or reshape it) and how much interest they take in it. The quadrants suggest an engagement strategy: manage closely (high power, high interest), keep satisfied (high power, low interest), keep informed (low power, high interest) and monitor (low power, low interest).

The grid is about engagement, not about whose concerns count. Patients of a hospital have little formal power over a booking system's design but the highest stakes of anyone, and some legal duties (accessibility, data protection) exist precisely to protect people with little power. Treat the grid as a reminder of whom to talk to and how often, and keep a separate judgement about which concerns are critical. Positions also move: a regulator with low interest becomes the most interested stakeholder of all the week after a data breach.

Conflicting concerns and how to make them explicit

Concerns conflict all the time, and an architecture that pleases everyone usually means a conflict has been hidden rather than resolved. The security team wants every login protected by multi-factor authentication; the patient representative points out that many elderly patients have no smartphone. Finance wants a single small database server; operations wants a standby replica in a second data centre. The product owner wants a new feature every week; the testers want time to regression-test the integration with the hospital's patient administration system.

An architect's contribution is not to pick a winner quietly but to make the conflict visible, quantified and owned. In practice that means four things. State both concerns precisely, ideally as testable scenarios, so the argument is about numbers rather than adjectives. Show the options and their consequences side by side: for example, MFA for staff and for patients who opt in, with a one-time code by text message or landline call as a fallback. Name the decision owner: some trade-offs belong to the sponsor or to a risk committee, not to the architect. Record the outcome and its rationale, so that when someone asks in two years why patients can log in without MFA, the answer exists. The next section, Decisions and trade-offs, covers the mechanics of weighing such options.

Some conflicts dissolve on inspection. The security team may not need MFA for every patient action, only for viewing test results; the patient group may be content with it there. Asking each side why they hold the concern, and what outcome they actually fear, often reveals a design that satisfies both.

How concerns feed requirements and documentation

Concerns are the raw material for two later activities. The first is requirements engineering. A concern about speed becomes a quality attribute requirement, which Chapter 2 teaches you to write as a measurable scenario (source, stimulus, artifact, environment, response and response measure): see Writing quality attribute scenarios. A concern such as "patient data must stay in the UK" becomes a constraint, a decision already made for you. Concerns that turn out not to affect the structure of the system stay as ordinary functional or project requirements.

The second is documentation. 42010 organises an architecture description around concerns: a viewpoint names the concerns it frames and the stakeholders it serves, and a view applies that viewpoint to your system. The operations team's concerns call for a deployment view showing servers, regions and failover; the data protection officer's call for a data-flow view showing where personal data travels and where it rests; developers need a module view showing what depends on what. A diagram that does not answer any stakeholder's concern is decoration. Chapter 4 covers this properly in Views and viewpoints.

Traceability ties the two together. If you can follow a line from a stakeholder, through a concern, to a requirement, a decision and a view, you can answer the two questions every reviewer eventually asks: why is it built like this, and have we forgotten anyone?