Bis hierher hat K4 Ihnen beigebracht, Architekturentscheidungen zu treffen. Dieses Modul handelt davon, sie mit anderen zu treffen. Microsoft beschreibt die Rolle einer Lösungsarchitektin so: Sie sammelt die Erwartungen der Beteiligten, versteht den geschäftlichen Zusammenhang und formt daraus einen Entwurf, der Technik, Betrieb und Geschäft ausbalanciert, und sie hält die Beteiligten über Abwägungen und bewusst getragene Risiken auf dem Laufenden. Die Hälfte davon ist Kommunikation. Diese Lektion zeigt, mit wem, worüber und in welcher Form.
Für dieses Modul ist die Kladde das Produkt eines erfundenen Softwarehauses mit zwölf Leuten: eine Geschäftsführerin, ein Produktverantwortlicher, fünf Entwicklerinnen und Entwickler, eine Person für den Betrieb, eine für den Support, dazu Vertrieb und Buchhaltung in Teilzeit. Die Kunden sind die Büros aus K4. Sie, die Architektin oder der Architekt, sind eine der fünf aus der Entwicklung.
Wer etwas von der Architektur will
Ein Stakeholder ist jede Person oder Gruppe, die von der Architektur betroffen ist oder sie beeinflussen kann. Jede Gruppe hat eigene Anliegen, und jedes Anliegen hat ein Dokument, das es beantwortet. Die meisten davon haben Sie in K4 schon geschrieben:
| Gruppe | Typische Anliegen | Was sie von Ihnen braucht |
|---|---|---|
| Fachseite (Büros, Produktverantwortlicher) | Was kann die Kladde, wann, und was kostet ein neues Modul? | Qualitätsziele (4.1.2), Kontextdiagramm (4.1.4), eine Schätzung mit Bandbreite (4.14.2) |
| Geschäftsführung | Kosten, Risiko, Abhängigkeiten, Wachstum | Kosten je Büro (4.1.5), eine Seite Architektur, die wichtigsten ADRs |
| Betrieb | Was läuft wo, wer wird nachts geweckt, wie wird zurückgerollt? | Deployment-Diagramm, Notfallplan (4.7.5), Alarme und Runbooks |
| Sicherheit | Wo sind die Vertrauensgrenzen, wer darf was? | Bedrohungsmodell (4.8.2), Rechtetabelle (4.8.5) |
| Recht und Datenschutz | Welche Daten, wo, wie lange, wer verarbeitet im Auftrag? | Datenverzeichnis (4.8.3), Löschkonzept (4.8.4, 4.13.5), Regionen |
| Einkauf (beim Softwarehaus und bei großen Kunden) | Vertragslaufzeiten, Kündbarkeit, Abhängigkeit von einem Anbieter, Verfügbarkeitszusagen | Liste der Dienste mit Preismodell, Verfügbarkeit (4.7.4), Ausstiegsweg |
| Team | Wo gehört mein Code hin, welche Regel gilt, warum ist das so? | Komponentendiagramme, Hausordnung, ADRs, Architekturtests |
Zwei Gruppen werden gern vergessen. Der Support hört als Erster, wenn etwas nicht stimmt, und braucht Wege, einen Fall zu untersuchen, ohne Rechte an Kundendaten zu bekommen. Und der Einkauf eines großen Kunden fragt nicht nach Orleans, sondern nach Kündigungsfristen und danach, was mit den Daten geschieht, wenn der Vertrag endet. Beide Fragen haben Folgen für die Architektur.