Architecture without Architects

Die Begriffe „Architektur“ und „Architekt“ hat die Softwareentwicklung aus der Baubranche adoptiert. Eine klug gewählte Softwarearchitektur, die sich auf bewährte Strukturmuster stützt und dadurch Flexibilität und Wartbarkeit bietet, ist unbestreitbar Teil eines erfolgreichen Softwareprojektes. Hier ist die Analogie des Begriffs „Architektur“ zwischen Bau- und Softwareindustrie richtig. Aber ist die begriffliche Gleichsetzung darüber hinaus nicht eher irreführend? Welche Rolle sollte ein Softwarearchitekt überhaupt innerhalb eines Softwareprojekts spielen? Ist der Softwarearchitekt vielleicht sogar überflüssig?

Genau darum ging es beim ThoughtWorks Talk mit Martin Fowler, Verfasser des agilen Manifests sowie bekannter Bücher wie „Analysis Patterns“ (1997), „Refactor“ (1999) und „Patterns of Enterprise Application Architecture“ (2003) und Erik Dörnenburg (Head of Technology, ThoughtWorks Europe) am 14. Juli in München.

Gebäudeplanung versus Softwareplanung

Ein Architekt am Bau zeichnet detaillierte Pläne der Gebäude, die danach gebaut werden, ohne dass er dabei selbst Hand an die Kelle legt. Auch der Softwarearchitekt plant, setzt aber selten die eigenen Entwürfe in Code um.

Neben dieser Gemeinsamkeit gibt es aber auch deutliche Unterschiede:

Spannend wird es, wenn man den Detailierungsgrad von Bauplänen dem der Architekturpläne von Softwarearchitekturen gegenüberstellt. Während Softwarearchitekturen meistens mit Mitteln von Powerpoint skizziert werden, findet man bei Bauplänen ausschließlich Millimeterpapier und syntaxartige Symbole vor, alles inklusive Haftungsansprüchen gegenüber fehlerhaften Plänen.

Das Erstellen von Bauplänen ist daher eher mit dem Verfassen von Programmcode zu vergleichen (bei dem danach auch der „Build“ folgt). Damit wäre die Rolle des Gebäude-Architekten eher mit der Rolle des Programmierers zu vergleichen.

Noch schwieriger wird der Vergleich nach der Bauphase: Während ein Gebäude danach im Regelfall weitgehend unverändert bleibt und der Architekt sich neuen Projekten zuwendet fängt bei Software die Wartungsphase an und die Anpassungen werden meistens noch von den ursprünglichen Entwicklern mitbegleitet.

Die Analogie zur Stadtentwicklung

Ein Softwareprojekt ähnelt daher womöglich weniger dem Gebäudebau, sondern eher dem Prozess einer Stadtentwicklung.

Stadtentwicklungen und Wartungsphasen von Software zeigen auffällige Parallelen, wenn man betrachtet, wie Städte in der Vergangenheit mit viel Vorausplanung angelegt wurden, dann aber durch z.B. massiven Zuzug oder neue Technologien (Kanalisation, Straßenverkehr oder Beton) vor unvorhersehbare Anforderungen gestellt werden, die es zu integrieren galt.

Zum Vergleich ein Beispiel aus dem Softwarebereich: Bei Projekten mit Microservices geben Architekten häufig nur das Übertragungsprotokoll und das Dokumentationstemplate für die Services vor und lassen das Projekt dann alleine. Die Funktionalität der Services wird dann durch die Entwickler ausgehandelt und führt schnell zu einem Zoo an verschiedenen Servicetypen, die die Struktur der Servicearchitektur überwuchern, wenn nicht nachgebessert wird.

Die Architektur von Software wird nach Fowler und Dörnenburg eher durch evolutionäre Effekte strukturiert als durch die Artefakte eines Architekten. Softwarearchitekten können ihre Projektrolle nicht aus der Analogie zur Baubranche legitimieren. Sie sind verdächtig, überflüssig zu sein und durch ihre abstrakten Softwarelösungen womöglich sogar Schaden anzurichten. 

Fowler und Dörnenburg stellen folgende Axiome auf:
1. „An Architect’s value is inversely proportional to the number of decisions he makes and the number of diagrams he draws.”
2. Most of the things an architect has traditionally done should be done by developers, by tools or not at all.”

Die wahre Rolle des Softwarearchitekten

Die Kritik an Elfenbeinturm-Architekten ist nicht neu aber immer wieder unterhaltsam. Die Analogie von Softwareprojekten zur Stadtentwicklung und den „Evolutionsdruck“ auf Softwareprojekte könnte man auch noch weiterführen. Aber welche Rolle soll denn nun der Softwarearchitekt noch spielen?

Nach Fowler und Dörnenburg sollten dem Softwarearchitekten vor allem drei wichtige Aufgaben zufallen:

  1. Häufig fehlt dem einzelnen Entwickler die komplette Übersicht über die Projektstruktur und Anforderungen eines Softwareprojekts. Als „Communication-Hub“ der Entwicklerteams verhindert der Softwarearchitekt das Auseinanderlaufen des Projekts in Insellösungen bei der die Teams lediglich Teilaspekte der Anforderungen berücksichtigen und am Bedarf das Kunden vorbei entwickeln.
  2. Fördern und Fordern: Der Softwarearchitekt soll die Entwickler dabei anleiten sich zu verbessern. Er hilft ihnen mit technischem Expertenwissen sich in neue Technologien einzuarbeiten und sich nicht in Sackgassen zu manövrieren.
  3. Bereitstellung von Code: Vor allem durch das Bereitstellen von Beispielcode und einer Style-Richtlinie kann der Softwarearchitekt wertvolle Arbeit für die Homogenität des Implementierungsstils liefern. Außerdem können Architekten bei Ressourcen-Engpässen an Manpower die Teams konstruktiv unterstützen.

Der Softwarearchitekt wird in dieser Sicht deutlich stärker in den gesamten Entwicklungsprozess einer Software integriert, statt nur in der ersten, der Planungsphase eine Rolle zu spielen. 

Weiterführende Informationen: http://martinfowler.com/