Teil 1: Die Architekturmetapher in der Softwareentwicklung hinterfragen!

Warum Architektur nicht zur agilen Softwareentwicklung passt
Keine Kommentare

Die Welt, besonders die der Computer und ihrer Software, wird immer dynamischer und volatiler. Ist unter diesen Bedingungen die Metapher vom Bauen wirklich noch hilfreich? Sollte Softwareentwicklung nicht besser als ein Mannschaftsspiel verstanden und der Softwarearchitekt als Trainer seines Entwicklungsteams gesehen werden?

Ein solcher Ansatz erlaubt einen unkonventionellen Blick auf den Softwareentwicklungsprozess und liefert quasi nebenbei plausible Erklärungen für Probleme, die in der Praxis immer wieder auftauchen. Nicht zuletzt ergeben sich daraus auch neue Lösungsansätze. Der Beitrag stellt einiges ganz bewusst überspitzt dar. Es geht nicht darum, ausgearbeitete Ergebnisse zu präsentieren – durch die ungewohnte Sicht sollen vielmehr die Diskussionen belebt und neue Einsichten provoziert werden.

Die Bau-Metapher

Der Vergleich mit dem Bau eines Gebäudes ist eine der ältesten Analogien für die Softwareentwicklung. Zu der Zeit, in der Programme als Teil des Computers verkauft wurden, war das offensichtlich ein passendes Modell. Mittlerweile hat sich die Welt um uns gewandelt und mit ihr die Rolle der Software. Das Bild vom Bauen, obwohl in Details immer wieder an aktuelle Entwicklungen angepasst, droht die Sicht auf bestimmte Aspekte zu behindern, weil wichtige Voraussetzungen im Laufe der Jahre entfallen sind oder an Bedeutung verloren haben.

Ein grundlegender Aspekt beim Bauen ist Langfristigkeit. Gebaut wird vorrangig für über den Tag hinausreichende Ziele. Damit verknüpft ist die relative Beständigkeit der äußeren Umstände. Genauso wird immer unter der Annahme gebaut, dass sich die Umgebung einschließlich zu nutzender Technologien, Preise und Besitzverhältnissen während des Bauens und auch danach nur in beschränktem Maß ändert. Als dritter Aspekt kommt außerdem hinzu, dass Bauen und Architektur als Erfahrungstätigkeiten durch kleinschrittige Entwicklung, die sich jeweils nur wenig vom Erprobten entfernt, gekennzeichnet sind. Versuche, die Schrittlänge leichtfertig zu vergrößern, haben von der Antike bis heute immer wieder ins – zumindest finanzielle – Desaster geführt.

DevOps Docker Camp

Sie lernen die Konzepte von Docker und bauen Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf.

Softwarearchitektur

Von der Bau-Metapher ist es nur ein kleiner Schritt zur Architektur. Die Gesellschaft für Informatik schreibt in ihrem Informatiklexikon: „Häufig wird die Rolle der Softwarearchitekten mit der Rolle der Gebäudearchitekten verglichen.“ und in Bezug auf Enterprise-Application-Integration weiter: „In derartigen Umgebungen passt die Analogie zur Stadtplanung besser.“

Es lohnt sich, die Begriffe genauer zu hinterfragen. Neben vielen anderen ist es eine wesentliche Aufgabe der Architektur, schon vor der Bauausführung einen möglichst vollständigen Entwurf des angestrebten Produkts (= Bauwerks) anzufertigen. Allein dieses Anliegen ist nur unter der angesprochenen Konstanz der Randbedingungen sinnvoll. Besonders zu erwähnen ist noch, dass diese Konstanz vor allem für die Anforderungen oder die Ziele wichtig ist, die das durch den Architekten zu entwerfende Bauwerk erfüllen soll.

Wenn diese Kriterien ernst genommen werden, kann es Softwarearchitekten im engeren Sinn eigentlich gar nicht geben. Ein Charakteristikum von Software besteht schließlich darin, dass es – abgesehen eventuell von Datenträgern – keine materielle Produktion gibt; stattdessen wäre die vollständige Vorlage des Architekten – streng genommen – bereits das Produkt. Die begrifflichen Schwierigkeiten, die aus der Analogie folgen, spiegeln sich in den vielen verschiedenen Definitionsversuchen wider, die das Software Engineering Institute der Carnegie Mellon University in einer eindrucksvollen Liste zusammengestellt hat. Die Häufigkeit, mit der dort Begriffe wie Komponenten, Schnittstellen und Entwurfsregeln vorkommen, lässt die Analogie zur Stadtplanung als eine besser passende erscheinen. So wird zumindest der Widerspruch zwischen Vorlage und Produkt aus dem Weg geräumt. Zusammengefasst kann man für das am Bauen orientierte Verständnis folgende zwei Charakteristiken nennen:

  • Relative Konstanz der Randbedingungen: Veränderungen können als Störungen interpretiert werden, auf die zu reagieren fast immer nur relativ geringen Aufwand erfordert.
  • Detaillierte Vorlage (Bauplan) als Grundlage der Realisierung: Das Ergebnis unterscheidet sich im Idealfall nur wenig von der Vorlage.

Die natürliche Weise, Projekte unter diesen Vorbedingungen zu realisieren, stellt das Wasserfallmodell dar. Betrachtet man jetzt allerdings die Bedingungen, unter denen heute Software entsteht, so sind diese Prämissen nur noch sehr selten erfüllt. Die relative Konstanz der Randbedingungen gerät dabei gleich von zwei Seiten her unter Druck. Die fachlichen und technischen Anforderungen (z. B. Vernetzung) an die Software nehmen zu. Die Systeme werden immer komplexer, darum dauern Erstellung und Erprobung trotz verbesserter Entwicklungstechnologien tendenziell immer länger. Da die Welt währenddessen nicht stillsteht, vergrößert allein das schon die Varianz der zu berücksichtigen Randbedingungen. Gleichzeitig nimmt die Geschwindigkeit zu, mit der sich das Umfeld verändert. Die Einsicht, dass das Wasserfallmodell und seine Abkömmlinge unter diesen Umständen nicht mehr angemessen sind, hat sich bereits vor Jahren durchgesetzt, doch für die logische Konsequenz, dass man sich auch von der zugrunde liegenden Bau-Metapher lösen sollte, ist das noch nicht der Fall.

Agilität

Einer der bisher erfolgreichsten Ansätze, sich dem Problem zunehmend volatiler Projektumfelder zu stellen, ist das agile Vorgehen. Im Wesentlichen ist das ein Ansatz von unten her, also aus den Details Software zu entwickeln. Am besten verstanden und erprobt sind die agilen Arbeitsweisen für kleinere Aufgaben, die von einzelnen Teams gelöst werden können; es gibt inzwischen aber Vorschläge, diese Methodik auf größere Organisationen zu übertragen. Dabei geht jedoch zwangsläufig ein Teil der ursprünglichen Flexibilität verloren.

Bei allen diesen Versuchen, flexiblere Vorgehensmodelle zu etablieren, zeigt sich eine bemerkenswerte Unsicherheit in Bezug auf die Rolle der Softwarearchitektur. Die Definitionen entfernen sich dabei deutlich von der Funktion der ideellen Vorwegnahme des realen Ergebnisses hin zu rein methodischen Vorgaben:

Es ist offensichtlich, dass die Fähigkeit, auf Veränderungen schnell reagieren zu können, immer wichtiger wird, weil der ständige Wandel zu einem Teil der Entwicklungsprozesse geworden ist. Alle Bemühungen, den Architekturbegriff so auszuweiten oder abzuändern, dass er unter diesen Bedingungen sinnvoll verwendbar bleibt, verdeutlichen nur, dass die Metapher vom Bauen zur Zwangsjacke geworden ist.

Dabei ist Agilität nur der erste Schritt auf den untersten Ebenen, sich von der Vorstellung des Bauens von Software zu entfernen. Benötigt wird eine geänderte, ganzheitlich agile Betrachtung der Prozesse, in denen Software entsteht.

Randbedingungen der Softwareentwicklung

Die Umstände, unter denen heute ein großer Teil der Software entwickelt wird, sind bereits angerissen worden. Die wichtigsten Herausforderungen sind

  • ein komplexes und ständigem Wandel unterworfenes Umfeld, daraus resultierend
  • zunächst relativ vage und sich (bisweilen schnell) wandelnde Zielvorstellungen („Moving Targets“)
  • keine längerfristige Vorhersagbarkeit der äußeren Einflüsse
  • keine langfristige Planbarkeit
  • die Notwendigkeit, Entscheidungen kurzfristig und ohne ausreichende Datenbasis treffen zu müssen
  • die Notwendigkeit, laufend Bewertungen vorzunehmen und zu aktualisieren
  • den entstehenden enormen Kommunikationsaufwand zu beschränken

Der letzte Punkt verdient besondere Beachtung. Ständiger Wandel heißt, dass ständig Abstimmungen erforderlich sind und Informationen über Änderungen weitergegeben werden müssen. Bei größeren Projekten muss der Informationsfluss deshalb bewusst organisiert und kanalisiert werden, um zu verhindern, dass dadurch unzulässig viele Kapazitäten gebunden werden. Bei Scrum erreicht man das beispielsweise durch eine gewissermaßen getaktete Weltsicht, bei der Einflüsse von außen während eines Sprints weitgehend unberücksichtigt bleiben. Anpassungen erfolgen nur in der jeweiligen Initialisierungsphase.

Typisch ist ebenfalls, dass die Komplexität es schwer macht, die Konsequenzen einzelner Modifikationen – unabhängig ob intern oder extern verursacht – nur annähernd vollständig vorauszusehen.

Ausblick

Was gebraucht wird, ist ein Modell, das beschreibt, wie ein unscharf definiertes Ziel unter laufend und scheinbar weitgehend zufällig wechselnden Bedingungen erreicht werden kann. Dieses Modell erarbeiten wir in Teil 2 dieser Artikelserie.

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -