Stakeholder, ihre Anliegen und wie Architektur ihnen dient

Wer die Stakeholder sind

Ein Stakeholder ist jeder, der ein berechtigtes Interesse an einem System hat: Menschen, die es nutzen, bezahlen, bauen, betreiben, regulieren oder von ihm betroffen sind. ISO/IEC/IEEE 42010:2022, die internationale Norm für Architekturbeschreibungen, definiert den Begriff weit: als Rolle, Position, Einzelperson, Organisation oder Gruppe davon, die ein Interesse, Recht, Anteil oder einen Anspruch an dem beschriebenen Gegenstand hat. Zwei Merkmale dieser Definition sind in der Praxis wichtig. Erstens ist ein Stakeholder oft eine Gruppe und keine Person: „Patienten“ oder „die Bereitschaftsingenieure“ statt einer namentlich bekannten Person. Zweitens genügt ein Anspruch oder ein Recht: Eine Aufsichtsbehörde, die sich nie in Ihr System einloggt, ist trotzdem ein Stakeholder, weil sie Ihnen den Betrieb untersagen kann.

Die Liste ist länger, als die meisten Teams erwarten. Bei einem typischen kommerziellen System umfasst sie:

Nutzer (die Menschen, die die Software im Alltag bedienen, oft mehrere unterschiedliche Gruppen); Kunden (wer bezahlt, ist womöglich gar kein Nutzer); den Product Owner oder Produktmanager, der entscheidet, was gebaut wird; den Sponsor, der die Arbeit finanziert und für ihren Erfolg geradesteht; Entwickler, die den Code verstehen und ändern müssen; Tester, die Daten bereitstellen und Verhalten beobachten können müssen; Betriebspersonal und Site Reliability Engineers (SREs), die das System deployen, überwachen und um drei Uhr morgens wiederherstellen; das Sicherheitsteam; den Datenschutzbeauftragten, wo personenbezogene Daten verarbeitet werden (nach UK GDPR und DSGVO müssen manche Organisationen einen benennen); Recht und Einkauf, denen es um Lizenzen, Verträge und Haftung geht; die Finanzabteilung, der die Betriebskosten ebenso wichtig sind wie die Entwicklungskosten; Aufsichtsbehörden und Prüfer; sowie Integratoren von Drittanbietern, also die anderen Teams und Unternehmen, deren Software Ihre aufruft oder von ihr aufgerufen wird.

Manche Stakeholder fehlen in jedem Meeting: die Entwickler, die das System in fünf Jahren warten werden, der Support, der die Beschwerden entgegennimmt, Menschen mit Behinderungen, die die Oberfläche nutzen werden, und Bürgerinnen und Bürger, die von seinen Entscheidungen betroffen sind. Zu den Aufgaben einer Architektin oder eines Architekten gehört es, für diejenigen zu sprechen, die nicht im Raum sind.

Anliegen: worauf es Stakeholdern ankommt

In 42010 ist ein Anliegen jede Angelegenheit, die für einen Stakeholder relevant oder wichtig ist. Der Begriff ist bewusst weit gefasst. Ein Anliegen kann eine Qualität sein („Bleibt die Buchungsseite am Montagmorgen schnell?“), Kosten („Was kostet der Betrieb pro Monat?“), ein Risiko („Was passiert, wenn der SMS-Anbieter ausfällt?“), eine Randbedingung („Müssen Patientendaten im Vereinigten Königreich bleiben?“), eine Frage der Machbarkeit („Kann unser Team das mit seinen vorhandenen Fähigkeiten bauen?“) oder eine organisatorische Frage („Welches Team ist für die Integration mit dem Hausarztsystem zuständig?“).

Anliegen sind noch keine Anforderungen. Meist werden sie vage formuliert, im eigenen Vokabular des Stakeholders, und oft sind es eher Sorgen als Spezifikationen. „Ich will nicht noch einmal einen Ausfall wie im letzten Winter“ ist ein Anliegen; „der Buchungsservice ist in jedem Kalendermonat zu 99,9 % verfügbar, gemessen am Load Balancer“ ist eine daraus abgeleitete Anforderung. Wenn Sie das Anliegen zuerst in den Worten des Stakeholders festhalten und es erst dann schärfen, bleibt nachvollziehbar, woher eine Anforderung stammt und warum sie wichtig ist.

Ein Anliegen wird oft von mehreren Stakeholdern geteilt, und ein Stakeholder hat meist viele Anliegen. Sicherheit ist ein Anliegen des Sicherheitsteams, des Datenschutzbeauftragten, des Sponsors (der Schlagzeilen fürchtet) und der Patienten (die fürchten, dass ihre Akten nach außen dringen). Genau wegen dieser Viele-zu-viele-Beziehung behandelt 42010 Anliegen als Scharnier zwischen Menschen und Architektur: Entscheidungen beantworten Anliegen, und Sichten werden nach den Anliegen gegliedert, die sie adressieren.

Stakeholder erfassen: die Macht-Interesse-Matrix

Bei zwanzig oder mehr Stakeholder-Gruppen können Sie nicht jeder die gleiche Aufmerksamkeit schenken. Ein weit verbreitetes Werkzeug ist die Macht-Interesse-Matrix, die meist Aubrey Mendelow zugeschrieben wird, dessen Aufsatz über Stakeholder und Umfeldanalyse aus dem Jahr 1981 stammt (oft wird er mit 1991 zitiert). Jeder Stakeholder wird danach eingeordnet, wie viel Macht er über das System hat (es zu finanzieren, zu genehmigen, zu blockieren oder umzugestalten) und wie viel Interesse er daran zeigt. Die Quadranten legen eine Strategie der Einbindung nahe: eng einbinden (viel Macht, viel Interesse), zufrieden halten (viel Macht, wenig Interesse), informiert halten (wenig Macht, viel Interesse) und im Blick behalten (wenig Macht, wenig Interesse).

Bei der Matrix geht es um Einbindung, nicht darum, wessen Anliegen zählen. Die Patienten eines Krankenhauses haben wenig formale Macht über das Design eines Buchungssystems, aber mehr auf dem Spiel als alle anderen, und manche gesetzlichen Pflichten (Barrierefreiheit, Datenschutz) gibt es gerade, um Menschen mit wenig Macht zu schützen. Verstehen Sie die Matrix als Erinnerung daran, mit wem Sie wie oft sprechen sollten, und urteilen Sie getrennt davon, welche Anliegen kritisch sind. Auch Positionen verschieben sich: Eine Aufsichtsbehörde mit geringem Interesse wird in der Woche nach einer Datenpanne zum interessiertesten Stakeholder von allen.

Widersprüchliche Anliegen und wie man sie explizit macht

Anliegen widersprechen sich ständig, und eine Architektur, die alle zufriedenstellt, bedeutet meist, dass ein Konflikt verdeckt statt gelöst wurde. Das Sicherheitsteam will jede Anmeldung mit Multi-Faktor-Authentifizierung schützen; die Patientenvertretung weist darauf hin, dass viele ältere Patienten kein Smartphone haben. Die Finanzabteilung will einen einzigen kleinen Datenbankserver; der Betrieb will ein Standby-Replikat in einem zweiten Rechenzentrum. Der Product Owner will jede Woche ein neues Feature; die Tester wollen Zeit für Regressionstests der Integration mit dem Patientenverwaltungssystem des Krankenhauses.

Der Beitrag der Architektur besteht nicht darin, stillschweigend einen Sieger zu küren, sondern den Konflikt sichtbar, beziffert und verantwortet zu machen. In der Praxis heißt das vier Dinge. Formulieren Sie beide Anliegen präzise, idealerweise als testbare Szenarien, damit über Zahlen statt über Adjektive gestritten wird. Stellen Sie die Optionen und ihre Konsequenzen nebeneinander: zum Beispiel MFA für das Personal und für Patienten, die sich dafür entscheiden, mit einem Einmalcode per SMS oder Festnetzanruf als Ausweichlösung. Benennen Sie, wer entscheidet: Manche Abwägungen gehören dem Sponsor oder einem Risikoausschuss, nicht der Architektur. Halten Sie das Ergebnis und seine Begründung fest, damit es eine Antwort gibt, wenn in zwei Jahren jemand fragt, warum sich Patienten ohne MFA anmelden können. Der nächste Abschnitt, Entscheidungen und Abwägungen, behandelt, wie man solche Optionen gegeneinander abwägt.

Manche Konflikte lösen sich bei näherem Hinsehen auf. Das Sicherheitsteam braucht MFA vielleicht nicht für jede Aktion der Patienten, sondern nur für das Abrufen von Befunden; damit kann die Patientengruppe womöglich leben. Wenn Sie jede Seite fragen, warum sie das Anliegen hat und welches Ergebnis sie eigentlich fürchtet, zeigt sich oft ein Design, das beide zufriedenstellt.

Wie Anliegen in Anforderungen und Dokumentation einfließen

Anliegen sind das Rohmaterial für zwei spätere Tätigkeiten. Die erste ist das Requirements Engineering. Ein Anliegen zur Geschwindigkeit wird zu einer Anforderung an ein Qualitätsmerkmal, die Sie in Kapitel 2 als messbares Szenario formulieren lernen (Quelle, Stimulus, Artefakt, Umgebung, Antwort und Antwortmaß): siehe Testbare Qualitätsszenarien schreiben. Ein Anliegen wie „Patientendaten müssen im Vereinigten Königreich bleiben“ wird zu einer Randbedingung, einer Entscheidung, die bereits für Sie getroffen ist. Anliegen, die sich als bedeutungslos für die Struktur des Systems erweisen, bleiben gewöhnliche funktionale oder Projektanforderungen.

Die zweite ist die Dokumentation. 42010 gliedert eine Architekturbeschreibung nach Anliegen: Ein Blickwinkel benennt die Anliegen, die er erfasst, und die Stakeholder, denen er dient, und eine Sicht wendet diesen Blickwinkel auf Ihr System an. Die Anliegen des Betriebsteams verlangen eine Verteilungssicht mit Servern, Regionen und Failover; die des Datenschutzbeauftragten eine Datenflusssicht, die zeigt, wohin personenbezogene Daten fließen und wo sie gespeichert sind; Entwickler brauchen eine Modulsicht, die zeigt, was wovon abhängt. Ein Diagramm, das kein Anliegen eines Stakeholders beantwortet, ist Dekoration. Kapitel 4 behandelt das ausführlich in Sichten und Blickwinkel.

Rückverfolgbarkeit verbindet beides. Wenn Sie eine Linie von einem Stakeholder über ein Anliegen zu einer Anforderung, einer Entscheidung und einer Sicht ziehen können, können Sie die zwei Fragen beantworten, die jede Prüferin und jeder Prüfer irgendwann stellt: Warum ist es so gebaut, und haben wir jemanden vergessen?