Wenn Komplexität wächst, entscheidet Struktur über Qualität
Fangen wir mit einem Beispiel aus dem Alltag an: In meiner Kindheit und Jugend habe ich viel mit LEGO‑Bausteinen gespielt. Der Clou: genormte Schnittstellen machen Komplexität beherrschbar. Aus wenigen Standardsteinen lassen sich erstaunlich komplexe Modelle bauen – zum Beispiel der Millennium Falcon aus Star Wars. Und mit denselben Bauteilen entstehen genauso gut andere Strukturen: Man erweitert, repariert oder passt an, ohne alles neu zu bauen – mal auf Stein‑Ebene, mal mit fertigen Baugruppen. Mit etwas Kreativität wird neben dem Falcon und einigen anderen Sets schnell eine kleine Flotte aus X‑Wing und TIE‑Fightern – und plötzlich sind nicht mehr die einzelnen Klemmbausteine die wichtigsten Elemente, sondern die zusammengesetzten Schiffe.
Genau dieses Prinzip übertragen wir auf Software: Wir schneiden Funktionen in klar abgegrenzte Module mit stabilen Schnittstellen. So bleiben Änderungen dort, wo sie hingehören – im jeweiligen Modul. Tests werden präziser (z. B. als Regression gegen die Schnittstellenbeschreibung), und Veröffentlichungen neuer Versionen / Updates werden berechenbarer, weil weniger unbeabsichtigte Seiteneffekte auftreten.
Im LEGO-Bild heißt das: Ich stelle die Schiffe um und baue eine neue Szene – ohne dass sich an den Schiffen selbst oder ihren Eigenschaften etwas ändern muss.
Übertragen auf unsere Steuerungs- und Entscheidungsunterstützung: Wenn wir z. B. an einem Monitoring-Modul arbeiten (etwa „RTC‑Monitor“, der Datenströme, Dienste und Systemkomponenten überwacht), betrifft das primär Beobachtung und Alarmierung. Die eigentliche Steuerlogik bleibt unverändert, solange die definierten Schnittstellen eingehalten werden.
Die Geschichte dahinter: Von „alles hängt an allem“ zu klaren Bausteinen
Softwareentwicklung hat in den vergangenen Jahrzehnten diverse Revolutionen und Evolutionen durchlaufen: von Maschinensprache zu Hochsprachen, von Großrechnern zum Heim‑PC und weiter zu Smartwatches, VR und AR. Und auch die Softwarearchitektur hat dazugelernt: Weg von „alles hängt an allem“ hin zu klareren Bausteinen. Dazu später mehr.
Auch die itwh‑Software hat eine lange, ereignisreiche Historie. Eine der Gründungsideen des itwh war, die hydrodynamische Kanalnetzberechnung von Großrechnern auf PCs zu bringen – HYSTEM‑EXTRAN wurde geboren. Seitdem haben wir viele Produktzyklen und Technologiewechsel erlebt: von FORTRAN auf Großrechnern über Stationen wie C++ (mit den ersten echten Benutzeroberflächen) bis hin zu modernem .NET 10. Parallel hat sich auch der innere Aufbau weiterentwickelt.
Das ist genau der Punkt, an dem Modularität praktisch wird: Wir können neue Funktionen in klar abgegrenzten Bausteinen entwickeln, ohne den bewährten Kern zu destabilisieren. So ist HYSTEM‑EXTRAN Online – unser digitaler Kanalnetz‑Zwilling – eines der Module aus dem <CAMPUS>‑Baukasten für Steuerungs‑ und Entscheidungsunterstützungssysteme. Die technologische Grundlage der klassischen Desktop‑Kanalnetzsimulation wird mit wenigen Anpassungen zu einem integralen Bestandteil einer anderen Produktgruppe.
Was dadurch messbar besser wird
In der Praxis sehen wir das vor allem an der Größe von Änderungen: Neue Funktionen oder Bugfixes betreffen häufig nur einen Baustein und seine Schnittstellen – statt quer durch das gesamte System zu gehen. Dadurch wird auch die Fehlersuche zielgerichteter: Probleme lassen sich schneller auf ein einzelnes Modul eingrenzen. Der Suchkorridor wird dadurch deutlich kleiner und Reaktionen werden planbarer – gerade in einem Umfeld mit hohen Anforderungen an Stabilität und Sicherheit.
Stabilität profitiert zusätzlich von der besseren Testbarkeit: Neben Unit-Tests lassen sich Module isoliert gegen ihre Schnittstellen testen (Komponententests), ohne ein komplettes Gesamtszenario aufzubauen. Für das Zusammenspiel bleiben große Integrationstests weiterhin wichtig – aber sie sind nicht mehr der erste und einzige Prüfpunkt.
Ein weiterer positiver Effekt: Paralleles Arbeiten wird einfacher. Wenn Schnittstellen klar sind, können Teams an unterschiedlichen Modulen weiterentwickeln, mit weniger Koordinationsaufwand und ohne ständig aufeinander warten zu müssen.
Blick in unsere Steuerungsmodule: Warum Modularität dort besonders zählt
Das ist besonders in unserer Steuerungsfamilie relevant: In unserem Baukastensystem gibt es inzwischen rund 20 Module, die sich je nach Anwendungsfall kombinieren lassen. Damit das in Angebot, Betrieb und Abrechnung trotzdem übersichtlich bleibt, bündeln wir häufig genutzte Kombinationen als Pakete.
Ein Beispiel ist das Basispaket: Es enthält die Basisfunktionen für Überwachung und Datenaufzeichnung – und als „Rückgrat“ eine Nachrichtenzentrale auf Basis der Open-Source-Software RabbitMQ (inklusive Erlang-Laufzeit, die „Nachrichtenzentrale“, über die alle unsere Module miteinander sprechen). Dieses Basispaket steckt in allen Gesamtsystemen, egal ob es am Ende um Steuerung, Entscheidungsunterstützung, Visualisierung oder Datenmanagement geht.
Darauf aufbauend gibt es die passenden Pakete für die jeweiligen Anwendungsfälle. Das vereinfacht unsere Planung sowie Entwicklungs- und Testumgebungen (gleiche Basis, klare Erweiterungen) – und es hilft Kunden, Kosten zielgerichtet einzusetzen: Gebucht wird nur, was für den konkreten Einsatz tatsächlich gebraucht wird.
Auch für spätere Anwendungsfälle bleibt das System flexibel: Startet ein Kunde zunächst mit Monitoring, Datenaufzeichnung und „einfacher Steuerung“, lässt sich das Setup später gezielt erweitern – zum Beispiel um ein Paket zur Radardaten‑Prozessierung (u. a. mit unserem Modul „NVIS‑Server“), um radarbasierte Niederschlagsdaten nutzbar zu machen. Wichtig dabei: Die Erweiterung ergänzt das System, ohne den bewährten Kern umzuwerfen. So bleibt das Grundsystem stabil, während neue Datenquellen/Logiken schrittweise dazukommen.
Warum das auch Security einfacher macht (Teaser)
Auch im Hinblick auf IT‑Sicherheit, gerade auch im Umfeld der Echtzeitsteuerung ein zentrales Thema, bringt dieser Architekturansatz klare Vorteile. Um den Rahmen dieses Beitrags nicht zu sprengen, skizziere ich hier nur einen Aspekt; vertiefende Security-Themen greifen wir in separaten Beiträgen auf.
Ein Sicherheitsprinzip, das sich durch Modularität besonders gut umsetzen lässt, ist die Segregation of Duties (SoD), auf Deutsch „Funktionstrennung“: Durch getrennte Module (und getrennte Konfigurationsbereiche) können Verantwortlichkeiten sauber abgegrenzt werden. So dürfen z. B. nur Ingenieurinnen und Ingenieure mit Steuerungserfahrung die Regelbasis unseres Moduls „CONTROL“ anpassen, während Änderungen am Monitoring (z. B. im „RTC‑Monitor“) auf eine IT‑affine Rolle beschränkt sind. Technisch lässt sich das über ein Rollen- und Rechtekonzept bis hin zu konkreten Kontrollen wie getrennten Konfigurationspfaden und passenden Datei-/Verzeichnisrechten absichern.
Ausblick: Architektur & Craftsmanship – was im Hintergrund dafür sorgt
Modulare Architekturen bringen viele Vorteile. Sie erhöhen aber auch die Anforderungen an konsequente Umsetzung. Gerade bei uns heißt das: Neben umfangreichem Domänenwissen braucht es viel Sorgfalt in Konzeption, Schnittstellen und Pflege der Module.
Genau hier kommt Software Craftsmanship ins Spiel: Nicht als „akademische Kür“, sondern als professionelles Handwerk. Im LEGO-Bild: Es reicht nicht, viele genormte Steine zu haben – du brauchst auch eine saubere Sortierung, klare Bauanleitungen und Qualitätskontrollen, damit aus Bausteinen ein stabiles Modell wird. In Software sind das u. a. verständlicher Code, sinnvolle Tests, Reviews, Refactoring und ein verlässlicher Build-/Release-Prozess.
Auch in Zeiten von KI, LLMs und Coding-Assistenten gilt: Diese Werkzeuge erhöhen die Geschwindigkeit – die Verantwortung für Qualität, Verständlichkeit und Wartbarkeit bleibt beim Team. Wie wir das bei itwh konkret leben (und welche Praktiken sich in unserem Umfeld bewährt haben), beschreibe ich im nächsten Beitrag.
Das ist genau die Art Umfeld, in dem gute Entwicklerarbeit sichtbar wird: klare Verantwortungen, saubere Schnittstellen und eine Kultur, die Qualität aktiv schützt. Diese Themen gehen wir im Rahmen einer echten agilen Transformation ganz aktiv gemeinsam an.
Fazit: Was das für euch als Anwender bedeutet
Wenn man Modularität auf einen Nenner bringen will, dann so: Wir bauen Systeme, die sich verändern dürfen, ohne dabei instabil zu werden. Für euch als Anwender heißt das ganz konkret:
Mehr Stabilität im Betrieb: Änderungen bleiben häufiger lokal, und das Risiko unerwarteter Seiteneffekte sinkt.
Schnellere Reaktion bei Bedarf: Fehlersuche und Bugfixes werden zielgerichteter, weil Zuständigkeiten und Grenzen klarer sind.
Planbare Erweiterungen: Ihr könnt mit einem passenden Einstiegspaket starten und später schrittweise ausbauen – ohne einen Neustart des Gesamtsystems.
Bessere Nachvollziehbarkeit: Klare Bausteine, klare Pakete – das hilft bei Planung, Betrieb und Kosten.
Und: Modularität ist für uns nicht nur Architektur, sondern auch Haltung. Damit das zuverlässig funktioniert, investieren wir bewusst in saubere Schnittstellen, Tests und Craftsmanship – und genau darum geht es im zweiten Teil.
Wenn dich besonders der Security-Aspekt interessiert: Dazu folgt ein eigener Beitrag aus unserem Team, der das Thema deutlich tiefer beleuchtet.
