Soziotechnische Architektur-Reviews: Teams verstehen, nicht nur Artefakte

Klassische Architektur-Reviews beschäftigen sich mit dem Code: Architektur gibt dem Code schließlich Struktur. Diese Struktur ist zentral für die Änderbarkeit.

Metriken machen die Qualität dieser Struktur messbar und ermöglichen die schnelle Analyse auch großer Projekte. Ein System sollte in überschaubar große Bestandteile mit möglichst wenigen Abhängigkeiten aufgeteilt werden. Zu solchen Bestandteilen zählen Klassen, Packages (Sammlungen von Klassen in Java) oder Microservices. Die Größe der Bestandteile und die Anzahl der Abhängigkeiten kann man als Metrik messen und so die Qualität beurteilen.

Besonders schlimm sind zyklische Abhängigkeiten: Wenn beispielsweise zwei Packages wechselseitig voneinander abhängen, kann eine Änderung in einem der Packages das andere beeinflussen. Eigentlich sollten die beiden Packages also getrennt sein – in Wirklichkeit sind sie aber eins. So ein Zyklus ist eine Art „Todsünde“ in der Architektur.

Es gibt aber noch andere Metriken. Man kann auch die zyklomatische Komplexität von Methoden messen. Das ist die Anzahl der möglichen Ausführungspfade durch eine Methode. Jede Fallunterscheidung (if-Statement) ergibt einen weiteren möglichen Ausführungspfad. Mehr Ausführungspfade bedeutet, dass der Code komplexer und schwerer zu verstehen ist.

Aber treffen solche Metriken den Kern der Probleme?

Metriken haben wenig Aussagekraft

Metriken bergen fast immer Probleme. Nicht selten muss man von einem „Big Ball of Mud“ sprechen. Das ist ein System mit so schlechten Metriken, dass es eigentlich keine echte Strukturierung hat. Wenn niemand mit entsprechenden Werkzeugen die Metriken managt, ergibt sich fast immer ein unstrukturiertes System. Es ist dann trivial herauszufinden, dass ein System schlecht strukturiert ist. Wenn das so einfach ist – welchen Wert hat dieser Einblick?

Es stellen sich dann eher andere Fragen:

• Das Verschieben einer einzigen Klasse kann einen Zyklus auflösen. Wir haben dann eine „Todsünde“ beseitigt. Aber ist das System wirklich signifikant einfacher änderbar?
• Vielleicht kommt das Team mit dem System ausreichend gut zurecht, weil es sich an die schlechte Strukturierung gewöhnt hat. Wie kann man das erfassen?
• Ein System bildet eine Fachlichkeit ab. Wie hoch ist die minimale Komplexität, die für eine bestimmte Fachlichkeit benötigt wird? Wie viel überflüssige Komplexität hat das System dann?

Eigentlich interessiert uns die Änderbarkeit des Systems. Die Metriken können Hinweise auf eine gute oder schlechte Änderbarkeit geben, aber nicht mehr. Es ist durchaus denkbar, dass ein System mit schlechten Metriken dennoch ausreichend änderbar ist, weil das Team das System schon lange weiterentwickelt und sich an die Strukturierung gewöhnt hat.

Gute Metriken bedeuten auch nicht unbedingt eine gute Änderbarkeit: Wenn ein Team ein perfekt strukturiertes System ohne Übergabe und Wissenstransfer übernimmt, wird es das System dennoch nur schwer ändern können. Es gibt sogar Hinweise, dass selbst eine ausführliche und klare Dokumentation nicht ausreichend ist, um ein System sinnvoll weiterzuentwickeln, sondern das ursprüngliche Team zur Verfügung stehen muss.

Software ist ein soziotechnisches System

An diesem Punkt hilft eine andere Perspektive:

Softwaresysteme sind nicht rein technische Systeme. Sie sind soziotechnische Systeme.

Die Idee der soziotechnischen Systeme geht unter anderem auf die Untersuchung im britischen Steinkohlebergbau zurück. In diesem Bereich kann man nicht einfach nur die Maschinen und Technologien betrachten, sondern man muss die Menschen mit betrachten – und zwar als spezifische Individuen, nicht als austauschbare Ressourcen. Der Verdacht liegt nahe, dass die Betrachtung der individuellen Menschen im Bereich Softwareentwicklung noch wichtiger ist.

Orientiert man sich an dieser Idee, muss man bei Reviews anders vorgehen. Die zentrale Frage lautet dann nicht: Wie sieht die Architektur aus? Und wie gut ist sie? Wichtig sind stattdessen Fragen wie: Wie geht dieses Team mit dieser Architektur um? Welche Probleme hat es dabei?

Teams haben die Expertise für ihre Systeme

Das führt zu einem weiteren wichtigen Perspektivwechsel: Die Menschen, die täglich an einem System arbeiten, sind offensichtlich die Expertinnen und Experten für das System. Es lohnt sich, diese Expertise zu nutzen.

Interviews mit diesen Menschen werden daher zu einem zentralen Bestandteil des Review. Als Einstieg bieten sich offene Fragen an:

• Was sind die Hauptstärken des Systems?
• Was sind die Hauptherausforderungen?

So kann man eine Unterhaltung starten, in deren Verlauf die Expertinnen und Experten einen nahezu automatisch zu den Hauptherausforderungen des Systems führen. Wenn das Review bestimmte Herausforderungen oder Fragestellungen untersuchen soll, muss man natürlich diese Punkte in das Gespräch einfließen lassen.

Wichtig ist außerdem eine Mischung unterschiedlicher Personen als Interviewpartner. Neben denjenigen, die das System umsetzen, sind auch Benutzerinnen und Benutzer sowie andere Stakeholder relevant. Schließlich sind sie die Quelle der Anforderungen, die dem Projekt und damit der Architektur zugrunde liegen. Wenn sich die Perspektiven der verschiedenen Gruppen sehr unterscheiden, ist das ein interessantes Ergebnis. Schließlich kann das Projekt wohl kaum erfolgreich sein, wenn verschiedene Gruppen das Ziel des Projekts unterschiedlich sehen.

Architekturprobleme sind oft soziale Probleme

So führen diese Reviews zu anderen Erkenntnissen.

Ein Beispiel: In einem Review beschwerten sich viele Interviewpartner über dieselbe Architekturentscheidung. Sie wurde als katastrophal empfunden. Interessanterweise konnte aber niemand eine Alternative oder eine Idee zu einer Alternative nennen, die unter den damaligen Randbedingungen funktioniert hätte.

Die eigentliche Erkenntnis war also nicht: „Die Entscheidung war richtig oder falsch.“ Sondern: „Das Team hat diese Entscheidung nie akzeptiert.“ Das ist ein völlig anderes Problem und muss völlig anders gelöst werden.

Ergebnisse

Ein Architektur-Review sollte nicht nur Erkenntnisse produzieren. Stattdessen ergeben diese Reviews eine konkrete Liste mit nach Dringlichkeit und Wichtigkeit priorisierten Empfehlungen für Handlungen.

Manchmal beginnt die Veränderung sogar schon während der Interviews. Menschen merken, dass ihre Perspektive ernst genommen wird, Probleme ausgesprochen werden und andere ähnliche Schwierigkeiten sehen. Dadurch entsteht häufig bereits eine Änderung. Oft geht das Review dann in eine Beratung über. Die Basis für den Erfolg der Beratung hat dabei die offene Kommunikation bei den Interviews und das daraus entstehende Vertrauen gelegt.

Wenn also wie in dem bereits genannten Beispiel eine Entscheidung nicht akzeptiert worden ist, dann kann die vertrauensvolle Kommunikation helfen, die Zusammenarbeit zu verbessern. Weil alle ihre Meinung einbringen und Alternativen vorschlagen konnten, können sich die Beteiligten vielleicht eher mit der Realität abfinden oder nach echten Alternativen suchen, die den Rahmenbedingungen tatsächlich gerecht werden.

Auch in einem anderen Fall ging das Review in eine Beratung mit der Arbeit an den identifizierten Herausforderungen über, die tatsächlich das Vorgehen in dem Projekt geändert haben. Eine andere Beratung hatte vorher mit einem viel größeren Team ein Review vorgenommen und einen Foliensatz erstellt. Sicher hat der Foliensatz interessante und relevante Erkenntnisse enthalten – sie nützen nur nichts, wenn sie das Projekt nicht verbessern. Bei der Effektivität ist ein soziotechnisches Review daher oft überlegen.

Fazit

Klassische Architektur-Reviews fokussieren häufig auf technische Artefakte. Aber Software entsteht durch Menschen.

Viele Architekturprobleme sind letztlich soziale Probleme. Deshalb lohnt es sich, Architektur als soziotechnisches System zu betrachten. Dadurch dringt man schneller zu den zentralen Herausforderungen vor, weil man sich durch die Expertise der Teams leiten lassen kann, statt ungesteuert das gesamte System im Detail zu bewerten. Gleichzeitig verbessern die Interviews die Kommunikation und führen oft auch zu mehr Vertrauen – eine wichtige Voraussetzung, um zu echter Verbesserung zu gelangen. Es gibt zu soziotechnischen Architektur-Reviews auch eine Episode bei Software-Architektur im Stream und eine Webseite.

Interviews mit offenen Fragen können auch in anderen Kontexten hilfreich sein: Wenn in einem Projekt eine Situation unklar ist, helfen vertrauliche Gespräche mit offenen Fragen oft weiter. Genauso kann man den Ansatz nutzen, um in einem unbekannten Kontext wie einem neuen Projekt die beteiligten Personen besser zu verstehen und mit ihnen eine gemeinsame Basis zu finden. Um solche Gespräche durchzuführen, kann das Cheat Sheet helfen. Regeln können tatsächlich dabei helfen, besser zu kommunizieren – und das Cheat Sheet enthält dazu einige Ideen, die aus den Interviews verschiedener Reviews entstanden sind und sich dabei bewährt haben.

(rme)