Key takeaways
- A concern explains why a description is useful.
- Roles stabilize responsibilities beyond particular individuals.
- Missing a stakeholder can create an architecture gap.
Start from concerns
A stakeholder is a person, team, or organization with an interest in the system being studied. A concern is a matter relevant to that architecture: cost, compliance, availability, usability, or delivery time, for example. Stakeholders do not all express the same needs, and their significance may vary according to the decision.
In an administrative request service, a citizen wants an understandable procedure, a case worker needs to process requests correctly, and a manager protects information. These concerns can conflict. Making them visible supports selection of appropriate views and informed trade-offs by people with legitimate authority.
A role is not a person
A role describes an expected behavior or responsibility. One person may perform several roles, and several people may perform the same role. This distinction helps define interactions and decision rights even when organizational structures or staffing change. Identify actual actors for communication and roles for understanding the structure of responsibilities.
- Identify internal and external stakeholders.
- Document concerns and potential conflicts.
- Check who decides, who contributes, and who needs to understand the result.
TERMS TO KNOW
The terms, in context.
- Concern
- A stakeholder’s relevant interest in the system.
- Role
- Behavior or responsibility that may be performed by an actor.