Wartungskosten von Software: Was nach dem Launch kommt

Was nach dem ersten Tag anfängt

Am Tag nach dem Launch läuft die Anwendung. Die Daten kommen rein, die Abläufe funktionieren, die Testphase ist vorbei. Für viele ist das der Moment, in dem das Projekt endet. Tatsächlich beginnt hier etwas anderes.

Software ist kein Gebäude, das fertig gebaut wird und dann steht. Sie ist eingebettet in eine Umgebung, die sich ohne Zutun verändert. Der Browser, den Ihre Kunden nutzen, erscheint in einer neuen Version. Ein externer Dienst, an den Ihre Anwendung Daten übermittelt, ändert sein Verhalten. Das Betriebssystem des Servers bekommt ein Sicherheitsupdate. Nichts davon ist eine Fehlfunktion. Es ist der normale Zustand einer Software, die in Betrieb ist.

In den ersten Wochen nach dem Launch sammeln sich Beobachtungen an. Jemand aus dem Team stellt fest, dass ein bestimmter Schritt umständlicher ist als gedacht. Ein Kunde fragt nach etwas, das in der Planungsphase kein Thema war. Eine Ausnahme tritt auf, für die es noch keine Regel gibt. Jede dieser Beobachtungen ist für sich klein. Zusammen bilden sie eine Liste, die länger wird, noch bevor die erste abgehakt ist.

Was sich verändert, ohne dass jemand es beschlossen hat

Ein Teil der Veränderungen kommt von außen. Zahlungsanbieter aktualisieren ihre Anforderungen. Behörden ändern Formularvorgaben. Steuerregeln verschieben sich. Die Anwendung war korrekt — für den Stand des Tages, an dem sie fertiggestellt wurde. Dieser Stand altert.

Ein anderer Teil kommt von innen. Menschen, die das System täglich bedienen, entwickeln Gewohnheiten, die an der ursprünglichen Entwurfslogik vorbeigehen. Nicht aus Böswilligkeit, sondern weil der Alltag anders aussieht als der Entwurf es vorgesehen hat. Irgendwann befinden sich Daten im System, die so nicht hätten entstehen sollen, und niemand kann mehr genau sagen, wie sie dort hinkamen.

Dann gibt es die personellen Wechsel. Wer das System eingeführt hat, kennt seine Eigenheiten — welche Eingabe welchen Effekt hat, wo Vorsicht geboten ist, was unter bestimmten Umständen nicht funktioniert. Wer neu dazukommt, kennt das nicht. Dieses Wissen ist selten aufgeschrieben, nicht weil es niemanden interessiert, sondern weil es sich in dem Moment, in dem alles läuft, nicht dringlich anfühlt.

Die ersten Monate als Maßstab

Was in den ersten Monaten nach dem Launch an laufender Betreuung anfällt, ist in den meisten Projekten der verlässlichste Hinweis darauf, was dauerhaft anfallen wird. Nicht als Ausnahme, sondern als Grundlast. Ein System, das in dieser Phase regelmäßig kleine Eingriffe braucht, wird das in einem Jahr noch brauchen — und in zwei Jahren, wenn sich die Umgebung weiter verändert hat.

Externe Abhängigkeiten, die sich ohne Ankündigung ändern
Nutzungsgewohnheiten, die sich vom ursprünglichen Entwurf entfernen
Wissen, das nur in den Köpfen derjenigen lebt, die täglich damit arbeiten
Anforderungen, die erst sichtbar werden, wenn echte Daten im System sind

Das ist keine Kritik an der Entwicklung. Es ist die Beschreibung dessen, was Software ist: ein Artefakt, das gepflegt wird, solange es genutzt wird. Wer das einkalkuliert, bevor das Projekt beginnt, trifft andere Entscheidungen als jemand, der davon ausgeht, dass mit dem Launch die Rechnung endet.

Warum Änderungen teurer sind als das Original

Eine neue Funktion kostet beim ersten Mal oft weniger als dieselbe Funktion ein Jahr später, wenn sie in einen gewachsenen Bestand eingefügt werden muss. Das klingt zunächst unlogisch — schließlich steht ja schon etwas. Aber genau das ist der Punkt: Es steht schon etwas, und jede neue Zeile muss sich mit dem Bestehenden vertragen.

Was beim Bau noch nebeneinander stand, ist nach einem Jahr miteinander verwoben. Eine Änderung an der Auftragsmaske berührt die Rechnungslogik. Die Rechnungslogik hängt an der Kundendatei. Die Kundendatei war ursprünglich für drei Felder gedacht, hat aber inzwischen zwölf. Wer jetzt etwas ändern will, muss zunächst verstehen, was diese Verflechtung bedeutet — und das kostet Zeit, bevor die eigentliche Arbeit beginnt.

Was beim Original fehlte, zeigt sich jetzt

Viele Entscheidungen, die beim ersten Aufbau getroffen wurden, sind nicht dokumentiert. Nicht weil jemand geschludert hätte, sondern weil im Moment der Entscheidung klar war, warum es so gemacht wird — und Klarheit selten aufgeschrieben wird. Ein Jahr später ist diese Klarheit weg. Wer die Anwendung weiterentwickelt, muss rekonstruieren, was damals gedacht war, bevor er entscheiden kann, was jetzt sinnvoll ist.

Das gilt besonders für Ausnahmen. Jede Fachanwendung kennt den Fall, der eigentlich nicht vorkommen sollte und dann doch vorkam. Der Workaround dafür wurde irgendwo eingebaut — manchmal sauber, manchmal schnell, weil Druck war. Wer die Stelle nicht kennt, läuft Gefahr, sie mit einer neuen Änderung zu überlagern. Das Ergebnis sind Fehler, die in der Abnahme nicht auftauchen, weil der Testfall für diesen einen Ausnahmefall nicht existiert.

Die Kosten der Rücksicht

Je länger eine Anwendung läuft, desto mehr hängt von ihr ab. Andere Abläufe, andere Personen, gespeicherte Daten aus Monaten oder Jahren. Eine Änderung, die in einem neuen System einfach wäre, muss im Bestand mit Rücksicht auf alles Vorhandene gemacht werden:

Daten, die im alten Format vorliegen und nicht pauschal umgeschrieben werden können
Nutzerinnen und Nutzer, die sich an bestimmte Abläufe gewöhnt haben und bei Änderungen neu eingearbeitet werden müssen
Abhängigkeiten zu anderen Systemen, die beim ersten Bau noch nicht bekannt waren, weil sie damals noch nicht existierten

Keine dieser Rücksichten ist überflüssig. Aber jede kostet, und die Summe davon erklärt, warum eine scheinbar kleine Erweiterung im Angebot so ausfällt, dass sie verwundert.

Was dabei selten ausgesprochen wird: Der Aufwand für eine Änderung spiegelt nicht den Wert der Änderung, sondern den Zustand der Basis, auf der sie steht. Wer früh in eine saubere Grundlage investiert hat, zahlt weniger — nicht weil die Änderung einfacher ist, sondern weil der Weg dahin kürzer ist. Wer früh gespart hat, zahlt später, und dann oft mehr als einmal.

Die Stellen, an denen Zeit verloren geht — nicht in der Entwicklung

Wenn eine Änderung länger dauert als erwartet, suchen die meisten Beteiligten das Problem im Code. Tatsächlich liegt der größte Teil der verlorenen Zeit woanders: in Abstimmungen, Wartezeiten und Entscheidungen, die niemand trifft, weil niemand zuständig ist.

Die Lücke zwischen Meldung und Auftrag

Jemand im Unternehmen bemerkt, dass etwas nicht stimmt. Die Schaltfläche reagiert nicht wie erwartet. Ein Bericht zeigt falsche Zahlen. Diese Beobachtung landet als Nachricht, manchmal als Anruf, manchmal gar nicht — weil die Person nicht sicher ist, ob es sich lohnt, es anzusprechen. Bis aus einer Wahrnehmung ein klarer Auftrag wird, vergehen in vielen Betrieben Tage. Nicht weil niemand reagieren will, sondern weil nicht festgelegt ist, wer etwas entscheidet, was genau behoben werden soll und ob es dringend ist.

Das Beschreiben, was eigentlich gemeint ist

Wenn der Auftrag dann kommt, beginnt ein zweiter Zeitverlust: das Verstehen. "Das Feld soll sich anders verhalten" ist ein Ausgangspunkt, kein Auftrag. Was genau soll passieren? Unter welchen Bedingungen? Was soll danach noch funktionieren, was darf sich verändern? Diese Fragen werden nicht aus Bösartigkeit gestellt — sie sind notwendig. Aber jede Rückfrage kostet Zeit auf beiden Seiten, und mehrere Rückfragen hintereinander verschieben den Start um Tage.

Die Prüfung, die niemand einplant

Wenn eine Änderung fertig ist, muss jemand prüfen, ob sie das tut, was gemeint war. Diese Person ist selten der Entwickler — sie kennt den Zusammenhang, aber nicht den Alltag, in dem die Anwendung läuft. Die Prüfung liegt also bei einer Fachkraft, die gleichzeitig Angebote schreibt, Termine wahrnimmt und Telefonate führt. Feedback kommt, wenn es kommt. Manchmal nach einem Tag, manchmal nach zwei Wochen. In dieser Zeit hängt die Änderung fertig und unberührt.

Eine Meldung, die keine klare Zuständigkeit hat, wandert — von Person zu Person, von Kanal zu Kanal.
Ein Auftrag ohne Priorität wird bearbeitet, wenn Kapazität da ist. Nicht wenn er dringend ist.
Feedback, das nicht terminiert ist, kommt dann, wenn es passt — was selten mit dem Zeitplan zusammenfällt.

Das sind keine Versäumnisse einzelner Personen. Es sind Lücken in der Art, wie Softwarebetrieb organisiert ist — oder genauer: wie selten er überhaupt organisiert ist. Wer eine Anwendung in Betrieb hat, hat meistens geregelt, wer sie entwickelt. Wer zuständig ist, wenn etwas geprüft, entschieden oder freigegeben werden muss, ist seltener festgelegt.

Was eine Anwendung stabil hält und was sie zermürbt

Stabilität in Software entsteht nicht durch einen guten Start. Sie ist das Ergebnis von Entscheidungen, die in den ersten Monaten oft unsichtbar bleiben — und die sich erst zwei oder drei Jahre später zeigen.

Was Stabilität erzeugt

Eine Anwendung, die langfristig zuverlässig läuft, hat meistens eine Eigenschaft: Sie wurde so gebaut, dass jeder Teil eine klare Aufgabe hat und nur diese. Wo Zuständigkeiten sauber getrennt sind, lässt sich etwas ändern, ohne dass drei andere Stellen aufhören zu funktionieren. Das klingt selbstverständlich. Es ist selten.

Hinzu kommt, wie die Anwendung mit Fehlern umgeht. Nicht jeder Fehler lässt sich verhindern — ein Dienst, von dem die Anwendung abhängt, kann vorübergehend nicht erreichbar sein. Eine Antwort kann ausbleiben. Was dann passiert, ist eine Gestaltungsfrage: Bricht das System ab, oder informiert es und wartet? Anwendungen, die freundlich mit dem Unerwarteten umgehen, erzeugen deutlich weniger Folgeaufwand.

Auch die Dokumentation hat hier ihren Platz — nicht als Nachschlagewerk für Entwickler, sondern als Gedächtnis. Wer gebaut hat, warum etwas so gebaut wurde, welche Ausnahmen bewusst eingebaut wurden: Das ist das Wissen, das sechs Monate nach dem Launch fehlt, wenn jemand eine Änderung vornehmen soll und nicht weiß, was er damit berührt.

Was eine Anwendung zermürbt

Der häufigste Auslöser ist nicht ein großer Fehler. Es sind kleine Zugeständnisse, die sich summieren. Eine Funktion wird schnell eingebaut, weil der Termin drängt. Die Stelle, an der sie eingefügt wird, ist nicht die richtige — aber die richtige Stelle würde zwei Wochen kosten. Drei Monate später kommt die nächste Funktion. Sie passt auch nicht richtig. Nach einem Jahr gibt es Dutzende solcher Stellen, und wer etwas ändern will, navigiert durch Entscheidungen, die damals niemand aufgeschrieben hat.

Abhängigkeiten von Anbietern, die ihre Bedingungen oder ihr Verhalten ändern — und die eigene Anwendung merkt es als letzte.
Daten, die über die Jahre in ein Format gewachsen sind, das niemand ursprünglich so geplant hat.
Funktionen, die für zehn Nutzerinnen und Nutzer gebaut wurden und jetzt von zweitausend genutzt werden — ohne dass irgendjemand die Grundlagen angepasst hat.

Keiner dieser Punkte ist ein Versagen. Sie sind die normale Entwicklung einer Anwendung, die wächst. Der Unterschied liegt darin, ob das jemand im Blick hat oder nicht. Wo niemand regelmäßig prüft, ob die Fundamente noch zur Last passen, die darauf steht, wächst der Aufwand für jede einzelne Änderung — still und ohne Vorwarnung. Nicht weil schlechte Arbeit geleistet wurde, sondern weil gute Arbeit, die nicht gepflegt wird, mit der Zeit aufhört, gute Arbeit zu sein.

Woran man früh erkennt, dass es teurer wird als geplant

Die meisten Budgetüberschreitungen kündigen sich an. Nicht in Zahlen, sondern in Verhaltensweisen — von der Software, von den Entwicklerinnen und Entwicklern, manchmal auch von den eigenen Mitarbeiterinnen und Mitarbeitern. Wer weiß, worauf er achtet, sieht sie früh genug.

Jede Kleinigkeit braucht eine Erklärung davor

Wenn Sie mit einer einfachen Bitte beginnen — ein Feld umbenennen, eine Spalte hinzufügen, eine Regel ändern — und die Antwort lautet: „Dafür müssen wir erst verstehen, wie das mit dem Rest zusammenhängt", ist das kein Zeichen von Gründlichkeit. Es ist ein Zeichen, dass niemand mehr den Überblick hat. Eine Anwendung, die nach zwei Jahren niemand mehr vollständig versteht, kostet bei jeder Änderung das Doppelte der eigentlichen Arbeit — weil die Hälfte der Zeit damit verbracht wird, sie zu rekonstruieren.

Fehler tauchen dort auf, wo nichts angefasst wurde

Sie beauftragen eine Korrektur in der Auftragsmaske, und plötzlich stimmt die Rechnungsnummer nicht mehr. Dieser Zusammenhang war nicht vorhersehbar und auch nicht gemeint — aber er ist da. Wenn Änderungen an einer Stelle regelmäßig Probleme an einer anderen auslösen, ist das kein Pech. Es ist ein Muster, das sich wiederholen wird. Jede neue Funktion macht es wahrscheinlicher, dass die nächste Änderung etwas zerbricht.

Die Anwendung hängt an einer Person

Wenn der Satz „Frag lieber erst Thomas, bevor wir das anfassen" zur Standardantwort wird, ist das kein Kompliment für Thomas. Es bedeutet, dass das Wissen über die Anwendung nicht dokumentiert, nicht übertragbar und nicht ersetzbar ist. Fällt diese Person aus — durch Krankheit, Kündigung oder einfach Urlaub — steht alles still. Abhängigkeiten dieser Art werden selten kleiner.

Was man selbst beobachten kann

Anfragen, die früher in einem Tag erledigt waren, dauern jetzt eine Woche — ohne dass die Anfragen komplexer geworden wären.
Neue Mitarbeiterinnen oder Mitarbeiter brauchen unverhältnismäßig lange, um mit dem System produktiv zu werden.
Die Anleitung, die beim Launch erstellt wurde, stimmt nicht mehr mit dem überein, was die Software tatsächlich tut.
Aktualisierungen werden aufgeschoben, weil alle wissen, dass danach etwas nicht mehr funktioniert.

Keines dieser Zeichen ist ein Notfall für sich. Zusammen beschreiben sie eine Anwendung, deren Wartung mit jedem Monat aufwendiger wird — nicht weil die Anforderungen gewachsen sind, sondern weil das Fundament nicht dafür gebaut wurde, zu wachsen. Der Punkt, an dem eine Neuentwicklung günstiger ist als weitere Pflege, kommt in solchen Systemen früher als erwartet.