Wer in großen Organisationen über Modernisierung spricht, landet irgendwann fast automatisch bei demselben Bild: Da ist ein über Jahre gewachsener Block aus Logik, Abhängigkeiten, Sonderfällen, Schnittstellen und historisch verständlichen, technisch aber kaum noch beherrschbaren Entscheidungen. Von außen sieht das nach einem Monolithen aus. Von innen ist es meist eher ein Biotop. Alles hängt mit allem zusammen, jeder Eingriff hat Nebenwirkungen, und trotzdem weiß jeder, dass es so nicht bleiben kann.
Die naheliegende Fantasie dazu lautet: einmal sauber auseinanderziehen, in Microservices überführen, fertig. In der Praxis beginnt genau hier das Problem. Denn der schwierigste Teil einer solchen Transformation ist nicht das technische Zerlegen, sondern das fachliche Schneiden. Wo verläuft eine sinnvolle Grenze? Was gehört zusammen? Welche Logik ist wirklich eigenständig, welche nur scheinbar? Und was passiert, wenn man falsch schneidet und aus einem großen Problem zehn kleinere macht, die sich fortan nur noch gegenseitig blockieren?
Deshalb ist die vernünftigere Form der Modernisierung oft unspektakulärer, aber deutlich belastbarer. Sie beginnt nicht mit dem großen Architekturversprechen, sondern mit einem systematischen Vorgehen. Zuerst wird die Domäne verstanden: Akteure, Abhängigkeiten, Ereignisse, Regeln, Übergaben. Dann werden fachliche Zusammenhänge sichtbar gemacht, bevor technische Grenzen gezogen werden. Verfahren wie Domain Storytelling oder Event Storming wirken auf den ersten Blick beinahe harmlos, manchmal fast zu harmlos für die Größe des Problems. Tatsächlich leisten sie etwas Entscheidendes: Sie holen die Fachlogik aus dem diffusen Gesamtsystem heraus und machen sichtbar, wo daraus sinnvolle Einheiten werden könnten.
Darin liegt ein wichtiger Perspektivwechsel. Nicht die Technik bestimmt zuerst den Schnitt, sondern die Fachlichkeit. Wo hohe fachliche Dichte ist, wo Begriffe, Regeln und Abläufe eng zusammengehören, lohnt es sich, Inhalte in Modellen zu isolieren. Das entkoppelt die Logik von der Implementierung. Und genau das senkt später Wartungsaufwand. Wer Fachlichkeit dauerhaft in Technik versteckt, macht jede Änderung teuer. Wer sie als Modell ausdrückbar macht, erhöht die Chance auf Langlebigkeit. Das ist weniger spektakulär als ein neues Framework, aber meist der solidere Fortschritt.
Auch die Migration selbst folgt in reifen Organisationen selten der heroischen Logik des Komplettaustauschs. Erfolgreicher ist meistens die schrittweise Ablösung. Erst Randbereiche. Dann weniger kritische Services. Dann, mit wachsender Sicherheit, die zentraleren Teile. Dazwischen Parallelbetrieb, Umschalten über Gateways, vorsichtige Entkopplung alter und neuer Welt. Das klingt langsamer, ist aber oft die schnellere Methode, wenn man Betriebssicherheit, Lernkurve und Fehlertoleranz zusammennimmt. Der Charme solcher Muster liegt gerade darin, dass sie keine Perfektion am Reißbrett verlangen. Sie erlauben Bewegung, ohne das Gesamtsystem in einen Ausnahmezustand zu versetzen.
Mit dem Aufkommen von KI bekommt diese Debatte eine neue Schicht. Viele hoffen, dass man sich beim Weg in modernere Architekturen nun von Maschinen helfen lassen kann: beim Verstehen des Altsystems, beim Schneiden von Domänen, bei der Migration, bei der Umsetzung. Das ist nicht falsch. Aber es verschiebt das Problem nicht automatisch. KI hilft dort, wo Strukturen sichtbar sind, Muster erkannt werden können und fachliche Inhalte sauber beschrieben sind. Sie ersetzt nicht die Notwendigkeit, gute Schnitte zu machen. Im Gegenteil: Je unklarer die fachlichen Grenzen, desto mehr produziert auch KI nur Geschwindigkeit in die falsche Richtung.
Ähnlich nüchtern fällt der Blick auf Integrationsfragen aus. Synchron oder asynchron, REST oder Message-basierte Kommunikation – all das sind keine Stilfragen, sondern Entscheidungen mit Folgen für Kopplung, Ausfallsicherheit und Steuerbarkeit. Die Versuchung ist groß, überall dieselbe Antwort zu verwenden. Doch gerade in Übergangsarchitekturen braucht es meistens beides: direkte Kommunikation dort, wo sie fachlich sinnvoll ist, entkoppelte Muster dort, wo Resilienz und lose Kopplung wichtiger sind. Architektur wird hier weniger zum Dogma als zur Kunst der passenden Verbindung.
Und dann ist da noch die Frage, die in vielen Modernisierungsprojekten fast religiös geführt wird: Low Code oder Eigenimplementierung? Auch hier hilft meist kein Bekenntnis, sondern nur Differenzierung. Wo Datenstrukturen häufig geändert werden, wo Hierarchien erfasst und Oberflächen aus Modellen abgeleitet werden können, spielt ein modellbasierter Low-Code-Ansatz seine Stärke aus. Wo dagegen eng zugeschnittene Fachlogik, Berechnungen, Vergleichslogiken oder nicht dokumentenzentrierte Datenflüsse dominieren, stößt er an Grenzen. Die produktive Antwort liegt daher selten im Entweder-oder. Sie liegt in der Fähigkeit, beide Formen bewusst zu kombinieren.
Vielleicht ist das die eigentliche Lektion solcher Transformationsbilder. Große Systeme scheitern selten daran, dass niemand ihre Probleme kennt. Sie scheitern eher daran, dass man sie entweder für rein technische Probleme hält oder für so groß, dass nur noch ein großer Wurf hilft. Beides ist bequem, aber selten richtig. Wirkliche Modernisierung beginnt früher und tiefer: beim Verstehen fachlicher Zusammenhänge, beim Trennen von Logik und Technik, beim vorsichtigen Aufbau neuer Strukturen und beim Mut, nicht alles auf einmal zu lösen.
Das ist weniger dramatisch als die Erzählung vom radikalen Neustart. Aber wahrscheinlich näher an der Art, wie Organisationen tatsächlich lernfähig werden. Nicht durch den einen Schnitt, sondern durch viele richtige.
