Skip to content
Software Architecture Guide

Stakeholder

Explanation

Section titled “Explanation”

A stakeholder is an individual, a team, an organization, or a whole class of them. What they share is an interest in the realization of the system.

Typical projects involve representatives from many stakeholder classes. Each class has its own requirements, interests, and needs. These needs can differ, so the architect must balance and prioritize them.

Classes need representatives. A stakeholder is often a class, such as “all users”, not one person. Someone must speak for that class. The architect must make sure representation is adequate across the board. If a class is ignored, problems appear later.

Stakeholders shape the architecture work. They determine how extensive and detailed the architecture work and its results must be.

Documenting stakeholders. The arc42 template (see arc42 Architecture Documentation Template) has a section 1.3 for an explicit stakeholder overview. The goal is to avoid surprises later in development. You should know all parties involved in developing the system or affected by it. The overview is a table with these columns:

  • the role,
  • the person’s name,
  • their expectations about the architecture and its documentation.

Example

Section titled “Example”

A team builds an online booking system. Its stakeholder table might list “Customer (class)” with a named representative from a customer panel, “Operations lead” who expects simple monitoring, and “Product owner” who expects short, readable documentation. Each row states what that party expects from the architecture and its documentation. When the operations lead’s needs clash with the customers’ needs, the architect weighs both and sets priorities.

Trade-offs

Section titled “Trade-offs”

Serving every stakeholder fully is not possible, because their needs differ. The architect must balance and prioritize. Skipping a class to save effort causes problems later.

Checks

Section titled “Checks”
  • The document has an explicit stakeholder overview, so no surprises arise later in development.
  • The stakeholder overview lists roles, names, and their expectations about the architecture and its documentation.
  • Every stakeholder class has a representative, so no class is ignored.
Section titled “Related”

Sources

Section titled “Sources”