Individuelle Softwareentwickler Dokumentation für Legacy Software Systeme

Der moderne Fortschritt bei neuen Technologien ermöglicht uns immer rascher komplexe und intelligente Softwarelösungen zu entwickeln. Im Jahrestakt entstehen neue Programmiersprachen und es werden Frameworks für die unterschiedlichsten Anwendungsbereiche von Softwarelösungen entwickelt und perfektioniert. Doch die Realität in den größten Unternehmen der Welt ist eine Andere. Der Abstand zwischen der modernen Softwarewelt und der tatsächlich implementierten Softwaretechnologie in diesen Unternehmen triftet mit kontinuierlicher Geschwindigkeit auseinander. Die Sprache ist von den großen Legacy Software Anwendungen, die bei großen Unternehmen und Konzernen heute im Einsatz sind. Sie tragen einen Großteil der westlichen Wertschöpfungskette und ermöglichen den Austausch von Zahlungsmitteln, das Einkaufen von Waren, die Auszahlung von Löhnen und das effiziente Betreiben unserer Infrastruktur. Diese Systeme sind wie große Tankschiffe, die einmal auf Kurs gebracht, unaufhaltsam ihren Dienst vollrichten und die Unternehmen an ihr langfristiges Ziel bringen. Die Baustoffe dieser großen Legacy Anwendungen wurden vor einem halben Jahrhundert entwickelt. Zwei bis drei Evolutionsstufen nach der Erfindung der Lochkarten für automatisierte Webstühle, tragen Sie die klingenden Namen wie Programmiersprache Nummer eins (PL/1) oder gemeinsamen Geschäftsprogrammiersprache (COBOL). Der Fakt, dass diese Programmiersprachen vor über 50 Jahren am Markt eingeführt wurden, darf nicht darüber hinweg täuschen, dass sie immer noch sehr weit verbreitet sind und unsere gesellschaftlich, wichtigsten Softwareanwendungen damit programmiert sind.
Die Unternehmen spüren einen gewaltigen Druck sich zu modernisieren. Dieser Druck wird durch die Kunden, den Markt, den Mitarbeitern, den Partnern und regulatorischen Anforderungen erzeugt. Es entsteht der dringende Bedarf zur Digitalisierung, zur Automatisierung und zum vermehrten Einsatz von künstlicher Intelligenz zum Treffen von intelligenten Geschäftsentscheidungen. Dazu müssen sich diese Legacy Softwareanwendungen in ein dynamisches Modernisierungsumfeld einbetten und werden in den kommenden Jahrzehnten schrittweise ihre Funktionalitäten an modernere Softwaresysteme abgeben.

Wie modernisiert man Legacy Anwendungen?

In den letzten Jahrzehnten wurde regelmäßig versucht diese großen monolithischen Softwareanwendungen abzulösen und durch schlankere und service-orientierte Softwaresysteme zu ersetzen. Der Grund warum diese Vorhaben nicht so einfach in der Realität umzusetzen sind, liegt in der fachlichen und technischen Komplexität der Legacy Anwendungen. Sie beinhalten einen Großteil der Kernwertschöpfung und fachlicher Logik und sind mit den anderen IT-Systemen so vernetzt, dass bereits das Lösen einer oder zwei Knotenpunkte einen totalen Kollaps in der Wertschöpfungskette verursachen kann. Gerade dieses Risiko, dass die wertschöpfenden Anwendungen nicht in der gewünschten Qualität und Geschwindigkeit funktionieren, lassen viele Entscheidungsträger Abstand von Modernisierungsprojekten halten. Zusätzlich sprechen wir von hohen ein- bis dreistelligen Millionenbeträgen für diese Projekte und einer Amortisierungsdauer von mehreren Jahren bis Jahrzehnten. Status Quo in den meisten Unternehmen ist das Verständnis, dass die großen monolithischen Systeme schrittweise von ihrer Funktionalität erlöst werden und die neu entwickelten Umfeldsysteme diese Funktionalitäten übernehmen. Ein konzertiertes Orchester von einzelnen fachlichen Softwareservices soll über die Jahrzehnte die Legacy Anwendung ablösen und schlussendlich obsolet werden lassen. In der Realität bedeutet das, dass diese Host-Systeme noch Jahrzehnte im Einsatz bleiben werden und sich die Software entwickelnden Abteilungen auf diesen Umstand einstellen müssen.

Was sind die Herausforderungen für die Weiterentwicklung und Wartung von komplexen Legacy Anwendungen?

Der größte Blocker in der Weiterentwicklung und Digitalisierung unserer westlichen Unternehmen liegt im ausgeprägten Mangel an guten Softwareentwicklern und Software-Engineers. Dieser Umstand verstärkt sich nochmals, wenn man Spezialkenntnisse in den vorhin genannten historischen Programmiersprachen benötigt. Ein Großteil der Softwareentwickler, die vor zig Jahren auf diese Technologie geschult wurden, geht oder ging bereits in den wohlverdienten Ruhestand. Über bleibt ein auserlesener Kreis an Softwareentwicklern, die sich diese Programmiersprachen im Laufe ihrer Karriere neu angeeignet haben. Der Bedarf am Markt ist jedoch um einiges höher, als die tatsächlich vorhandenen Expertise. Die großen IT Unternehmen haben bereits Initiativen gestartet, um neue junge Softwareentwickler auf diese wichtigen Programmiersprachen auszubilden. Ein weiterer Ansatz ist es, die vorhandenen Ressourcen (Softwareentwicklerrinnen und Softwareentwickler) effizienter zu nutzen. Bei modernen objektorientierten Programmiersprachen und Frameworks ist man es gewöhnt, dass Anwendungen State of the Art Programmierumgebungen intelligente Unterstützungsleistungen für die Softwareentwickler zur Verfügung stellen. Für historische Programmiersprachen mangelt es an diesen modernen und KI-gestützten Programmierunterstützungen. Sehr viele Unternehmen haben sich die Programmierumgebungen selbst erstellt. Zusätzlich mangelt es in allen Fällen an einer adäquaten Dokumentation der Softwareanwendungen. Diese Anwendungen wuchsen historisch über Jahrzehnte und zusätzlich zum Team, haben sich auch die Werkzeuge und Methoden der Dokumentation geändert. Fakt ist, dass eine ganzheitliche Dokumentation dringen nötig wäre, aber die vorliegende Information nicht das Prädikat „Softwareentwickler Dokumentation“ verdient. Dabei reicht es nicht nur die Struktur der Software darzustellen oder tapetenartig, große Diagramme und Graphen zu generieren, sondern man muss die Komplexität dieser mammutartigen Softwaregebilde beherrschbar machen. Der kennende Leser dieses Artikels wird sofort zustimmend nicken bei der Aussage, dass jedes dieser Software Ungetüm ein Unikat ist. Genau aus diesem Grund, hat sich keine standardisierte Methodik zur Beherrschbarkeit der Komplexität am Markt etabliert. Der Hauptfaktor für die Komplexität liegt in der Individualität der Legacy Anwendung und nur eine individuelle Dokumentation kann diese Komplexität für Softwareentwickler beherrschbar machen.

Wie kann die Komplexität eine Legacy Anwendung beherrschbar gemacht werden?

Schritt eins zur Beherrschbarkeit von Komplexität ist das Auffinden von Gemeinsamkeiten. Jede Softwareanwendung wird von vier spezifischen Dimensionen geprägt:
• Interaktion der Benutzer mit der Anwendung,
• Speicherung und Verarbeitung von Daten,
• Austausch von Daten und Funktionalitäten mit umliegenden Softwareanwendungen und
• Zeitgesteuerte Verarbeitung von Daten und Funktionalität.
Basierend auf diesen Dimensionen ist es möglich eine Art Landkarte für diese Legacy Anwendungen anzufertigen.

Benutzerinteraktion

Jede softwarebasierte Geschäftsanwendung reagiert auf Eingaben und Befehle von Benutzerinnen und Benutzer. Diese Benutzerkommandos verarbeiten Daten, tauschen Daten aus, berechnen Werte und spiele die Ergebnisse zurück an die Benutzer. Wir Menschen sind stark visuell getriggert und können uns durch Bilder und grafische Darstellungen weit besser in komplexe Materie einarbeiten als durch das Lesen von seitenlangem Text. Aus diesem Grund ist das Darstellen von grafischen Oberflächen in einer individuellen Softwaredokumentation eine essenzielle Notwendigkeit und wird idealerweise automatisch generiert. Die tatsächlichen Digitalisierungspotenziale der vorliegenden Legacy Anwendung werden somit sichtbar. Anhand der grafischen Oberfläche bekommt man innerhalb von Sekunden einen guten Gesamteindruck der Anwendung und die Einarbeitung in die komplexe Materie wird signifikant erleichtert. Doch es interessiert nicht nur die grafische Darstellung, sondern auch der Ablauf der Benutzerinteraktion. Der Benutzer-Kontrollfluss kann über ein grafisches Ablaufdiagramm vom Aufruf einer Maske zur Navigation einer anderen Maske dargestellt werden. Mittels Drill-Down Möglichkeiten werden Komplexitätsstufen abstrahiert. Für Modernisierungsprojekte ist es essenziell, dass man Programmvariablen und Funktionsaufrufe von der grafischen Oberfläche, über die Programmlogik, bis hin zur Daten-Persistenz Schicht nachvollziehen kann. Wichtig für die Reduktion der Komplexität ist die grafische Aufbereitung dieser Informationen und die übersichtliche Darstellung.

Daten und Datenzugriffe

Unumstritten sind Daten die härteste Währung unseres Zeitalters. Ein Hauptgrund für das lange Überleben von Legacy Anwendungen liegt darin, dass diese Softwaresysteme die größten und wertvollsten Datenschätze unserer modernen Unternehmen hüten. Der Schlüssel für eine erfolgreiche Modernisierung liegt also darin, diese Datentöpfe zu dezentralisieren und verteilten Datenzugriff darauf zu gewähren. 

Der Zugriff und die Verwaltung dieser Datensätze kann auf die fünf CRUDS-Zugriffsmuster reduziert werden:

• C: CREATE – Neuanlage von Datensätze
• R: READ – Lesen von Datensätze
• U: UPDATE – Datensätze manipulieren und bearbeiten
• D: DELETE – Datensätze löschen
• S: SEARCH – Datensätze suchen und auflisten

Durch die Datenstrukturen, die eine Software Anwendung implementiert hat, erhält man tiefe Einblicke in die fachliche Logik und den technischen Aufbau. Die Beschaffenheit der Daten-Persistenz-Schicht ist individuell, wie die umgesetzten Geschäftsanwendungsfälle. Dennoch benötigt man detaillierte Analyse und Erkenntnisse um Transformationsentscheidungen evidenzbasiert zu treffen und Komplexitäten und Aufwand richtig abzuschätzen. Speziell für die Einarbeitung in neue Legacy-Projekt oder Anwendungen sind diese datenzentrierten Ansichten des Programminhalts von großer Bedeutung. Fehler können schneller gefunden und behoben werden und Ineffizienzen in der Programmstruktur beseitigt werden. Doch nicht nur die Datenmanipulationen sind von Interesse, sondern auch der Fluss der Daten durch die funktionale Anwendung. Spannend ist die Übersicht der Daten und der Datenvariablen von der grafischen Oberfläche, über Schnittstellen bis hin zur Datenbank. Ein weiterer Aspekt zur Reduktion der Komplexität von diesen Anwendungen, ist das Reverse Engineering des tatsächlichen Datenbank-Schemas. Damit ist die tatsächliche Datennutzung gemeint, die direkt aus dem Programm-Code abgeleitet werden kann. Im Gegensatz zu klassischen oder technischen Datendiagrammen (DDLs oder Entity-Relationship-Modell) werden in diesen tatsächlichen Datenmodellen nur fachliche Datenattribute angeführt, wenn das Programm auch tatsächlich Datenmanipulationen an diesen Datenattributen durchführt. Die Differenz zwischen dem technischen Datenmodell und dem tatsächlichen Datenmodell, zeigt Ineffizienzen und etwaige Probleme im Datenmanagement auf. Speziell bei großen Ablöseprojekten oder bei Projekten zur modulweisen Ablöse einer Legacy Anwendung in Service orientierte Module ist diese Datennutzungs- und Manipulationssicht unbedingt notwendig.

Schnittstellen

In unserer heutigen Welt steht kein Softwaresystem allein auf der grünen Wiese. Ganz im Gegenteil. Die Anwendungen sind stärker vernetzt als das gesponnene Netz einer Spinne. Ständig werden Daten zwischen den Systemen ausgetauscht und landen an unterschiedlichsten Stellen in Datentöpfen. Die Daten werden von unterschiedlichsten Services und Softwareprogrammen manipuliert und basierend auf ihnen werden neue Ergebnisse berechnet. Die Analyse eines einzelnen monolithischen Systems ohne die umliegenden Systeme mit zu betrachten, würde zu fatalen fachlichen Fehleinschätzungen und massiver Unterschätzung des Aufwands führen. Außerdem ergibt sich sehr viel Fach- und Geschäftslogik erst durch die Interaktion mit anderen Systemen. Beispiele dafür sind das Austauschen von Benutzerdaten mit dem HR-System, die Anbindung von ERP-Systemen zur Finanzbuchung oder der Austausch von Kunden Daten mit CRM-Systemen. Für erfahrene Legacy System Programmierer bleibt die größte Herausforderung der große, monolithische und linear programmierte Softwareprogrammcode. Speziell die Informationen zu den ausgetauschten Daten und den vorhandenen Schnittstellen in akzeptable Zeit, mit akzeptablem Aufwand zu extrahieren und fachliche Abläufe daraus ableiten zu können, ist in der Realität praktische unmöglich. Es benötigt die automatisierte Analyse des gesamten Programmcodes einer Legacy Anwendung, um alle tatsächlich umgesetzten Schnittstellen mit anderen Systemen aufzulisten. Technologie hat sich über die vergangenen Jahrzehnte massiv weiterentwickelt und gewandelt. In ihrer Anfangszeit tauschten diese Softwaresysteme ihre Daten über Dateien aus. Mit dem Einzug von Datenbank-Technologien und Web-Technologien wurde das Schnittstellenverhalten angepasst. Moderne Hostsysteme verwenden durchaus zeitgemäße Schnittstellenarchitekturen wie REST oder Web Services. Bereits eine vollständige Auflistung aller Interaktionsmöglichkeiten mit anderen Umsystemen bietet in Modernisierungs- und Softwareentwicklungsprojekten erhebliche Vorteile und eine signifikante Aufwandsreduktion. Auch die Fehlerbehebung und Wartung erleichtert sich durch das rasche Auffinden der benötigten Schnittstelle inklusive Drill-Down Möglichkeiten, bis hin zum tatsächlichen Programmcode.

Zeitgesteuerte Verarbeitung

Wann immer man über historische Legacy Anwendungen liest, spricht oder schreibt ist die zeitgesteuerte Batch Verarbeitung das Herzstück dieser Anwendungen. Erst in den letzten Jahrzehnten bildete sich ein online-fähiger Bereich heraus. Der Kern der Anwendung blieb jedoch als Batch Verarbeitung bestehen. Programmierer, die in modernen Programmiersprachen ausgebildet wurden, fehlt sehr häufig das Verständnis für die Stapelverarbeitung und auch der Wille diese vollständig zu erfassen und zu verstehen. Zusätzlich zeigt die Erfahrung aus zig Projekten, dass vor allem die Stapelverarbeitung eines der wohl gehüteten Geheimnisse der Senioren Softwareentwickler im Unternehmen ist und sie dieses Wissen wie einen Schatz beschützen. Die Erfahrung zeigt, dass es für Business Analysten zehnmal so aufwändig ist, eine Scheduler-Information oder die Scheduler Abläufe zu bekommen, als das Datendiagramm einer Legacy Anwendung. Das bedeutet es ist sehr zeitraubend und aufwändig in einer Organisation die korrekten Informationen zu bekommen – wann und welcher zeitgesteuerte Job bei einer Anwendung läuft und welche Parameter mitgegeben werden. Dies mag auch daran liegen, dass das Wissen schrittweise aus den Unternehmen schwindet und die Einarbeitung speziell in diese zeitgesteuerte Verarbeitung ungemein aufwändiger ist als in die klassische von Benutzer gesteuerte Onlineverarbeitung. Die Trennung in Softwareentwicklungsteams und Softwarebetrieb Teams verstärkt den Effekt des Information-Hiddings. Zusätzlich zu den Scheduler Informationen, die Aussage treffen „wann – was – wie“ ausgeführt wird ist der tatsächliche Ablauf der Stapelverarbeitung von Nutzen. Es geht um die Fachlogik, die durch diese zeitgesteuerte Stapelverarbeitung ausgeführt wird. Oft simulieren diese Systeme eine Onlinefähigkeit durch kurzfristig angestoßene Abarbeitung von Stapelbearbeitungen. Eine erfolgreiche und vollständige Modernisierung dieser Anwendungen ist nur durch intensives Verständnis der gesamten Stapelverarbeitung möglich.

Code-Analytics & Software-Insights

Software trifft Entscheidungen basierend auf programmierter Logik und den zu Grunde liegenden Daten. Bei Digitalisierungsprojekten und großen Software Ablöseprojekten sollte man ähnlich vorgehen und die Entscheidungen auf einer bewerten Modernisierungsmethodik und analysiert Daten treffen. Dabei spielt die Methodik eine wichtige Rolle. Eine neue Phase bei Modernisierungsprojekten ist die Discovery Phase. Dabei wird ein Legacy System automatisiert und vollständig analysiert und dokumentiert. Weiters werden für alle wichtigen Bereiche dieser monolithischen Software Kennzahlen extrahiert, die eine Indikation für den Aufwand und die Komplexität einer Neuentwicklung liefern. Entscheidungen des Managements werden somit Daten basiert und entsprechend der Realität getroffen. Fehler werden vermieden und die geschäftskritischen Bereiche der Anwendung höher und richtig priorisiert. Transparenz wird erreicht, wenn eine vollständige Softwaredokumentation um handfeste Zahlen, Daten und Fakten erweitert wird.

Wie kann man Softwareentscheidungen für alle transparent und nachvollziehbar machen?

Geschäfts- und gesellschaftliche Entscheidungen in unserer digitalisierten Welt werden immer mehr durch Software Algorithmen getroffen. Diese Entscheidungen müssen für die Managerinnen und Manager, die Mitarbeiterinnen und Mitarbeiter und allen Teilnehmer unserer Gesellschaft nachvollziehbar sein. Nur eine vollautomatisierte Dokumentation und Aufbereitung von Softwarealgorithmen ermöglicht diese Transparenz an fachlichen Entscheidungen und programmierter Logik. Eine adaptive Darstellungsweise ermöglicht es den unterschiedlichen Zielgruppen die Entscheidungen nachzuvollziehen und ihre Schlüsse daraus zu ziehen. Die Darstellung von Entscheidungen kann man durch mathematische Formeln, Entscheidungstabellen oder grafischen Abläufen darstellen. Je nach Anwendungsfall sind unterschiedliche Methoden und Darstellungsweisen von Relevanz.
Jedes Legacy System ist individuell. Die Art und Weise im Aufbau einer Software entspricht der Komplexität eines physischen Gebäudekomplexes. Dies kann variieren vom kleinen Einfamilienhaus bis zum Wolkenkratzer in einer der großen Städte der Welt. Je nach Anwendungszweck unterscheidet sich die Architektur und der Aufbau dieser Gebäude signifikant. Dieser Umstand kann auch auf Softwaresystemen umgelegt werden. Dies ist auch der Grund, warum eine individuelle angepasste automatisierte Dokumentation von großen Softwaresystemen notwendig ist. Zusätzlich sind die aktuellen Herausforderungen der Softwareentwicklungsteams von Projekt zu Projekt verschieden. Eine hundertprozentig standardisierte Softwaredokumentation entspricht nur zu einem geringen Grad den individuellen Anforderungen dieser Teams. Die Erfahrung zeigt, dass man mit geringem Aufwand ein entsprechendes Dokumentations-Framework – wie zum Beispiel Sysparency – derartig anpassen kann, dass die wichtigen und individuellen Fragestellungen der Softwareentwicklungsteams zur Zufriedenheit gelöst werden können. Abhängig ist diese Individualität auch vom Lebenszyklus der Legacy Anwendung. Für ein Ablöseprojekt benötige ich andere Dokumentationsart, als für die von der Compliance vorgeschriebene Dokumentation einer laufenden Kernbankanwendung. Für eine Anwendung, die sehr Fehler behaftet ist und stark in einem Softwareverbund eingebunden ist, benötigt die Struktur stärkere Methoden und Analyseverfahren zum Auffinden dieser fehlerhaften Programmstellen und der Nachverfolgung der Abhängigkeiten. Außerdem unterscheiden sich die Ansprüche an die Darstellung einer Dokumentation. Die Art und Weise der grafischen Darstellung der Komplexitäten und der semantischen Information, die aus dem Programmcode extrahiert wird müssen pro große Legacy Anwendung individuell konfiguriert werden.

In den letzten zehn Jahren forschen, dass Software Competence Center Hagenberg gemeinsam mit Sysparency an dem optimalen Framework zur Analyse und automatisierten Generierung einer Dokumentation von historisch gewachsenen Legacy Anwendungen. Das Ergebnis ist das Sysparency Transparenz Produkt. Die Algorithmen verarbeiten unterschiedlichste Programmiersprachen und bauen daraus abstrakte digitale Modelle der Softwareanwendung. Aus unterschiedlichsten Perspektiven wird dieses abstrakte Modell analysiert und die jeweilige Informationen in der gewünschten Art und Weise als Dokumentation generiert. So ermöglicht es dem Softwareentwickler eine rasche Einarbeitungszeit in eine neue Legacy Anwendung, dem Manager das rasche Treffen der richtigen Modernisierungsentscheidungen und den Fachbereiche das Einarbeiten und nachvollziehen der bereits implementiert Fachlogik. All diese Themen tragen zu erfolgreichen Digitalisierungsprojekten und Modernisierungsvorhaben bei und Sparen Zeit und Ressourcen.

Kostenlose News erhalten

Melden Sie sich zu unserem Newsletter an und erhalten zu Infos zu TOP-Themen.