Warum Software verrostet und wie wir gegen den Verfall ankämpfen.

Fertig?

Eine Applikation ist schnell mal geschrieben. Dann ist sie fertig. Dann ist sie fertig? Dann beginnt erst das eigentliche Problem, nämlich die Applikation auf aktuellem Stand zu halten. Dies trifft besonders auf Business-Applikationen zu, deren Funktion oft über viele Jahre erhalten und an die aktuellen Anforderungen angepasst werden soll. Macht man das nicht, so verrottet sie langsam und Rufe werden laut, sie von Grund auf neu zu schreiben. Das versuchen wir aus mehreren Gründen zu vermeiden, die wir aber an dieser Stelle nicht ausführen wollen. Vielmehr stellen wir die Frage, warum Applikationen oft nicht auf modernem Stand gehalten werden.

• Ein Grund ist, dass Applikationen oft in Projekten entwickelt werden. Ein Projekt hat definitionsgemäß einen Anfang und ein Ende. Wenn das Projekt zu Ende ist, ist die Applikation nach Ansicht vieler Verantwortlicher fertig. Das Projektteam wird in eine Wartungsorganisation umgewandelt, die zwingend notwendige Features ergänzt. Technische Modernisierung wird hintangestellt.
• Manch ein/e Entwickler:in oder Architekt:in hat vielleicht Ideen, was man verbessern könnte, aber nachdem die Applikation ja “funktioniert” und “fertig” ist, ist kein Budget für grundlegende Änderungen vorhanden.
• Architekturen sind teilweise aufgebaut wie ein Kristall. Maximale Wiederverwendung von Code, ungebrochene Abhängigkeitsgraphen, wunderschön anzusehen. Doch bricht man einen Teil heraus, zersplittert das Werk in tausend Teile. Man kann nicht einen Teil ändern, ohne dass man alles ändert. Teilweise oder iterative Modernisierung ist in solchen Architekturen nicht möglich.
• Oft ist auch die Testabdeckung gering und wenn auch das Wissen über Designentscheidungen und Zusammenhänge verloren geht, so traut sich niemand mehr tiefer in den Code einzugreifen. Statt strukturellen Anpassungen werden Rucksäcke gebaut, die Komplexität steigt und immer mehr Abhängigkeiten kommen ins System.
• Vielfach fehlt auch eine langfristige Strategie, in welche Richtung sich eine Applikation verändern soll. Was bedeutet “besser” konkret? Wie kann ich messen, ob eine Änderung das System verbessert hat? Nachdem man nicht weiß, wohin man gehen soll, bleibt man stehen.

Je länger Systeme in solchem Zustand verharren, desto schwieriger wird eine Modernisierung, desto teurer wird die Wartung, desto unzufriedener werden alle Beteiligten, desto lauter wird der Ruf nach einem Schlussstrich: “Schreiben wir alles neu!”

Applikation auf ewig

Wenn uns niemand ein Endedatum für die Applikation sagen kann, oder dieses in ferner Zukunft liegt, gehen wir davon aus, dass die Applikation praktisch ewig leben wird. Sie wird unvorhergesehene Anforderungen erfüllen müssen, grundlegende Technologiewandel erleben und von Generationen an Entwickler:innen geändert werden. Damit das gelingen kann, müssen wir die oben genannten Probleme in den Griff bekommen.

Bewusstsein

Um ein Problem zu lösen, müssen wir uns des Problems bewusst sein. “Wir” sind in diesem Fall alle Beteiligten, vom Management angefangen (das wird was kosten), über die Entwickler:innen (wir machen das nicht husch-pfusch) bis zu den Benutzer:innen (der Fehler bleibt für immer, wenn ich ihn nicht melde). Die Antwort auf die Frage “Wie lange soll die Software bestehen bleiben?” soll an prominenter Stelle niedergeschrieben und kommuniziert werden.

Das Bewusstsein für die dafür nötige Qualität (Qualitätsbewusstsein) ist aber nie einfach da, es muss im Projekt oder in der Wartungsorganisation erarbeitet werden. In Retrospektiven, Pair Programming oder Code Reviews kann diesem Thema Platz eingeräumt werden.

Strategische Ziele

Leider haben wir keine unbegrenzten Ressourcen. Weder Geld, noch Zeit oder Energie. Wir müssen daher priorisieren, wie viele unserer Ressourcen wir wofür einsetzen. Dabei kommt uns zugute, dass nicht alles gleich wichtig ist. Nicht jedes Stück Software muss ewig leben und nicht jede Funktion muss hochperformant sein. Oft genügt einfach auch Durchschnitt. 

Um zu beurteilen, was wichtig ist, helfen uns strategische Ziele anhand deren wir Modernisierungsschritte priorisieren und Qualitätsanforderungen bewerten können. Auch hier ist die Kommunikation entscheidend. Eine Strategie, die niemand kennt, setzt niemand um.

Messen

Der Galileo Galilei (fälschlich?) zugeschriebene Satz 

“Man muß messen, was messbar ist, und messbar machen, was noch nicht messbar ist”

ist auch bei der Verfolgung seiner strategischen Ziele in der Softwareentwicklung hilfreich. Da strategische Ziele oft auch fachlich motiviert sind, sind hier fachliche Metriken besonders interessant. Dem Messen von fachlichen Metriken mit Observability-Werkzeugen aus dem Betrieb haben wir daher in Openly Shift Observability Left and Up einen eigenen Artikel gewidmet.

Budget

Neben dem Budget für Wartung und Neuentwicklung sollte vom Management ein fester Prozentsatz an Budget für technische Modernisierung bereitgestellt werden. Ungefähr ein Drittel für jeden der Bereiche kann als grober Richtwert angesehen werden. Siehe auch diese Capgemini Studie.

Änderbarkeit hat Priorität

Für die Architektur wird Änderbarkeit zum wesentlichen Qualitätsmerkmal. Die gute Nachricht ist, dass, sofern auf sauberes Design geachtet wird, Änderungen desto leichter werden, je öfter man sie macht. Ändern, was man ändern will und nicht ändern, was man nicht ändern will, spart langfristig auch Kosten in der Applikationswartung.

Plädoyer für Modernisierung

Große Software Systeme, wie sie im Enterprise Umfeld häufig anzutreffen sind, über Jahrzehnte hinweg  aktuell zu halten, ist eine der großen Herausforderungen der IT. Doch auch wenn es schwierig ist, ist es möglich, und eine erfolgreiche Modernisierungsstrategie bringt letztendlich nicht nur bessere Qualität, sondern spart langfristig auch Kosten.