|
|
|
»manage
it«
als
|
Softwareentwicklung und Modernisierung Vierter Frühling für Legacy Legacy-Systeme haben in der Unternehmens-IT eine festen Platz, sie abzulösen würde einen großen Aufwand und ein unkalkulierbares Risiko mit sich bringen. Stattdessen müssen die bewährten Applikationen modernisiert werden, sei es um Kosten zu reduzieren, sei es um aktuelle Technologien einzubinden.
ot gesagt wurden Legacy-Systeme schon oft. Als beispielsweise Anfang der 90er-Jahre die PCs zum erstem Mal in die Business-IT hinein schnupperten und jeder von den phantastischen Möglichkeiten der Client-Server-Architektur schwärmte. Als zum Jahrtausendwechsel revolutionäre Geschäftsmodelle das Unterste zu Oberst kehrten, brauchte die Welt nichts weniger als COBOL-Applikationen. Heute kreist auch die Business-IT ums Web, das neue Geschäftsprozesse initiiert, neue Architekturen und Infrastrukturen benötigt. Den Legacy-Systemen haben diese Entwicklungen letztlich nicht viel anhaben können, sie bilden in vielen Unternehmen weiterhin den harten Kern der Anwendungslandschaft. Es gibt weltweit einen riesigen Bestand an ausgereifter und bewährter Legacy-Software. Insbesondere bei kritischen Aufgaben, bei großem Transaktionsaufkommen und hohen Benutzerzahlen sind diese Systeme erste Wahl, weil sie hinsichtlich Performance und Stabilität nicht so leicht zu übertreffen sind: Warenwirtschaftsysteme größerer Unternehmen, Buchungssysteme, Kontoführung in Banken, Vertragsverwaltung in Versicherungen usw. Die Millionen von Code-Zeilen der Legacy-Systeme stellen einen enormen Wert dar, den kein Unternehmen einfach abschreiben kann. Eine komplette Neuentwicklung der Anwendungen mit »modernen« Technologien würde die Entwicklungsabteilungen der Unternehmen über Jahre blockieren, viele Millionenbeträge verschlingen und unterdessen aktuelle Weiterentwicklungen unmöglich machen. Hinsichtlich der Geschäftslogik würde eine Neuentwicklung keinen funktionellen Vorteil bringen. Sie wäre auch sehr risikoreich, denn man müsste ausgereifte Applikationen und Prozesse durch umfangreiche Neuentwicklungen ersetzen, deren Bewährungsprobe nach Abschluss der Arbeiten noch aussteht. Die Unternehmen haben in den vergangenen Jahren und Jahrzehnten ja nicht nur in die Code-Erstellung investiert, sondern auch in das gesamte Softwareumfeld vom Requirements-Management bis zum Test, um die Sicherheit und Zuverlässigkeit ihrer Anwendungen zu optimieren. Auch hier müsste man bei einer vollständigen Neuentwicklung mit anderen Technologien von vorne anfangen. Etliche Anwender haben in der Vergangenheit die damit verbundenen Risiken unterschätzt und haben viel Lehrgeld zahlen müssen, beispielsweise in aufwendigen Java-Großprojekten. Mittlerweile hat sich, insbesondere in großen Unternehmen, eine Koexistenz von Java und Legacy durchgesetzt, Von der Idee, man könnte die Legacy-Systeme komplett ablösen, hat man sich verabschiedet. Kurzfristig ist das ganz ausgeschlossen, mittelfristig schwierig, langfristig immer noch unwahrscheinlich. Einfach weitermachen wie bisher und so tun als wäre noch 1992, geht natürlich auch nicht. Die neuen Geschäftsmodelle und -prozesse, das allgegenwärtige Web, die neuen Infrastrukturen und Architekturen gibt es ja, sie stellen Anforderungen, auf die sich die Unternehmen einlassen müssen. Die großen, monolithischen Anwendungssysteme, die auf teueren, 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, warum er für die geringste Erweiterung, etwa beim Speicher oder bei der CPU-Leistung, horrende Beträge zahlen soll. Hier haben die Unix-, Linux- und Windows-Server die Maßstäbe unwiderruflich verändert. Daraus ergibt sich eine klare Strategie: Legacy-Anwendungen müssen da erhalten werden, wo sie ihre unübertroffenen Stärken haben, also in der Umsetzung von Geschäftslogik in Transaktionen. Sie müssen da modernisiert werden, wo zum einen eine flexible Interaktion mit den aktuellen Softwarewelten von Web bis Mobilfunk erforderlich ist, zum anderen, wo sie die aktuellen Entwicklungen der Hardwaretechnologie nutzen können. Behalten und portieren Hinsichtlich der Hardware stehen die Alternativen zu Großrechnern und proprietären Hosts längst bereit. Die x86-basierten Systeme mit 32- und 64-Bit-Architektur haben mittlerweile nicht nur hinsichtlich der Performance, sondern auch bei der Stabilität, ihrem traditionellen Schwachpunkt, viel Boden gut gemacht, sowohl unter Linux als auch unter Windows. 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. Intel- oder AMD-Hardware ist mitunter um das Zehnfache günstiger zu haben als ein leistungsmäßig vergleichbarer Mainframe. Die Kluft zwischen Preis und Performance weitet sich immer mehr, trotz aller technologischen Fortschritte, die IBM im Mainframe-Sektor weiterhin macht. Während sich der Markt von den kleinen Mainframes langsam verabschiedet, werden sich die großen behaupten. So rechnen Gartner-Analysten damit, dass bis 2010 rund 80 Prozent der Unternehmen mit kleineren Mainframes diese Plattform verlassen werden, während größere Mainframes SOA-fähig gemacht und beibehalten werden. 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, also auf Batch-Systeme, Scheduler, Druckspooler usw., die häufig ganz auf den Mainframe ausgerichtet sind. Zur Überraschung der Anwender verbessert sich dabei in der Regel sogar die Performance, weil die Applikation nun die CPU für sich alleine nutzen kann. Durch den Wegfall des Host-Systems lassen sich erhebliche Kosten einsparen, 80 Prozent Einsparung bei Hard- und Softwarekosten sind durchaus realistisch. Demgegenüber sind die Umstellungskosten gering, weil der Applikations-Code ja nicht angefasst werden muss. Da die bewährte Business-Logik weiterhin 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 bemerken, dass sie auf einer neuen Plattform arbeiten. Selbst komplexe Mainframe-CICS-Applikationen können auf diese Weise ihre technische Basis wechseln, ohne dass sich an ihrer Leistungsfähigkeit etwas ändert. Sie wird allerdings auch nicht gesteigert, der Business-Value der portierten Legacy-Applikation, also ihr Beitrag zur Wertschöpfung eines Unternehmens, bleibt unverändert. Auf Grund der (gewollten) 1:1-Umstellung entsprechen die Applikationen natürlich noch ganz dem Look-and-Feel des vorherigen Host-Systems, so dass unter Umständen weitere Anpassungs- und Modernisierungsarbeiten erforderlich sind. Namhafte Anbieter wie EDS, CSC, Accenture, Microsoft und Micro Focus arbeiten bei der Umsetzung dieses Konzepts seit langem zusammen und können auch zahlreiche erfolgreich Projekte vorweisen. Behalten und erweitern Eine flexiblere und kostengünstigere Hardwareplattform reicht vielen Unternehmen heute nicht mehr. Sie benötigen – zusätzlich – eine flexiblere Applikationslandschaft. Anforderungen wie GUI, Web-Zugriff, PDA-Anschluss usw. bedingen jedoch keine Änderungen der Business-Logik, im Gegenteil, sie setzten gut eingespielte Backend-Prozesse voraus. Diese in den Legacy-Systemen abgebildet und können weiter genutzt werden. Neue Module für neue Anforderungen können über Java oder Web Services problemlos integriert werden. Damit das nicht zu aufwendigen Entwicklungsarbeiten führt, stellen die einschlägigen Anbieter leistungsfähige Werkzeuge zur Verfügung, so zum Beispiel den Component Generator von Micro Focus, der vorhandene Legacy-Module automatisch kapselt und in eine Komponentenarchitektur, zum Beispiel J2EE, überführt. Die Applikationsmodernisierung erhält die wertvolle Business-Logik und integriert neue Funktionalitäten. Der Entwicklungsaufwand ist demgemäß höher als bei der Portierung, aber erheblich geringer als bei Neuentwicklungen, zumal man auf diese Weise auch partielle Modernisierungsprojekte durchführen kann. Mehr Flexibilität lässt sich erreichen, wenn die Legacy-Applikation in eine serviceoorientierte Architektur (SOA) integriert wird. Da sich eine SOA definitionsgemäß gegenüber den Technologien neutral verhält, ist es unerheblich, ob die zugrunde liegenden Services als J2EE- oder als COBOL-Komponenten realisiert wurden. Man kann also auf der Ebene der Geschäftsprozesse in COBOL geschriebene Prozess-Module kapseln und über standardisierte Schnittstellen lose verbinden. Sind bewährte COBOL-Komponenten vorhanden, so können sie als Services allen Applikationen zur Verfügung gestellt werden – beispielsweise auch Web-Anwendungen. Die Wiederverwendung von Legacy Services minimiert die Risiken der Softwareentwicklung und reduziert die Kosten. Zudem lassen sich auch vorhandene Qualifikationen weiter nutzen, so dass auch unter diesem Aspekt optimaler Investitionsschutz erreicht wird. Joachim Blome _____________________________________________________________________ Joachim Blome ist Leiter der deutschen Niederlassung von Micro Focus
Modernisierung in der Praxis – erweiterte Applikationen · Schweizerische Unfallversicherungsanstalt, Luzern Die Schweizerische Unfallversicherungsanstalt hat in einem umfangreichen Migrations-Projekt ihre Kernanwendungen von einer Client-Server-Architektur unter OS/2 auf eine verteilte Thin-Client-Architektur mit Java-Front-Ends umgestellt. Dabei konnte die mit COBOL entwickelte Geschäftslogik komplett übernommen werden – über eine neue Middleware-Schicht greifen die Java-GUIs auf die COBOL-Module zu. · WAGO-Kontakttechnik, Minden Um seine zentrale Anwendung für die Warenwirtschaft mit einer zeitgemäßen grafischen Oberfläche zu versehen, hat die WAGO-Kontakttechnik die vorhandenen COBOL-Masken mit Hilfe von Micro Focus automatisch umgestellt. Das GUI läuft nun auf dem PC, die Applikationslogik konnte auf dem Unix-System bleiben.
Modernisierung in der Praxis – neue Hardwareplattformen · Peek & Cloppenburg, Hamburg Zur Ablösung des teuren VSE-Mainframe hat Peek & Cloppenburg in Hamburg sein COBOL-Warenwirtschaftssystem mit Micro Focus ohne großen Aufwand nach Windows migriert. Die Applikationen laufen auf der neuen Plattform stabil und performant, und das Unternehmen konnte erhebliche Einsparungen erzielen. · Zusatzversorgungskasse Detmold Die ZVK konnte den bisherigen Mainframe nicht mehr mitbenutzen und musste für ihre Anwendungen eine neue Hardwareplattform finden. Da ein bloßer Hardwaretausch zu teuer gewesen wäre, entschied sich die ZVK für den Einsatz des Enterprise Server von Micro Focus. Damit lassen sich Mainframe-Applikationen ohne Performance-Einbußen in einer Windows-Umgebung betreiben. · Coop, Basel Die Coop Schweiz hat ihr Kundenbindungsprogramm »Supercard« von einem OS/390-Mainframe auf die Unix-Plattform portiert. Vorhandene COBOL-Applikationen für die umfangreiche und performancekritische Daten-Aggregation konnten mit Net Express und Server Express von Micro Focus ohne Neuprogrammierung in die neue Umgebung übernommen werden. Die neue Architektur bietet mehr Flexibilität für die Coop und mehr Komfort für die Coop-Kunden.
Modernisierung der Benutzerschnittstelle: herkömmlicher Green Screen
Dieselbe Legacy-Anwendung mit modernem Browser-GUI
Bei der Portierung von Legacy-Anwendungen müssen neben dem eigentlichen Code so weit wie möglich auch Bestandteile der Applikationsinfrastruktur übertragen werden.
|
|