Außerbetriebsetzung - immer in beruhigender Ferne?

"Der Mensch, der ich morgen sein werde, ist mir ein Fremder" - Dieses Zitat vom Nobelpreisträger und Psychologen Daniel Kahneman beschreibt unsere Denkschwäche einer zu geringen Gewichtung der Zukunft bei Handlungsentscheidungen. Das kennen wir alle aus dem Supermarkt: dort finden wir Fett, Zucker, Alkohol, Nikotin und vieles mehr. Ein paar Minuten Genuss, die Folgen schleppen wir für den Rest unseres verkürzten Lebens mit uns herum. Aber die Zukunft ist unserem jetzigen ich egal: wir kaufen und futtern. Das ist menschlich.

Auch die Außerbetriebsetzung von Software scheint in beruhigender Ferne zu liegen. Als Entwickler bin ich dann schon lange nicht mehr in diesem Laden, sondern in einem anderen tätig, nach mir die Sintflut. Auch Geschäftsleitungen der Anbieterfirma ist die schnelle Auslieferung mit Rechnung und Geldeingang wichtiger. Für die Käufer gilt Ähnliches: Hauptsache eine schnelle Lösung. Kann man so wollen und entscheiden.

Ich steuere einfach einmal zwei Gedanken ein: (1) die geplante und (2) die ungeplante Außerbetriebsetzung.

Geplante Außerbetriebsetzung - der Normalfall
Die geplante Außerbetriebsetzung erscheint als der angenehmere Fall. Grundsätzlich müssen wir davon ausgehen, dass die Entropie einer Software stetig zunimmt, insbesondere bei naiver Nutzung von KI. Mit jedem Update geht es mit der Klarheit der Struktur bergab (law of increasing entropy, Belady & Lehman, 1985). Die Software altert, die Architektur degeneriert während des Alterungsprozesses. Die Anpassung an neue Anforderungen wird zunehmend anspruchsvoller und kostenträchtiger. Safety und Security sind gleichfalls von wachsender Kritikalität betroffen. Irgendwann kommt die Entscheidung zu einem neuen System. Das Prinzip never‑change‑a‑running‑system ist an seine Grenze gekommen oder hat diese längst überschritten (law of continuing change, Belady & Lehman, 1985). Daten müssen DSGVO‑konform gelöscht werden oder aus steuerrechtlichen Gründen langfristig gespeichert bleiben. Spannend, wenn in der selben Datenbank beide Fälle vorkommen. Beim Löschen müssen SSDs und Server so geschreddert werden, dass keine Wiederherstellung möglich ist. In LLMs eingegebene Daten sind aus den LLMs wieder zu entfernen (machen Sie das mal mit Daten aus Schatten‑KI‑Anwendungen Ihres Personals, von denen Sie gar nichts wissen), was technisch nicht realitätsnah möglich ist. Datenbestände müssen auf das neue System migrieren. Möglicherweise können einige Module wiederverwendet werden. Manchmal reicht ein Reengineering aus: die Rückversetzung oder Weiterentwicklung 🙄 der Software in einen wartbaren Zustand. Oder auch ein Refactoring: Verbesserung der internen Struktur einer Software in kleinen Schritten mit Tests ohne Veränderung des äußeren Verhaltens. Bei der Entwicklung einer Software kann und sollte dieser Übergang und sollten diese Aspekte bereits mitgedacht werden. Es kann schneller kommen, als man meint. Stichwort des Leitbilds: Design for change. Klar ist: der Fokus auf die Geschwindigkeit bei der Erstellung von Software bringt typischerweise hohe technische Schulden mit sich, die erst nach und nach deutlich werden. Sie beschleunigen die Degeneration während des Betriebs deutlich und führen zu allerlei Aufwand bis hin zur frühen Außerbetriebsetzung. Es wird deutlich: ein sauber durchgeführter Software‑Engineering‑Prozess entlang der Komponenten des V‑Modells mit Einbezug von DevOps rechnet sich. Lassen wir nicht zu, dass der Mensch, der wir morgen sein werden, uns heute ein Fremder ist. Ansonsten wird er uns im Rückblick nicht sonderlich mögen. Genau das ist die Botschaft von Software Engineering: man beziehe bereits am Anfang einer Entwicklung den gesamten Software Development Life Cycle SDLC konsequent bis einschließlich dem Ende in die Planung ein.

Ungeplante Außerbetriebsetzung - der Unfall
Im Jahr 2026 ging die Meldung durch die Presse, dass nahezu alle Unternehmen in Deutschland bei Ausfall des Internets schlagartig handlungsunfähig werden, nicht mehr produzieren können. Dieser Zug scheint abgefahren - aber vielleicht sollten wir es vermeiden, zusätzlich auch noch von den KI‑Hyperscalern abhängig zu werden. Eine kurze Anweisung des amerikanschen Präsidenten Donald T. aus W. reichte 2026 aus, um Anthropic dazu zu bringen, bestimmte Services nicht mehr außerhalb der USA anzubieten. Große LLMs (Large Language Models) stellen, Stand Mitte 2026, ein Milliarden‑Minusgeschäft dar: ein hoher Wasserverbrauch für Verdunstungskühlung von GPUs der Server, unfassbar hohe Stromkosten, Kosten für GPUs und Speicher und damit ein enormer Ressourcenverbrauch sind einige der Ursachen des Phantastilliarden‑Minusgeschäftes. Wie lange kann so etwas gutgehen?

Auch die Insolvenz eines Anbieters oder eine Business‑Entscheidung zur Aufgabe einer Sparte oder eines Produktes kann uns ohne jede Vorwarnung jederzeit treffen. Alle Daten: weg. Softwarenutzungsrechte SaaC: weg. Abhängigkeiten nach außen wie Plugins oder Module, die wir vormals gerne genutzt haben, sind verschwunden oder werden nicht weiterentwickelt. Cyberangriffe, End‑of‑Life‑Events (Auslistung), urplötzliches Aufkommen von Lizenzproblemen, Gesetzesänderungen oder schwerwiegende Fehler (Bugs) in der Software, die auf einen Trigger hin ausbrechen, das alles können Ursachen für einen schlagartigen Zusammenbruch sein. Probleme bei Software kündigen sich nicht langsam an wie das Schleifgeräusch einer Bremse. Realität werdende Szenarien kommen (scheinbar) aus dem Nichts, treffen uns schlagartig und unvermutet wie ein Erdbeben.

Das erinnert mich an ein Erlebnis auf einer Behörde 2026: ich wollte ein amtliches Ausweisdokument erneuern und der Drucker funktionierte nicht. Die Dame griff entspannt in eine Schublade, zauberte einen Vordruck herbei, ich füllte ihn aus und die Dinge gingen einen guten Weg. Vielleicht eine taugliche Metapher für den Ansatz eines Plans B für alle Fälle. Wie wäre ein Workshop mit dem strategischen Werkzeug „Szenariotechnik“?

Reden wir jetzt darüber!