Neu bauen oder renovieren?

Joachim Blome ist Chef der deutschen Dependance von Micro Focus.

Allen Unkenrufen zum Trotz: Die Legacy-Systeme sind nicht tot zu kriegen. Ungeachtetet aller in der Business-IT erfolgten Neuerungen stellen sie weiterhin den harten Kern der Applikationslandschaft dar.

Wundern darf das nicht. Der weltweite Bestand an ausgereifter, bewährter Legacy-Software ist riesig. Insbesondere bei kritischen Aufgaben, grossem Transaktionsaufkommen und hohen Benutzerzahlen sind sie punkto Performance und Stabilität kaum zu übertreffen. Sie stehen in den Warenwirtschaftssystemen von Grossfirmen ebenso im Einsatz wie in der Kontenführung der Banken oder in der Vertragsverwaltung der Versicherungen.

So stehen die IT-Verantwortlichen vor einem Dilemma: Soll eine aufwändige und risikoreiche Softwareentwicklung für komplett neue Applikationen initiiert werden? Oder soll man einfach weiter machen wie bisher und so tun, als schrieben wir noch immer das Jahr 1992?

Beides funktioniert in der Praxis nicht. Eine komplette Neuentwicklung der Anwendungen mit «modernen» Technologien würde die Entwicklungsabteilungen über Jahre blockieren und Millionen kosten. Dabei würde sie hinsichtlich der Geschäftslogik keinen funktionellen Vorteil bringen. Überdies wäre die Ablösung der alten Systeme enorm riskant, weil ausgereifte Applikationen und Prozesse durch solche ersetzt würden, deren Bewährungsprobe nach Abschluss der Arbeiten noch ausstünde. Wobei auch für das gesamte Umfeld, vom Requirements-Management bis hin zum Testen mit anderen Technologien von vorne begonnen werden müsste. Andererseits stellen die Millionen von Code-Zeilen der Altsysteme einen enormen Wert dar - den kein Unternehmen einfach abschreiben kann.

Dieser Problematik ungeachtet zwingen jedoch die neuen Geschäftsmodelle und -prozesse, das allgegenwärtige Web, neue Infrastrukturen und Architekturen die Firmen, zu handeln. Grosse, monolithische Anwendungssysteme, die auf teuren, proprietären Plattformen laufen, passen nicht mehr in eine Zeit, die ganz auf Flexibilität und Agilität ausgerichtet ist. Sie lassen sich nur schwer mit anderen Systemen verbinden oder auf neue Anforderungen ausrichten. Kein Anwender versteht heute noch, weshalb er horrende Beträge selbst für geringste Erweiterungen, etwa beim Speicher oder bei der CPU-Leistung, bezahlen soll. Die Unix-, Linux- und Windows-Server haben in diesem Bereich die Massstäbe unwiderruflich verändert.

Aus dieser Lage ergibt sich eine klare Strategie: Die bewährten Legacy-Systeme müssen dort erhalten werden, wo sie unübertroffene Stärken besitzen: In der Umsetzung von Geschäftslogik in Transaktionen. Und sie müssen überall dort modernisiert werden, wo einerseits eine flexible Interaktion mit den aktuellen Softwarewelten von Web bis -Mobilfunk erforderlich ist und wo sie andererseits die aktuellen Entwicklungen der Hardwaretechnologie gewinnbringend nutzen können.

Geht es um die Hardware, stehen die Alternativen zu Grossrechnern und proprietären Hosts längst bereit. Die x86-basierten Systeme mit 32- und 64-Bit-Architektur haben nicht nur punkto Performance, sondern auch bei der Stabilität - ihrem traditionellen Schwachpunkt - sowohl unter Linux wie unter Windows viel Boden gut gemacht.

Daher werden in den nächsten Jahren die kleineren Mainframes unter Druck geraten, weil sie den Kostenvorteil der PC-Systeme nicht mehr ausgleichen können. Ist doch Intel- oder AMD-Hardware mitunter um das Zehnfache günstiger zu haben als ein leistungsmässig vergleichbarer Mainframe. Mainframe-Anwendungen lassen sich heute in vollem Umfang, ohne Einschränkung ihrer Funktionalität und nahezu ohne Code-Änderungen, auf Windows, Linux oder Unix portieren. Anpassungen beschränken sich meist auf die Infrastruktur der Applikationen wie Batch-Systeme, Scheduler oder Druckspooler, die häufig ganz auf den Mainframe ausgerichtet sind. Zur Überraschung der Anwender verbessert sich im Regelfall sogar die Performance, weil die Applikation nun die CPU für sich alleine nutzen kann.

Durch Wegfall des Host-Systems sind bis zu 80 Prozent Einsparung bei Hard- und Softwarekosten realisierbar. Darüber hinaus sind die Umstellungskosten gering, weil der Applikations-Code nicht angefasst wird. Da überdies die bewährte Business-Logik weiter zur Verfügung steht, sind auch die Risiken der Umstellung gering.

Nach der Portierung läuft alles wie gehabt, die meisten User werden gar nicht merken, dass sie auf einer neuen Plattform arbeiten. Aufgrund der Eins-zu-Eins-Umstellung entsprechen die Applikationen allerdings noch ganz dem Look-and-Feel des vorherigen Host-Systems. Daher bietet es sich an, die Oberfläche zu modernisieren. Für die Umsetzung arbeiten Anbieter wie EDS, CSC, Accenture, Microsoft und Micro Focus zusammen.

Geht es um die Software, wünschen sich viele Unternehmen zusätzlich zu einer -vielseitigeren und kostengünstigeren Hardwareplattform auch eine flexiblere -Applikationslandschaft. Zeitgemässe Anforderungen wie GUI, Webzugriff und PDA-Anschluss bedingen allerdings keine Änderungen der Business-Logik. Im Gegenteil setzen sie zwingend gut eingespielte Backend-Prozesse voraus.

Diese sind in den Legacy-Systemen bereits abgebildet und sollten weiter genutzt werden. Die für moderne Anforderungen notwendigen, neuen Module können über Java oder Web Services problemlos integriert werden.

Damit dies nicht zu aufwändigen Entwicklungsarbeiten führt, stellen die Anbieter entsprechende Werkzeuge zur Verfügung. Diese erlauben es beispielsweise, die vorhandenen Legacy-Module automatisch -zu kapseln und in eine Komponenten--Architektur wie etwa J2EE zu überführen.

Diese Art der Applikations-Modernisierung erhält die wertvolle Business-Logik und integriert neue Funktionalitäten. Zwar ist dabei der Entwicklungsaufwand höher als bei der Portierung. Er ist aber dennoch viel geringer als bei Neuentwicklungen.

Noch mehr Flexibilität lässt sich erreichen, wenn eine Legacy-Anwendung in eine Service-orientierte Architektur (SOA) integriert wird. Da sich eine SOA technikneutral verhält, ist es unerheblich, ob die zugrunde liegenden Services als J2EE- oder als Cobol-Komponenten realisiert wurden.

Die Wiederverwendung von Legacy Services minimiert die Risiken der Softwareentwicklung und reduziert die Kosten. Zudem lassen sich vorhandene Qualifikationen weiter nutzen, sodass insgesamt mit einer Modernisierung auch ein optimaler Investitionsschutz erreicht wird.

Aus der Praxis

Wie eine Modernisierung der Legacy-Systeme praktisch erfolgt, zeigen zwei Beispiele.

Der Detailhändlerin war daran gelegen, ihr Kundenbindungsprogramm «Supercard» flexibler zu gestalten und für die Kundschaft komfortabler zu machen. Dazu wurde es von einem OS-390-Mainframe auf eine Unix-Plattform portiert. Dabei konnten die vorhandenen Cobol-Applikationen für die umfangreiche und performance-kritische Daten-Aggregation durch Einsatz entsprechender Werkzeuge ohne Neuprogrammierung in die neue Umgebung übernommen werden.

Die Suva stand vor dem Problem, ihre Anwendungen auf den neuesten Stand bringen zu müssen. Dazu wurden in einem umfangreichen Migrationsprojekt alle Kernanwendungen von einer Client-Server-Architektur unter OS2 auf eine verteilte Thin-Client-Architektur mit Java-Front-Ends umgestellt. Dabei konnte die vorhandene, mit Cobol entwickelte Geschäftslogik komplett übernommen werden. Heute greifen die Java-GUIs über eine neue Middleware-Schicht auf die Cobol-Module zu.