Es gibt viele unterschiedliche Definitionen von Softwarearchitektur. Statt alle aufzulisten und zu bewerten, möchte ich hier meine eigene vorstellen:
„Eine gute Softwarearchitektur strukturiert ein System in Teile mit klaren Aufgaben und bewusst gestalteten Abhängigkeiten, die zusammenarbeiten, um die Anforderungen an das System zu erfüllen.“
Warum ist das wichtig?
Je größer ein Softwaresystem wird, desto schwieriger wird es, den Überblick zu behalten. Eine verständliche Struktur hilft dabei, die einzelnen Teile zu verstehen und gezielt weiterzuentwickeln.
Besonders wichtig sind die Abhängigkeiten zwischen diesen Teilen. Denn wenn eine kleine Änderung an einer Stelle Anpassungen an vielen anderen Stellen notwendig macht, werden selbst einfache Erweiterungen schnell teuer und riskant.
Dabei spielt auch die Wiederverwendung eine Rolle. Es wäre beispielsweise ungünstig, dieselbe Berechnung an zehn verschiedenen Stellen unterschiedlich zu implementieren und bei jeder Änderung zehnmal anpassen zu müssen. Andererseits kann zu viel Wiederverwendung unerwünschte Abhängigkeiten schaffen.
Ähnlich wie bei einem Unternehmen stellt sich deshalb die Frage: Wer übernimmt welche Aufgaben, wer arbeitet mit wem zusammen und wo liegen die Verantwortlichkeiten?
Eine gute Softwarearchitektur findet darauf passende Antworten.
Entscheidend sind dabei die Anforderungen an das System. Es muss nicht nur die gewünschten Funktionen bereitstellen, sondern beispielsweise auch zuverlässig, sicher, performant und leicht änderbar sein.
Allerdings lassen sich nicht alle Ziele gleichermaßen optimieren. Mehr Flexibilität kann beispielsweise zusätzliche Komplexität verursachen. Deshalb besteht eine gute Softwarearchitektur immer aus bewussten Kompromissen.
Die beste Architektur ist also nicht die technisch ausgefeilteste, sondern diejenige, die zu den Anforderungen, den wirtschaftlichen Zielen und den verfügbaren Ressourcen passt.
Vielleicht kennen Sie das aus Ihrem Unternehmen:
Eine scheinbar kleine Änderung an Ihrer Software dauert plötzlich Wochen statt Tagen. Niemand kann zuverlässig abschätzen, welche anderen Funktionen davon betroffen sein könnten. Selbst erfahrene Entwickler müssen lange suchen, bevor sie verstehen, wo etwas geändert werden muss.
Hinter solchen Problemen kann eine ungünstige Softwarearchitektur stecken.
Ein besonders ausgeprägtes Beispiel ist der sogenannte „Big Ball of Mud“: ein System, dessen Struktur kaum noch erkennbar ist und in dem zahlreiche Teile unübersichtlich voneinander abhängen.
Das hat Folgen: Änderungen verursachen unerwartete Nebeneffekte, Fehler treten an scheinbar unbeteiligten Stellen auf und neue Funktionen lassen sich nur mit immer aufwendigeren Umwegen einbauen.
Mit jeder weiteren Änderung kann sich diese Situation verschlimmern.
Das kostet Zeit und Geld, erhöht Risiken und schränkt die Fähigkeit Ihres Unternehmens ein, auf neue Anforderungen zu reagieren.
Eine gute Softwarearchitektur zeichnet sich dagegen durch eine nachvollziehbare Struktur, klare Verantwortlichkeiten und gezielt begrenzte Abhängigkeiten aus.
Eine bessere Softwarearchitektur ist kein Selbstzweck. Sie soll Ihrem Unternehmen konkrete Vorteile bringen:
Entscheidend ist dabei, dass nicht jede Verbesserung einen großen Umbau erfordert. Häufig lassen sich bereits durch kleine, gezielte Veränderungen erhebliche Schwierigkeiten beseitigen.
Welche Verbesserungen sinnvoll sind, hängt davon ab, wo die größten Probleme liegen und welcher Nutzen sich mit vertretbarem Aufwand erzielen lässt.
Die Definition von Softwarearchitektur weiter oben nennt bereits vier Ansatzpunkte, an denen sich ein bestehendes System untersuchen und verbessern lässt:
Die Struktur lässt sich verbessern, indem beispielsweise große, unhandliche Teile in kleinere zerlegt oder Aufgaben und Verantwortlichkeiten klarer verteilt werden. Dadurch wird das System verständlicher und lässt sich leichter ändern.
Die Abhängigkeiten lassen sich gezielt reduzieren oder anders gestalten, sodass Änderungen an einem Teil möglichst wenige andere Teile betreffen. Das verringert den Änderungsaufwand und das Risiko unerwarteter Fehler.
Die Zusammenarbeit lässt sich verbessern, indem beispielsweise die Kommunikation zwischen den Teilen vereinfacht, Schnittstellen klarer definiert oder unnötige Zwischenschritte beseitigt werden. Dadurch können Abläufe verständlicher, zuverlässiger und effizienter werden.
Die Anforderungen können überprüft und präzisiert werden. Denn manchmal entstehen Probleme nicht durch eine schlechte technische Umsetzung, sondern durch unklare, widersprüchliche oder inzwischen veränderte Anforderungen. Erst wenn klar ist, was das System leisten soll, lässt sich beurteilen, welche Architektur dafür geeignet ist.
Allerdings ist nicht jede technisch mögliche Verbesserung auch wirtschaftlich sinnvoll. Deshalb sollten zunächst die größten Probleme und ihre Ursachen identifiziert werden. Anschließend lassen sich Verbesserungen nach Nutzen, Aufwand und Risiko priorisieren und Schritt für Schritt umsetzen.
Das Ziel ist nicht, das gesamte System neu zu bauen, sondern es mit möglichst überschaubaren Änderungen wieder leichter verständlich, zuverlässiger und besser änderbar zu machen.
Eine gute Softwarearchitektur allein reicht nicht aus, um ein erfolgreiches Softwaresystem zu entwickeln und weiterzuentwickeln. Ebenso wichtig sind klare Anforderungen und geeignete Tests.
Anforderungen beschreiben, was das System leisten muss und welche Eigenschaften es besitzen soll. Sie bilden damit eine wichtige Grundlage für Architekturentscheidungen und die Bewertung des Systems.
Tests helfen dabei, zu überprüfen, ob das System die Anforderungen erfüllt und ob Änderungen unerwünschte Nebenwirkungen verursachen. Je früher Fehler erkannt werden, desto geringer ist häufig der Aufwand, sie zu beheben.
Anforderungen, Softwarearchitektur und Tests ergänzen sich damit gegenseitig und tragen gemeinsam zur Qualität und langfristigen Änderbarkeit eines Systems bei.
Mehr darüber erfahren Sie in meinen Artikeln:
