Der Modernisierungsplan steht, das Budget ist vorläufig genehmigt. Der Dienstleister stellt die erste Frage: „Wo ist die Systemdokumentation?". Es stellt sich heraus: Es gibt ein Wiki, zuletzt vor fünf Jahren aktualisiert, ein paar Diagramme „irgendwo auf dem Netzlaufwerk" und Code, der sich selbst als Dokumentation dient. Das Angebot steigt um ein Drittel. Denn der Dienstleister bepreist nicht die Arbeit, sondern die Unsicherheit.
Dieser Text beschreibt eine Praxis, die diese Unsicherheit vom Tisch nimmt: Bevor irgendjemand den Code einer alten Anwendung anfasst, wird das Wissen über sie rekonstruiert. Bis vor Kurzem bedeutete diese Etappe Wochen an Analystenarbeit, und kaum jemand entschied sich dafür. Heute erledigt KI den Großteil dieser Analyse in Arbeitstagen. Und das ändert die Reihenfolge des gesamten Projekts.
Erst die Landkarte, dann der Code
Ein System ohne aktuelle Dokumentation zu modernisieren ist wie ein Gebäude ohne Installationsplan zu sanieren. Es geht, aber jedes Aufstemmen einer Wand ist eine Lotterie: Vielleicht ist dahinter nichts, vielleicht ein Rohr, an dem ein halbes Stockwerk hängt. In Anwendungen ist dieses Rohr mal die Integration mit dem Data Warehouse, an die sich nur der Autor des Codes erinnerte, mal der nächtliche Export, aus dem die Buchhaltung still und leise ihre Daten zieht.
Deshalb ist die vernünftige Reihenfolge das Gegenteil der intuitiven. Man beginnt nicht mit dem Schreiben neuen Codes und nicht einmal mit dem Angebot. Man beginnt mit der Landkarte.
Was KI aus Code, Datenbank und Logs herausholt
Moderne Analysewerkzeuge können drei Quellen der Wahrheit über ein System lesen: den Quellcode, die Struktur der Datenbank und die Logs aus dem Produktionsbetrieb. Aus ihrer Kreuzung entsteht eine Systemlandkarte, die vier Ebenen umfasst.
Die erste sind die Module: woraus das System besteht und wofür jeder Teil zuständig ist, beschrieben in einer Sprache, die auch Menschen außerhalb der IT verstehen. Die zweite sind die Datenflüsse: wo Daten hereinkommen, was unterwegs mit ihnen passiert, wo sie landen. Die dritte sind die Integrationen, also alle Stellen, an denen die Anwendung mit anderen Systemen spricht: Buchhaltung, Lager, Shop, Partner. Genau dort bricht es bei Änderungen am häufigsten.
Die vierte Ebene ist die am wenigsten offensichtliche: toter Code. Die Loganalyse zeigt, welche Funktionen seit Jahren nicht aufgerufen wurden und in welche Tabellen seit 2019 niemand mehr schreibt. In älteren Systemen macht dieser Ballast oft einen beträchtlichen Teil des Ganzen aus. Jede Zeile, die nicht übertragen werden muss, ist eine reale Ersparnis im Projekt.
Was die Landkarte an der Entscheidung „neu schreiben oder modernisieren" ändert
Über die Entscheidung selbst haben wir separat geschrieben, im Text über die vier Kriterien: das Entscheidungsframework. Die Systemlandkarte liefert diesen Kriterien harte Daten. Ohne sie schätzt man technische Schulden nach Gefühl und Risiken anhand von Anekdoten. Mit ihr sieht man schwarz auf weiß: welche Module Geschäftswert tragen, welche tot sind, wo die Integrationen sitzen, die das Risiko jeder Änderung erhöhen.
Die Ergebnisse überraschen in beide Richtungen. Mal erweist sich ein System, das „von Grund auf neu geschrieben werden muss", als zu drei Vierteln gesund, und es genügt, zwei Module auszutauschen. Mal ist es umgekehrt: Die Anwendung sieht harmlos aus, und die Landkarte offenbart ein gutes Dutzend undokumentierter Verbindungen, die eine Teilmodernisierung teurer machen als das Neuschreiben. In beiden Fällen fällt die Entscheidung auf Basis von Daten, nicht von Emotionen. Und ein Dienstleister, der eine Landkarte statt eines Rätsels bekommt, bepreist Arbeit statt Risiko.
Unserer Ansicht nach sollte die Erstellung der Landkarte eine eigene, erste Etappe des Modernisierungsvertrags sein, mit eigener Abnahme. Selbst wenn Sie nach dieser Etappe entscheiden, dass jemand anderes die Modernisierung übernimmt oder Sie sie gar nicht durchführen, bleibt die Dokumentation im Unternehmen und arbeitet weiter.
Wie Sie prüfen, was die KI erzeugt hat
Automatisch erzeugte Dokumentation ist kein Orakel. Sie muss geprüft werden. Die wirksamste Methode ist simpel: ein Review mit der Person, die das System am besten kennt, oft der einzigen im Unternehmen. Der Unterschied zum klassischen Vorgehen liegt in der Rolle dieser Person. Sie bitten sie nicht, ihr Wissen aufzuschreiben, was niemand mag und sich über Monate zieht. Sie bitten um die Durchsicht einer fertigen Beschreibung, und ein „hier stimmt es, hier nicht" geht um ein Vielfaches schneller als das Schreiben von Grund auf.
Eine gute Praxis ist es, einige der wichtigsten Prozesse von Anfang bis Ende durchzugehen: Bestellung, Rechnung, Reklamation. Wenn die Landkarte die kritischen Flüsse und stichprobenartig geprüfte Details korrekt beschreibt, kann man ihr in den übrigen Bereichen vertrauen. Das lässt sich an einem Tag erledigen.
Was KI nicht rekonstruieren kann
Hier ein ehrlicher Vorbehalt: Der Code sagt, was das System tut, aber nicht, wozu. Eine merkwürdige Ausnahme bei der Rabattberechnung kann ein Fehler sein, oder eine Vertriebsabsprache aus dem Jahr 2016, die für einen großen Kunden weiterhin gilt. Das entscheidet keine Codeanalyse. Geschäftliche Absichten von vor einem Jahrzehnt rekonstruiert man durch Interviews: kurze Gespräche mit Leuten aus Vertrieb, Buchhaltung und Betrieb, geführt bereits mit der Landkarte in der Hand. Die Landkarte sagt, wonach man fragen sollte, aber die Antworten hat der Mensch.
Ein eigenes Thema ist auch das Umfeld der Anwendung: Server, Netzwerk, Backups. Über die Dokumentation dieser Ebene haben wir im Text über das Audit der Infrastrukturdokumentation geschrieben.
Bei ESKOM AI führen wir die Mapping-Etappe mit einem Team spezialisierter KI-Agenten unter Aufsicht erfahrener Ingenieure durch: Die Analyse eines typischen Unternehmenssystems dauert Arbeitstage, und das Ergebnis ist eine Dokumentation, die für Geschäftsführung und Technikteam gleichermaßen lesbar ist. Fällt danach die Entscheidung für die Modernisierung, laufen die weiteren Arbeiten in einem automatisierten Softwareentwicklungsprozess mit dem vollen Testumfang — Unit-, Integrations-, E2E-, UI-, Sicherheits- und Lasttests.
Womit Sie bei sich anfangen können
Wählen Sie ein System aus: das, dessen Modernisierung Sie am längsten aufschieben oder das anzufassen Sie am meisten fürchten. Beauftragen Sie die Erstellung seiner Landkarte als eigenständige, kleine Etappe, bevor Sie irgendjemanden um ein Angebot für den Umbau bitten. In einer kostenlosen Beratung sagen wir Ihnen, wie sich so eine Etappe planen lässt und was Sie danach erwarten können.
Vereinbaren Sie eine kostenlose Beratung über das Kontaktformular →