Wartung

Die Wartungsphase klärt, was nach dem Go-Live geschieht: den längsten Teil des Lebenszyklus, den laufenden Betrieb mit Fehlerbehebung, Anpassungen und kleineren Erweiterungen. Hier zeigt sich, ob Architektur, Codequalität und organisatorische Entscheidungen aus den früheren Phasen tragfähig waren.

Monitoring, Support und gelebte Betriebsprozesse liefern kontinuierlich Signale über Stabilität, Nutzung und Verbesserungspotenziale. Wartung ist damit weniger ein Abschluss als eine fortlaufende Rückmeldeschleife in den gesamten SDLC.

Was in der Wartungsphase geklärt wird

Vier Bereiche bestimmen, wie gut eine Lösung durch ihren Alltag kommt:

• Betrieb: Läuft das System stabil und werden Störungen schnell erkannt und behoben?
• Weiterentwicklung: Welche kleineren Anpassungen und Erweiterungen sind nötig, ohne gleich ein neues Projekt auszulösen?
• Technische Schulden: Welche der bewusst eingegangenen Kompromisse werden jetzt fällig?
• Rückkopplung: Welche Erkenntnisse aus dem Alltag fließen zurück in die Planung künftiger Vorhaben?

Anders als in den vorherigen Phasen gibt es hier kein klar definiertes Ende. Wartung läuft, solange eine Lösung im Einsatz ist, oft Jahre nach den Entscheidungen, die sie einmal geprägt haben.

Wer typischerweise beteiligt ist

Betrieb und Operations überwachen das System und reagieren auf Störungen, häufig als Erste, die von einem Problem erfahren. Der Support ist die eigentliche Anlaufstelle für Nutzer und sammelt dabei nebenbei wertvolles Feedback, das selten von allein irgendwo landet. Das Entwicklungsteam behebt Fehler und setzt kleinere Erweiterungen um, meist mit deutlich weniger Kapazität, als während der eigentlichen Entwicklung zur Verfügung stand. Product Owner oder Management entscheiden, wie viel Priorität Wartung neben neuen Vorhaben tatsächlich bekommt, eine Entscheidung mit langfristigen Folgen.

Typische Risiken

Wird Wartung lediglich als Kostenblock verstanden, veralten Systeme schleichend, technische Schulden steigen an und dieselben Fehlentscheidungen wiederholen sich in neuen Vorhaben. Wer Wartung von Anfang an gering priorisiert, zahlt diesen Preis meist erst Jahre später, wenn er kaum noch mit der ursprünglichen Entscheidung in Verbindung gebracht wird.

Was aus der Wartung in die nächste Planung einfließen sollte

Wartung ist die einzige Phase ohne feste nächste Station, sie mündet stattdessen zurück in die Planung künftiger Vorhaben:

Rückfluss-Artefakt	Warum es zählt
Dokumentierte Störungen und ihre Ursachen	Verhindert, dass sich bekannte Fehler in neuen Vorhaben wiederholen
Liste angehäufter technischer Schulden	Macht sichtbar, was künftige Planung berücksichtigen muss
Nutzungs- und Supportdaten aus dem Alltag	Zeigt, was Nutzer tatsächlich brauchen, nicht nur was einmal angenommen wurde
Rückblick auf frühere Architektur- und Design-Entscheidungen	Liefert gelernte Lektionen für die nächste Design-Phase

Fragen, die sich alle Beteiligten stellen sollten

• Wie fließen Erfahrungen aus Betrieb und Support systematisch in neue Planungs- und Analysephasen ein?
• Wird Wartung mit ausreichend Kapazität und Priorität versehen, oder nur mit dem, was nach neuen Projekten übrig bleibt?

Diese Fragen sind für Management besonders relevant, weil Wartungsbudgets oft als Erstes gekürzt werden, wenn an anderer Stelle gespart werden muss.

Im Beispiel: Ablösung des Ticketsystems

In der Wartung unseres Beispiels zur Systemablösung zeigt sich über Monate und Jahre, ob Architektur, Codequalität und Prozessentscheidungen aus den vorherigen Phasen tragfähig sind, oder ob sich technische Schulden und organisatorische Reibungen aufbauen. Erkenntnisse aus dieser Phase fließen im besten Fall direkt in die Planung des nächsten Vorhabens ein, der Kreislauf beginnt von vorn.