Legacy-Anwendungen – Asset oder Ballast?
Die Modernisierung von Altanwendungen kostet Zeit, Nerven und Geld. Nicht immer ist klar, ob sich der Aufwand lohnt.
Startups haben es gut: Sie können neue Systeme bauen, ohne Rücksicht auf vorhandene zu nehmen. Aber irgendwann wird aus einem erfolgreichen Startup ein Unternehmen mit gewachsener IT-Struktur. Das Thema Legacy-Modernisierung ist also ein Evergreen. Welche Probleme sich dabei wie lösen lassen, diskutierten auf Einladung der COMPUTERWOCHE Modernisierungsexperten aus sieben Unternehmen.
Alle reden von der digitalen Transformation. Dabei denkt fast jeder zuerst an das Digitale, nur wenige an die Transformation. Doch die meisten Unternehmen fangen nicht auf der grünen Wiese an; ihre Systeme und Anwendungen sind oft über Jahrzehnte gewachsen, in unterschiedlichen Sprachen programmiert und über teils abenteuerliche Hängebrücken miteinander verbunden. Die gewachsenen Systeme wegzuwerfen und alles neu zu entwickeln ist utopisch, denn sie sind unternehmenskritisch: Das darin enthaltene Wissen lässt sich nicht ohne Weiteres ersetzen. „Legacy heißt Vermächtnis und sollte eigentlich etwas Positives sein“, sagt Stefan Tilkov, CEO der innoQ Deutschland mit Sitz in Monheim. Dass der Begriff negativ besetzt sei, liege nur daran, dass die „geerbten“Anwendungen so unbeweglich sind. Sie schneller, flexibler und agiler zu machen, ist das Ziel der Legacy-Modernisierung.
Den Modernisierungsdruck spüren viele Unternehmen – und nicht erst seit gestern. In den großen Konzernen, in vielen Behörden, aber auch bei den größeren Mittelständlern schlummert so manche Legacy-Leiche im Keller. Budgets für die Wiederbelebung wollen aber allenfalls die extrem datengetriebenen Unternehmen, vor allem in der Finanzwirtschaft, lockermachen. In anderen Betrieben segeln Modernisierungsprojekte auch schon mal unter falscher Flagge. „Im Zusammenhang mit dem Stichwort Digitalisierung wurden Mega-IT-Budgets freigesetzt, die nun aber erst einmal für die Modernisierung der Kernsysteme investiert werden“, stellt Gunnar Tacke, Managing Business Analyst bei Capgemini, fest.
Warum Legacy-Modernisierung?
So kommt es, dass sich derzeit schon fast ein Modernisierungs-Boom abzeichnet. Davon profitieren auch die Berater und Systemhäuser. Axel Rupp, Partner bei Deloitte Consulting, sieht vier Treiber für diesen „ständig wachsenden Markt“:
Die Entwickler, die das technische und das Business-Know-how der Anwendungen haben, gehen in den kommenden Jahren nach und nach in den Ruhestand (der Fachjargon spricht hier vom „Brain Drain“). In der Implementierung von Geschäftsanforderungen dominieren immer mehr die Faktoren Agilität, Effizienz und Geschwindigkeit. Da können die älteren Systeme nicht mithalten. Dasselbe gilt für offene Schnittstellen und Interoperabilität in der Systemlandschaft, die mittlerweile „Key“sind. Die Betriebskosten der gewachsenen Systeme, vor allem auf dem Mainframe, sind sehr hoch, verglichen mit virtuellen Umgebungen oder Cloud-Ansätzen.
Allerdings beschränkt sich der Modernisierungsbedarf keineswegs auf den Mainframe. Daran erinnerte Georg Lauer, Senior Principal Business Technology Architect bei CA Deutschland, seine Diskussionspartner: „Das hier ist keine Plattformdiskussion, sondern eine über geschäftskritische Systeme.“Viele Unternehmen wollten ihre Mainframes durchaus behalten, und sie suchten nach Wegen, sie sinnvoll in eine moderne Umgebung einzubinden. Auf der anderen Seite sind Legacy-Probleme auch bei Anwendern zu finden, die noch nie etwas mit Mainframes zu tun hatten. Laut innoQGeschäftsführer Tilkov gibt es „Unmengen von Delphi-, C++ oder Java-Programmen, die niemand mehr warten kann“.
Services und Microservices
Diese Probleme sind nicht neu. Vor zehn Jahren textete die COMPUTERWOCHE: „Wertstoff Legacy-Code: Rette ihn, wer kann“. Genau genommen war die Wiederverwendung vorhandener Software schon im vergangenen Jahrtausend ein Thema auf Software-Engineering-Konferenzen. Und eine ganze Reihe von Unternehmen portiert heute noch einen Teil ihres Softwarecodes auf neuere Programmiersprachen, beispielsweise von Cobol auf Java. Nach Rupps Überzeugung ist ein solches Szenario hinsichtlich Projektlaufzeit, Kosten und RoI der Neuentwicklung vorzuziehen.
Auch auf der Anwendungsebene wurden längst Konzepte entwickelt, mit denen sich technisch veraltete Applikationen weiter nutzen und integrieren lassen. Zu Beginn des Jahrtausends machte die SOA (Service-orientierte Architektur) Furore, weiterentwickelt wurde sie zu den „Microservices“. Beiden gemeinsam ist die Idee, Applikationen in überschaubare Bestandteile („Services“) zu zerlegen und über eine Verbindungsschicht (zum Beispiel einen Enterprise-Service-Bus) anzusprechen. Eine solche Architektur ist technisch anspruchsvoll. Damit die monolithischen Altanwendungen dort hineinpassen, müssen sie entlang ihrer geschäftlichen Logik zerteilt werden. Es reiche nicht, ein neues Frontend vor die Anwendung zu packen, warnt Tilkov: „Die spannende Logik steckt im Backend.“Doch unternehmenskritische Applikationen zu zerteilen bedeute einen „enormen Kraftakt“.
Lift and Shift als Übergangslösung?
Aus diesem Grund entscheiden sich viele Betriebe, erst einmal ein „Lift and Shift“zu unternehmen. Henning von Kielpinski, Vice President Geschäftsentwicklung und Allianzen bei der Münchner Consol Software, spricht hier von einem Ansatz, bei dem „ein System mit minimalem Aufwand in eine abgekapselte Umgebung, beispielsweise eine Public Cloud, verschoben wird“. Consol habe diesen Schritt oft übersehen und stattdessen gleich komplexe Lösungen wie Microservices promotet, räumte von Kielpinski ein; das allerdings nicht grundlos: Bei Lift and Shift werden die Applikationen gar nicht erst angefasst; die „Altlast“wird einfach über den Zaun geworfen, die Verantwortung dem Cloud-Betreiber überlassen.
Das kann keine Dauerlösung sein, findet der Consol-Manager: „Für eine wirkliche Modernisierung muss man irgendwann das Messer
nehmen und die Systeme zerschneiden, um zu verstehen, wie sie funktionieren.“Die IT-Industrie bietet dafür auch schon Hilfestellung an, beispielsweise in Form der Container-Technik.
Container erlauben es, eine Anwendung auf unterschiedliche technische Plattformen aufzuteilen – einschließlich aller Cloud-Varianten. Nicht nur Microservices werden häufig von Dritten in der Cloud bereitgestellt. Immer öfter lagern die Unternehmen auch ihre selbstentwickelten Anwendungen ganz oder teilweise in fremdbetriebene Umgebungen aus. Allerdings scheuen sich viele noch, die unternehmenskritischen Bestandteile ihrer IT-Landschaft ebenfalls auszulagern. Sie führen gern Sicherheitsbedenken oder regulatorische Beschränkungen ins Feld. Die schleppende Akzeptanz der Deutschen Cloud legt allerdings den Verdacht nahe, dass dieses Argument nur vorgeschoben ist.
Wie dem auch sei: Teile ihrer Systeme behalten die Unternehmen lieber bei sich. Im Ergebnis haben sie dann oft eine „hybride Umgebung“. Grundsätzlich bewerten die Round-Table-Teilnehmer diesen Trend als vielversprechend. Von Kielpinski hält allerdings nichts davon, ihn überzustrapazieren: „Manches geht einfach nicht hybrid, und wenn sich der Gedanke nicht von selbst aufdrängt, bringt es nichts, das mit Gewalt zu versuchen.“
Neuentwicklung ist wieder en vogue
Das Pendant zu den integrierten Services bildet auf der Development-Seite eine standardisierte Entwicklungsumgebung, die unterschiedliche Programmiersprachen abdeckt. Die Entwickler können also in ihrer gewohnten Umgebung oder auch mit neuen, „agilen“Methoden arbeiten, entwickeln aber gegen eine standardisierte Schnittstelle und im Rahmen eines für alle verbindlichen Makroprozesses. „Wir brauchen eine durchgängige Entwicklungsumgebung und zugehörige Prozesse, die unabhängig von der Programmiersprache sind“, fordert Daniela Schilling, Geschäftsführerin der Delta Software Technology. Dazu müssten auch langjährige Entwickler noch einmal einen neuen Prozess erlernen. Aber das sollte kein Problem sein, wenn der Prozess sauber definiert und mit intensiver Schulung vermittelt wird. Im Rahmen einer neuen Entwicklungsumgebung lassen sich auch Strukturen schaffen, bei denen die Anwendungserstellung Hand in Hand mit dem IT-Betrieb arbeitet. Solche „DevOps“-Systeme empfehlen sich vor allem für Applikationen, die quasi „im Flug“änderbar sein müssen.
Die Diskussion belegt: Die Neuentwicklung veralteter Applikationen oder auch die eigenhändige Ergänzung durch neue Anwendungssysteme ist kein Tabu – nicht nur da, wo der Markt noch keine passenden Angebote bereitstellt oder die Wartung für eine Komponente ausläuft. „IT wird eben nicht mehr nur als lästiger Kosten-, sondern als Wettbewerbsfaktor gesehen“, so Tilkov, „deshalb entwickeln die Unternehmen heute wieder vermehrt selbst.“
Standardisierung ist häufig schmerzhaft
Fürs Erste passé ist der Run auf Standardsoftware. „Alles, was sinnvoll standardisierbar ist, ist schon standardisiert“, konstatierte Andreas Espenschied, der als Senior Vice President bei der Software AG für die Geschäftsentwicklung der Datenbank- und Entwicklungsumgebung „Adabas/Natural“verantwortlich zeichnet: „Wenn man darüber hinaus standardisieren will, wird es schmerzhaft, denn dann geht es an die DNA des Unternehmens.“Möglicherweise hat ja auch das 2010 mit viel Brimborium ins Leben gerufene und vor etwas mehr als zwei Jahren nahezu unbemerkt entschlafene „Magellan“-Projekt der Deutschen Bank zur Verbreitung einer gewissen Skepsis beigetragen. Selbst mit viel gutem Willen – und üppigem Budget – lassen sich vermutlich nicht alle Unternehmensprozesse ohne Verluste in Standardsoftware abbilden. Die „Monsterprojekte“der Vergangenheit gibt es heute ohnehin nicht mehr. Das hat nicht nur innoQ-CEO Tilkov
beobachtet. Und noch etwas fiel ihm auf: „Heute wird von Anfang an so entwickelt, dass eine Modernisierung in Zukunft hoffentlich leichter wird.“Eine Umgestaltung, die morgen schon wieder Schnee von gestern ist, braucht tatsächlich niemand. Wer seine IT-Architektur einmal anfasst, sollte sie lieber gleich auf maximale Flexibilität und Erweiterbarkeit trimmen. „Wir müssen uns Gedanken machen über die Evolutionsfähigkeit der Architektur“, sagt Capgemini-Analyst Tacke.
Eine in diesem Sinne „nachhaltige“Architektur umfasst neben der Entwicklungsumgebung und der (Micro-)Service-orientierten Struktur sicher auch die Prozesse. Espenschied liegt deshalb ein „kontinuierlicher Modernisierungsprozess“am Herzen, der die permanente Weiterentwicklung und Bereitstellung neuer Business-Funktionen ermögliche – was immerhin die Kernaufgabe der IT sei. Tilkov geht noch einen Schritt weiter: Auch die (IT-)Organisation müsse modernisiert werden. Die Prozesse, die sich rund um die Entwicklung und Wartung der Legacy-Anwendungen etabliert hätten, seien schließlich auch in der Organisation verankert. Deshalb reiche es selten, nur die Technik zu modernisieren: „Organisation und Prozesse müssen sich ebenfalls verändern. Und dagegen ist die Cobol-Modernisierung ein Kinderspiel.“
Bleibt die Frage, wer diese Aufgaben eigentlich in die Hand nehmen soll. Denn sie sind nicht gerade ein Traumjob. Tilkov bringt es auf den Punkt: „Neue Mitarbeiter haben oft keinen Bock, sich auf eine hinübergerettete, proprietäre Umgebung einzulassen und sich damit ihren Lebenslauf zu verderben. Die hippen Leute wollen cooles Zeug.“Auf der anderen Seite wollten aber gerade die jüngeren Leute heute sinnstiftende Dinge tun und zum Erfolg des Unternehmens beitragen. An diesem Punkt sind die Youngsters eventuell zu packen. Auch Lauer sieht in Sachen Personalbedarf keineswegs schwarz. Sein Arbeitgeber CA Deutschland zieht sich das Know-how selbst heran: „Wir haben ein Ausbildungszentrum in Prag, wo wir junge Leute am Mainframe ausbilden, die wir dann auch in unserem Entwicklungszentrum beschäftigen.“Delta-Geschäftsführerin Schilling konstatiert: Es sei ja durchaus verständlich, dass vor allem IT-Einsteiger gern bei einem Startup mit neuester Technologie arbeiten. Allerdings seien manche der coolen Unternehmen bei näherem Hinsehen dann vielleicht doch nicht ganz so cool.