Alt-Software ablösen: Warum die KI-Dokumentation der erste Schritt sein muss
Alt-Anwendungen ohne Dokumentation lassen sich nur schwer ersetzen, weil niemand mehr genau weiß, was sie fachlich tun. Dieses Wissen steckt jedoch weiterhin in der Software selbst und kann mit KI ausgelesen werden, bevor die Neuentwicklung beginnt.
Alt-Anwendungen ablösen: Warum die Dokumentation am Anfang steht, nicht am Ende
In fast jedem Unternehmen läuft irgendwo eine Software, die seit Jahren gewachsen ist und ihren Dienst noch tut, sich aber nicht mehr aktualisieren lässt. Der Mitarbeiter, der sie geschrieben hat, ist längst weg. Eine Anleitung gab es nie. Der Dienstleister meldet sich nicht mehr, oder die Firma dahinter existiert gar nicht mehr. Die Anwendung wird täglich benutzt, aber niemand kann sie noch anfassen.
Ich begegne dieser Konstellation immer wieder, und sie folgt fast immer demselben Muster. Das System ist zu wichtig, um es abzuschalten, und zu undurchsichtig, um es zu ändern. Es funktioniert, solange niemand etwas anrührt. Genau das macht es zu einem Risiko, das mit jedem Jahr leiser, aber größer wird.
Der falsche erste Gedanke
Wenn so etwas abgelöst werden soll, geht der erste Gedanke fast reflexhaft zur neuen Anwendung. Wie soll sie aussehen, was soll sie können, wer entwickelt sie. Das ist verständlich, aber es setzt am falschen Ende an.
Das eigentliche Problem ist nicht das Neuentwickeln. Moderne Software zu bauen ist heute ein gut verstandenes Handwerk. Das Problem ist, dass niemand mehr genau weiß, was die alte Software fachlich tut. Welche Berechnungen sie ausführt, welche Sonderfälle sie kennt, welche Regeln sie still im Hintergrund durchsetzt. Diese stillen Regeln sind das Gefährliche, denn sie sind oft genau jene, an die sich der laufende Betrieb über Jahre angepasst hat, ohne dass es jemandem bewusst wäre.
Wer ohne dieses Wissen neu entwickelt, baut nicht das System nach, sondern eine Vermutung davon. Am Ende fehlt die Hälfte der Sonderfälle, und sie tauchen erst auf, wenn die neue Anwendung im Produktivbetrieb auf die Realität trifft.
Das Wissen ist nicht weg
Was dabei übersehen wird: Das Wissen ist nicht wirklich verschwunden. Es steckt weiterhin in der Software selbst.
Es liegt in den Beschriftungen der Eingabemasken, in den Namen und Kommentaren der Datenbank, in den Texten, die das System bei einer Fehleingabe ausgibt, in den Rechenschritten hinter den Auswertungen. Eine über Jahre gewachsene Anwendung ist eine erstaunlich vollständige Dokumentation ihrer selbst, nur eben in einer Form, die schwer zu lesen ist. Sie ist über tausende Zeilen verteilt, in einer Sprache geschrieben, die nicht für Menschen gedacht war, und durchsetzt von Entscheidungen, deren Begründung niemand mehr kennt.
Bisher musste ein Team genau dieses Wissen mühsam von Hand zurückgewinnen. Feld für Feld, Regel für Regel, Bildschirm für Bildschirm. Diese Arbeit war so teuer und langwierig, dass viele Unternehmen die Ablösung lieber weiter aufgeschoben haben. Nicht weil sie das System für ungefährlich hielten, sondern weil der erste Schritt allein schon abschreckend war.
Der eigentliche Hebel
Genau an dieser Stelle hat sich etwas verschoben. Eine speziell dafür eingerichtete KI kann die bestehende Anwendung und die letzten noch auffindbaren Unterlagen durchlesen und herausschreiben, was die Software fachlich leistet.
Das ist keine Magie und auch kein vollautomatischer Knopfdruck. Es ist im Kern eine Lesearbeit, und Lesen großer Mengen strukturierten Texts gehört zu dem, was solche Modelle gut können. Aus dieser Arbeit entsteht eine geordnete Dokumentation in normaler Sprache statt in Fachjargon. Sie beschreibt, was das System tut, in einer Form, die auch jemand versteht, der den Quellcode nie gesehen hat.
Zwei Eigenschaften sind dabei entscheidend, und sie unterscheiden eine brauchbare Dokumentation von einer gefährlichen. Jeder Punkt lässt sich auf die Stelle im Bestand zurückführen, aus der er stammt. Eine Aussage über eine Berechnung ist nur so viel wert wie der Verweis auf die Zeile, in der diese Berechnung tatsächlich passiert. Und alles, was sich nicht eindeutig klären lässt, wird offen als ungeklärt markiert, nicht stillschweigend geraten. Eine Dokumentation, die plausibel klingt, aber an einzelnen Stellen erfunden ist, wäre schlimmer als gar keine, weil sie Vertrauen erzeugt, wo keines hingehört.
Warum diese Reihenfolge zählt
Erst diese Dokumentation macht die Neuentwicklung überhaupt planbar. Wer nicht sauber aufgeschrieben hat, was eine Anwendung tut, kann sie nicht verlässlich neu bauen. Die Dokumentation ist kein Nebenprodukt des Projekts, sondern seine Grundlage.
Mit ihr lässt sich entscheiden, was übernommen werden muss, was bewusst entfallen kann und was nie hätte existieren sollen. Sie macht aus einer Blackbox eine Liste von Anforderungen, über die man reden, die man priorisieren und die man hinterfragen kann. Und sie trennt die fachliche Frage, was das System leisten soll, sauber von der technischen Frage, wie es gebaut wird. Diese Trennung ist der eigentliche Gewinn, denn sie erlaubt es, die alte Technik vollständig hinter sich zu lassen, ohne das fachliche Wissen mit aufzugeben.
Was früher der teuerste und langsamste Teil eines solchen Projekts war, fällt damit auf einen Bruchteil des Aufwands. Das verändert die Wirtschaftlichkeit der gesamten Ablösung. Ein Vorhaben, das vorher allein an der Analysephase gescheitert ist, wird damit zum ersten Mal realistisch.
Wo der Mensch bleibt
Ich halte nichts davon, diesen Schritt als vollautomatisch zu verkaufen. Die KI übernimmt die Fleißarbeit, das Durchsehen und Zusammentragen, das früher Wochen gekostet hat. Aber die markierten Lücken, die widersprüchlichen Stellen, die Regeln, deren Sinn sich aus dem Code allein nicht erschließt, brauchen weiterhin jemanden, der sie einordnet. Oft sind das Fachabteilungen, die zwar nie in den Code geschaut haben, aber genau wissen, warum ein bestimmter Sonderfall existiert.
Die Arbeit verschwindet also nicht, sie verschiebt sich. Weg vom mechanischen Herauslesen, hin zum eigentlichen Verstehen und Entscheiden. Das ist die Arbeit, für die Menschen ohnehin gebraucht werden.
Wo man anfängt
Wer eine alte Anwendung ersetzen will, fängt also nicht beim Entwickeln an, sondern damit, das Wissen aus der alten Software zurückzuholen. Das ist der unscheinbare erste Schritt, der über Erfolg oder Scheitern des gesamten Projekts entscheidet.
Die Technik dafür ist heute gut genug, um diese Arbeit zu übernehmen. Was lange als der teuerste und abschreckendste Teil galt, ist damit zum machbaren Anfang geworden. Und damit verschiebt sich die eigentliche Frage. Sie lautet nicht mehr, ob man sich die Ablösung leisten kann, sondern nur noch, wann man sie angeht.
&w=3840&q=75)