Skip to content
Software Architecture Guide

Stakeholder Identification

Explanation

Section titled “Explanation”

Stakeholders are individuals, teams or organizations with an interest in the system being described. Their interests are called concerns. Examples are performance, security or maintainability. See the articles Stakeholder and Stakeholder Concern.

Where it sits in the process. Stakeholder management starts with identification. Analysis follows. It rates each stakeholder’s influence and interest. Tailored communication plans come after that.

Questions that help you find them. A guide to stakeholder management lists guiding questions. Examples:

  • Who gains from this change, and who loses?
  • Who decides?
  • Who controls resources?
  • Who has specialist skills?
  • Who has influence?

Cover every class. An architect should make sure stakeholders are adequately represented. Every stakeholder class needs consideration. Two classes are examples:

  • Acquirers oversee the procurement of the system or product.
  • Assessors check conformance to standards and legal regulation.

Record them. The architecture description must address stakeholder concerns explicitly. It must link stakeholders to those concerns. The arc42 template uses a table for this. Each row has a role or name, a contact and expectations. Stakeholders can be persons, roles or organizations.

Example

Section titled “Example”

A company plans a new online ordering system. The team asks the guiding questions. Who gains? Customers and the sales team. Who loses? Staff whose manual work disappears. Who decides? The department head. Who controls the budget? The finance lead. Who has specialist skills? A long-time developer. Who checks legal rules? A compliance officer. Each answer becomes a row in the stakeholder table with a role, a contact and expectations.

Trade-offs

Section titled “Trade-offs”

The facts give no cost or effort figures. They do show one risk: a missed stakeholder class leaves its concerns unaddressed. A stakeholder table lists roles and contacts, but the architecture description must still link each stakeholder to concerns.

Stakeholder management steps, starting with identification.

Diagram source 
flowchart LR
  A[Identify stakeholders] --> B[Analyze influence and interest]
  B --> C[Plan communication]

Checks

Section titled “Checks”
  • The document lists stakeholders in a table with role or name, contact and expectations.
  • Each stakeholder is linked to concerns, and the concerns are addressed explicitly.
  • Every stakeholder class is considered, for example acquirers and assessors.
  • Identification used guiding questions such as who gains or loses, who decides and who controls resources.
Section titled “Related”

Sources

Section titled “Sources”