# Stakeholder

**In short:** A stakeholder is a person, team, organization, or class of such parties with an interest in a system being built. Architects must balance their different needs and make sure each class is represented.

## 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

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

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

- 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.

## Related

- [Stakeholder Concern](https://arc.fuet.ch/concepts/forces-decisions/stakeholder-concern.md)
- [Stakeholder Identification](https://arc.fuet.ch/concepts/vision-stakeholders/stakeholder-identification.md)
- [Stakeholder Power Grid](https://arc.fuet.ch/concepts/vision-stakeholders/stakeholder-power-grid.md)
- [Concern](https://arc.fuet.ch/concepts/forces-decisions/concern.md)
- [arc42 Introduction and Goals](https://arc.fuet.ch/concepts/documentation/arc42-introduction-and-goals.md)
- [arc42 Architecture Documentation Template](https://arc.fuet.ch/concepts/documentation/arc42-documentation-template.md)
- [Stakeholder Perspective and Concern](https://arc.fuet.ch/concepts/documentation/stakeholder-perspective-and-concern.md)
- [ISO/IEC/IEEE 42010 Architecture Description Standard](https://arc.fuet.ch/concepts/documentation/iso-iec-ieee-42010-architecture-description-standard.md)

## Sources

- [Software Systems Architecture](https://www.viewpoints-and-perspectives.info/home/stakeholders/) — viewpoints-and-perspectives.info, accessed 2026-11-09
- [1 - Introduction and Goals | arc42 Documentation](https://docs.arc42.org/section-1/) — docs.arc42.org, accessed 2026-11-09