Die berühmte „Was-wäre-wenn…?“-Frage – Der Schlüssel zur soliden Software-Architektur

Wie ich bereits in einem früheren Artike (oder auch hier) erwähnt habe, beginnen die wichtigsten Fragen in der Software-Architektur mit „Was wäre, wenn…?“. Wird eine dieser Fragen übergangen oder vorschnell beantwortet, ohne gründlich darüber nachzudenken, darf man sich später nicht wundern, wenn bereits kleine Änderungen – etwa ein neues Feature oder eine Kundenanpassung – mühsame und kostspielige Anpassungen an unzähligen Stellen im Code nach sich ziehen.

Plötzlich müssen Methoden geändert, Signaturen angepasst und Rückgabewerte modifiziert werden. Ganze Datentypen, inklusive ihrer Eigenschaften, Methoden und Events, müssen umgestaltet werden. Dadurch verlieren bestehende Unit-Tests ihre Gültigkeit, müssen umgeschrieben oder gar entfernt werden. Noch schlimmer: Neue Unit-Tests passen oft nicht mehr nahtlos in das ursprünglich durchdachte Konzept.

Das TDD-Paradigma, kann hier paradoxerweise zu Problemen führen. Denn wenn die Architektur bereits auf wackligen Beinen steht, entstehen „Risse“ nicht nur im Code, sondern auch in der Benutzerführung – spürbar durch inkonsistente Steuerung oder unerwartetes Verhalten der Oberfläche bei Desktop-Anwendungen und Mobile-Apps.


Flexibilität: Was sich immer ändern wird

Manche Dinge ändern sich zwangsläufig – und sollten daher von vornherein leicht konfigurierbar oder erweiterbar sein:

  • Theme, Look & Feel – weil sich Design-Standards weiterentwickeln.
  • Sprachunterstützung – denn neue Märkte bedeuten neue Anforderungen.
  • Datenexport – weil Kunden irgendwann ein anderes Format benötigen.
  • Diagramme und Reports – da sich Analyse- und Visualisierungsanforderungen ändern.
  • Kommunikation mit Schnittstellen und Protokollen – weil neue Technologien und Standards entstehen.

Unwahrscheinliche Änderungen? Vielleicht doch nicht!

Dann gibt es Dinge, bei denen man glaubt, sie würden nie oder nur in den seltensten Fällen geändert werden – und doch geschieht es irgendwann:

  • Der Kunde will Produktionsdaten in einer exotischen Datenbank oder einem speziellen Dateiformat speichern.
  • Eine „unbedeutende“ Zahl soll plötzlich auf dem Bildschirm angezeigt oder eine neue Konfigurationsmöglichkeit für die Nachtschicht integriert werden.
  • Eine günstigere SPS oder Industrie-Kamera eines unbekannten Herstellers muss eingebunden werden – leider nicht ganz standardkonform.

Ob, wann und wie solche Änderungen kommen, ist nur eine Frage der Zeit.


Architektur ist wie Schach – erst denken, dann ziehen!

Ein guter Software-Architekt verhält sich wie ein professioneller Schachspieler: Er nimmt sich Zeit für das Vorausdenken, prüft verschiedene Szenarien und fragt sich „Was wäre, wenn…?“, bevor er zur Tastatur greift.

Denn grobe Architekturfehler verhalten sich wie unbedachte Züge im Schach: Ein frühzeitiger Fehlgriff kann zum Schachmatt führen – oder die gesamte Strategie unnötig kompliziert und mühselig machen. Einmal falsch platziert, steht die Figur im Weg und macht jede weitere Planung schwieriger.

Besser also, man nimmt sich die Zeit für eine durchdachte Architektur – bevor man sich später durch einen Flickenteppich aus Workarounds kämpft.

Klaus und seine magische Kiste: Warum Monolithen nicht die Antwort sind

Neulich erzählte mir mein Beifahrer von einem faszinierenden Geschäftspartner in der Mechatronik und Automatisierung. Dieser war seit Jahren in der Branche tätig und frustriert über die ständigen Anpassungen in komplexen Systemen. Jede kleine Änderung führte dazu, dass Kollegen monatelang das gesamte System umstellen mussten. Ein neuer SPS-Typ, der keinen GOTO-Befehl unterstützte? Problem. Ein spezieller Sensor, der nur RS-232, aber kein CAN konnte? Noch ein Problem. Also beschloss unser Held, das Problem ein für alle Mal zu lösen, indem er eine programmierbare „magische Kiste“ baute – ein Gerät mit allen möglichen Schnittstellen, das angeblich jedes Kompatibilitätsproblem beheben sollte. Ohne Code. Klingt toll, oder? Nun ja…

Als ich diese Geschichte hörte, musste ich schmunzeln. Ich unterbrach meinen Beifahrer und erklärte ihm, warum ich skeptisch war – anhand der berüchtigten All-in-One-Stereoanlagen aus den 1980er Jahren. Diese Geräte waren damals der letzte Schrei und versprachen alles in einem: CD-Player, Kassettendeck, Verstärker, Radio – und oft sogar einen Schallplattenspieler. Doch sie waren Monolithen, und das brachte erhebliche Nachteile mit sich:

  1. Monolithen und Modularität: Wenn das eingebaute Netzteil oder der Verstärker kaputtging, funktionierte gar nichts mehr. Weder der CD-Player noch die Kassettendecks – alles war tot.
  2. Bezahlte Überflüssigkeit: Selbst wenn man nur CDs abspielen wollte, zahlte man für Funktionen, die man nicht brauchte – wie ein zweites Kassettendeck oder den eingebauten Plattenspieler.
  3. Platzfresser: Diese Geräte waren riesig und belegten mehr Raum als nötig.
  4. Eingeschränkte Kompatibilität: Lautsprecher konnten manchmal ersetzt werden, aber nur, wenn sie über standardisierte Cinch-Buchsen angeschlossen waren. Wenn nicht, Pech gehabt.
  5. Qualitätskompromisse: Audiophile legten sich oft zwei Systeme zu, weil eines bessere Kassettenwiedergabe bot, während das andere bei CDs brillierte.

Und das alles in einer Ära ohne EU-Gewährleistung! Manche Hersteller boten stolz ein halbes Jahr Garantie, andere gerade mal zwei Monate.

Die Wende zur Modularität

Ende der 80er und Anfang der 90er lernten die Hersteller aus ihren Fehlern. Sie zerlegten ihre Monolithen in einzelne Module. Verbraucher konnten nun:

  1. Nur die Module kaufen, die sie tatsächlich benötigten.
  2. Komponenten verschiedener Hersteller kombinieren: ein Kassettendeck von Marke X, ein CD-Player von Marke Y und ein Verstärker von Marke Z – ideal, um die 1000-Gigawatt-Boxen fürs nächste Erdbeben mit Saft zu versorgen.

Die Lektion für die Software

Die Geschichte der Stereoanlagen zeigt, warum Modularität wichtig ist – eine Lektion, die auch in der Softwareentwicklung gilt. Die Frustration des Automatisierungs-Mechatronikers, der nach jeder kleinen Änderung das gesamte System anpassen musste, deutet auf ein grundlegendes Problem hin: Ad-hoc-Programmierung ohne durchdachte Software-System-Architektur.

Ein erfahrener Softwareentwickler (bzw. SW-Architekt) hätte sich sofort gefragt:

  1. Was, wenn Hersteller U nicht mehr existiert?
  2. Was, wenn Hersteller V das Produkt nicht mehr anbietet?
  3. Was, wenn Hersteller W die Lizenzbedingungen ändert?
  4. Was, wenn Hersteller X seine Treiber oder Schnittstellen ändert?
  5. Was, wenn Hersteller Y nur noch neue Modelle ohne vollständige Abwärtskompatibilität verkauft?
  6. Was, wenn Standard Z obsolet wird?

Die Liste ließe sich endlos fortsetzen. Ohne diese „Was-wäre-wenn„-Fragen läuft man Gefahr, eine digitale eierlegende Wollmilchsau zu bauen – eine magische Kiste, die zwar beeindruckend klingt, in der Praxis aber niemand will.

Niemand möchte von einem einzigen Hersteller abhängig sein, oder von einem einzigen Softwaresystem oder Produktmodell usw.

Niemand möchte mehr für Schnittstellen und wunderbare Features und Möglichkeiten bezahlen, die zwar mehr Raum und Speicher belegen und komplexer sind, diese aber nicht benötigt.

Der Unterschied zwischen Coder und Architekt

Hier kommt die entscheidende Lektion: Code zu schreiben ist nicht dasselbe wie Softwarearchitektur. Wer die Konzepte von Modularität, Komplexität und Abhängigkeiten nicht versteht, investiert vielleicht Jahre in einen Monolithen, der letztlich unbrauchbar ist.

Also, wenn Ihnen das nächste Mal jemand eine magische All-in-One-Lösung verspricht, denken Sie an die Stereoanlagen der 80er – und seien Sie skeptisch. Modularität mag weniger glamourös klingen, aber sie ist der Schlüssel zu langlebigen, flexiblen und wartbaren Systemen. Und das gilt für Hardware genauso wie für Software.

Gewidmet an P.M. (der Beifahrer)
Im nächsten Artikel erkläre ich dir, wie manche mit Buzz-Words wie „Low Code“ und „No Code“ viel Geld für das Blaue vom Himmel und sonstige Versprechungen (Blabla) verlangen und reich werden, während ihre Kunden doppelt und dreifach draufzahlen.