Software Lifecycle Management: "Auch Nullen und Einsen werden alt"

Individuelles Projekt beginnt

Den Anfang der Geschichte kennt Ihr vermutlich alle: Man hat ein Projekt vor sich, und braucht eine Software, die man nicht von der Stange kaufen kann, sondern individuell baut. Eine schöne neue Website zum Beispiel, für die man nicht einfach nur ein fertiges Template nutzen kann.
Konzepte und Designs werden gemacht, das Prototyping gibt einen ersten Eindruck, vielleicht baut man währenddessen sogar noch einen Datenbestand auf... und man schreibt die Software, über Wochen und Monate. Je nach Komplexität sind mehrere Technologien involviert: Datenbank, Webserver, Applikationsserver; die Businesslogik wird vielleicht mit Java oder PHP umgesetzt, das Frontend mit HTML (oder gleich das Ganze mit einer JS-Technologie)... und schon wird deutlich, dass wir eben nicht über "eine Software" sprechen, sondern über einen ganzen Komponenten-Katalog, der unterschiedlichen Einflüssen und Lebensdauern unterworfen ist. Und es ist ein bisschen wie bei uns Menschen: Die Beteiligten altern unterschiedlich gut. Doch dazu gleich mehr.

Verschiedene Ansätze: Veränderung oder Erweiterung

Ist die Software einmal im Betrieb, gibt es verschiedene Ansätze: Vielleicht ist der Funktionsumfang so komplett und der Zweck so eng umrissen, dass lange keine Erweiterung gemacht wird. Vielleicht gibt es - auch bedingt durch ein agiles Projektvorgehen - mehrere Deliverables die nach GO Live liegen und die das MVP (Minimum viable Product) erweitern. Wir bei Kittelberger kennen Website-Systeme, die über Jahre hinweg jede Woche um kleine und große neue Funktionen/Inkremente erweitert werden, die dann weltweit ausgerollt werden - so ist "die Website" dann nicht ein Projekt, das endet, sondern fast schon ein Produkt welches weiter entwickelt wird. Das ist dann vermutlich der beste Fall, weil neue Funktionen auch oft neuere Komponenten erzwingen.

Also: Ist eine Software erstmal live, gibt es die unterschiedlichsten Szenarien für das, wie oft sie geändert oder erweitert wird. In beiden Fällen vergisst man leicht, was oben bereits angeklungen ist: Nicht alle Teile einer Software altern gleich gut.

Liefernde Systeme: Die Datenbank, aus der deine Produkte kommen (oder deine Stellen-Anzeigen, oder andere externe Datenquellen) ist nach außen vielleicht sogar nicht erreichbar - damit hast Du hier schonmal kein Sicherheitsproblem. Wenn es gut läuft, dann basiert der Export für die Website auf einem Standard-Format, das du auch nach einem Update der Datenbank weiter konsistent und validierbar erzeugen kannst.
Infrastruktur: Aktualität und Ausstattung deines Web-Servers oder Applikationsservers sind im Zweifel sicherheitsrelevant. Nicht selten hängt an der Version des Applikationsservers aber auch die Version der darauf lauffähigen Software (Beispiel: Du kannst auf einem aktuellen Tomcat einfach keine 10 Jahre alte Java-App mehr laufen lassen). Weitere Beispiele sind Updates der TLS-Version und andere scheinbare Kleinigkeiten, die auf einmal teure und riskante Abhängigkeiten haben.
Frontend/Backend: Meist müssen eingesetzte Bibliotheken und Komponenten hier häufiger aktualisiert werden, manche Versionssprünge sind sehr groß und bedingen anspruchsvolle Änderungen.

Weitere Faktoren und Risiken

Dazu kommen weitere Faktoren: Will man als Dienstleister oder Hersteller vielleicht auf eine neue Technologie setzen? Ist die bestehende Software zwar noch funktionsfähig und wird in kritischen Umgebungen eingesetzt, aber schlecht dokumentiert und wäre ihre Ablösung teuer - und gibt es vielleicht kaum jemanden mehr, der sie beherrscht? Was hier exotisch klingt, geht der deutschen Industrie seit Jahrzehnten mit der 60er Jahre Programmiersprache COBOL so.

Und egal ob Website-System oder interne Backend-Applikation: Die Risiken sind per se überall dieselben: Betrieb, Sicherheit - aber auch Flexibilität.
Und alle diese Risiken haben eins gemeinsam: Lang genug ignoriert, können sie richtig teuer werden.

"Aber es tut doch noch!"

Es gibt, neben einer gewissen technischen Komplexität, einen wichtigen Grund, der das Thema "End of Life" immer wieder unbeliebt macht. Er lässt sich am besten zusammenfassen in dem einen kleinen Satz: "Tut doch noch!"

Warum also Geld ausgeben für etwas, das noch funktioniert? Nicht selten ist ja die Pflege und Aktualisierung einer Software aufwändig, doch nach außen bleibt die Mühe oft unsichtbar (oft genug ist das ja sogar das Ziel!).

Damit wir uns richtig verstehen: Wir Kittelbergers sind Schwaben und verstehen jeden, der Geld und Mühe lieber spart, wenn er das Gefühl hat, dass es nicht nutzt. Und tatsächlich ist die Wartung und Aktualisierung einer Software ohne Funktions-Änderung häufig ein Kostenpunkt, dem scheinbar aus User-Sicht nicht so recht ein Nutzen gegenübersteht. Oder zumindest: Ein Nutzen, den man zuerst sichtbar machen muss. Denn wer würde abstreiten, dass eine stabile und sichere Applikation nützt?

One by one, two by two

Wir empfehlen also, das Thema "Lebenszyklus" für jede eingesetzte Software immer mal wieder aufs Tableau zu nehmen, wenn z.B. die jährliche Verlängerung der Betriebsangebote auf dem Programm steht, oder wenn eine größere Änderung ohnehin Eingriffe in die Architektur verlangt.

Sehr oft ist es dann nämlich möglich,

eine Aktualisierung im Zuge größerer Änderungen zeitgleich einzuplanen und die Aufwände überschaubar zu halten
mit (wirklich genügend) Vorlauf die Ablösung und den Austausch bestimmter Komponenten zu planen
aus diesem Vorgehen wertvolle Impulse zu ziehen, die auch funktional neue Türen öffnen - und dann macht's auch dem User Spaß :-)

Zusammengefasst: Es gibt keine Faustregel für die Lebenszeit einer Software. Wenn man's gut macht, dann wird ein System immer wieder neu bewertet, überarbeitet und mit neuen Komponenten versehen. Darin liegen eine Menge Möglichkeiten - viel Erfolg dabei!