Software-Erosion: Eine stille Bedrohung für langfristige Softwarequalität

Software-Erosion ist der teuerste Posten, den niemand budgetiert. Kein einzelner Bug, kein spektakulärer Ausfall — sondern ein schleichender Verfall, der jedes neue Feature ein Stück langsamer, jede Änderung ein Stück riskanter und jede Schätzung ein Stück unzuverlässiger macht. Am Ende kostet Software-Erosion mehr als jeder Vorfall, der es je in ein Incident-Protokoll geschafft hat — gerade weil sie nie in einem steht.

Das Tückische daran: Erosion ist kein Versagen. Sie ist die Physik der Software. Jedes System, das in Betrieb ist und sich weiterentwickelt, erodiert — die einzige Frage ist, wie früh Sie gegensteuern. Dieser Artikel zeigt, woran Sie den Verfall erkennen, bevor er teuer wird, was er Sie wirklich kostet und welche Strategien ihn tatsächlich stoppen — statt der üblichen Allgemeinplätze „mehr Refactoring, mehr Dokumentation”.

Was Software-Erosion wirklich ist (und was nicht)

Software-Erosion — auch Software-Verfall oder „Architektur-Drift” genannt — ist nicht der Verfall von Code, der unangetastet im Regal liegt. Code, der nie geändert wird, erodiert nicht; er veraltet höchstens technologisch. Erosion entsteht im Gegenteil dort, wo am meisten passiert: Sie ist die wachsende Lücke zwischen der Architektur, die Sie ursprünglich entworfen haben, und den Änderungen, die die Realität seither erzwungen hat.

Jede Anforderung, die unter Zeitdruck „irgendwie reingeschoben” wird, jede Abkürzung, die nie zurückgebaut wird, jede Abhängigkeit, die niemand aktualisiert — jede für sich ist harmlos. In Summe verschiebt sich das System Stück für Stück weg von der klaren Struktur, mit der es einmal begann. Das ist der Kern: Erosion ist nicht ein großer Fehler, sondern die Summe tausend kleiner, jeweils vernünftiger Entscheidungen.

Deshalb lässt sie sich auch nicht „wegtesten”. Ihre Tests können grün sein, Ihre Software kann funktionieren — und trotzdem erodiert die Architektur darunter. Der Schaden zeigt sich nicht in der Funktion, sondern in der Veränderbarkeit.

Woran Sie Erosion erkennen, bevor sie teuer wird

Der gefährlichste Moment ist der, in dem die Erosion längst läuft, aber niemand sie benennt. Sie verstecken sich in Sätzen, die in fast jedem Team fallen. Die folgenden Frühwarnzeichen sind verlässlicher als jede Metrik:

Was Sie hören oder beobachten	Was dahintersteckt
„Das vergleichbare Feature ging letztes Jahr doppelt so schnell.”	Sinkende Entwicklungsgeschwindigkeit — das erste, härteste Symptom.
„Modul X fasst keiner gern an.”	Eine Stelle ist so verworren, dass selbst erfahrene Entwickler sie meiden.
„Der Bugfix hat drei neue Bugs erzeugt.”	Enge, unsichtbare Kopplung — eine Änderung zieht unkalkulierbare Folgen nach sich.
„Onboarding dauert bei uns Monate.”	Das Wissen steckt in Köpfen, nicht in Struktur und Dokumentation.
„Aufräumen steht seit zwei Jahren im Backlog.”	Technische Schulden, die nie getilgt werden — der Zins läuft weiter.
„Updaten trauen wir uns nicht.”	Veraltete Abhängigkeiten, deren Aktualisierung niemand mehr beherrscht.
Schätzungen liegen systematisch zu niedrig.	Die Komplexität ist nicht mehr greifbar — ein klassisches Erosions-Symptom.

Wenn Sie zwei oder drei dieser Sätze wiedererkennen, ist das kein Grund zur Panik — aber ein klares Signal, jetzt hinzusehen, statt zu warten, bis es sich in der Roadmap niederschlägt.

Kommt Ihnen das bekannt vor? Aus diffusem Bauchgefühl wird in einem Architecture Review eine priorisierte Roadmap — der erste Schritt ist ein unverbindliches Erstgespräch.

Warum Erosion entsteht — die wahren Ursachen

Die Ursachen sind teils technisch, teils organisatorisch — und sie verstärken sich gegenseitig.

Technische Schulden mit Zinseszins. Jede bewusste Abkürzung zugunsten der Geschwindigkeit ist ein Kredit. Das ist legitim — solange er getilgt wird. Wird er das nicht, wächst der Zins: Jede weitere Änderung baut auf der Abkürzung auf, und irgendwann ist die Schuld größer als der ursprüngliche Code wert war.

Wissensverlust. Software lebt von implizitem Wissen — „warum ist das so gebaut?”. Verlässt eine Schlüsselperson das Team, ohne dass dieses Wissen in Struktur, Tests oder Architecture Decision Records übergegangen ist, bleibt Code zurück, den niemand mehr versteht. Unverstandener Code wird nicht refaktoriert — er wird umschifft. Und Umschiffen ist Erosion in Reinform.

Dependency-Drift und veraltete Runtimes. Frameworks, Bibliotheken, Laufzeitumgebungen entwickeln sich weiter. Wer nicht mitzieht, sammelt nicht nur Sicherheitslücken (eine unsupportete Runtime bedeutet ungepatchte CVEs), sondern verbaut sich auch den Zugang zu modernen Werkzeugen — bis ein Update kein Update mehr ist, sondern ein Migrationsprojekt.

Anforderungsdruck ohne Refactoring-Budget. Die häufigste Ursache ist die banalste: Das Geschäft fordert Features, der Plan kennt keinen Posten für Strukturpflege. Erosion ist dann nicht das Ergebnis schlechter Entwickler, sondern eines Prozesses, der Pflege systematisch nicht einplant.

Fehlende Architektur-Grenzen. Wo keine klaren Modul- und Abhängigkeitsgrenzen definiert (und durchgesetzt) sind, wächst Kopplung von allein. Genau hier entscheidet sich, ob ein System über Jahre wartbar bleibt — ein Thema, das wir im Vergleich modularer Monolith vs. Microservices ausführlich behandeln.

Was Erosion kostet — der Zinseszins der Vernachlässigung

Der Schaden ist real, auch wenn er nie als Einzelposten auftaucht. Er verteilt sich auf vier Konten:

• Geschwindigkeit. Das teuerste Konto. Was anfangs Tage dauert, dauert später Wochen. Die Auslieferungsfähigkeit — Ihr eigentlicher Wettbewerbsvorteil — sinkt kontinuierlich.
• Risiko. Jede Änderung an einem eroded System ist ein Glücksspiel. Mit der Kopplung steigt die Wahrscheinlichkeit, dass eine kleine Anpassung etwas Entferntes zerstört.
• Sicherheit und Compliance. Veraltete Runtimes und Bibliotheken sind offene Flanken. Was als „läuft doch” durchgeht, ist regulatorisch oft längst ein Problem.
• Mensch. Erosion ist ein stiller Treiber von Fluktuation. Gute Entwickler wollen nicht jeden Tag gegen ein System kämpfen, das sie ausbremst.

Diese vier Konten sind keine Theorie. In einer McKinsey-Erhebung schätzten CIOs, dass technische Schulden 20 bis 40 % des Werts ihrer gesamten Technologie-Landschaft ausmachen — und dass 10 bis 20 % des Budgets, das eigentlich für Neues gedacht ist, ins Abtragen ebendieser Schuld fließen. Anders gesagt: Bis zu jeder fünfte Euro Ihres Innovationsbudgets versickert in der Wartung von Code, der einmal schneller fertig werden sollte. Übersetzt auf den Alltag heißt das — braucht Ihr Team heute doppelt so lange für eine Änderung wie vor zwei Jahren, zahlen Sie faktisch den doppelten Preis für dasselbe Ergebnis.

Das ist kein abstraktes Risiko: Eine produktive Software verursacht ohnehin jährlich 15 bis 25 % der Initial-Entwicklung an Wartung — und etwa alle drei bis fünf Jahre einen Modernisierungs-Schub von 20 bis 40 %. Wie sich diese Zahlen in ein Projektbudget einordnen, haben wir in Was kostet Softwareentwicklung im Mittelstand? durchgerechnet. Erosion verschiebt genau diese Kurve nach oben: Vernachlässigung macht aus „normalem Lebenszyklus” einen teuren Sanierungsfall.

Und der Posten wächst, sobald man ihn ignoriert: 60 % der von McKinsey befragten CIOs sahen ihre Schuldenlast binnen drei Jahren steigen. Das ist die eigentliche Tücke der Erosion — der günstigste Zeitpunkt, gegen sie vorzugehen, war vor einem Jahr; der zweitgünstigste ist heute. Jeder aufgeschobene Monat macht aus einem kleinen Refactoring ein größeres und irgendwann aus einem Update ein Migrationsprojekt. Genau diesen Kipppunkt erreichte die Anwendungslandschaft bei Omniga (mehr dazu weiter unten), als aus „veralteter Runtime” ein vollständiges Modernisierungsvorhaben wurde.

Refactor, Rewrite oder Strangler-Fig? Die eigentliche Entscheidung

Hat sich Erosion erst einmal aufgestaut, stellt sich die Frage, die fast jedes Team falsch beantwortet: kontinuierlich aufräumen, alles neu bauen — oder schrittweise ablösen?

Ansatz	Wann sinnvoll	Risiko	Realität
Kontinuierliches Refactoring	Schuld ist lokal begrenzt, Architektur im Kern tragfähig	gering	Der Normalfall — Pflege im laufenden Betrieb, eingebaut in den Sprint.
Big-Bang-Rewrite	Fast nie	sehr hoch	Klingt verlockend, scheitert meist: Das alte System läuft weiter, das neue verschlingt Jahre, und die Erosion beginnt im Neubau von vorn.
Strangler-Fig / inkrementelle Ablösung	Architektur am Limit, aber Betrieb darf nicht stehen	mittel	Der pragmatische Mittelweg: Stück für Stück ersetzen, ohne den Geschäftsbetrieb zu unterbrechen.

Die ehrliche Antwort ist fast immer: nicht der große Wurf, sondern der erste saubere Schnitt. Ein Big-Bang-Rewrite tauscht ein bekanntes, erodiertes System gegen ein unbekanntes, unfertiges — und tilgt die Schuld nicht, sondern verlagert sie. Die Strangler-Fig-Strategie — Altes schrittweise durch Neues ersetzen, während beides parallel läuft — ist in der Praxis fast immer überlegen, weil sie das Risiko in beherrschbare Etappen zerlegt.

Erosion verhindern, bevor sie beginnt

Am günstigsten ist die Erosion, die gar nicht erst entsteht. Prävention kostet einen Bruchteil der Sanierung — und besteht aus konkreten Praktiken, nicht aus guten Vorsätzen:

• Architektur-Grenzen in der CI durchsetzen. Modul- und Abhängigkeitsgrenzen werden nicht in einem Dokument festgehalten, sondern als automatische Tests (Architektur-Fitness-Funktionen), die einen verbotenen Zugriff zum Build-Fehler machen. Was die CI verbietet, erodiert nicht.
• Architecture Decision Records (ADRs). Jede wichtige Entscheidung wird mit ihrem Warum festgehalten. Das macht aus implizitem Kopfwissen explizites, überprüfbares Wissen — und überlebt jeden Personalwechsel.
• Refactoring als Teil der Definition of Done. Aufräumen ist kein eigenes Projekt, das man „irgendwann” macht, sondern Bestandteil jeder Story. Schuld wird getilgt, wo sie entsteht.
• Regelmäßige Architecture Reviews. Ein nüchterner Blick von außen, bevor die Drift sich festsetzt — präventiv statt reaktiv.
• Dependency-Updates als Routine. Kleine, regelmäßige Updates sind harmlos. Der gefürchtete „große Sprung” entsteht nur, wenn man die kleinen jahrelang aufschiebt.

Der gemeinsame Nenner: Erosion wird nicht durch einmalige Heldentaten gestoppt, sondern durch Disziplin, die in den normalen Arbeitsfluss eingebaut ist.

Erosion im KI-Zeitalter — beschleunigt oder gebremst?

Seit KI-Assistenten Code in Minuten produzieren, hat das Thema eine neue Schärfe. Die Werkzeuge sind eine zweischneidige Klinge.

Ohne Disziplin beschleunigen sie die Erosion. Wer ein LLM ungeprüft Code generieren lässt, bekommt mehr Code, schneller — aber nicht zwangsläufig verstandenen Code. Mehr Volumen bei weniger Durchdringung ist exakt das Rezept für Architektur-Drift, nur im Zeitraffer.

Richtig eingesetzt sind sie eines der besten Mittel dagegen. Genau die Arbeit, die Teams am liebsten aufschieben — Tests nachziehen, mechanische Refactorings, Dependency-Upgrades durcharbeiten, undokumentierten Code erklären — wird mit KI ungleich billiger. Die Kunst hat sich nicht verändert: Sie liegt weiterhin in der Architektur, in den Grenzen, im Warum. KI ist hier Werkzeug, nicht Architekt — eine Perspektive, die wir in Senior Engineering im KI-Zeitalter vertiefen. Die Disziplin entscheidet, auf welche Seite der Klinge Sie fallen.

Aus der Praxis: Erosion zurückdrängen bei Omniga

Wie das in der Realität aussieht, zeigt unser Projekt mit der Omniga GmbH & Co. KG, einem Multi-Brand-IT-Unternehmen aus Regensburg. Über Jahre war dort eine heterogene Anwendungslandschaft auf .NET Framework 4.6 organisch gewachsen — funktional stabil, aber mit hohen technischen Schulden, enger Kopplung und einer Runtime jenseits des Support-Fensters. Ein Lehrbuchfall erodierter Software.

Statt eines riskanten Big-Bang-Rewrites haben wir die gesamte Landschaft inkrementell auf .NET 8 migriert — priorisiert nach Kritikalität, mit durchgesetzten Architektur-Grenzen und modernisierten CI/CD-Pipelines. Das Ergebnis: deutlich reduzierte technische Schulden, eine einheitliche Plattform für interne Systeme und kundenseitige SaaS-Produkte — und keine Ausfallzeit während der gesamten Migration. Die ganze Geschichte steht in der .NET-Modernisierung für Omniga.

Fazit

Software-Erosion ist kein Versagen, sondern der Normalzustand jedes lebenden Systems. Sie lässt sich nicht abschaffen — aber kontrollieren. Der Unterschied zwischen einer Software, die in fünf Jahren noch trägt, und einer, die zum Sanierungsfall wird, liegt nicht in der Abwesenheit von Erosion, sondern im frühen, disziplinierten Gegensteuern: sichtbare Architektur-Grenzen, getilgte Schuld, aktuelle Abhängigkeiten, ein neutraler Blick von außen, bevor die Drift sich festsetzt.

Die Frage ist also nicht ob Ihre Software erodiert — sondern wie früh Sie anfangen, dagegenzuhalten.

---

Den Zustand einer Architektur ehrlich einzuordnen, ist Architekten-Arbeit — bei uns macht das ein Software-Architekt, kein Junior mit Checkliste. Wir benennen Risiken klar, sagen Ihnen ebenso deutlich, wo kein Handlungsbedarf besteht, und bewerten neutral — ohne uns automatisch um den Folge-Auftrag zu bewerben. Was dabei herauskommt, ist eine Software-Architektur-Roadmap, die Sie auch ohne uns umsetzen könnten. Die einzige offene Frage ist, wie früh Sie anfangen — bevor die Erosion es für Sie entscheidet.