1.2. Stakeholders
Ar42 specifications helper
Contents
Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that
-
should know the architecture
-
have to be convinced of the architecture
-
have to work with the architecture or with code
-
need the documentation of the architecture for their work
-
have to come up with decisions about the system or its development
Motivation
You should know all parties involved in development of the system or affected by the system. Otherwise, you may get nasty surprises later in the development process. These stakeholders determine the extent and the level of detail of your work and its results.
Form
Table with role names, person names, and their expectations with respect to the architecture and its documentation.
| Role / organisational unit | Named contacts* | Why they care – expectations toward the architecture & its documentation |
|---|---|---|
| Project Sponsor / Steering Committee | xxx | 1-page executive summary that shows cost/benefit, risk mitigation and compatibility with IT strategy. |
| Product Owner | Ksenia S. | Traceability from backlog epics → architectural building blocks; confidence that the solution can evolve toward a full SRM suite. |
| RFQ Manager (Tailor-Made Desk) | xxx | Understand how the tool supports their daily RFQ workflow and data quality rules; ensure UX decisions match the BPMN flows. |
| Requester (Event Manager) | xxx | See that event-specific needs (location, technical capacity, lead-time) are reflected in the data model and UI. |
| Approver (TM Desk Lead / CFO) | xxx | Clarity on authorisation layers, audit trail, and how separation-of-duties is enforced. |
| Finance (Accounts Payable) | xxx | Interface contracts for future Purchase Order & invoice integration with ERP; confidence that data fields meet legal invoicing rules. |
| InfoSec / DPO | xxx | authentication flow; need security-related ADRs and quality scenarios. |
| Solution Architect | Victor H. | Single source of truth for all cross-cutting decisions, quality-attribute scenarios, and C4 views to communicate with dev team. |
| Frontend Developers | Ksenia M. | Clear front-end architecture (modules, state management, API façade), REST/JSON contracts and style guide. |
| Backend Developers | Victor H. | Component cut, layering rules, data-access policy, coding standards, ADRs; well-documented domain model. |
| DevOps / Customer IT | xxx | Deployment topology, container/runbook docs, CI/CD oks |
| QA / Test Engineers | Christophe B., Maryam A. | End-to-end use-case view, quality goals, testability tactics; mapping of stories to components to build test plans. |
| University Supervisor | xxx | Completeness and consistency of the documentation as part of the academic assessment. |