Wartungshölle? Nein, danke!

Herausforderungen und Lösungsansätze für die Wartung von Individual-Software

Individual-Software löst sehr individuelle Probleme und stellt die IT deshalb schon während ihrer Entwicklung vor besondere Herausforderungen. Alle erfolgreichen – im Sinne von produktiv gesetzten – Individual-Softwareprodukte haben dabei eine entscheidende Gemeinsamkeit: Sie erfordern über einen in der Regel sehr langen Zeitraum kontinuierliche Wartung, Pflege und Weiterentwicklung der entwickelten Software. Leider wird dem Thema Wartung oft nicht rechtzeitig die notwendige Aufmerksamkeit geschenkt, und das Wartungsteam, die Auftraggeber und die Nutzer des Systems landen alle gemeinsam in der Wartungshölle. Generell möchte ich im Folgenden Sie als meine Leser für dieses Thema sensibilisieren. Konkret stelle ich dazu zunächst dar, was eigentlich alles falsch läuft, um im Anschluss daran Lösungsoptionen aufzuzeigen.

Es gibt im Groben zwei unterschiedliche Optionen die Softwarewartung organisatorisch zu gestalten. Im ersten Fall betreuen größere Projektteams die Software dauerhaft selbst. Dies wird dann gerne als “You build it, you run it ” bezeichnet. Im zweiten Fall übergeben die Projektteams die Software für die Pflege an Wartungsteams. Teilweise erfolgt dies dann auch von einem IT-Dienstleister an den Auftraggeber oder aber umgekehrt. Insbesondere im zweiten Fall zeigt sich: Wird die Wartung nicht frühzeitig berücksichtigt, ergeben sich immer wieder die gleichen Probleme. Änderungen an der sich im produktiven Betrieb befindlichen Software werden notwendig, und diese Änderungen sind dann häufig gleichzeitig:

• exorbitant teuer
• mit sehr hohem Risiko behaftet
• oder extrem langwierig.

Am Ende machen die Änderungen dann keinem der Beteiligten Spaß. Sie erzeugen Schmerzen und Frust bei Entwicklern, Auftraggebern und Anwendern. Hohe Kosten,  Kündigungen frustrierter Mitarbeiter, Reputationsverluste auf Kundenseite führen zu Umsatzverlusten und können dem Unternehmen nachhaltig schaden.

Aber muss das so sein? Muss das so weh tun? Kann man die Schmerzen und die unangenehmen Folgen lindern oder vielleicht sogar komplett vermeiden?

Stellen wir uns zunächst einmal die Frage: Was läuft eigentlich falsch?

Leider erlebe ich oft genug, dass sich zu Beginn der Produktentwicklung – also zu Beginn des eigentlichen Software-Entwicklungsprojekts –  weder die Auftraggeber noch die Projektdurchführenden intensiv genug Gedanken über die spätere Wartung und Weiterentwicklung machen. Aus diesem Grund berücksichtigten die beteiligten Teams und Stakeholder das Thema nicht in angemessener Weise, und auch die zur Entwicklung der Software verwendeten Prozesse beachten es kaum.

Abb. 1: Software-Produktlebenszyklus

Softwareprodukte folgen in etwa dem im obigen Bild dargestellten Produktlebenszyklus. In der Einführungsphase erstellt das, in der Regel einige Entwickler starke, Projektteam initial die Software. Bis zur Produktivsetzung ist das Team voll fokussiert auf die Fertigstellung des Produkts. Nach der Produktivsetzung übernimmt das Projektteam häufig dann auch zunächst die Wartung und Weiterentwicklung im Übergang in die Wachstumsphase. Früher oder später wird dann aber das Entwicklungsteam vom Produkt abgezogen und die Wartung an eine andere Organisationseinheit und andere Entwickler übergeben. Diese sollen dann in der Reifephase die Wartung, Pflege und Weiterentwicklung übernehmen.

Solange das Projektteam noch die Wartung und Weiterentwicklung übernimmt, treten in der Regel kaum Probleme auf. Da neben der Entwicklung neuer Features auch immer mal wieder Wartungsfälle zu behandeln sind, sinkt naturgemäß die Produktivität etwas. Gut aufgesetzte Prozesse helfen hier zwischen den unterschiedlichen Aufgabentypen zu vermitteln und Reibungsverluste gering zu halten. Das Projektteam kennt die (selbstentwickelte) Software in- und auswendig. Fehler werden schnell gefunden und Risiken bei der Behebung sind bekannt und können adäquat berücksichtigt werden.

Spätestens beim mehr oder weniger geplanten Übergang an ein Wartungsteam fangen dann aber die Probleme an:

• Die Software ist nicht wirklich wartbar.
• Es fehlen ausreichende und automatisierte Tests.
• Die Dokumentation ist nicht geeignet, um den Entwicklern die benötigten Informationen zu liefern.

Die Liste lässt sich fast beliebig fortführen. Nicht zu unterschätzen ist darüber hinaus, dass die Reifephase und somit die Wartung in der Regel einen deutlich längeren Zeiträume umfassen wird, als die beiden vorherigen Phasen. Die Einführungs- und Wachstumsphase der Individualsoftware dauert oft nicht länger als ein bis zwei Jahre. Es ist aber nicht unüblich, die Software im Anschluss an diese Phasen über Jahre hinweg zu verwenden und zu betreiben. Nach ein bis zwei Jahren Spaß bei der Entwicklung der Software soll jetzt also ein deutlich längerer frustrierender Zeitraum der Wartung und Weiterentwicklung folgen? Das muss nicht so sein!

Stellen wir uns also die nächste Frage: Was ist zu tun?

Allgemeingültige Empfehlungen kann es nicht geben. Alles ist individuell:

• Die zu entwickelnde Software ist per Definition individuell.
• Die Organisationen, die die Software erstellen und verwenden, sind individuell.
• Fertigungstiefen und Arten der Zusammenarbeit zwischen Kunden, Fachabteilungen, IT und Dienstleistern sind sehr individuell.

Immer gleich bleibt aber, dass alle Beteiligten schon frühzeitig, also beim Aufsetzen des Software-Entwicklungsprojekts, über Softwarewartung nachdenken sollten. Häufig erlebe ich in Projekten, dass diese Überlegungen ausbleiben. Dies wird von den Verantwortlichen dann damit begründet, dass ja zu diesem frühen Zeitpunkt noch gar nicht absehbar sei, was in ein bis zwei Jahren passieren werde. Auch wenn exakte Prognosen schwierig bis unmöglich sind, sollte dieser Umstand die Kunden, die Auftraggeber und das Projektteam aber nicht davon abhalten unter bestimmten Annahmen zumindest grobe Festlegungen zu treffen. Diese sind dann im Sinne einer agilen Planung fortwährend zu überprüfen und immer wieder anzupassen.

Alle Projektbeteiligten sollten auf jeden Fall folgende Fragestellungen beachten:

• Welche Änderungshäufigkeit wird erwartet?
  Ist das Umfeld eher stabil oder sind aufgrund von Änderungen an Geschäftsmodellen, Geschäftsprozessen oder aber auch neuen gesetzliche Anforderungen regelmäßige Anpassungen zu erwarten?
• Wie soll die Wartung organisatorisch aufgesetzt werden?
  “You build it, you run it” durch das Entwicklerteam oder aber ein Übergang an ein Wartungsteam? Vielleicht auch eine Kombination aus beiden Ansätzen? Existiert das für die Wartung vorgesehene Team bereits? Falls nein, wann und wie wird es aufgebaut? Ist ein Übergang in der Verantwortung von einem Dienstleister oder zu einem Dienstleister geplant?
• Wie kann Wissen erhalten und weitergeben werden?
  Wie kann verhindert werden, dass das Wissen aufgrund eines Wechsels in der Zuständigkeit verloren geht? Welche Dokumentation soll entstehen, um die Software später warten zu können? Wie bleibt diese Dokumentation aktuell?
• Wie kann die Software “wartungsfreundlich” entwickelt werden?
  Wie können Werkzeuge und Infrastruktur so bereitgestellt werden, dass die Wartung erleichtert wird?
• Welche Regelungen und Vereinbarungen sollen in Bezug auf Service Level Agreements für den Betrieb getroffen werden?
  Wie wird die Wichtigkeit der Software für das Geschäft des Auftraggebers und wie wird das Nutzungsverhalten der Anwender eingeschätzt? Welche Auswirkungen hat dies auf Organisationsstrukturen und abzuschließende Verträge und bereitzustellende Wartungsbudgets?

Meiner Erfahrung nach hat es sich bewährt, diese Fragestellungen schon beim Aufsetzen der Software-Entwicklungsvorhaben anhand einer Checkliste strukturiert zu prüfen. In diesem Zuge werden dann in Abstimmung zwischen allen Projektbeteiligten erste grobe Annahmen und Festlegungen getroffen. Bei Bedarf werden Maßnahmen und Folgeaktivitäten definiert.

Abb. 2: Auszug aus einer bei codecentric verwendeten Checkliste

In regelmäßigen Abständen und zu bestimmten Meilensteinen im Produktlebenszyklus, wie zum Beispiel der Produktionseinführung, holt das Projektteam die Checkliste erneut hervor und aktualisiert die Maßnahmen auf Basis der neuen,  mit ziemlicher Sicherheit veränderten Situation. Beim Übergang der Wartungsverwantwortung an ein Wartungsteam erfolgt diese Aktualisierung natürlich zusammen mit eben diesem Wartungsteam.

Und eine letzte Frage: Welche konkreten Maßnahmen können die Projektverantwortlichen festlegen?

Was aber kann Software nun wartbarer machen? Was sorgt dafür, dass Sie der Wartungshölle entgehen oder zumindest die Temperaturen in dieser erträglich halten können? Im Folgenden stelle ich exemplarisch und ohne ins Detail zu gehen ein paar Lösungsansätze für die oben stehenden Fragestellungen dar. Es sei noch einmal betont, dass es aufgrund der hohen Individualität keine allgemeingültigen Best Practices geben kann.

Erzeugen Sie wartbare, gut strukturierte Software:

Beachten Sie bei der Entwicklung der Software die Prinzipien des Softwarecraftmanships . Denken Sie vor allem an regelmäßige Aktualisierungen in Bezug auf Libraries und Tools, an Refactoring und den Abbau beziehungsweise die Kontrolle von technischen Schulden.

Setzen Sie auf Automatisierung:

Versuchen Sie einen hohen Automatisierungsgrad in Bezug auf Tests, Provisionierung von Entwicklungsumgebungen, CI und CD zu erreichen. Setzen Sie auf DevOps-Ansätze und auf flexible und skalierbare Infrastrukturen. Denken Sie rechtzeitig an Applikationsmonitoring in Ergänzung zum in der Regel berücksichtigten Infrastrukturmonitoring.

Sorgen Sie für eine gute Wissensverteilung:

Verteilen Sie Wissen gezielt, und vermeiden Sie Kopfmonopole. Übergeben Sie Wissen nicht über Schulungsveranstaltungen, sondern durch die gemeinsame Bearbeitung konkreter Aufgabenstellungen. Erzeugen sie eine adäquate Dokumentation (“So viel wie nötig, so wenig wie möglich”), und halten Sie diese aktuell.

Definieren Sie klare Zuständigkeiten:

Führen Sie Überlegungen zu Teamstrukturen und Prozessen durch. Setzen Sie dabei aber bitte auf leichtgewichtige und flexible Lösungen. Verwenden Sie zum Beispiel Kanban anstelle von Scrum, um auf kontinuierliche Verbesserung zu setzen.

Erzeugen Sie ein handlungsfähiges und motiviertes Wartungsteam:

Investieren Sie in Ihre Mitarbeiter. Denken Sie an Aus- und Weiterbildung. Setzen Sie auf Mitarbeiter mit hoher Problemlösungsfähigkeit (“T-Shaped People”) und stellen Sie die Verfügbarkeit von Spezialisten zur Lösung von Spezialproblemen sicher.

Fazit

Es gibt  für die Wartung von Individual-Software leider keine allgemeingültigen Best Practices. Dies darf aber nicht als Entschuldigung dafür dienen, das Thema so lange unberücksichtigt zu lassen, bis es zu spät ist und wir uns dann sprichwörtlich in der Wartungshölle wiederfinden. Es geht nicht darum allgemeingültig zu definieren, wie mit dem Thema umgegangen werde soll. Vielmehr ist es wichtig frühzeitig und rechtzeitig erste Überlegungen anzustellen und diese fortwährend zu hinterfragen und zu aktualisieren. Berücksichtigen Sie also die Aspekte der Wartung von Individual-Software rechtzeitig, angemessen und ganzheitlich. Nur so können Sie die Schmerzen und den Frust in der Wartungsphase Ihrer Softwareprodukte verringern. Nur so kann Wartung gelingen und dann sogar Spaß machen.

Übrigens: Dieser Blog Post erschien ursprünglich in der Spezialausgabe „Digitalisierung“ des codecentric Softwerker-Magazins. Warum ein ganzes Heft zum Thema Digitalisierung? Weil der Umstand, dass die Digitalisierung unsere Wirtschaft in vielen Bereichen verändert kein Märchen, nicht nur „the next big thing“ und kein leeres Buzzword Bingo darstellt. 
Jetzt die Ausgabe kostenlos anfordern .