Welche Haltbarkeit hat Software und wie wird diese signalisiert? In der Lebensmittelindustrie werden Produkte mit einem Mindesthaltbarkeitsdatum gekennzeichnet. Das schafft eine geteilte Erwartungshaltung und gibt eine gewisse Garantie. Bei sachgemäßer Handhabung ist das Produkt bis zu diesem Zeitpunkt in Ordnung.

Auch Software Produkte haben eine begrenzte Lebensdauer. Mit fortschreitender Zeit steigt das Risiko, dass sie nicht mehr funktionieren. Das passiert ohne äußerliche Einwirkung und obwohl der Quellcode selbst nicht verfällt. Die Ursache der begrenzten Lebensdauer ist in den Abhängigkeiten der Software zu finden. Diese haben ein Eigenleben und verändern sich auf einer anderen Zeitschiene. Jede Veränderung hat die Chance für die abhängige Software fatal zu sein.

Der erste Schritt ist es diese expliziten und impliziten Abhängigkeiten zu identifizieren. Statt jede potenzielle Abhängigkeit einzeln aufzulisten, sind diese gruppiert.

Risikogruppen von Abhängigkeiten

Infrastruktur

Eine klassische Desktop-Anwendung ist für eine bestimmte CPU-Architektur kompiliert. Bei der Markteinführung der Apple M1 Geräte funktionierten plötzlich bestehende Desktop-Anwendungen nicht mehr aufgrund der neuen CPU-Architektur. Dasselbe gilt für Web-Anwendungen. Bei diesen kommt hinzu dass sie in der Regel auf fremden Geräten betrieben werden. Dieses Gerät kann jederzeit verschwinden: Der Hosting-Provider schließt, ändert seinen Fokus, passt das Produktsortiment an oder verliert sein gesamtes Rechenzentrum bei einem Brand. Fakt ist, dass selbst das Fundament, auf dem Anwendungen stehen, instabil ist. Zumindest bei der Betrachtung auf einer langen Zeitspanne.

Programmiersprache

Auch die Programmiersprache kann der Grund sein, dass etwas von heute auf morgen nicht mehr funktioniert. Bei einer interpretierten Programmiersprache braucht es eine funktionierende Laufzeitumgebung um etwas ausführen zu können. Das eigene Programm funktioniert oft nur mit einer kleinen Auswahl an Versionen. Sobald davon keine mehr vorhanden ist, steht alles. PHP ist dafür ein anschauliches Beispiel. Unzählige Web-Anwendungen mussten angepasst werden als die Hosting-Provider veraltete PHP Versionen aus ihrem Angebot entfernten.

Fremdcode

Die meisten Anwendungen nutzen Bibliotheken, Frameworks und Softwarekomponenten Dritter. Diese Abhängigkeiten entwickeln sich kontinuierlich weiter. Eine unglückliche Kombination davon kann dazu führen, dass die eigene Anwendung nicht mehr installierbar ist ohne das die Abhängigkeiten aktualisiert und angepasst werden. Das trifft besonders auf umfangreichen Fremdcode zu, der selbst wieder Abhängigkeiten hat.

Externe Dienste

Eine Anwendung bedient sich oft externer Dienste, um die eigene Aufgabe zu erfüllen. Dazu kommuniziert sie per Schnittstelle mit anderen Anwendungen. In einer Web-Anwendung werden zum Beispiel E-Mails über Postmark versandt und Bezahlungen per Stripe abgewickelt. Auch diese Schnittstellen unterlaufen Veränderungen. Irgendwann sind diese nicht mehr rückwärts kompatibel und führen dazu, dass bestimmte Funktionen der Anwendung nicht mehr korrekt funktionieren.

Anwendungsfeld

Zu guter Letzt kann sich das Anwendungsfeld der Software selbst ändern. Sobald ein Unternehmen seine Prozesse verändert funktioniert die Web-Anwendung zur Prozessautomatisierung nicht mehr. Aus Sicht des Unternehmens hat die Software Wert verloren und ist möglicherweise nicht mehr brauchbar.

Risikoreduzierung

Wie zu sehen ist, existiert Software in einer harschen Umwelt. Die Kräfte die auf sie einwirken sind nicht kontrollierbar. Bewusste Entscheidungen bei der Entwicklung können die Lebensdauer jedoch absolut verlängern.

• Standardhardware für Server bzw. Computer wählen. Spezialplattformen vermeiden, die nur bei einem Anbieter erhältlich sind. Es gibt zu viele Gründe, wieso eines Tages ein Wechsel nötig sein wird. Ohne Vendor Lock-in ist das wesentlich einfacher zu überleben.

• Langweilige und etablierte Programmiersprache nutzen. Idealerweise produziert sie eine einzelne ausführbare Binary.

• Konservative Wahl von Frameworks, Bibliotheken und anderen Komponenten. Es ist unrealistisch keinen Fremdcode zu nutzen. Die optimale Anzahl liegt jedoch näher bei 0 als bei 100.

• Dasselbe Prinzip gilt für externe Dienste, so wenige wie möglich verwenden. Wenn die Integration über einen eigenen Adapter passiert, reduzieren sich die nötigen Anpassungen bei einem Anbieterwechsel.

Die Frage nach dem Mindesthaltbarkeitsdatum von Software ist nicht einfach beantwortet. Sie erfordert eine reflektierte Auseinandersetzung mit dem gesamten Entstehungsprozess. Passiert das nicht, entsteht in der Regel eine fragile Anwendung die auf Veränderungen in der Umwelt anfällig ist.

Darüber nachzudenken wie lange eine Anwendung garantiert lauffähig bleibt, ist der erste Schritt daran etwas zu ändern.