Tools und Methoden der Software-Archäologie in Legacy-Systemen

Die Software-Archäologie ist nicht jedermann bekannt, wird aber in vielen Projekten angewendet. Entwickler, die in diesem Bereich tätig sind, stehen oft vor der Herausforderung, die Funktionsweise eines alten, oft ungepflegten Systems zu verstehen, um Lösungen für eine Optimierung oder gar einen Austausch des Systems zu erarbeiten.

Um jene Entwickler bei dieser scheinbar überwältigenden Aufgabe zu unterstützen, liefert dieser Artikel eine Einführung in die Software-Archäologie, stellt Ansätze und Tools vor, die bei der Analyse von Legacy-Systemen hilfreich sind, und teilt einige bewährte Methoden aus der Arbeit von 7P.

Was ist Software-Archäologie?

“Software-Archäologie” beschäftigt sich mit dem Untersuchen und dem Dokumentieren von Legacy-Systemen. Wie der Begriff bereits andeutet, weist die Software-Archäologie viele Parallelen zur echten Archäologie auf:

• Die Software-Archäologie beschäftigt sich mit der Analyse von teilweise uralten Systemen.
• Genau wie in der echten Archäologie existiert für die Legacy-Systeme kaum bis keine Dokumentation.
• Teile des Systems (z. B. einige Quelltexte) können in einem Legacy-System fehlen.
• Legacy-Systeme können in einer exotischen und nicht mehr gebräuchlichen Programmiersprache entwickelt worden sein (z. B. COBOL).
• Die im Legacy-System verwendeten Lösungen können unlogisch, unperformant und sogar seltsam erscheinen, auch wenn es während der Entwicklung des Systems nicht so war.

Wie man sieht, ist die Arbeit des Softwareingenieurs der eines Archäologen sehr ähnlich. Er wird vor allem gebraucht, wenn in einem Unternehmen eine oder mehrere der folgenden Situationen auftreten:

• Die ursprünglichen Entwickler haben das Unternehmen verlassen.
• Die Dokumentation wurde nur sporadisch gepflegt – “Confluence is the place where information is sent to die.”
• Die Arbeit am Quellcode erfolgte direkt auf dem Server, ohne Einsatz von Versionskontrollsystemen (VCS), insbesondere bei älteren PHP-Projekten.
• Die Software wurde in einer Programmiersprache entwickelt, die “archaisch” ist, d.h. für die es heute kaum noch Experten gibt, und in der kaum bis gar nicht mehr weiterentwickelt wird (MUMPS, COBOL).
• Die verwendeten Frameworks enthalten Sicherheitslücken.
• Es werden archaische Netzwerkprotokolle benutzt, mit denen sich nur wenige Menschen auskennen (wie OpenFT).
• Das System funktioniert unter modernen Betriebssystemen nicht.
• Das System ist unkontrolliert gewachsen und unperformant geworden.
• Die Erhaltung des Systems erfordert einen enormen Kraft- und Geldaufwand.
• Das System ist nicht DSGVO-konform (z. B. fehlende Verschlüsselung).

All diese Schwierigkeiten führen meist dazu, dass die Projektleitung beschließt, das System zu ersetzen oder es zumindest auf den aktuellen Stand der Technik zu bringen. Die Softwareingenieure, die mit diesem Projekt beauftragt werden, stehen vor großen Herausforderungen: Wie funktioniert das System? Wie finde ich heraus, wie, was und warum es tut, was es tut? Wie bekomme ich das System in den Griff oder wie schaffe ich eine saubere Spezifikation für ein neues System? Hier wird der Ingenieur zum Archäologen. Wie Entwickler diese Herausforderungen meistern können, erfahren Sie in den folgenden Abschnitten.

Schritt 1 der Software-Archäologie: Die Prospektion

Wie in der Archäologie, ist der erste Schritt die sogenannte Prospektion – eine Erfassung des alten Systems und eine klare Abgrenzung dessen, was untersucht und verändert wird. Dies ist ein zerstörungsfreier Prozess: Es werden Pläne erstellt, aber noch keine “Ausgrabungen” durchgeführt.

Folgende Aufgaben werden durchgeführt:

• Abgrenzung: Umfasst das System die gesamte IT-Landschaft des Unternehmens (eher unwahrscheinlich) oder nur einen Teil davon?
• Analyse:
  – Was macht das System? Ist es ein CRM-System, das die Kunden und ihre Aufträge verwaltet? Ist es ein Datenübertragungssystem, das die Daten von A nach B verschiebt? Wer sind die Nutzer des Systems? Was tut das System für diese Benutzer?
  – Steht das System allein, ohne Verbindung zu anderen Systemes, oder ist es mit anderen Systemen verbunden, die im Scope des Projekte nicht oder minimal berührt werden?
• Projektrahmen: Muss das ganze System neu aufgesetzt werden oder wird “nur” die Optimierung des bestehenden Systems beauftragt (z. B. die Datenverarbeitung DSGVO-konform gestalten)?

Diese Aufgabe wird in der Regel von Software-Architekten mit Unterstützung von Business-Analysten durchgeführt. Sie bereiten die “Landschaft” für die Entwickler vor. Wichtig sind klare und eindeutige Zielvorgaben. Denn nichts ist schlimmer als unklar definierte oder widersprüchliche Anforderungen, vor allem wenn sie ein Legacy-System betreffen, das höchstwahrscheinlich unlogisch und unklar ist. Unklare Ziele würden die anschließenden technische Arbeit stören und können sogar zum Scheitern des Projekts führen.

Schritt 2 der Software-Archäologie: Die Grabung

Nach Abschluss der Prospektion beginnt die eigentliche Systemanalyse – die “Grabung”. In dieser Phase werden die einzelnen Komponenten des Systems detailliert untersucht und dokumentiert. Ziel ist es, ein umfassendes Verständnis des Systems zu erlangen, um darauf aufbauend fundierte Entscheidungen für den Umbau des Systems treffen zu können.
Ein wesentlicher Bestandteil der Software-Archäologie ist der Einsatz geeigneter Tools und Frameworks, um die Analyse und Dokumentation von Legacy-Systemen effizient zu gestalten. Dabei kommen verschiedene Werkzeuge zum Einsatz, die je nach System und Technologie variieren können:

• Versionskontrollsysteme (VCS): Tools wie Git oder SVN helfen, den aktuellen Stand des Quellcodes zu erfassen und Änderungen nachvollziehbar zu dokumentieren.
• Code-Analyse-Tools: Werkzeuge wie SonarQube oder Coverity untersuchen den Quellcode auf Schwachstellen, Sicherheitslücken und mögliche Fehler.
• Dokumentationstools: Systeme wie Confluence oder Doxygen unterstützen bei der Erstellung und Pflege der Dokumentation.
• Reverse-Engineering-Tools: Mit Tools wie Enterprise Architect oder UMLet können bestehende Systeme grafisch modelliert und strukturell nachvollzogen werden.

Schritt 3 der Software-Archäologie: Der Neubau

Nachdem das alte System vollständig analysiert und dokumentiert wurde, wird auf Basis der gewonnenen Erkenntnisse ein neues System aufgebaut. Es sollte in Übereinstimmung mit Clean Architecture und Clean Code entwickelt werden und/oder neue Geschäftsanforderungen erfüllen, die mit dem Altsystem nicht mehr umgesetzt werden konnten.

Bei der Durchführung dieses Schrittes sind folgende Punkte zu beachten:

• Um den Betrieb nicht zu stören, werden beide Systeme – das alte und das neue – zunächst parallel betrieben. Das bedeutet, dass die Trafik nach und nach vom alten auf das neue System umgestellt werden muss. Wie dies genau geschieht, hängt vom Projekt ab.
• In der Anfangsphase wird man parallel zur Neuentwicklung auch den einen oder anderen Bug im Altsystem beheben müssen.

Software-Archäologie: Fallbeispiele

Um die Theorie in die Praxis umzusetzen, betrachten wir nun zwei konkrete Fallbeispiele aus der Praxis:

Fallbeispiel 1: Migration eines in Shell/Perl/C entwickelten Systems nach Java

Projekt: Kopfstelle Justiz

In diesem Projekt wurde 7P beauftragt, um ein altes System zum Datenaustausch zwischen Behörden, das aus C/Shell- und Perl-Skripten entwickelt wurde, nach Java zu migrieren.
Es gab mehrere Herausforderungen, die gemeistert werden mussten und bei denen Software-Archäologie zum Einsatz kam:

• Das System wurde ohne Verwendung eines Versionsverwaltungssystems entwickelt, denn die Skripte waren nur auf einem produktiven Server verfügbar.
• Die Dokumentation war rudimentär und deckte nicht das gesamte System ab.
• Es gab kein Testsystem, auf dem Änderungen getestet werden konnten – ein Testsystem musste erst aufgebaut werden.

Das Team hat die Herausforderungen gemeistert und das System erfolgreich in Java implementiert.

Fallbeispiel 2: Verbesserung von Geschwindigkeit und Latenz eines CRM-Systems

Bei einem Kunden von 7P sollte die Performance des Systems optimiert werden. Auch in solchen Fällen kommen die Methoden der Software-Archäologie zum Einsatz:

• Es war unklar, warum das System des Kunden langsam war. Daher mussten die Logs umfangreich analysiert und Traces gesammelt werden, um zu verstehen, was die Software tut bzw. wie und wo sie auf die Datenbank und andere Systeme zugreift.
• Die Dokumentation war lückenhaft, sodass nicht immer klar war, welches Verhalten vom System erwartet oder fehlerhaft war.

Trotz dieser Voraussetzungen ist es dem Team gelungen, das System zu verstehen und eine Leistungsoptimierung des Systems zu erzielen.

Fazit

Die Software-Archäologie ist eine anspruchsvolle Disziplin, die viel Geduld, Know-how und geeignete Werkzeuge erfordert. Sie ermöglicht es, alte, leistungsschwache und oft unsichere Systeme zu analysieren, zu dokumentieren und auf einen modernen Stand zu bringen. Dabei ist vor allem ein strukturiertes Vorgehen entscheidend für den Erfolg.

Mit den richtigen Ansätzen, Tools und einem klaren Ziel vor Augen können auch die ältesten und komplexesten Legacy-Systeme erfolgreich modernisiert werden. Die Rolle der Software-Archäologie ist somit essenziell, um digitale Artefakte der Vergangenheit zu bewahren und gleichzeitig zukunftsfähig zu machen. Dies stellt nicht nur einen großen Mehrwert für Unternehmen dar, sondern sichert auch deren langfristige Wettbewerbsfähigkeit.