Transparenz für die Legacy-Ablöse: automatisierte Softwaredokumentation

Die Ablöse über Jahrzehnte gewachsener Unternehmenssoftware ist zu einer Aufgabe geworden, die selbst große Projektteams kaum mehr in einem überschaubaren Zeitraum bewältigen. Der Grund liegt selten in der neuen Technologie, sondern im alten System: Niemand kann verlässlich sagen, was es tut. Dieser Beitrag zeigt, warum automatisierte Softwaredokumentation ein entscheidender Hebel für die Legacy-Ablöse ist, was Prüferinnen und Prüfer verlangen und wie wir mit Sysparency Transparenz in Bestandssysteme bringen.

Warum die Ablöse gewachsener Systeme ins Stocken gerät

In den meisten Unternehmen arbeitet im Kern eine historisch gewachsene Unternehmenssoftware. Diese ERP- und Kernsysteme sind das schlagende Herz der gesamten IT-Architektur, die sich über Jahrzehnte rund um sie herum entwickelt hat. Ohne sie fließen keine Daten in die vielen Business Services, die darauf aufsetzen. Statt das System auf den jeweils aktuellen Stand der Technik zu erneuern, wurde über die Jahre hinzugefügt, was gerade gebraucht wurde: neue Funktionen, weitere Programmiersprachen, produktbezogene Technologie-Stacks. Die Systemkomplexität ist damit dramatisch gestiegen, und das Ganze durchschaut nur noch ein kleiner Kreis von Eingeweihten.

Gleichzeitig kommen in den Unternehmen immer mehr intelligente Softwarealgorithmen zum Einsatz, die selbstlernend und ohne menschliches Zutun Entscheidungen treffen. Im Buch „Das selbstfahrende Unternehmen“ (Springer Gabler 2021) habe ich beschrieben, dass die Akzeptanz dieser Algorithmen von ihrer Nachvollziehbarkeit abhängt: Was nicht verstanden wird, wird ins Mystische gezogen und abgelehnt. Beide Probleme überlagern sich. Die neuen Algorithmen müssen erklärbar sein, und die alten Systeme, an die sie andocken, sind es nicht. Bevor kognitive Software auf ein Fundament gesetzt wird, muss dieses Fundament transparent sein.

Im Buch habe ich Robotic Process Automation als Brückentechnologie eingeordnet: Softwareroboter überbrücken die Lücke zwischen Altsystemen und neuen Anwendungen, solange die Ablöse noch aussteht. Eine Brücke ersetzt aber keinen Neubau. Irgendwann muss das Altsystem abgelöst werden, und jedes Jahr, das ein Unternehmen wartet, macht diese Ablöse teurer.

Durchblick nur für Eingeweihte: das Quellcode-Problem

Der Quellcode der oft jahrzehntelang genutzten Unternehmenssoftware wird in vielen Unternehmen wie „das Heiligste“ behandelt. Nur wenige Menschen haben Zugang dazu, und noch weniger sind in der Lage, ihn zu lesen und zu verstehen. Daraus entstehen Engpässe bei genau jenen Ressourcen, die eine Ablöse am dringendsten braucht: erfahrene Entwicklerinnen und Entwickler, die das System kennen. Viele von ihnen stehen kurz vor dem Ruhestand, und ihr Wissen ist oft nirgends niedergeschrieben.

Anforderungsanalytikerinnen und Anforderungsanalytiker können die tatsächliche Anwendung in ihrer ganzen Komplexität nur fragmentarisch erfassen. Für das Management entsteht aus der lückenhaften Dokumentation ein falsches Bild der bestehenden Software, meist ein zu einfaches. Unsere Praxis zeigt, dass mit manueller Dokumentation selbst nach fünf Jahren nur ein Bruchteil eines großen Bestandssystems beschrieben ist. Damit wird jede Wartung, jede Weiterentwicklung und vor allem eine vollständige Ablöse extrem aufwendig und teuer. Viele Unternehmen lassen sich davon abschrecken und halten an der bestehenden Lösung fest. Das Szenario der Ablöse ist unausweichlich, aber es wird verdrängt.

Was Prüferinnen und Prüfer verlangen

Das zentrale Argument für automatisierte Dokumentation kommt nicht aus der IT, sondern aus der Prüfung. In systemkritischen Branchen wie Banken, Versicherungen, Energieversorgung und Gesundheitswesen sind Unternehmen verpflichtet, die eingesetzte Software so zu dokumentieren, dass ihre wesentlichen Aspekte extern prüfbar und nachvollziehbar sind. Für den Finanzsektor sind die aufsichtsrechtlichen Vorgaben eindeutig: Die Bankaufsichtlichen Anforderungen an die IT (BAIT) der deutschen BaFin und die EBA-Leitlinien zum Management von IKT- und Sicherheitsrisiken verlangen eine aktuelle Dokumentation der Anwendungen und der von ihnen unterstützten Geschäftsprozesse. Mit der Verordnung (EU) 2022/2554 über die digitale operationale Resilienz im Finanzsektor (DORA), die seit Januar 2023 in Kraft ist und ab Januar 2025 anzuwenden sein wird, wird die Identifikation und Dokumentation aller IKT-gestützten Geschäftsfunktionen und Informationsressourcen für Finanzunternehmen europaweit zur Pflicht.

Aus der Sicht der Prüferinnen und Prüfer lassen sich die Anforderungen an eine Systemdokumentation so zusammenfassen:

• Vollständig. Alle Programme, Schnittstellen und Datenflüsse sind erfasst, nicht nur die bekannten.
• Aktuell. Die Dokumentation beschreibt den Stand des produktiven Systems, nicht den Stand der letzten Großprojekte.
• Verständlich. Auch Personen mit fachlicher, aber ohne IT-technische Expertise können die Beschreibung lesen und beurteilen.
• Belegt. Jede Aussage lässt sich auf den Quellcode zurückführen, aus dem sie stammt.
• Wiederholbar. Die Dokumentation kann für die nächste Prüfung ohne neues Großprojekt erneuert werden.

Manuell erstellte Dokumentation scheitert regelmäßig an den ersten beiden Punkten. Sie ist am Tag ihrer Fertigstellung bereits veraltet und deckt nur ab, was das Team in der verfügbaren Zeit erfassen konnte. Ich erwarte, dass die gesetzlichen Rahmenbedingungen weiter verschärft werden und dass für systemkritische Software künftig eine automatisiert erzeugte Dokumentation einschließlich der Softwarearchitektur vorzulegen sein wird. Ohne diese Grundlage ist eine objektive und zuverlässige Prüfung nicht möglich.

Fallbeispiel: das Legacy-Dilemma einer Bank

Ein typisches, anonymisiertes Beispiel aus unserer Beratungspraxis: Die Leiterin der zentralen IT einer Bank verantwortet ein über Jahrzehnte gewachsenes Kernsystem, dessen Komponenten großteils im Haus entwickelt und ergänzt wurden. Das System ist systemkritisch für die Bank und ihre Kundinnen und Kunden, aber es weist keine hinreichende Dokumentation auf. Externe Prüferinnen und Prüfer haben das bereits mehrfach als Feststellung festgehalten. Die Bank steht vor der Aufgabe, das System innerhalb von fünf Jahren abzulösen.

Der erste Schritt, und zugleich die Planungsgrundlage für alle weiteren, ist eine aktuelle Analyse und Dokumentation des tatsächlichen Verhaltens der Software. Allein dieser Schritt wurde mit rund drei Jahren für ein komplettes Softwareentwicklungsteam kalkuliert und hätte annähernd ein Drittel des gesamten Ablösebudgets verbraucht. Das erschien unrealistisch, aber bei einem Projekt dieser Größenordnung bot sich zunächst kein anderer Weg.

Mit automatisierter Softwaredokumentation stellte sich die Ausgangslage anders dar (Erfahrungswerte aus Sysparency- und ReqPOOL-Projekten, projektspezifisch validierbar):

1. Analyse aus dem Code. Sysparency analysiert das historisch gewachsene System anhand des Programmcodes systematisch und dokumentiert es automatisiert.
2. Prüfungsfähige Dokumentation. Gemeinsam mit den Expertinnen und Experten von Sysparency entsteht die für die Prüfung erforderliche Dokumentation zeitgerecht.
3. Entlastung des Ablöseteams. Das Team wird nur mit einem Bruchteil des ursprünglich kalkulierten Aufwands belastet, das Ablösebudget sinkt entsprechend.
4. Fachbereiche bleiben im Tagesgeschäft. Etwa ein Drittel der IT-Expertinnen und IT-Experten aus den Fachbereichen musste nicht in das Projekt einbezogen werden, weil die Dokumentationsbasis auch ohne sie stabil war.

Der erste Schritt erfolgt damit nicht nur schneller und mit weniger Ressourcen. Die professionell aufbereitete Dokumentationsbasis erleichtert und beschleunigt alle weiteren Schritte der Ablöse: Spezifikation, Ausschreibung, Migration und Abnahme.

Wie automatisierte Dokumentation arbeitet

Sysparency ist ein wissenschaftliches Spin-off aus Linz und Partnerunternehmen von ReqPOOL. Die Analysesoftware liest den Quellcode eines Bestandssystems ein und leitet daraus den gesamten Aufbau und die Funktionen des Systems ab, weitgehend unabhängig von Programmiersprache und Alter des Codes. Voraussetzung ist die vollständige Zugänglichkeit des Systems für alle Beteiligten des Projektteams. Auf dieser Grundlage entstehen in kurzer Zeit drei Perspektiven auf dasselbe System:

Die Projekte beginnen oft schon in der Discovery-Phase. Noch vor der präzisen Spezifikation und Planung werden sämtliche Systemrisiken erhoben, weil die Software in ihrer ganzen Funktionalität erfasst ist. Risiken lassen sich damit früh behandeln, und das Management erhält eine fundierte Entscheidungsgrundlage, ob und wie das Ablöseprojekt in Budget, Scope und Zeit durchführbar ist.

Der Nutzen steigt mit der Größe des Systems. Mit wachsender Projektgröße führt zusätzliche Manpower zu erheblichen kommunikativen Problemen, ein Effekt, den Frederick Brooks bereits 1975 in „The Mythical Man-Month“ beschrieben hat. Eine automatisierte Lösung skaliert dagegen ungehindert mit der Komplexität. Je nach Größe des Projekts lassen sich gegenüber manuell erstellter Dokumentation bis zu 90 Prozent des Aufwands einsparen, und die Dokumentation liegt in einem Bruchteil der Zeit vor. In der Folge beschleunigen sich Entwicklungs- und Ablöseprozesse um bis zu ein Drittel (Erfahrungswerte aus Sysparency-Projekten, projektspezifisch validierbar).

Ein Aspekt ist mir dabei besonders wichtig: Die Software hat, anders als Menschen und Teams, keine eigenen Interessen. Sie dokumentiert, was der Code tut, nicht, was jemand in Erinnerung hat oder gerne hätte. Lücken und Sonderfälle werden sichtbar statt übergangen. Seit ChatGPT werden wir häufig gefragt, ob nicht ein Sprachmodell den Code erklären könnte. Für einzelne Funktionen ist das eine Hilfe. Eine prüfungsfähige Dokumentation von Millionen Codezeilen braucht jedoch eine systematische, vollständige und wiederholbare Analyse, deren Ergebnis sich auf jede Zeile zurückführen lässt. Sprachmodelle können darauf aufsetzen, sie ersetzen diese Grundlage nicht.

Transparenz als Vorstufe des selbstfahrenden Unternehmens

Im vorigen Beitrag dieser Serie habe ich Transparenz als Prinzip des selbstfahrenden Unternehmens beschrieben: Alle Daten und Fakten stehen in Echtzeit zur Verfügung, ungünstige Praktiken lassen sich nicht mehr verschleiern. Die automatisierte Dokumentation von Bestandssystemen ist die handfeste Vorstufe dazu. Sie macht zunächst das sichtbar, was heute schon läuft.

Im Buch habe ich für das Unternehmen 2035 eine Konsequenz formuliert, die vielen auf den ersten Blick radikal erscheint:

Ebenso wird der Wirtschaftsprüfer überflüssig, da diese Systeme vollkommen transparent sind.

Davon sind wir 2023 weit entfernt. Heute kritisieren Prüferinnen und Prüfer fehlende Dokumentation, und Unternehmen erstellen sie mühsam nachträglich. Im selbstfahrenden Unternehmen ist die Dokumentation kein nachgelagertes Projekt mehr, sondern eine Eigenschaft der Software selbst: Das System kann jederzeit erklären, was es tut und warum. Der Weg dorthin beginnt nicht mit neuen Algorithmen, sondern mit der Lesbarkeit der bestehenden. Wer sein Altsystem vollständig kennt, kann entscheiden, was davon in die Zukunft mitgenommen wird und was nicht, und kann diese Entscheidung gegenüber Aufsicht, Eigentümerinnen und Eigentümern sowie Belegschaft begründen.

Der nächste Schritt

Wie Transparenz, Algorithmen und Enterprise Architecture im selbstfahrenden Unternehmen zusammenwirken, beschreibt das Buch „Das selbstfahrende Unternehmen“: Zum Buch. Wenn Sie vor der Ablöse eines gewachsenen Systems stehen oder eine Feststellung der Prüfung zur Dokumentation offen haben, klären wir in einem Gespräch, wie eine automatisierte Dokumentationsbasis Ihr Vorhaben verkürzt: Expertengespräch buchen.