Legacy-Modernisierung fordert IT-Manager heraus

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, für Plattformen jeglicher Art optimiert und über teils abenteuerliche Hängebrücken miteinander verbunden.

Die gewachsenen Systeme wegwerfen und alles neu 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 GmbH 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.

Informationen zur Studie sowie den Partner-Paketen finden Sie hier

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, locker machen.

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", hat Gunnar Tacke, Managing Business Analyst bei Capgemini, festgestellt.

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 der Deloitte Consulting GmbH, sieht vier Treiber für diesen "ständig wachsenden Markt":

• Die Entwickler, die das technische und das Business-Knowhow 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 der CA Deutschland GmbH, 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 innoQ-Geschä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 Software-Codes auf neuere Programmiersprachen, beispielsweise von Cobol auf Java. Nach Rupps Überzeugung ist ein solches Szenario hinsichtlich Projektlaufzeit, Kosten und RoI der Neuentwicklung vorzuziehen.

Zum Video: Legacy-Modernisierung fordert IT-Manager heraus

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 hinein passen, 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 & Shift als Übergangslösung?

Aus diesem Grund entscheiden sich viele Betriebe, lieber erst einmal ein "Lift & Shift" zu unternehmen. Henning von Kielpinski, Vice President Geschäftsentwicklung und Allianzen bei der Münchner ConSol Software GmbH, spricht hier von einem Ansatz, bei dem "ein System mit minimalem Aufwand in eine abgekapselte Umgebung, beispielsweise einePublic Cloud, verschoben wird".

ConSol habe diesen Schritt oft übersehen und stattdessen gleich komplexe Lösungen wie Microservices promoted, räumte von Kielpinski ein; das allerdings nicht grundlos: Bei Lift & Shift werden die Applikationen gar nicht erst angefasst; die "Altlast" wird einfach über den Zaun geworfen, die Verantwortung dafür teilweise 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, die als legitime Nachfolgerin der Virtualisierung gilt.

Ab in die Cloud: Wann der Hybrid-Gedanke Erfolg verspricht

Container erlauben es, eine Anwendung auf unterschiedliche technische Plattformen aufzuteilen - einschließlich allerCloud-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 Roundtable-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 GmbH. 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.

Allein diese Diskussion belegt: Die Neuentwicklung veralteter Applikationen oder auch die eigenhändige Ergänzung durch neue Anwendungssysteme ist kein Tabu-Thema - nicht nur da, wo der Markt noch keine passenden Angebote bereitstellt oder beispielweise die Wartung für eine Komponente ausläuft. "IT wird eben nicht mehr nur als lästiger Kosten-, sondern als Wettbewerbsfaktor gesehen", warf Tilkov in die Runde, "deshalb entwickeln die Unternehmen heute wieder vermehrt selbst."

Standardisierung ist häufig schmerzhaft

Fürs Erste passé ist vielmehr 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.

Aus den Fehlern der Vergangenheit lernen

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", formuliert es Capgemini-Analyst Tacke.

Informationen zur Studie sowie den Partner-Paketen finden Sie hier

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."

Das Personal selbst heranziehen

Bleibt die Frage, wer diese Aufgaben eigentlich in die Hand nehmen soll. Denn sie sind nicht gerade ein Traumjob für IT-Mitarbeiter. 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."

Das Schlusswort gehörte Delta-Geschäftsführerin Schilling: 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.