Thought Leadership
Legacy-Software macht vielen Unternehmen das Leben schwer. Nadine Riederer, CEO der Avision GmbH, erläutert im Interview, wie sie sich gezielt auf Vordermann bringen lassen.
Die Basis jeder Softwaremodernisierung sollte eine gründliche Bestandsaufnahme sein. Wie geht man dabei am besten vor?
Nadine Riederer (Foto, Quelle Avision): Zunächst ist es wichtig zu verstehen, dass eine Software nicht nur aus Sourcecode besteht, sondern auch aus fachlichen und organisatorischen Prozessen. Um Optimierungspotenziale zu identifizieren, müssen Unternehmen deshalb vor allem klären, welchem Zweck eine Software dient, welche Prozesse sie abbildet und welche Bestandteile eventuell nicht mehr genutzt werden. Wichtig ist aber auch, die Benutzer zu identifizieren. Sie müssen die Modernisierung begleiten und am Ende auch akzeptieren. Die technische Bestandsaufnahme bildet dann erst den letzten Schritt.
Legacy-Software ist häufig schlecht dokumentiert. Wie kann dennoch nachvollzogen werden, wie sie technisch funktioniert?
Durch die Abklärung des fachlichen Kontextes wissen Unternehmen bereits, welche Daten eine Anwendung verarbeitet. Und wenn sie den fachlichen Zusammenhang kennen, verstehen sie auch die Benennung von Datenbanktabellen, Objekten und Methoden: die Entwickler auch sehr alter Software haben sie meist fachlich benannt. Im nächsten Schritt sollte dann der komplette Umfang einer Anwendung ermittelt werden, um sie anschließend in kleinere Bestandteile zu unterteilen, also etwa Datenbank, grafische Benutzerschnittstelle, Schnittstellen oder Backendverarbeitung.
Da früher oft sehr datenbankkonzentrisch programmiert wurde, lohnt sich danach immer ein genauerer Blick auf die Datenbank. Anschließend sollten die Schnittstellen unter die Lupe genommen werden, um Datenkonsumenten und -lieferanten sowie die übertragenen Dateninhalte zu identifizieren. Dabei können spezielle Tools wie der Orion Metadata Harvester helfen. Auch für die abschließende Analyse des Sourcecodes gibt es wertvolle Hilfswerkzeuge, um die Kopplung der verschiedenen Objekte untereinander zu identifizieren. Gemeinsam mit dem fachlichen Kontext lassen sich Sinn und Zweck der meisten Softwarebestandteile damit sehr schnell erkennen.
Nach welchen Kriterien wird entschieden, welche Bausteine beibehalten oder ausgetauscht werden?
Das hängt von der Zielsetzung des Projekts ab. Bei einem Refactoring etwa werden vor allem Bausteine mit vielen Abhängigkeiten bearbeitet und nicht mehr unterstützte Frameworks durch moderne ersetzt. Ist das Ziel erhöhte Sicherheit, konzentriert man sich auf die Bausteine mit User-Interaktion und die Datenhaltung und sorgt durch modernere Technologien dafür, dass man etwa kryptografische Methoden einsetzen oder SQL-Injections verhindern kann. Oft ist das Ziel aber, Einschränkungen der Anwender zu verringern, etwa, wenn eine Software immer langsamer wird oder seit einem Systemupgrade nicht mehr richtig funktioniert. Dann gilt es, die verantwortlichen Bausteine zu finden, zu überarbeiten oder gegebenenfalls auszutauschen.
Wie werden neue Features integriert?
Theoretisch geht die Einbindung neuer Features ganz einfach: die anzupassende Stelle finden, Tests schreiben, um Seiteneffekte zu vermeiden, und dann das neue Feature integrieren. Sobald man die allgemeine Ebene verlässt, wird es allerdings schwieriger. Möglicherweise ist es besser, erst ein veraltetes Framework auszutauschen, um das neue Feature dann zukunftssicher und einfacher integrieren zu können. Oder aber das neue Feature verlangt eine Anpassung der Schnittstellen und damit nicht nur lokale Veränderungen. In Legacy-Anwendungen ist eine lose Kopplung von einzelnen Modulen nicht besonders häufig, daher ist bei jeder größeren Anpassung mit Seiteneffekten zu rechnen. Wenn Tests zur Verfügung stehen – optimalerweise automatisiert – kann man Features integrieren und auf Seiteneffekte prüfen. Falls nicht, werden zusätzliche Tests nötig.
Wie lässt sich die Performance von Altanwendungen steigern?
Häufig lässt sich die Performance schon durch bloßes Aufräumen verbessern. Also alles raus, was nicht mehr gebraucht wird! Und auch so mancher neue Index in der Datenbank hat die Leistungsfähigkeit schon deutlich erhöht. Aber natürlich gibt es auch durch die technischen Innovationen der letzten Jahre einige Möglichkeiten. Monolithische Anwendungen lassen sich zerteilen und auf mehrere virtuelle Systeme verteilen oder in die Cloud bringen. Auch der Wechsel von Betriebssystemen, Datenbanken und Frameworks bietet sich oft an. Einen Königsweg gibt es aber nicht, deshalb muss zunächst immer genau analysiert werden.
Wie wird aus einer alten ungesicherten Software eine moderne, vor unbefugtem Zugriff gesicherte Anwendung? Die auch noch DSGVO-konform ist?
Zunächst einmal müssen die zu sichernden Daten identifiziert und klassifiziert werden. Auch dabei können Werkzeuge wie der genannte Metadata Harvester helfen. Dann sollte überprüft werden, ob diese Daten überhaupt nötig sind. Die Datensparsamkeit ist ja eines der wichtigsten Prinzipien der DSGVO. Außerdem gilt: Daten, die nicht gespeichert oder erfasst werden, muss man auch nicht schützen. Zudem hilft es an dieser Stelle, ein vernünftiges Benutzer- und Rollenkonzept aufzusetzen. Das ist durch kein uns bekanntes Werkzeug automatisierbar, deshalb ist hier Nachdenken gefragt.
Durch Bedrohungsanalysen mit der STRIDE-Methodik lassen sich mögliche Schwachstellen identifizieren. Durch Werkzeuge zur statischen und dynamischen Security-Analyse, wie Fortify von HP oder VEGA von Subgraph, können dann konkrete Ansatzpunkte gefunden werden. Ein einfacher Ansatz mit großer Wirkung ist, mit kryptografischen Verfahren zu arbeiten, Dateien verschlüsselt abzulegen und verschlüsselte Protokolle bei der Kommunikation zu benutzen. Das ist auch in Legacy-Software schnell realisierbar, da es sich dabei meist um sehr lokale Anpassungen handelt.
Frau Riederer, vielen Dank für das Gespräch!
