Monolithen und Big Balls of Mud verschwinden nicht von selbst — aber sie müssen auch nicht im Big Bang sterben.

Du kennst das System. Vielleicht hast du es geerbt. Vielleicht hast du es mitgebaut. Zehn, fünfzehn Jahre alt, kaum Dokumentation, Abhängigkeiten die niemand mehr versteht. Ein Anfassen bricht drei andere Stellen. Ein Refactoring-Versuch vor zwei Jahren wurde nach drei Monaten abgebrochen — zu viel Risiko, zu wenig Rückendeckung.

Was jetzt? Die meisten Teams beantworten diese Frage falsch. Nicht weil sie die falschen Methoden kennen, sondern weil sie beim falschen Problem anfangen.

Das eigentliche Problem: Der Einstieg ist keine technische Frage

Wenn Teams vor einer chaotischen Codebasis stehen, greifen sie instinktiv zu technischen Antworten: Microservices, hexagonale Architektur, Event Sourcing. Die Zielarchitektur steht schnell im Whiteboard. Was fehlt, ist nicht die Vision — es ist der erste Schritt.

Das Problem ist struktureller Natur: Ohne ein gemeinsames Verständnis der Domäne weiß niemand, wo sinnvolle Grenzen verlaufen. Ohne klare Modulgrenzen bleibt jede Zielarchitektur abstrakt. Ohne eine Methode, Fortschritt in Minuten statt Monaten zu messen, verliert das Team den Glauben — lange bevor der erste Sprint endet.

Hinzu kommt die politische Dimension. Modernisierungsprojekte brauchen Budget. Budget braucht Argumente. Argumente brauchen Ergebnisse. Wer auf den Big Bang setzt, liefert Ergebnisse erst nach Monaten — wenn überhaupt. Das ist der eigentliche Grund, warum so viele Modernisierungsvorhaben scheitern: nicht mangelndes technisches Können, sondern das falsche Zeitmodell.

Der Denkrahmen: Modernisierung ist kein Projekt, sondern eine Praxis

Der entscheidende Shift ist nicht technisch, er ist konzeptuell. Wer Modernisierung als einmaliges Projekt begreift, braucht einen Big Bang. Wer sie als kontinuierliche Praxis begreift, braucht Habits — und die richtigen Einstiegspunkte.

Modernisierung scheitert nicht am fehlenden Willen und nicht an schlechten Werkzeugen. Sie scheitert daran, dass Teams versuchen, ein System-Problem mit einem Projekt zu lösen — statt mit einer Praxis.

Das bedeutet konkret: Die Frage ist nicht „Wie sieht unsere Zielarchitektur aus?“, sondern „Was ist der kleinste nächste Schritt, der das System messbar besser macht?“ Und: „Wie stellen wir sicher, dass dieser Schritt morgen auch gemacht wird, und übermorgen, und nächste Woche?“ Das klingt banal. Es ist es nicht.

Die Lösungsebenen: Von Diagnose bis Gewohnheit

Modernisierung beginnt mit Domänenverstehen

Wer ein chaotisches System modernisieren will, ohne die Domäne zu verstehen, zieht Grenzen an den falschen Stellen. Das Ergebnis: neue Architektur, alte Probleme.

Henning Schwentner zeigt, wie man bestehende Systeme — Monolithen, Big Balls of Mud — mit dem Modularity Maturity Index (MMI) bewertet und auf drei Ebenen transformiert: taktisch (Code-Struktur), soziotechnisch (Team-Verantwortlichkeiten) und strategisch (Domänengrenzen). Collaborative Modeling mit DDD macht implizites Wissen explizit und zeigt, wo sinnvolle Schnitte verlaufen — bevor Architekturentscheidungen fallen.

Du nimmst einen Katalog bewährter Refactorings, konkreter Heuristiken und einsetzbarer Tools mit — für dein eigenes System, am nächsten Morgen.

Legacy-Software mit DDD modernisieren mit Henning Schwentner

Große Vorhaben in lieferbare Einheiten zerlegen

Zu große Stories sind eines der teuersten Probleme in Softwareprojekten — und gleichzeitig eines der am meisten unterschätzten. „Fast fertig“ ist kein lieferbarer Zustand.

Elephant Carpaccio ist eine Coding Kata, die genau dieses Denken herausfordert: In extrem kurzen Iterationen entsteht eine lauffähige Anwendung. Jede Iteration liefert ein echtes Increment — kein Mock, kein Platzhalter. Das Team entscheidet selbst, wie es implementiert — klassisch, KI-unterstützt oder vollständig prompt-getrieben. Im Mittelpunkt steht vertikales Schneiden statt technischer Teilaufgaben, mit bewussten Entscheidungen zu Scope, Qualität und Tempo.

Du schärfst dein Gespür dafür, was innerhalb weniger Minuten wirklich lieferbar ist — und warum das die wichtigste Fähigkeit bei der Modernisierung ist.

The Elephant Carpaccio mit Tom Asel

Die Zielarchitektur klar machen: Hexagonal denken

Hexagonale Architektur verspricht klare Trennung von Geschäftslogik und technischen Belangen — aber an der Umsetzung in reale, gewachsene Systeme scheitern viele Teams. Nicht weil das Prinzip falsch ist, sondern weil Package-Struktur, Modulgrenzen und Dependency Inversion im Konkreten schwieriger sind als im Diagramm.

Tom Asel und Dagmar de Haan nehmen Design-Entscheidungen auf Architektur-, Modul- und Code-Ebene durch — plattformunabhängig, mit praktischen Übungen. Das Kernprinzip der Dependency Inversion wird nicht erklärt, sondern angewendet: auf Systeme, wie sie in der Realität aussehen.

Du gehst mit einer praktischen Grundlage für die Einführung oder Umstellung auf hexagonale Architektur — für dein konkretes Projekt, nicht für ein Beispielsystem.

Vom Schichten-Modell zur hexagonalen Architektur mit Tom Asel und Dagmar de Haan

Modernisierung als tägliche Praxis etablieren

Der häufigste Grund, warum Modernisierungsvorhaben steckenbleiben, ist nicht technischer Natur. Es ist das Modell: Ein großes Projekt, ein großes Budget, ein großes Risiko. Und dann passiert — Politik.

Michael Plöd stellt zwei Ideen vor, die dieses Modell auflösen: Team-Habits und die 1%-Methode, angelehnt an James Clears „Atomic Habits“. Das Prinzip: Verbesserungen so klein machen, dass sie das Tagesgeschäft nicht berühren — aber so regelmäßig, dass sie sich über Zeit exponentiell kumulieren. Kein Big Bang, keine große Ankündigung, keine Genehmigung erforderlich. Nur tägliche, minimale Schritte die sich summieren.

Du verlässt die Keynote mit einer konkreten Idee, wie du morgen anfängst — ohne Projektantrag.

Kontinuierliche Architektur-Modernisierung mit der 1%-Methode mit Michael Plöd

Was du heute tun kannst

• Domäne vor Architektur: Bevor du die nächste Zielarchitektur zeichnest, führe eine Collaborative-Modeling-Session mit deinem Team durch. Frag: Wo verlaufen die natürlichen Grenzen in unserer Domäne? Die Antwort verändert, welche Schnitte sinnvoll sind.
• Messe deinen Modularity Maturity Index: Der MMI gibt dir eine nüchterne Standortbestimmung für dein System — ohne Blaming, ohne Schönfärberei. Schon die Diagnose zeigt, wo der erste sinnvolle Hebel sitzt.
• Starte mit einem 1%-Schritt: Identifiziere eine einzige, isolierte Verbesserung, die du und dein Team diese Woche umsetzen können — in unter zwei Stunden. Nicht die wichtigste. Die machbarste. Und haltet das fest: Was wurde gemacht, was hat es gebracht?

Fazit: Der erste Schritt ist keine Frage der Architektur

Gewachsene Software modernisieren bedeutet nicht, ein besseres Zielbild zu haben. Es bedeutet, einen besseren ersten Schritt zu machen — und dann den zweiten. Domänenverstehen liefert die Orientierung. Vertikales Schneiden liefert frühe Ergebnisse. Hexagonale Architektur gibt eine tragfähige Zielstruktur. Und Team-Habits machen aus einem Vorhaben eine Praxis.

Wer wartet, bis das System bereit ist für einen großen Schnitt, wartet meistens zu lange. Wer anfängt, bevor alles klar ist — mit dem kleinsten sinnvollen Schritt — kommt an.

Wer diese Ansätze hands-on durcharbeiten will: Henning Schwentner, Tom Asel, Dagmar de Haan und Michael Plöd sind beim Software Architecture Summit in Berlin im Oktober 2026 dabei. Vier Workshops, ein Cluster — von der Diagnose bis zur täglichen Praxis.

Key Takeaways

• Modernisierung scheitert nicht am fehlenden Werkzeug, sondern am falschen Einstiegspunkt — Domänenverstehen kommt vor Architekturentscheidungen.
• Der Modularity Maturity Index (MMI) gibt eine strukturierte Standortbestimmung: taktisch, soziotechnisch, strategisch.
• Vertikales Schneiden (Elephant Carpaccio) macht sichtbar, was in Minuten wirklich lieferbar ist — und schärft das wichtigste Skill bei der Modernisierung.
• Hexagonale Architektur löst das Dependency-Problem auf Code-Ebene — aber nur, wenn Modulgrenzen aus der Domäne kommen, nicht aus dem Diagramm.
• Die 1%-Methode ersetzt den Big Bang durch tägliche Mini-Schritte, die sich exponentiell kumulieren — ohne Projektantrag, ohne Politik.