Babelfisch für Softwarearchitekten – Kommunikation mit den Stakeholdern
Die Arbeit von Softwarearchitekten erfordert nicht nur technisches Wissen, sondern auch eine ganze Menge Kommunikation. Tipps und Templates helfen dabei.
(Bild: iX, erstellt mit Midjourney)
- Dr. Michael Stal
In der praktischen Arbeit müssen Softwarearchitektinnen und -architekten mit Personen in vielen unterschiedlichen Positionen und Rollen zusammenarbeiten. Dabei agieren sie überwiegend ohne Macht, sie müssen also kommunikativ eher mit Motivation arbeiten statt mit der Autorität einer Führungsposition. Abbildung 1 zeigt eine Auswahl der wichtigsten Kommunikationspartner.
Natürlich sollten Softwarearchitekten darauf achten, keinen Tod durch Meetings zu erleiden. Diese sollten sich auf das notwendige Minimum beschränken, denn Überkommunikation ist genauso kontraproduktiv wie Unterkommunikation. Das Wasserfallmodell tendiert anfangs oft zu Unterkommunikation, aber in späteren Phasen, bisweilen auch Panikmodus genannt, zu Überkommunikation. In agilen Umgebungen verteilen sich im Idealfall die Kommunikationsaufwände gleichmäßig über die Projektlaufzeit.
Architektur als Kommunikationsmittel
Die Softwarearchitektur dient als verpflichtende Guideline zur Umsetzung des Problems, sprich der Anforderungen. Daher ist deren Kommunikation nicht nur für Entwickler essenziell. Für die Kommunikation empfehlen sich folgende Mittel:
Die Architekturdokumentation darf nicht nur das Was und das Wie berücksichtigen, sondern muss auch das Warum der getroffenen Architekturentscheidungen abdecken. Manchen Architekturdokumenten ist anzusehen, dass die Architekten unmotiviert ihrer Dokumentationspflicht nachgekommen sind, was die Sache für die Zielgruppen und letztendlich auch die Architekten selbst schwierig macht. Daher sollten sie sich vorher genau überlegen, welche Informationen Stakeholder wie zum Beispiel Produktmanagerinnen, Tester oder Entwickler benötigen.
Zur Strukturierung und Komplettierung dieser Dokumente empfiehlt es sich, auf ein vorhandenes Template wie arc42 zuzugreifen. Abbildung 2 zeigt die Vorgaben von arc42 mit Ebene 1 (Whitebox-Beschreibung des Gesamtsystems und Blackbox-Beschreibungen der darin enthaltenen Bausteine) und Ebene 2 (Hineinzoomen in einige Bausteine der Ebene 1). Ebene 3 würde wiederum in Ebene 2 hineinzoomen und so weiter.
(Bild: arc42)
Solche Templates basieren auf jahrzehntelangen Erfahrungen und weisen in der Regel einen Topdown-Ansatz auf, um Leser nicht zu überfordern. Natürlich dürfen die Dokumente nicht zu umfangreich sein, sondern sollten für Detailinformationen auf entsprechende Dokumente zu Subsystemen oder Komponenten verweisen. Ein Umfang von maximal 60 bis 80 Seiten pro Dokument erweist sich in der Praxis als zielführend.
Videos by heise
Erfolgreiche Kommunikation darf sich nicht im Austausch von Dokumenten erschöpfen, sondern sollte als Multi-Channel Communication auch über Präsentationen und Workshops erfolgen. Es hat sich als vorteilhaft herausgestellt, vor der Übergabe des Architekturdokuments eine Präsentation mit den wichtigsten Kernelementen zu zeigen. Einige Unternehmen organisieren zu diesem Zweck sogar Workshops mit Nutzern und Kunden.
Um Kommunikationspartner zu überzeugen, müssen Architekten ihre Entscheidungen begründen können. Architecture Decision Records (siehe Abbildung 3) helfen dabei. Sie geben das Thema der Entscheidung an, zeigen mögliche Alternativen und erläutern, weshalb eine Alternative den Vorrang bekommen hat. Ihre Speicherung erfolgt zusammen mit der Codebasis in Source-Management-Systemen wie GitHub. Davon profitieren nicht nur Newbies, sondern alle Stakeholder, die sich über Entscheidungen informieren wollen.
Aus Software-Pattern (siehe Abbildung 4) entsteht eine idiomatische Sprache für effektivere Kommunikation, von der alle Beteiligten profitieren. Statt beispielsweise von einer Ereignisquelle, einer Ereignisschnittstelle und Ereignisnutzern zu sprechen, reicht die Nennung des Observer-Pattern aus. Dadurch ist es überflüssig, einzelne Klassen und Schnittstellen zu erläutern, sondern man nutzt eine höhere Abstraktionsebene. Das gilt auch für DDD-Pattern (Domain-driven Design) auf Fachdomänenebene.
Das Nutzen einfacher Arbeitsmittel wie Whiteboards, Blackboards oder Flipcharts in einem Low-Tech-First-Ansatz hat viele Vorteile. Sie erlauben eine freiere und interaktivere Kommunikation sowie Zusammenarbeit und helfen, für jeden Zweck ein adäquates Mittel zu verwenden. Ohnehin erhöht häufiger Medienwechsel die Aufmerksamkeit. Ein relativ simples Verfahren besteht in Karteikärtchen, die in drei Bereiche unterteilt sind. Im oberen schlanken horizontalen Segment schreibt man einen Klassen- oder Komponentennamen (siehe Abbildung 5), darunter auf der linken Seite folgt eine Spalte „Responsibilities“ mit den Verantwortlichkeiten der Komponente und rechts daneben die Spalte „Collaborators“, also anderen Komponenten, mit denen die vorliegende zusammenarbeitet.
Diese CRC-Karten (Class-Responsibilities-Collaborators) lassen sich einfach erstellen, auf einer Pinnwand befestigen, gruppieren oder über Fäden verbinden. Auf diese Weise erhalten Entwurfsdiskussionen ein adäquates Tool zur Kommunikation. UML-Tools dokumentieren anschließend die Arbeitsergebnisse solcher Diskussionen in einem elektronischen Format.
Es hat sich bewährt, dass Softwarearchitektinnen und Entwickler mit Fachdomänenexperten getreu dem Ansatz des Domain-driven Design (DDD) eine Ubiquitous Language entwerfen, die die Fachkonzepte und ihre Beziehungen definiert. Dadurch lassen sich später Missverständnisse vermeiden. Die Entwicklung und Verbesserung dieser Sprache erfolgt kontinuierlich. Zusätzlich bietet DDD einen von der Problemdomäne gesteuerten Ansatz, der verhindert, dass sich Entwicklerinnen und Entwickler zu schnell auf die Lösungsdomäne stürzen. So konzentrieren sich Softwarearchitekten bei DDD auf die Entwicklung einer geeigneten Sprache für die Fachdomäne und befassen sich zu Beginn ausschließlich mit dem Problemraum beziehungsweise der Fachdomäne.
Wenn Architekten anderen Beteiligten die Dokumentation nur hinwerfen, sich aber danach nicht mehr darum kümmern, kommt es fast immer zu einer Architekturdrift. Das heißt, die Implementierung entspricht nicht dem Entwurf. Die Gründe dafür können vielfältig sein: Möglicherweise waren Entwickler unter Zeitdruck, haben die Architektur nicht verstanden oder haben aus ihrer Sicht unsinnige Entscheidungen durch eigene Alternativen ersetzt.
Daher ist es ratsam, Management by Walking zu betreiben, sich also kontinuierlich unter die Developer zu mischen, deren Feedback einzuholen und Fragen zu klären. Ebenso sollten Architekten an der Implementierung mitarbeiten, und zwar nicht nur, um der „Eat your own dog food!“-Regel zu folgen, sondern um in Kontakt mit Entwicklern zu bleiben. Es wäre allerdings kontraproduktiv, wenn Architekten im kritischen Pfad arbeiten.
Reviews besitzen neben Optimierungsaspekten auch Kommunikationsaspekte. Durch ein Architektur-Review lassen sich erfahrungsgemäß sowohl Fragen klären als auch Problematiken und Risiken aufspüren. Zudem erhöht sich das Verständnis aller Beteiligten von Problemen und der Architektur. Diesen Aspekt unterschätzen viele Projekte. Reviews sollten bei jedem Inkrement beziehungsweise Sprint erfolgen, um frühzeitig Probleme zu beheben. Das gilt selbstverständlich auch für Code oder Design Reviews.
Als leichtgewichtige Methode bieten sich Architecture Design Reviews an, um kurzfristig Feedback von Kundinnen oder Nutzern zu erhalten. Dazu stellt die Architektin Dokumente oder Entwicklungsartefakte und einen Fragebogen mit Aufgaben zusammen. Zum Beispiel hat das Entwicklungsteam eine Cloud-basierte Persistenzlösung mit AWS S3 erstellt und benötigt Feedback zur Nutzerfreundlichkeit. Die Architektin stellt die Implementierung samt Dokumentation zur Verfügung oder liefert eine URL, über die Reviewer den Dienst nutzen. Hinzu fügt sie für die Reviewer einen Fragebogen, der unter anderem abfragt: „Wie viel Zeit haben Sie benötigt, um über die API ein Verzeichnis zu kreieren und ein neues Objekt dort abzulegen?“ oder „Ist die Dokumentation aus Ihrer Sicht angemessen? Falls nein, tragen Sie bitte Verbesserungsvorschläge ein.“ Der Aufwand für solche Reviews hält sich in Grenzen, der Nutzen ist trotzdem groß. Ratsam ist, für den Verfasser des Reviews einen Tag einzuplanen und für den oder die Reviewer je einen weiteren Tag.
Knowledge Replicas: In einigen Projekten ergeben sich dadurch Stolperfallen, dass gewisse Kompetenzen nur in einzelnen Köpfen vorhanden sind. Verlässt eine Person das Unternehmen, entstehen Probleme. Daher empfiehlt sich eine Information-Sharing-Kultur, zu der auch Softwarearchitekten beitragen. Über jedes kritische Wissen sollten mehrere Personen verfügen. Die Informationen lassen sich via Coaching oder Mentoring teilen. Das gilt insbesondere für das von externen Beratern eingebrachte Wissen. Derartige Wünsche stoßen mitunter auf den Widerstand der Wissensträger, die ihren Wissensvorsprung und ihre Bedeutung für das Unternehmen dadurch sichern wollen, weshalb es entsprechender Anreize bedarf, etwa zusätzliche monetäre Vergütungen oder sichtbare Wertschätzung.
Metriken und Qualitätsprüfung durch Architekturevaluierungswerkzeuge (siehe Abbildung 6) ermöglichen die Bewertung der Architekturqualität, beispielsweise hinsichtlich Abhängigkeitszyklen, Größe der Codebasis, Fehlerbrennpunkten oder Komplexitätsaspekten. Was zunächst wie eine rein technische Facette erscheinen mag, bewährt sich auch für die Kommunikation, da reines Bauchgefühl oft nicht überzeugt. Durch handfeste Zahlen lassen sich andere Beteiligte eher dazu motivieren, Verbesserungsmaßnahmen vorzunehmen und zu finanzieren.
Frühzeitige Klärung offener Fragen spielt beim Projektstart eine wichtige Rolle. Softwarearchitekten sollten gezielt auf andere Beteiligte zugehen, um geschäftliche Aspekte, Anforderungen oder die Teststrategie zu klären. Das gilt selbst dann, wenn andere Rollen für diese Aktivität verantwortlich sind. Oft ist beispielsweise der Anforderungskatalog verbesserungswürdig, weil wichtige Informationen oder eindeutige Prioritäten fehlen, insbesondere in Bezug auf Qualitätsattribute. Im letzteren Fall erstellen Softwarearchitekten einen Utility Tree mit selbst eingeschätzten Prioritäten. Den diskutieren sie dann mit den verantwortlichen Rollen und ergreifen so die Initiative.
Softwarearchitekten und -entwickler stehen in Projekten häufig einem nebulösen und dynamischen Umfeld gegenüber. Der Anforderungskatalog ist nicht fertiggestellt oder besitzt mangelnde Qualität. Es fehlt an Erfahrungen mit neuen Technologien, das Team verfügt über zu wenig Wissen oder Ressourcen und vieles mehr. Zwei Faktoren helfen in solchen Situationen. Zum einen bietet ein agiler Prozess mit hintereinander folgenden Sprints und dadurch schnellem Feedback Vorteile. Zum anderen müssen Architektinnen und Architekten mit der entsprechenden Courage Sachverhalte aktiv klären (siehe vorhergehender Aspekt). Sind die Anforderungen unvollständig, sorgen Softwarearchitekten im Idealfall dafür, dass zumindest die wichtigsten 20 bis 30 Prozent der Anforderungen zeitnah vorliegen. Damit können sie eine ausreichende Architecture Baseline (Basisarchitektur) gewährleisten.
Parallel zur Klärungsphase lassen sich zum einen technische Prototypen erstellen, um die Brauchbarkeit und Eigenschaften neuer oder bisher nicht verwendeter Technologien zu eruieren, und zum anderen die dafür notwendigen Fortbildungsmaßnahmen organisieren und durchführen. Dieser Ansatz stammt vom sogenannten Twin-Peaks-Modell. Auch hierfür ist die Überzeugung anderer Beteiligter notwendig.
Blinde Flecke: Wer schon einmal ein Dokument oder ein Programm erstellt und einen darin befindlichen Fehler trotz mehrfacher Prüfung einfach nicht gefunden hat, weiß, dass das Gehirn Details unbewusst verdrängen oder zu falschen Kontexten vervollständigen kann. Ein berühmtes Beispiel ist das vermeintliche Gesicht auf der Mondoberfläche. Hier können andere Mitarbeiter gut unterstützen, weshalb Pair Programming oder Pair Designing hilfreich sind.
Retrospektiven beziehen sich auf die häufig unterschätzte Aktivität, auf die Vergangenheit zurückzublicken, um daraus für die Zukunft zu lernen. Treiber sind die Fragen „Was waren die Ursachen für Fehlschläge oder Probleme?“ und „Was waren die wichtigsten Erfolgsfaktoren?“. Neben technischen Aspekten ergeben sich oft auch kommunikative Defizite, die für Unheil gesorgt haben. Wer in der Rolle des Softwarearchitekten die Vergangenheit retrospektiv analysiert, sollte sich die Frage stellen, wo er oder sie besser hätten agieren können.
Wichtige Fragen der Kommunikation
Natürlich kann dieser Artikel nicht alle Eventualitäten abdecken, doch vor jeder Art von Kommunikation können sich Softwarearchitektinnen und -architekten beispielsweise folgende Fragen stellen:
- Warum/wozu ist das wichtig?
- Für wen ist das wichtig?
- Was will ich erreichen?
- Wie will ich es erreichen?
- Was erwarten oder benötigen die Kommunikationspartner (Zuhörerkontext)?
- Welche Persönlichkeitstypen liegen vor?
- Was ist das notwendige und hinreichende Minimum an Kommunikation beziehungsweise wie lässt sich Communication Overflow vermeiden?
- Welche Aufmerksamkeitsspannen haben meine Gesprächspartner?
Dazu kommt ein entscheidender und oft unterschätzter Faktor, der immer in das Kommunikationsverhalten hineinspielt: Wie schaffe ich es, einen guten Eindruck zu hinterlassen?
