Wir durchschauen Legacysysteme
Wir haben Sourcecodeanalysen weiterentwickelt und in eine neue Dimension gebracht: 3D - Virtual Reality! Der große Vorteil von 3D ist der unendlich große virtuelle Raum mit all seinen Möglichkeiten. Die Darstellung von monolithischen Applikationen in 3D ist besonders geeignet für Projekte, die eine Applikation “in die Cloud” bringen müssen. Dafür ist das Aufteilen des Monolithen, beispielsweise in Microservices notwendig - eine schwierige und zeitaufwändige Tätigkeit. Die Avesor 3D-Darstellung einer monolithischen Anwendung zeigt mit einem Blick beispielsweise alle Abhängigkeiten der Applikation. Werfen Sie einen Blick auf die VR-Brille, bestückt mit einem über 30 Jahre gewachsenen Cobol-System: Blick in VR.
Die Ergebnisse des technischen Assessments liegen innerhalb von zwei Sprints á zwei Wochen als detaillierter Bericht vor.
Die unverzichtbare Basis für die Planung und Risikoerhebung von Modernisierungs-projekten
Die Strukturen Ihres Legacysystems zur Analyse mit der AVESOR 2D-APP. Eine enorme Arbeits- und Zeitersparnis im Vergleich zur manuellen Softwareanalyse.
Konzipiert für alle, die eine schnelle und verlässliche Beurteilung des Sourcecodes des gesamten Altsystems benötigen.
Das Legacy-Systems mit allen Abhängigkeiten im Quellcode als 3D-Virtual-Reality-Modell zur Analyse mit VR-Brillen - ein Quantensprung in der Analyse von Legacy-Software.
Jahrzehnte alte Software für die interaktive Analyse in Virtual Reality, ohne eine einzige Zeile Sourcecode lesen zu müssen.
AVESOR Cockpit 3D mit Co-Working-Funktionalität für bis zu vier Teilnehmer und Update via WLAN bei erneutem Sourcecode Assessment.
Bis zu vier Mitarbeiter arbeiten im virtuellen Raum zusammen.
Ihr Legacysystem in 2D oder in 3D-Virtual Reality mit AI-Lernkomponente als interaktiver Ratgeber. Baut auf AVESOR® Cockpit auf.
Interaktiver Ratgeber mit AI-Lernkomponente für Legacyprojekte.
Analyse Legacysysteme in Virtual Reality
Inhaltsverzeichnis
1. Hintergründe – wie die Lösung entstand
1.1. Status quo in der Praxis
1.2. Technische Schulden entstehen
1.3. Wissen ist personenabhängig
2. Die Vision
2.1. Textbasierte Lösungen
2.2. YouTube
3. Virtual Reality – die Lösung
3.1. Die Lösung
3.2. Verwendete Hardware
4. Nutzen der Lösung
4.1. Benutzerkreis
4.2. Stets aktuell - kein Veralten
4.3. Hemmschwelle Virtual Reality zu benutzen
1. Hintergründe – wie die Lösung entstand
1.1. Status quo in der Praxis
Betriebliche Softwaresysteme wurden oftmals vor vielen Jahren individuell entwickelt und sind seither im praktischen Einsatz. Beispielsweise ist die Programmiersprache Cobol im Jahr 2019 seit 60 Jahren in Verwendung. Cobol ist für betriebliche Softwaresysteme die am häufigsten verwendet Programmiersprache. Die individuell entwickelte Software war ursprünglich nie für einen Einsatz von über 20, 30 oder sogar mehr Jahren konzipiert. Unternehmen wachsen und entwickeln sich weiter und müssen im Laufe der Jahre die Ablauf- und Aufbauorganisation an geänderte und neue Marktbedingungen anpassen. Die eingesetzte betriebliche Software muss daher ebenfalls permanent erweitert und angepasst werden - Software ist das Schmiermittel für die betrieblichen Prozesse. Über die Jahre und Jahrzehnte wird die ursprünglich individuell entwickelte Software zur Legacysoftware.
1.2. Technische Schulden entstehen
Die Geschäftsorganisation ist ständig gefordert. Neue Märkte sollen erschlossen oder der Kunde soll in die Prozesskette eingebunden werden. Beispielsweise, wenn der Kunde eine Benachrichtigung auf sein Smartphone erhalten soll, sobald die Ware das Lager verlässt und auf dem Weg zu ihm ist. Eine Anforderung, die vor 30 Jahren nicht absehbar war. All das passiert unter steigendem Zeitdruck. Softwareentwicklungsabteilungen haben für die notwendige unmittelbare Dokumentation, warum eine Erweiterungsanforderung in einer bestimmten Art und Weise umgesetzt wurde, nur in seltenen Fällen Zeit. Später wird es nicht mehr gemacht - aus Zeitgründen. Dadurch entstehen sogenannte Technische Schulden. Technische Schulden haben direkte Auswirkungen und verlängern die Zeitdauer und damit verbunden Kosten für die Erweiterung oder Anpassung der Software permanent. Steigende Umsetzungsdauern und Kosten sind die Zinsen, die für technische Schulden gezahlt werden müssen. Ältere Bauwerke werden durch eine Gebäudesanierung auf den aktuellen Stand der Technik gebracht. Im Softwareengineering gibt es ein Gegenstück zur Gebäudesanierung: Code-Refactoring. Das bedeutet, dass der Sourcecode grundlegend überarbeitet wird, damit künftige Erweiterungen des Systems rasch und sicher durchgeführt werden können. In der Praxis erfolgt ein Code-Refactoring aus Zeitgründen nur in den aller seltensten Fällen. Daraus resultiert, dass das Wissen über die Abhängigkeiten und Zusammenhänge im Softwaresystem stark personenabhängig wird.
1.3. Wissen ist personenabhängig
Das Wissen über Abhängigkeiten und Zusammenhänge im Softwaresystem - das Big Picture - ist in den Köpfen weniger Entwickler vorhanden. Wenn diese Entwickler das Unternehmen verlassen oder in Pension gehen, geht dieses Knowhow ebenfalls permanent verloren. Neue Mitarbeiter, die ein langjähriges Softwaresystem zur Betreuung übernehmen, stehen damit vor zwei Herausforderungen:
- Einerseits: das Erlernen der Legacytechnologie, wie beispielsweise Cobol – das ist der einfachere Teil.
- Andererseits: das Erarbeiten des Big Picture aus dem bestehenden umfangreichen und komplexen Sourcecode - das ist der der mühsame und zeitaufwendige Teil. Dieses Problem ist in der Praxis ein immens großes. Es ist für Unternehmen nahezu unmöglich, qualifizierten Nachwuchs für Legacysysteme zu finden.
2. Die Vision
Um in der oben geschilderten Situation zu unterstützen, hat AVESOR® Lösungsvarianten geprüft:
2.1. Textbasierte Lösungen
Komplexe Softwaresysteme sind einem Wollknäuel mit Fäden unterschiedlichster Farben vergleichbar. Man kann das Wollknäuel nicht auflösen, indem man ein Fadenende herauszieht und alle Farben lösen sich auf. Jede textbasierte Lösung, beispielsweise ein Bericht, der das Big Picture eines komplexen Softwaresystems beschreiben soll, resultiert notgedrungen in einem umfangreichen Text. Der Leser muss viel Zeit zum Studium aufwenden, um die Ergebnisse richtig zu verstehen. Zeit, die von Mitarbeitern beansprucht wird, die bereits jetzt keine Zeit haben. Textbasierte Lösungen veralten außerdem sehr rasch und werden damit innerhalb kurzer Zeit nutzlos. Diese Lösungen scheiden aus.
2.2. YouTube
YouTube ist ein wunderbares Medium. Viele lesen keine Zeile eines Benutzerhandbuches, um eine neue Software oder ein neues Spiel zu erkunden. Stattdessen wird auf YouTube nach einem Video gesucht, um das Verhalten der Software visuell mitverfolgen zu können und daraus die Anwendung der Software zu erfahren. YouTube ist ein ausgezeichnetes Medium – allerdings für Videos mit Anleitungscharakter. Im geschilderten Problemfall der Legacysoftware ist es notwendig, dass sich der Anwender (beispielsweise ein Projektleiter, Businessanalytiker oder ein Softwareingenieur) interaktiv einbringen kann. Auch YouTube kann im geschilderten Problemfall nicht helfen.
3. Virtual Reality – die Lösung
3.1. Die Lösung
Von Einstein stammt das Zitat: „Probleme kann man nie mit derselben Denkweise lösen, durch die sie entstanden sind“. Wir fanden eine Lösung für den Zugang zum Big Picture und zum Analysieren von Legacysystemen: Virtual Reality. Virtual Reality ist die Darstellung und Wahrnehmung der Realität in einer computergenerierten, interaktiven Umgebung. In Spielen bauen sich Spieler beispielsweise Welten und Charakter auf und interagieren mit dieser Welt. Wir bauen aus dem Sourcecode eines Cobol Legacysystems (meistens hunderte von Einzelprogrammen) automatisiert ein Legacy-Universum in Virtual Reality auf, welches interaktiv analysiert werden kann. Das Legacy-Universum in der virtuellen Realität umfasst alle Programme und Datenbanken des Systems mit all seinen Abhängigkeiten. Zusätzlich können zu jedem Programm und jeder verwendeten Datenbank Kernparameter, wie beispielsweise Größe, Komplexität, festgestellt Anomalien oder vorhandene Technische Schulden eingeblendet werden. Die Navigation im Legacy-Universum erfolgt durch einen VR-Controller. Mit dem VR-Controller können die einzelnen Objekte direkt angesteuert und herangezoomt werden. Man kann aber auch über die Menüsteuerung und eine Tabelle mit allen Programmen suchen / sortieren und speziell interessierende Elemente auswählen, um im virtuellen Raum dann sämtliche Abhängigkeiten mit den ein- und ausgehenden Informationsflüssen zu sehen. Die Zeit zum Analysieren von Legacysystemen reduziert sich auf einen Bruchteil der Zeit der üblichen manuelle Analyse. Mehr noch: durch die virtuelle Realität wird die Komplexität eines Systems in seiner ganzen Tragweite wahrgenommen - so, wie es mit keinem Bericht möglich ist. Die Analyse kann entweder einzeln oder als Gruppe in der virtuellen Realität erfolgen.
3.2. Verwendete Hardware
Die betrieblichen Abteilungen, die mit der Erstellung und Weiterentwicklung von Legacysystemen betraut sind, haben bisher keine Erfahrung mit Virtual Reality. Eine Anforderung war daher, dass die notwendige VR-Hardware sehr einfach zu bedienen sein muss – dies gilt sowohl für die VR-Brille als auch für den Controller. Unsere Wahl fiel auf die VR-Brille Oculus GO.
4. Nutzen der Lösung
4.1. Benutzerkreis
Die Lösung ist vorgesehen für den Benutzerkreis, der sich ein ganzheitliches Bild von einem jahrzehntelang gewachsenen Legacysystem machen muss. Beispielsweise trifft das auf Projektleiter, Softwareingenieure oder Businessanalytiker zu. Diese Personengruppe ist insbesondere dann gefordert, wenn Aufwand, Zeitbedarf und Risiken für ein Legacyprojekt eingeschätzt und beurteilt werden müssen. Der Nutzen der Anwendung besteht darin, dass das Big Picture – das ganzheitliche Bild – eines Legacysystems nicht mühsam manuell aus dem Sourcecode erarbeitet werden muss, sondern automatisiert erhoben und in Virtual Reality dargestellt wird. Die virtuelle Realität ermöglicht eine vollkommen neue und intensive Wahrnehmung der Größe und Komplexität eines Systems und seiner Teile.
4.2. Stets aktuell - kein Veralten
Durch die automatisierte Erstellung und das Updaten des VR-Modells über WLAN, kann das VR-Modell sehr leicht aktuell gehalten werden und im Vergleich zu textlichen Berichten nicht veralten. Theoretisch könnte das VR-Modell täglich aktualisiert werden. Praktisch wird das updaten des VR-Modells nach Umbauarbeiten im Code Sinn machen, wenn strukturelle Änderungen vorgenommen wurden, beispielsweise wenn Programme hinzu- oder wegkommen oder wenn neue externe Systeme angebunden wurden.
4.3. Hemmschwelle Virtual Reality zu benutzen
Wie erwähnt, ist die Anwendung von Virtual Reality in der Legacy-Softwareentwicklung ein vollkommen neuer Weg des Zugangs zur Analyse der Struktur eines Softwaresystem. Unsere Erfahrungen zeigen, dass der Einsatz einer VR-Brille in der Softwareentwicklung breite Akzeptanz finden.