Up to here, K4 has taught you to make architecture decisions. This module is about making them with other people. Microsoft describes the role of a solution architect like this: she collects the expectations of the people involved, understands the business context and shapes from it a design that balances technology, operations and business, and she keeps everyone informed about trade-offs and risks that were knowingly accepted. Half of that is communication. This lesson shows with whom, about what and in which form.
For this module, the Kladde is the product of an invented software house with twelve people: a managing director, a product owner, five developers, one person for operations, one for support, plus sales and accounting part-time. The customers are the offices from K4. You, the architect, are one of the five in development.
Who wants something from the architecture
A stakeholder is any person or group that is affected by the architecture or can influence it. Every group has concerns of its own, and every concern has a document that answers it. You have already written most of them in K4:
| Group | Typical concerns | What it needs from you |
|---|---|---|
| Business side (offices, product owner) | What can the Kladde do, when, and what does a new module cost? | Quality goals (4.1.2), context diagram (4.1.4), an estimate with a range (4.14.2) |
| Management | Cost, risk, dependencies, growth | Cost per office (4.1.5), one page of architecture, the most important ADRs |
| Operations | What runs where, who gets woken up at night, how is it rolled back? | Deployment diagram, disaster recovery plan (4.7.5), alerts and runbooks |
| Security | Where are the trust boundaries, who may do what? | Threat model (4.8.2), permissions table (4.8.5) |
| Legal and data protection | Which data, where, for how long, who processes on behalf of whom? | Record of processing (4.8.3), erasure concept (4.8.4, 4.13.5), regions |
| Purchasing (at the software house and at large customers) | Contract terms, termination, dependence on one vendor, availability commitments | List of services with pricing model, availability (4.7.4), exit path |
| Team | Where does my code belong, which rule applies, why is it like that? | Component diagrams, house rules, ADRs, architecture tests |
Two groups are easily forgotten. Support is the first to hear when something is wrong, and it needs ways to investigate a case without getting rights to customer data. And the purchasing department of a large customer does not ask about Orleans but about notice periods and about what happens to the data when the contract ends. Both questions have consequences for the architecture.