Grundlagen der Softwarearchitektur: Teil 4

Dr. Gernot Starke

This article is also available in English

• Teil 1: Gebäude, Zweck, Ästhetik
• Teil 2: Begriffe
• Teil 3: Aufgaben und Tätigkeiten
• Teil 4: Wer macht was? (dieser Artikel)
• Teil 5: Wie geht es weiter?

Die Antwort lautet (natürlich) mal wieder KDA (kommt drauf an), aber das haben Sie sich vermutlich schon gedacht beziehungsweise aus den letzten Folgen noch in Erinnerung. Es gibt eben in der Softwarearchitektur keine Patentlösungen für alle Fälle, das gilt auch für die Aufteilung der Aufgaben auf Personen.

Aber mal Schritt für Schritt: Welche Optionen gibt es denn überhaupt? Einerseits könnten wir monarchisch diktieren, also die Entscheidungsgewalt (im wahrsten Sinne des Wortes) maximal zentralisieren. Andererseits könnten wir die Architekturaufgaben einfach an das gesamte Entwicklungsteam delegieren - und maximal dezentralisieren. Dazwischen gibt es eine Vielzahl möglicher Varianten, von denen Sie in Abbildung 1 einige Vertreter finden (nach Toth [1] und Hohpe [2])

Anmerkung: Zur Vereinfachung beziehen sich die hier skizzierten Situationen auf Teams überschaubarer Größe, bis max 8–12 Personen. Für größere Teams oder Gruppen aus mehreren Teams müssen zusätzliche oder andere Regeln gelten, auf die ich erst in der kommenden (fünften) Folge dieser Serie eingehen werde.

Abbildung 1 zeigt vier Positionen des Spektrums zwischen komplett zentraler Verantwortung (aka “Monarchie” oder gar “Autokratie”), bis hin zur vollständigen Aufteilung der Aufgaben im Entwicklungsteam, einem rein demokratischen Modell.

Monarchie

Eine einzelne Person entscheidet, und besitzt auch Weisungsbefugnis gegenüber dem Entwicklungsteam. Das Team erhält Anweisungen oder Vorgaben. Die Monarchie kann Feedback unterbinden (absolute Monarchie) oder systematisch einfordern (benevolent dictator, nach Hohpe [2]). Als wesentliche Merkmale der Monarchie finden wir eine einzelne Person, die Architekturentscheidungen trifft, und das Team dann diese vorgegebenen Strukturen und Konzepte lediglich implementiert.

Häufig geht diese Arbeitsweise mit einer organisatorischen Trennung von Entwicklungsteam und Architektur einher: Die Verantwortung für Architekturentscheidungen liegt in einer anderen Abteilung oder Organisation als die Implementierung. Deswegen entwickeln gerade absolute Monarch:innen meist nicht selbst, legen also keine Hand an Sourcecode.

Andererseits gibt es auch Situationen, in denen die benevolent dictators ganz aktiv mit entwickeln, und sich teilweise hervorragend im Sourcecode auskennen. Zahlreiche Beispiele für solche wohlmeinenden Diktaturen stammen aus dem Open-Source Umfeld, so etwa wurde Guido van Rossum der Erfinder der Programmiersprache Python, lange Zeit als der “Benevolent Dictator” der Python-Community bezeichnet.

Diese letztgenannten Fälle unterscheiden sich nur wenig vom weiter unten beschriebenen Modell Architekt:in im Team

Vorteile

Auch wenn eine Monarchie aus der Perspektive agiler Softwareentwicklung sehr old school und wenig attraktiv für ein Entwicklungsteam erscheint, besitzt es dennoch einige immanente Vorteile:

• Die einzelne Person (Architekt:in) liefert konsistente, homogene Entscheidungen aus einem Guss.
• Weiterhin kann die Architekt:in schnell entscheiden, weil zeitaufwendige Abstimmungen entfallen. Beachten Sie dabei: In größeren Teams oder bei größeren Systemen kann dieser mögliche Vorteil leicht wegfallen!
• Eine in Technologie oder Domäne sehr erfahrene Person kann als Monarch:in ein wenig erfahrenes Team gut voranbringen.

Nachteile / Risiken

Die einzelne Person als Entscheider:in bringt natürlich eine Reihe systemischer Nachteile mit sich:

• Sie stellt offensichtlich sowohl hinsichtlich Zeit, Verfügbarkeit als auch Know-how einen Engpass oder Flaschenhals dar.
• Fällt diese Person aus, beispielsweise wegen Krankheit oder Urlaub, bleiben notwendige Entscheidungen liegen.
• In etwas größeren Teams oder bei größeren Systemen kann es vorkommen, dass die einzelne Person mit der Menge notwendiger Entscheidungen massiv überfordert wird (das relativiert den oben genannten möglichen Vorteil der hohen Entscheidungsgeschwindigkeit).
• Fehlt dieser Person wesentliches Know-how oder Erfahrung, werden Entscheidungen inhaltlich suboptimal oder gar schlecht ausfallen. Einem auch nur halbwegs erfahrenen Entwicklungsteam fallen solche inhaltlichen Defizite sofort auf, was die Akzeptanz entsprechender Architekturentscheidungen (und auch der entscheidenden Person) massiv beeinträchtigt.
• Durch das fehlende Feedback in der absoluten Monarchie können schlechte oder falsche Entscheidungen erst sehr spät gefunden werden, etwa in Test oder sogar Produktion.

In welchen Situationen einsetzen?

Aus den genannten Vor- und Nachteilen leite ich einige Situationen ab, in denen eine monarchische Organisation funktionieren könnte. Als wesentliche Voraussetzung sehe ich die passende Qualifikation der für die Architekturrolle vorgesehenen Person, sowohl in technischer wie kommunikativer Hinsicht.

• Offshoring oder Nearshoring: Eine Organisation oder ein Unternehmen vergibt reine Implementierungsaufträge aus Kostengründen an Teams oder Dienstleister im Ausland. Sie möchte die Hoheit über Architekturentscheidungen komplett behalten.
• Bei der Entwicklung eines kleinen oder mittelgroßen Systems besteht hoher Zeitdruck, Entscheidungen müssen schnell getroffen werden.
• Es besteht ein signifikant großes Know-how Gefälle zwischen Architekt:in (sehr erfahren) und Team (wenig erfahren).
• Es handelt sich um eine Standardaufgabe, d.h. wesentliche Architekturentscheidungen können übernommen werden (“der 5. Compiler”). Die Architekt:in hat solche Art Systeme bereits erfolgreich entwickelt und kennt typische Lösungsansätze, Technologien und auch Stolperfallen.

Architekt:in im Team

Das Modell mit einer einzelnen, benannten Person für die Architekturrolle gilt ebenso als klassisches Arbeitsmodell. Auch hier übernimmt eine einzelne Person die wesentlichen Architekturaufgaben, jedoch ist diese integraler Bestandteil des Entwicklungsteams. Gregor Hohpe bezeichnet diesen Modus treffend als Primus inter pares (übersetzt: “Erster unter Gleichen”, siehe [2]), und erklärt es wie folgt:

Architects are embedded into teams where they are just-another-team-member but one who focuses on the system structure and trade-offs, perhaps taking a longer-term view compared to other team members (and using a fancy Latin name).

Gregor Hohpe

Im Unterschied zum monarchischen Modell kann und sollte ein Primus inter pares das Entwicklungsteam befähigen, selbst zu eigenen Entscheidungen zu kommen. Die Architekt:in im Team kann aktiv bei der Entwicklung mitarbeiten, zumindest aber in kritischen Fällen als Coach für Andere fungieren.

Anders als bei den monarchischen Ansätzen hat ein Primus inter pares jedoch keine absolute Entscheidungsgewalt, sondern sollte Entscheidungen begründen und im Konsens mit dem Team treffen. In Zweifelsfällen jedoch darf diese Person durchaus alleine entscheiden.

Insgesamt stellt dieses Arbeitsmodell erhebliche Anforderungen an technische, methodische und kommunikative Fähigkeiten der betreffenden Person.

Vorteile

Eine einzelne Ansprechperson vereinfacht die Interaktion zwischen sonstigen Stakeholdern und dem Entwicklungsteam. Ebenso ist die Verantwortung für Architekturentscheidungen, analog zur Monarchie, ganz klar geregelt. Auch hier wird es konsistente, durchgängige Entscheidungen aus einem Guß geben.

Entwicklungsteams können Feedback geben und bekommen Erklärungen oder direkte Unterstützung in architektonischen Fragen.

Nachteile / Risiken

Immer noch hängen Entscheidungen stark vom Know-how und der Verfügbarkeit einer einzelnen Person ab. Dieser sogenannte Bus-Faktor [3] von 1 stellt in zeitlich, fachlich oder technisch schwierigen Situationen ein erhebliches Risiko dar.

In welchen Situationen einsetzen?

Aufgrund des hohen Kommunikationsaufkommens zwischen Team und Architekt:in sollte das Team eine Größe von 5–8 Personen nicht wesentlich überschreiten. Falls in einem Team ein hoher Coachingbedarf besteht, kann ein(e) Architekt:in im Team diesen abdecken. Als Voraussetzung für dieses Arbeitsmodell ist die Verfügbarkeit einer Person (Architekt:in) mit der Situation entsprechenden Menge an Erfahrung und Know-how, mindestens in der eingesetzten Technologie. Idealerweise kennt der/die Architekt:in auch die Fachdomäne. Sie muss in jedem Fall die Bereitschaft und Fähigkeit zu intensivem Coaching innerhalb des Teams mitbringen.

Setzen Sie dieses Modell auch in Situationen ein, in denen:

• Organisationen stark auf klare Rollenmodelle setzen und/oder
• wenig Erfahrung mit hochgradig autonomen Teams vorliegt.

Meiner Erfahrung nach findet sich dieses Modell oftmals im Bereich embedded-/real-time Systems oder in stark regulierten Bereichen wie Medizin-, Luftfahrt- oder Sicherheitstechnik.

Lassen Sie uns einen Schritt weiter in Richtung dezentrale Arbeitsmodelle gehen, und die Architekturrolle auf mehrere Köpfe verteilen:

Architekturagent:innen

Mehrere Personen teilen die Architekturarbeit untereinander auf. Es kann sein, dass einzelne Personen dabei entweder Themen oder auch Tätigkeiten aufgrund ihres spezifischen Spezialwissens besetzen. Die Bezeichnung “Architekturagenten” stammt von Stefan Toth ([1]).

Der genaue Modus dieser Aufteilung kann sich stark unterscheiden, von Spezialistentum bis hin zu themenfokussierten Gilden (siehe [4]). Ebenfalls kann die Besetzung dieses “Architekturteams” ab-und-zu wechseln, um weitere Personen aus dem Team intensiver zu coachen, auf die Architekturrolle vorzubereiten oder auch um deren spezielles Wissen zum passenden Zeitpunkt einzubringen.

Aus eigener Erfahrung empfehle ich drei Personen für dieses Modell:

• durch die ungerade Zahl finden diese drei bei Entscheidungen auf jeden Fall eine Mehrheit
• drei Personen können schnell miteinander kommunizieren, d.h. sie können bei Bedarf relativ schnell entscheiden

Falls ein solcher Modus für Sie grundsätzlich interessant klingt, empfehle ich Ihnen auch einen Blick auf das sogenannte Spotify Modell mit seinen Tribes, Chapters, Squats und Guildes.

Vorteile

Die Architekturagent:innen diskutieren Entscheidungen zu relevanten Themen im kleinen Kreis untereinander. Damit gibt zu solchen Entscheidungen in jedem Fall erstes Feedback, was einerseits das Risiko von Flüchtigkeitsfehlern erheblich senkt, andererseits die Qualität respektive die inhaltliche Güte (von Entscheidungen) steigert.

Der Rest des Teams hat in diesen Agenten mehrere Ansprechpersonen und Coaches, d.h. bekommt auf Fragen in der Regel schneller Antworten, als bei den Ein-Personen-Modellen.

Schließlich wird Architekturwissen durch dieses Modell schnell und intensiv vergemeinschaftet, d.h. verbreitet sich im Team. Das verringert Abhängigkeiten von Einzelpersonen und steigert den Bus-Faktor.

Alle diese genannten Vorteile des Agent:innen-Modells führen zu hoher Akzeptanz von Architekturentscheidungen und -arbeit im Team. Insbesondere dann, wenn die Agent:innen-Rolle ab-und-zu rotiert, d.h. auch weitere Personen in Architekturarbeit involviert werden.

Nachteile / Risiken

Die Besetzung der Agent:innen verursacht Entscheidungs- und Organisationsaufwand, in der Regel beim Management. Das Etablieren passender Kommunikationsprozesse zwischen den Agents könnte ebenfalls organisatorischen Aufwand mit sich bringen.

Zusätzlich entsteht inhärent Kommunikations- und Abstimmungsaufwand bei den Agent:innen untereinander. Das führt zu einem zeitlichen Overhead gegenüber rein monarchischen Modellen (der aus meiner Sicht durch die höhere inhaltliche Qualität und die verbesserte Akzeptanz mehr als wettgemacht wird).

Zusätzlich droht das Risiko, dass die Besetzung dieser Rolle zu Streitigkeiten im Team führt, weil eben nur einige aber nicht alle Personen mitentscheiden dürfen.

In welchen Situationen einsetzen?

Sobald das Know-How oder die Erfahrung einzelner Personen nicht mehr ausreicht, oder die Aufgaben eines Projektes schlichtweg zu groß oder schwierig sind, bietet sich das dezentrale Agent:innen-Modell an.

Um Architekturfähigkeiten und -Know-How gezielt im Team zu etablieren oder zu verbreiten, ist dieses Modell ebenfalls hervorragend geeignet.

Der Ansatz rollierender Beteiligter hilft dabei, auch Teams mit hoher Volatilität zu konsistenter Architekturarbeit zu bewegen. Unangenehme Aufgaben können die Agent:innen untereinander aufteilen, getreu dem Motto “geteiltes Leid ist halbes Leid”.

Persönliche Erfahrung

Ich habe mit dem Modell von 2–3 Architekt:innen im Team hervorragend positive Erfahrung gesammelt. Auch in zeitlich oder inhaltlich kritischen Situationen konnten wir uns als Agent:innen gegenseitig unterstützen und zu angemessenen Entscheidungen kommen.

Von daher ist dies meine persönliche Empfehlung, falls keine harten Randbedingungen dagegen sprechen.

Demokratie

Wenn wir ohnehin die Architekturarbeit aufteilen, können wir sie doch gleich auf das gesamte Team verteilen: Das gesamte Team stimmt sich zu allen Architekturfragen und -entscheidungen eigenständig und gemeinschaftlich ab.

Natürlich gibt es auch hierbei viele Stellschrauben, etwa:

• müssen alle Entscheidungen gemeinsam getroffen werden, oder darf das Team manche Entscheidungen an Untergruppen oder Einzelne delegieren?
• braucht es Einstimmigkeit, oder genügt eine einfache Mehrheit für Entscheidungen?
• gibt es Typen von Entscheidungen, die etwa 75% Mehrheit benötigen?

Vorteile

Ein demokratisches Modell beteiligt sämtliche Personen aus dem Entwicklungsteam an Entscheidungen, was typischerweise zu hoher Akzeptanz führt. Ebenfalls positiv wirkt sich aus, dass die gesammelte Erfahrung aller Personen in solche Entscheidungen einfließen kann.

Nachteile / Risiken

Die normale Demokratie ist von politischem Kalkül geprägt, sowie von Koalitionen und Kompromissentscheidungen. In einem demokratischen Arbeitsmodell bei Softwareentwicklung droht das Risiko von Junktim-Entscheidungen (“Du bekommst bei Thema A Deinen Willen, wenn Du bei Thema B für meinen Vorschlag stimmst”). Es kann sehr leicht passieren, dass die Konsistenz von Entscheidungen dabei verloren geht, weil wechselnde Mehrheiten im Team eben zu wechselnden Präferenzen oder Prioritäten führen können.

Weiterhin können Entscheidungen lange dauern, weil hoher Abstimmungsaufwand im Team anfällt. Eine Abstimmung in einem 8–10 Personen Team dauert signifikant (!!) länger als eine mit nur 2 oder drei Personen.

Diese Faktoren führen in der Praxis meiner Erfahrung nach zur Verringerung der Akzeptanz rein demokratischer Modelle, Entwicklungsteams kommen von ganz alleine zu dem Modell der Agent:innen zurück.

In welchen Situationen einsetzen?

In kleinen Teams (max 7–8 Personen) mit sehr homogenem Know-how sowie für Projekte mit sehr geringem Zeitdruck (Frage am Rande: Gibt es so was - Projekte ohne Zeitdruck?) kann ein komplett dezentrales Modell gut funktionieren.

Wenn ein Team gut aufeinander eingeschwungen ist, gegenseitige Akzeptanz und gute Kommunikationskultur vorherrscht, ist dieser Ansatz ebenfalls passend.

Fazit: Schon wieder kommt es darauf an

Schon wieder kommt es darauf an: Es gibt kein eindeutig besseres Arbeitsmodell für Softwarearchitektur. Die vielseitigen Anforderungen und Randbedingungen von Softwaresystemen können wir nur bestmöglich mit den jeweils dazu passenden Arbeitsmodellen erfüllen. Sogar die in der agilen Welt oftmals kritisierten zentralistischen Modelle haben auch in der agilen Welt ihre Existenzberechtigung, insbesondere unter organisatorischen Randbedingungen wie Outsourcing oder Offshoring.

Es spricht vieles dafür, das konkrete Arbeitsmodell im Team explizit zu diskutieren. Stellen Sie dem Team die Frage “Wie sollen wir die nächste Zeit arbeiten”?

Ein Entwicklungsteam darf das Arbeitsmodell auch situativ anpassen, also etwa im Weihnachtsgeschäft oder der Vorbereitung auf einen kritischen Termin vom Agenten- oder demokratischen Modell zu einem Primus-inter-Pares wechseln.

Bleiben Sie auch in dieser Hinsicht offen.

Danksagung

Danke an Martina “m” und Martin Weck für gründliche Reviews!

Quellen