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.