Monolith zerlegen oder stabilisieren? Entscheidungskriterien für modulare Modernisierung

Montagmorgen, 9:10 Uhr: Ein Fachbereich meldet eine „kleine Anpassung“ im Bestellprozess. Die IT schaut kurz in den Tickettext, wirkt machbar. Zwei Stunden später ist die Stimmung eine andere. Der Build läuft länger als geplant, ein Nebenjob hängt am gleichen Release-Paket, und beim Blick in die Datenbank wird klar: Diese Änderung berührt mehr Tabellen und Trigger als gedacht. Spätestens jetzt taucht die Frage auf, die viele Teams regelmäßig beschäftigt: Monolith zerlegen oder stabilisieren?

Wer darauf reflexhaft mit „Microservices!“ antwortet, übersieht oft den Kern: Es geht nicht um ein Architektur-Label, sondern um Lieferfähigkeit und Betriebssicherheit. Dieser Praxisleitfaden führt durch eine pragmatische Prüfung, zeigt Entscheidungskriterien für modulare Modernisierung und beschreibt umsetzbare Schritte. Dazu kommen typische Fehlerbilder sowie klare Abbruch- und Eskalationspunkte – damit Modernisierung nicht zum Dauerprojekt ohne messbaren Effekt wird.

Monolith zerlegen oder stabilisieren: erst das Symptom, dann die Architektur

„Der Monolith ist schuld“ klingt eindeutig, ist aber selten präzise genug für eine Entscheidung. Ein Monolith (eine Anwendung als gemeinsames Deployment-Artefakt) kann sehr zuverlässig laufen – oder permanent reiben. Genauso gilt: Microservices (viele kleine, separat deploybare Dienste) können Durchlaufzeiten senken, bringen aber zwangsläufig mehr operative Aufgaben mit.

Martin Fowler ordnet diese Realität nüchtern ein: Microservices sind vor allem ein anderer Operations-Footprint – also ein anderer Betriebsaufwand mit mehr Komponenten, mehr Deployments, mehr Fehlerquellen und mehr Bedarf an Automatisierung.^[Quelle] Die Grenze dieser Aussage: Sie ersetzt keine Analyse Ihres Systems. Die praktische Folgerung ist trotzdem klar: Wer als Ziel „Microservices“ ausruft, bevor der Engpass sauber beschrieben ist, modernisiert schnell an der falschen Stelle.

Entscheidungskriterien: Wann Zerlegen wirklich hilft – und wann nicht

Modernisierungsdruck ist real: Security-Anforderungen steigen, Schnittstellen werden mehr, Teams wechseln, und die Business-Software soll gleichzeitig weiterlaufen und sich weiterentwickeln. Zerlegung kann ein sinnvoller Schritt sein – aber nur, wenn sie den Engpass adressiert und nicht nur das Architekturdiagramm verschönert.

Kriterium 1: Operative Reife – kann Ihr Betrieb den Footprint tragen?

Mit jeder zusätzlichen deploybaren Einheit steigt der Bedarf an sauberer Lieferung und Überwachung: CI/CD (automatisierte Build-/Test-/Deploy-Kette), Observability (Metriken, Logs und Traces zur Diagnose), Incident-Prozesse, Runbooks und klare Zuständigkeiten. AWS formuliert das als Abwägung: feinere Segmentierung kann Vorteile für Zuverlässigkeit und Skalierung bringen, erhöht aber mit der Anzahl der Komponenten die operative Komplexität.^[Quelle] Die Grenze: Das ist Leitplanke, keine Erfolgsgarantie. Die Folgerung: Wenn Sie heute schon Schwierigkeiten haben, ein Deployment stabil durchzubringen, dann multipliziert eine Service-Landschaft dieses Problem.

Konkrete Prüfpunkte, die man nicht wegmoderieren sollte:

• Release-Fähigkeit: Rollback/Backout ist definiert, Wartungsfenster und Kommunikation sind etabliert.
• Monitoring & Alarmierung: Alarme sind handlungsorientiert (nicht „alles rot“), Fehlerquellen sind eingrenzbar.
• Incident-Handhabung: Es gibt einen Rhythmus für Postmortems und Maßnahmen, nicht nur Ad-hoc-Feuerwehr.
• Ownership: Wer entscheidet über Schnittstellen, wer priorisiert, wer trägt Betrieb und Qualität?

Kriterium 2: Änderungsentkopplung – blockieren sich Anforderungen gegenseitig?

Zerlegung lohnt, wenn unabhängige Änderungen im Monolithen regelmäßig voneinander abhängig werden, obwohl sie fachlich getrennt sind. Typisches Muster: Ein Portalbereich braucht häufige Anpassungen, während ein Abrechnungsbereich selten verändert werden darf und hohe Sorgfalt erfordert. Wenn beide immer im gleichen Release-Zug landen, bremsen sie sich.

Umgekehrt ist Zerlegung oft ein Eigentor, wenn nahezu jede Änderung quer durch viele Bereiche läuft (Berechtigungen, Preislogik, Reporting, Datenbereinigung). Dann erzeugt man Schnittstellenverkehr statt Entkopplung – und die Koordination steigt, statt zu sinken.

Kriterium 3: Datenkopplung – steckt die Komplexität in der Datenbank?

Viele Systeme sind weniger über Code als über Daten gekoppelt: gemeinsame Tabellen, Trigger, transaktionale Abläufe und Batch-Jobs. Sam Newman stellt in seinen Dekompositionsmustern heraus, dass die eigentliche Herausforderung häufig die Daten- und Integrationsstrategie ist – und dass Big-Bang-Vorhaben dabei besonders riskant werden.^[Quelle]

Praktische Folgerung für den Betrieb: Wenn mehrere Komponenten ohne Regeln auf dieselben Tabellen schreiben, entstehen Seiteneffekte, die Sie kaum sauber zurückrollen können. Modulare Modernisierung braucht daher früh Entscheidungen zu Datenhoheit, Konsistenz und Reporting-Entkopplung.

Kriterium 4: Stabilität und fachlicher Wert – was muss erhalten bleiben?

In gewachsenen digitalen Unternehmenslösungen steckt oft viel korrekt abgebildete Domänenlogik: Sonderfälle, kaufmännische Regeln, Ausnahmen in Prozessen, historisch gewachsene Datenbereinigung. Das ist nicht „Legacy-Müll“, sondern häufig der Grund, warum das Geschäft überhaupt funktioniert. Modernisierung wird wirtschaftlich, wenn sie diesen Wert nicht leichtfertig verwirft – und gleichzeitig die Stellen identifiziert, die Betrieb und Weiterentwicklung unverhältnismäßig teuer machen.

Auswahl treffen: Drei Zielbilder, die in Unternehmen funktionieren

Zwischen „alles bleibt“ und „alles wird Microservices“ liegen praktikable Zielbilder, die Modernisierung planbar machen. AWS Prescriptive Guidance empfiehlt ausdrücklich, vor der Dekomposition zu prüfen, welche Teile überhaupt dekomponiert werden sollten, und inkrementelle Ansätze zu bevorzugen.^[Quelle]

Praxisleitfaden: Von der Prüfung zur Umsetzung (mit Stop/Go-Punkten)

1) Systemgrenzen sichtbar machen – klein genug, um genutzt zu werden

Sie brauchen keine 80-seitige Systemdokumentation, um zu entscheiden. Was hilft, ist eine kompakte Karte: Hauptprozesse, kritische Schnittstellen (z. B. Portale, EDI, Dateiexporte, REST-APIs), Batch-Jobs, sowie Stellen mit hoher Störanfälligkeit. Ziel: Entscheidungen treffen können, nicht Wissen archivieren.

Bewährt hat sich eine Sicht, die Betrieb und Fachbereich zusammenbringt: „Welche Prozessstrecke ist geschäftskritisch, und woran hängt sie technisch?“ Dann wird schnell sichtbar, wo eine Extraktion riskant wäre – und wo sie tatsächlich Entlastung bringen könnte.

2) Baseline-Metriken definieren – sonst bleibt es eine Glaubensfrage

Modernisierung ohne Baseline ist wie eine Performance-Optimierung ohne Messung. Entscheidend sind Kennzahlen, die sowohl Delivery als auch Betrieb abbilden: Deployment-Frequenz, Lead Time (von Anforderung bis produktiv), Change Failure Rate (Störungen nach Changes), MTTR (Mean Time to Recovery) und wiederkehrende Incident-Klassen. Die Metriken müssen nicht akademisch perfekt sein – aber sie müssen konsistent erhoben werden, damit ein Stop/Go möglich ist.

3) Kandidaten schneiden – nach Domäne, nicht nach Technikschichten

Ein häufiger Fehlstart ist der Schnitt nach Schichten („UI-Service“, „DB-Service“). Das erzeugt neue Abhängigkeiten, statt sie zu reduzieren. Domänenschnitt heißt: Ein Modul verantwortet einen fachlichen Bereich inklusive Regeln und Daten. Das ist für Teams meist greifbarer als rein technische Abgrenzung.

Wenn Sie die fachlichen Grenzen nicht benennen können, ist das kein Grund, schneller zu schneiden – sondern ein Signal, zuerst im Monolithen zu stabilisieren und zu modularisieren: Begriffe klären, Datenflüsse verstehen, Querschnittsfunktionen identifizieren.

4) Strangler statt Big Bang – kontrolliert umleiten, konsequent abschalten

Wenn Verfügbarkeit zählt und man Risiken kontrollieren muss, ist das Strangler-Fig-Pattern ein belastbarer Weg: Funktionen werden schrittweise neben dem bestehenden System ersetzt; der Verkehr wird kontrolliert umgeleitet, bis alte Pfade abgeschaltet werden.^[Quelle]

Wichtig ist die Disziplin hinter dem Muster: klare Routing-Entscheidungen, Kompatibilität in Daten und Schnittstellen, Monitoring über beide Wege – und ein echtes „Done“, wenn der alte Pfad entfernt ist. Sonst entsteht Parallelbetrieb als Dauerzustand.

5) Daten- und Reporting-Strategie früh festzurren

In der Praxis entscheidet sich Modernisierung oft an zwei Fragen: Wer „besitzt“ welche Daten – und wie wird berichtet? Wenn Reporting direkt auf operative Tabellen zugreift, blockiert es Veränderungen. Wenn mehrere Komponenten Daten „mitbenutzen“, ohne Regeln, entstehen Inkonsistenzen.

Planen Sie daher explizit:

• Datenhoheit: welches Modul ist führend für welche Entität (Kunde, Auftrag, Rechnung …)?
• Konsistenzanforderungen: wo ist starke Konsistenz nötig, wo reicht Eventual Consistency?
• Reporting-Entkopplung: wie werden Auswertungen versorgt, ohne operative Modelle zu verhärten?

6) Security und Betrieb pro Modul definieren – nicht später „dranflanschen“

Mit jeder neuen Komponente steigt die Angriffsfläche: Service-zu-Service-Kommunikation, Secrets, Berechtigungen, Audit-Trails. Klären Sie früh, wie Authentifizierung (z. B. zentral über SSO) und Autorisierung (rollen-/rechtebasiert je Domäne) zusammenspielen. Für den Alltag zählt außerdem: Logs müssen diagnostisch hilfreich sein, dürfen aber keine Datenschutz- und Aufbewahrungsregeln brechen. Diese Punkte gehören in Runbooks und Betriebsdokumentation – nicht nur in Architekturfolien.

8-Schritte-Checkliste für eine belastbare Go/No-Go-Entscheidung

1. Engpass benennen: Was genau soll besser werden (Release-Dauer, Stabilität, Skalierung, Parallelentwicklung)?
2. Baseline messen: Welche Kennzahlen bilden den Ist-Zustand ab (Lead Time, Change Failure Rate, MTTR etc.)?
3. Betriebsfähigkeit prüfen: CI/CD, Monitoring, Alarmierung, Runbooks, Incident-Prozesse, Ownership.
4. Domänenschnitt skizzieren: Wo sind natürliche fachliche Grenzen? Was sind Querschnittsthemen?
5. Datenstrategie entwerfen: Datenhoheit, Konsistenz, Reporting, Migrationspfade.
6. Abhängigkeiten inventarisieren: Jobs, Schnittstellen, Dateiexporte, Nutzergruppen, Berechtigungen.
7. Slice planen: ein kleines, lieferbares Paket inkl. Rollback und Monitoring-Zielen.
8. Stop/Go-Kriterien festlegen: Welche Signale stoppen die Zerlegung oder erzwingen einen Stabilisierungsschritt?

Typische Fehlerbilder – so sehen sie im Betrieb aus

Fehler 1: Mehr Komponenten, aber keine Ownership

Wenn niemand Ende-zu-Ende verantwortlich ist (Priorisierung, Qualität, Betrieb), wird aus Entkopplung ein Abstimmungsproblem. Im Incident-Fall führt das zu langen Runden, unklaren Entscheidungen und dem Reflex, wieder „alles gemeinsam“ zu deployen. Gegenmaßnahme: pro Modul ein klarer Owner-Kreis, definierte Übergaben und ein Decision-Log für Schnittstellen und Datenhoheit.

Fehler 2: Geteilte Daten ohne Regeln

Das Anti-Pattern ist bekannt: Dienste sind getrennt, schreiben aber weiterhin auf dieselben Tabellen oder nutzen direkte Datenbankzugriffe quer über Domänen hinweg. Das bricht Isolation, erschwert Audits und macht Rollbacks unzuverlässig. Gegenmaßnahme: Datenzugriffe über definierte Schnittstellen, klare Datenverantwortung und – wo nötig – kontrollierte Synchronisation (z. B. Events).

Fehler 3: Netzwerklatenz und Fehlerkaskaden werden „mit eingeplant“, aber nicht getestet

Was im Monolith ein In-Process-Aufruf war, wird in verteilten Architekturen ein Netzwerkaufruf mit Timeouts, Retries und potenziellen Kaskaden. Ohne saubere Timeouts, Korrelation (Request-IDs) und realistische Ende-zu-Ende-Tests wird die Fehleranalyse deutlich schwerer. Gegenmaßnahme: klare SLOs (messbare Service-Ziele), definierte Timeouts, Trace-Korrelation und Lasttests entlang kompletter Prozessstrecken.

Fehler 4: Schnitt nach Organigramm statt nach Fachlogik

Wenn Services primär Teamgrenzen abbilden, fachlich aber quer durch Prozesse laufen, bleibt die Kopplung – nur auf einer anderen Ebene. Gegenmaßnahme: domänenscharfer Schnitt, auch wenn das zunächst Reibung erzeugt. Wenn das organisatorisch nicht möglich ist, ist ein modularer Monolith oft der bessere Zwischenschritt.

Abbruch- und Eskalationspunkte: Wann Stabilisieren die bessere Entscheidung wird

Ein Modernisierungsvorhaben braucht Stop-Regeln, sonst frisst es Budget und Aufmerksamkeit. Diese Signale sind starke Gründe, bewusst umzuschalten:

• Operativer Overload: Alarmflut, steigende MTTR, On-Call nicht mehr abdeckbar.
• Keine messbare Verbesserung: Lead Time, Change Failure Rate oder Stabilität verbessern sich nicht erkennbar.
• Schnittstellenkomplexität explodiert: Versionierung ungeklärt, Breaking Changes häufen sich, Debugging wird zum Ratespiel.
• Datenkonflikte: Inkonsistenzen, doppelte Wahrheiten, schwer erklärbare Report-Abweichungen.
• Ownership bleibt unklar: Entscheidungen dauern, niemand trägt Verantwortung für Betrieb und Weiterentwicklung.

Eskalation bedeutet dann nicht „zurück zum Alten“, sondern: Stabilisierung priorisieren. Typische Maßnahmen sind: Regression für Kernprozesse nachziehen, Observability verbessern, Datenzugriffe konsolidieren, Modulgrenzen im Monolithen schärfen – und erst danach erneut prüfen, ob eine Extraktion wirklich Nutzen bringt.

Was „stabilisieren“ konkret heißt – und warum es oft schneller wirkt

Stabilisierung ist keine kosmetische Aufräumaktion. Im Betrieb zeigt sie sich als weniger Überraschungen und planbare Releases. Konkrete Hebel, die Teams unmittelbar spüren:

• Release-Mechanik: reproduzierbarer Build, konsistente Umgebungen, geübter Rollback-Pfad.
• Transparenz: Logging-Standards, Fehlerklassifikation, Korrelation von Requests über Prozessstrecken.
• Testfokus: Ende-zu-Ende-Regression für Kernflüsse (nicht nur isolierte Tests).
• Modulgrenzen im Monolithen: definierte interne APIs, disziplinierter Datenzugriff, klare Verantwortlichkeiten.
• Datenhygiene: eindeutige Stammdatenquellen, dokumentierte Nebenwirkungen von Jobs, reduzierte Sonderfalllogik.

Das Ergebnis ist häufig ein belastbarer modularer Monolith: Die Software bleibt als Einheit betreibbar, aber intern klarer geschnitten. Damit gewinnen Teams schon viel von dem zurück, was man sich von Zerlegung verspricht – ohne sofort die operative Komplexität zu vervielfachen.

Letzte Prüffrage, bevor Sie entscheiden

Wenn Sie heute zerlegen würden: Können Sie morgen früh bei einem Incident schnell sagen, welcher Teil verantwortlich ist, wer reagiert, welche Metrik den Fehler belegt und wie Sie zurückrollen? Wenn diese Frage unangenehm offen bleibt, ist die Entscheidung meist nicht „mehr Architektur“, sondern „mehr Betriebssicherheit“.

Wenn Sie Ihre Ausgangslage strukturiert bewerten und einen Modernisierungspfad mit klaren Stop/Go-Punkten aufsetzen möchten, können Sie uns dafür einmalig und gezielt ansprechen:

Für dieses Thema sind auch Legacy-Modernisierung und Strangler Fig Pattern wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.

Projekt oder Modernisierungsvorhaben mit Net-Base besprechen.