Foto: BalanceFormCreative - shutterstock.com
Normalerweise denken wir beim Begriff "Legacy-Software" an Anwendungen, die in COBOL geschrieben wurden und irgendwo auf einem Mainframe liegen. Diese Denkweise führt dazu, dass Entwickler ihren Code erstellen ohne vorauszuschauen und daran zu denken, wer diesen später einmal lesen muss.
"In dem Moment, in dem Sie Code ausliefern, handelt es sich um Legacy-Software", meint Jean Yang, Gründerin und CEO von Akita Software. Stellt sich die Frage, wie ein intelligenterer Umgang mit Legacy Code aussehen kann.
Network Calls und Komplexität
Ein Problem mit Code: Er ist nie wirklich statisch. Oder wie es Charity Majors, Mitbegründerin und CTO von Honeycomb, ausdrückt: "Man kann nicht wirklich wissen , wie sich die Software verhalten wird, bis man sie in Produktion gibt." Erst in der Produktion offenbarten sich die Risse im "Legacy"-Code, so Majors: "Ein kleines Stück Code ist ein kompliziertes System, aber sobald es in Betrieb ist, Benutzer, Traffic-Muster und eine zugrundeliegende Infrastruktur hat, wird es komplex. Man kann nicht vorhersagen, was passieren wird, wenn man etwas ändert. Man muss beobachten und sehen, was in einer kontrollierten Umgebung passiert."
Menschliche statt Code-Probleme
"Einzelne Ingenieure können Software schreiben, aber nur Teams können Software liefern, ausliefern und warten. Die kleinste Einheit bei der Bereitstellung von Software ist das Team", unterstreicht die Honeycomb-Managerin.
Wir könnten uns vormachen, dass die Probleme (Bugs, Fehler usw.) technische Probleme mit unserer Anwendung sind, fügt ihre Gesprächspartnerin Yang hinzu. Das gehe jedoch am Kern vorbei, so die Managerin: "Es ist immer ein menschliches Problem. Man muss den Menschen immer vertrauen. Und ein Großteil der Tools hilft dabei, herauszufinden, was die Leute in der Vergangenheit getan haben, was sie in letzter Zeit getan haben und was diese Probleme verursacht hat. Es geht nur um Menschen."
Das bringt uns zurück zu Legacy - und Observability.
Legacy verstehen
"Je länger die Erstellung einer Software zurückliegt, desto mehr steigen die Kosten, wenn Probleme gefunden und behoben werden müssen", so Majors. Daher könnten Observability-Tools entscheidend dazu beitragen, Probleme innerhalb von Minuten zu beheben. Sie ließen den Code in der kontrollierten Produktion laufen und ermöglichten es so den Entwicklern, ihren Legacy-Code kurz nach dem Schreiben zu debuggen - anstatt ihn Monate, Jahre oder sogar Jahrzehnte später zu entschlüsseln.
Das ist auch der Grund, warum eine gute Dokumentation so wichtig ist. Die dient nämlich nicht nur dazu, dass Andere mit dem von uns entworfenen Code zurechtkommen. Simon Willison, Gründer von Datasette, erklärt, er schreibe die Dokumentation auch für sich selbst, da er sonst dazu neige, zu vergessen, warum er den Code auf eine bestimmte Weise geschrieben hat: "Wenn ich in zwei Monaten zu dem Projekt zurückkehre, funktioniert alles, und ich weiß, wo alles ist, weil eine ausführliche Dokumentation vorliegt. Diese hilft mir - und anderen - , sich wieder in den Code einzufinden."
"Ein Teil der Entwicklungsarbeit besteht darin, gute Dokumentationen, gute Unit-Tests und gute Observability zu gewährleisten", meint Majors. "Nur so können Sie sehen, wie sich der Code in Verbindung mit verschiedenen Systemen und Bedingungen verhält. In der IDE werden Sie den Code niemals verstehen - Sie müssen ihn ausführen und dann beobachten."
Und was ist mit denjenigen, die Jahre oder Jahrzehnte später mit Ihrem Code arbeiten wollen? Softwareentwicklungsexperte Avishai Ish-Shalom drückte es vor kurzem so aus: "Unsere 'moderne' Infrastruktur wie Linux, MySQL, PostgreSQL etc. ist Jahrzehnte alt - selbst 'moderne' Clouds sind inzwischen im mittleren Teenageralter. Noch besorgniserregender ist, dass sich diese Infrastruktur zwar als deutlich flexibler und stabiler erweist als unsere optimistischsten Vorhersagen - aber es zeigen sich Alterserscheinungen, was die Wartung und Entwicklung Jahr für Jahr schwieriger macht."
Wir alle leben in einer Legacy-Welt, sowohl im Hinblick auf neue als auch auf alte Legacy-Systeme. Wir gehen (manchmal) von Monolithen zu Microservices über, wechseln von Festplatten zu RAM und tun viele weitere Dinge, wenn wir an Hardware- oder Softwarebeschränkungen stoßen oder Möglichkeiten zur Nutzung neuer Fortschritte erkennen. Für diejenigen, die mit Systemen zu tun haben, die Jahre oder Jahrzehnte alt sind, wird es noch schlimmer, wie Yang ausführt: "Jedes System, das im letzten Jahr gebaut wurde, hat die gleichen Eigenschaften. Aber bei Systemen, die vor fünf oder zehn Jahren gebaut wurden sieht das anders aus. Jedes Legacy-System ist auf seine eigene Art und Weise veraltet." (fm)
- Tobias Leicher, IBM
„Kein Frontend wird 20 Jahre überleben, weil es sehr stark der Mode unterworfen ist. Um aber Dinge, die sich über die Jahre etabliert und Konstanz haben, so zu gestalten, dass sie gut wiederverwendbar sind, ist nicht die Programmiersprache allein entscheidend, sondern ein guter Schnitt, einfacher Zugriff und der Umgang mit den technischen Schulden. Wichtig ist zu lernen, wie man das Management von Applikationen betreibt, die über Jahrzehnte hinweg immer wieder technische Schulden auf- und abgebaut und dabei innovationsfähig geblieben sind, ohne dass die Technologie als der einzige Treiber gesehen wurde. IT ist eine der wenigen Ingenieurswissenschaften bei denen wir selten von bestehenden guten Softwaresystemen lernen. Es lernt doch auch niemand einen Motor zu bauen, ohne sich vorher einen existierenden angesehen zu haben. Warum sammeln Softwareingenieure nicht einfach guten Code und lernen davon, man denke an Designpatterns, wie gute Anwendungen und Algorithmen implementiert wurden und bringen das anderen so bei?“ - Dr. Georg Loepp, Cegeka Deutschland
„Legacy-Systeme haben aber auch Gutes: eine starke Governance mit zum Beispiel einheitlichen Designvorgaben für die Architektur. Mit Zunahme der Client-Server-Architekturen wurden diese jedoch größtenteils aufgeweicht. Aber gerade was Governance-Prozesse oder Skalierbarkeit angeht, können wir von Legacy-Systemen lernen. In vielen modernen Architekturen müssen Standards überhaupt erst einmal umgesetzt werden, die man bei früheren Großrechnern out-of-the-Box hatte. Deshalb sollte man bei der Entscheidung über eine mögliche Ablösung, den Reifegrad neuer Technologien im Vorfeld genau prüfen und vor allem Kosten und Nutzen gegeneinander abwägen. Müssen bestehende Systeme tatsächlich abgelöst werden oder lassen sie sich so modernisieren, dass sie in der neuen Welt besser integriert und kostengünstiger weiterleben können?“ - Dr. Karsten Ballüder, Deloitte
„Wir haben heute eine völlig andere Art der Softwareentwicklung mit dem Fokus auf Funktionalität: Vieles von dem, was eine Softwareanwendung leisten muss, wird über frei verfügbare Frameworks zur Verfügung gestellt. Die Entwickler konzentrieren sich also nur auf das, was kunden- oder anwendungsspezifisch ist. Auch bei COBOL-Anwendungen liegt die eigentliche Geschäftsfunktionalität meist nur bei 20 Prozent der gesamten Code-Basis. Wenn man es nun schafft, diese wertvollen Nuggets an Funktionalität in den Altsystemen zu finden und in die neue Welt zu übertragen, dann hat man den Königsweg gefunden, weil man sich nur auf die Dinge konzentriert, die für das Geschäft wirklich wichtig und wertvoll sind.“ - Martin Reusch, Micro Focus
„Es gibt bei der Modernisierung von Legacy-Systemen nicht den einen Weg: Der Reifegrad von Anwendungen spielt eine große Rolle, zum anderen die individuellen Herausforderungen des Unternehmens. Was möchte man als Unternehmen erreichen und wo steht man in seiner derzeitigen Applikationsentwicklung? Sicher wird es unter Umständen Applikationen geben, die man tatsächlich neu schreiben muss. Doch bei Anwendungen, die echte individuelle Mehrwerte für das Unternehmen generieren und sich für eine Modernisierung eignen, reicht es auch nicht aus, schnell etwas zu machen und dann lange Zeit wieder nichts mehr. Man sollte versuchen, zu einer kontinuierlichen Modernisierung zu kommen, um sie dauerhaft stabil und funktional zu halten. So wie die Golden Gate Bridge, die täglich gestrichen und gewartet wird, damit sie weiterhin befahrbar bleibt.“ - Heidi Schmidt, PKS
„Die technischen Probleme sind schon anspruchsvoll genug. Es gibt zwar Tools, um Transparenz über das technische Durcheinander zu erlangen. Diese sind jedoch nutzlos, wenn die Menschen nicht in der Lage sind, das mit einer gemeinsamen Idee und mit einem gemeinsamen Verständnis über die eigentlichen Probleme nach vorne zu bringen. Dass Fachbereich und IT wieder eine gemeinsame Sprache sprechen ist deshalb essentiell, weil sich die IT-Strategie immer von der Business-Strategie ableiten muss. Für die Firmen ist das eine große Herausforderung, weil sie gleichzeitig unter Handlungsdruck stehen. Viele sind nach wie vor der Hoffnung, dass sie mit einer kurzen Therapie all diese Probleme auf einmal bereinigen können. Diese gibt es aber nicht und je länger man mit solchen Tabletten experimentiert, desto teuer wird es und desto mehr Zeit hat man verloren.“ - Constantin Klein, Syntax
„Wie Unternehmen ihre Systemlandschaft modernisierbar halten können, hängt natürlich davon ab, ob sie ihre eigene Software bauen, oder ob ihre Gesamtlandschaft aus vielen verschiedenen Lösungen besteht. Dazu sollte eine Strategie existieren und genau das stellt auch viele Software-Hersteller (ISVs) vor eine große Herausforderung. Diese müssen sich die Frage stellen, wie groß der Scope für eine Anwendung sein soll, die man nach Möglichkeit massenhaft verkaufen möchte. Wer bisher versucht hat, ein möglichst umfassendes System mit viel Funktionalität für eine bestimmte Branche oder eine bestimmte Problemstellung zu entwickeln, muss seine Lösungen künftig offener und integrierbarer gestalten. Zum einen, um weiterhin im Software-Markt relevant zu bleiben. Zum anderen, um Unternehmenskunden in die Lage zu versetzen, ein Software-Angebot in die eigene Gesamtarchitektur einzubetten.“ - Gerald Hoff, T-Systems M.A.R.S.
„Es fehlen einfach die Leute! Und damit kämpfen alle Unternehmen. Insbesondere wenn es um diejenigen mit Expertise geht, die solche Systeme betreiben können und auch die Verantwortung dafür haben. Die sind schwer zu finden und von den jungen Leuten will niemand mehr zu einem alten Energie-Konzern gehen, der CO2 produziert. Wie schafft man es also, dass Konzerne mit Legacy-IT als Arbeitgebermarke so spannend werden, dass junge Talente auch wirklich Lust haben, dort anzufangen? Nur wer Leute hat, die Projekte umsetzen wollen und auch Spaß daran haben, kann selbst mit einer kleinen Einheit eine Start-up-Geschwindigkeit aufnehmen.“
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.