Die Grundlagen der Modernisierung von Legacy

Die Software-Modernisierer
Die Grundlagen der Modernisierung von Legacy-Anwendungen
Für jede Organisation, die eine Modernisierung ihrer Legacy-Anwendungen anstrebt, hat der Vorgang eine
andere, ganz spezielle Bedeutung. Für die einen bedeutet er, eine Reihe von Programmen, die im Verlaufe
mehrerer Jahrzehnten entstanden, gegen ein neues kohärentes System auszutauschen, und hierfür die
neueste und beste Hard- und Softwaretechnik einzusetzen. Andere Organisationen verstehen hierunter,
vorhandene Applikationen von teuren Mainframe-Systemen auf effizientere handelsübliche Plattformen zu
migrieren.
Ein weitverbreitetes Ziel einer Modernisierung ist die Migration von COBOL- zu Java-basierten Umgebungen.
Mit dem Ziel einhergehen kann ein friedliches Nebeneinander von Java- und COBOL-Komponenten, die
letztliche Ablösung der COBOL-Komponenten mit funktionell gleichwertigen Java-Komponenten oder ein
Lösungsweg, der zwischen diesen zwei Extremen liegt. Ganz gleich welche der zahlreichen Möglichkeiten
zur Migration letztlich gewählt wird – der Ansatz ist stets derselbe: Das Re-Hosting und die Verfeinerung
erfolgen immer schrittweise.
Der Wechsel von einem COBOL-Programm, das auf einer traditionellen EDV-Plattform läuft, hin zu einem
modernen, wartbaren Java-basierten System ist weder einfach noch leicht. Aber mit dem richtigen Ansatz
und einem Mindestmaß an Einsatz und Entschlossenheit kann dieses Ziel erreicht werden. Wenn man sich
den folgenden Wahrheiten gegenüber nicht verschließt und gewisse Konsequenzen als gegeben hinnimmt,
kann dieses Ziel von praktisch jeder Organisation erreicht werden:
Wahrheit Nr. 1: Die einzige Spezifikation, die zählt, ist der bestehende Code.
Wahrheit Nr. 2: Sie wohnen weiter in Ihrem Haus, während es renoviert wird.
Wahrheit Nr. 3: Die Nahtstellen entscheiden über den Erfolg oder Misserfolg.
Gewiss lassen sich viele Einschränkungen und Fallstricke aufzählen, die bei Softwarekonvertierungen
auftreten können. Wenn man diese drei Wahrheiten indes akzeptiert und mit ihnen lebt, dann kann dies
den entscheidenden Unterschied ausmachen zwischen Erfolg und Misserfolg, zwischen Berechenbarkeit
und Überraschung. Die Akzeptanz dieser Wahrheiten kann darüber entscheiden, ob das Projekt
kontrollierbar bleibt oder den Beteiligten aus den Händen gleitet, ob es bezahlbar bleibt oder exorbitante
Kosten produziert.
COBOL ist die einzige Anforderung, die zählt.
Die Anforderungen, die an die Programmiersprache COBOL gestellt wurden, waren zu Beginn bescheiden.
Heute jedoch ist diese Genügsamkeit von COBOL nicht mehr die einzig entscheidende Eigenschaft dieser
Sprache. Zwanzig, dreißig, gar vierzig Jahre hinweg haben Nutzer ihre COBOL-Programme so angepasst,
verfeinert, verbessert und anderweitig modifiziert, dass sie den Datenverarbeitungsregeln und -standards
ihrer Unternehmen sowie den von außen erzwungenen Regeln, Anforderungen und Einstellungen, ja den
Vorgaben der direkten und indirekten Programmbenutzer haargenau entsprachen. In vielen, wenn nicht gar
© 2016 EasiRun Europa GmbH
EasiRun_Whitepaper_Legacy Modernisation_D_Java-is_2016_.docx | Seite 1 von 8
den meisten Fällen, gingen die Gründe für diese Anpassungen und die Einschränkungen, die hierdurch
erkauft wurden, dadurch verloren, dass Entwickler verstarben, Prozesse alles andere als perfekt umgesetzt
wurden, oder weil schlicht niemand daran dachte, dass es eines Tages wichtig werden würde,
Codeanpassungen nachzuvollziehen. Tatsächlich halten die meisten Programmierer den Programmcode
selbst für die einzig wahre Dokumentation.
Die „Väter“ von COBOL waren sich dieses Bedürfnisses nach Anpassung und Modifizierung bewusst und
erklärten es zu einem ihrer Ziele bei der Entwicklung der Programmiersprache.
Daher gestaltet sich jedes Unterfangen, ein Programm durch ein neues, funktionell kompatibles,
geschweige denn identisches Programm zu ersetzen extrem schwierig, wenn nicht gar unmöglich, sofern
dabei nicht der Ansatz gewählt wird, das relevante und gewünschte Verhalten auf eine bestimmte Art und
Weise aus dem vorhandenen Code zu “extrahieren” und die Ersatzimplementierung entsprechend zu
gestalten. Praktisch gesehen sind es die vorhandenen Funktionsmechanismen innerhalb des vorhandenen
Codes, in diesem Fall COBOL, welche die Spezifikationen beschreiben, die vorrangig erfüllt werden müssen.
Leben in einer Baustelle
In den seltensten Fällen kann ein Unternehmen sich den Luxus leisten, ein vollkommen neues Programmsystem zu schreiben und anschließend einem festgelegten Zeitplan folgend nahtlos vom alten auf
das neue System zu wechseln. Dieses Vorhaben gestaltet sich meist auch dann schwierig, wenn ein Unternehmen der Meinung ist, sich diesen Luxus erlauben zu können. In der Realität sind Umsetzungen dieser
Art gewaltig – und gewaltig teuer.
Migrationen, die diese Methode vorschreiben, basieren auf der Vorstellung, dass Änderungen am
vorhandenen System minimiert oder sehr präzise nachverfolgt werden können, während das neue System
entworfen und gebaut wird. Hierbei werden für gewöhnlich detaillierte Prozesse entworfen, die
sicherstellen sollen, dass die Annahmen über den Code zutreffen. Derartige Umsetzungspläne basieren
meist auf einem Projekt, für das ein bestimmter Umfang festgelegt wurde und dessen Fertigstellung
planmäßig zu erfolgen hat.
Diese Migrationen basieren auch auf der Annahme, dass die Entwickler des neuen Systems alles Nötige
über das zu ersetzende System wissen. Beide Annahmen stellen sich fast immer als falsch heraus. Das
Ergebnis ist, dass immer weitere Anstrengungen unternommen werden müssen, und das Projekt kein Ende
findet: Das Projekt schreitet ein Stück voran, dann tauchen Fehler auf – der Schritt muss wiederholt
werden, Programmwechsel werden geplant – aber nicht umgesetzt. In der Zwischenzeit laufen die
Altprogramme weiter, denn sie stützen letztlich ja das Business. Derweil müssen diese Altprogramme an
neue gesetzliche Vorschriften, die geschäftlichen Veränderungen und an die Bedürfnisse, Wünsche und
Launen der User weiter angepasst werden.
Nicht selten versucht in diesen Fällen eine Gruppe Abtrünniger, kühner aber wohlmeinender Entwickler,
das Altsystem soweit zu verbessern, dass es in einigen kritischen Punkten besser agiert als das neue
System. In vielen Fällen zieht sich das Migrationsprojekt solange hin, bis das neue System veraltet ist, noch
bevor es überhaupt zum Einsatz kommen konnte.
Eine Voraussetzung für eine erfolgreiche Modernisierung von Legacy-Anwendungen ist, dass das Ersatzsystem modular aufgebaut ist, so dass es produktiv parallel zu den noch nicht ersetzten Modulen eingesetzt
werden kann. Diese Module müssen klein genug gebaut sein, damit sie getestet werden können, noch
bevor die Altprogramme aufgrund betrieblicher Veränderungen in entscheidenden Punkten abgeändert
© 2016 EasiRun Europa GmbH
EasiRun_Whitepaper_Legacy Modernisation_D_Java-is_2016_.docx | Seite 2 von 8
werden müssen. Zudem muss auch das Legacy-System modularisiert sein, damit es der Ordnung des
neuen Ersatzsystems entspricht.
Über Erfolg oder Misserfolg des Projekts wird an den Nahtstellen entschieden
Doch auch mit einer Modul-Austausch-Strategie kommt es unweigerlich zu Reibungspunkten, an denen der
Code und die an ihn gestellten Anforderungen sich verändern und auf externe Faktoren reagieren. Diese
Reibungspunkte treten sehr wahrscheinlich an der Nahtstelle zwischen dem Austauschmodul und dem
Funktionsmechanismus des Altsystems auf, mit dem beide interagieren. An diesen Punkten sollten auch
Anpassungen an das Altsystem eingeplant und vorgenommen werden. Es kann davon ausgegangen werden, dass ein Großteil der nicht eingeplanten Arbeiten im Zusammenhang stehen werden mit
Schwierigkeiten an diesen Nahtstellen. Hinzu kommt, dass diese Nahtstellen nicht statisch sind, sondern
sich ständig verschieben und sich mit dem Einpflegen neuer Module und der Vereinnahmung dieser
Stellen fortwährend vermehren. Es lohnt daher, sich auf die Verwaltung der Nahtstellen zu konzentrieren,
da diese sich zum entscheidenden Faktor auswachsen können, welcher über Erfolg oder Misserfolg der
Modernisierung entscheidet.
Ein Gesamtbild entsteht
Mit diesen drei grundlegenden Wahrheiten - die es zu akzeptieren gilt - sowie mit COBOL als der
entscheidenden Anforderungssprache für die Projektierung, dem schrittweisen Systemwechsel mithilfe von
Modulen und der Minimierung von Unterbrechungen an den sich ständig verschiebenden Nahtstellen
zwischen dem neu entwickelten Code und dem parallel weiter genutzten Altcode, entwickelt sich nun ein
Bild von den Tools, die zur Erreichung des Ziels notwendig sind.
Das ideale Werkzeug hierfür wäre eines, das den Anforderungen der Programmiersprache des Ausgangssystems, also dem COBOL-Code Rechnung trägt, und gleichzeitig die Prozesse, die benötigt werden,
umfassend und detailliert abbildet, um hieraus neuen COBOL-Code zu generieren, welcher innerhalb einer
modernen Umgebung auf einer beliebigen Computerplattform ausgeführt werden kann.
Dieses Werkzeug sollte im Idealfall in der Lage sein, Altprogramme in ein Modulsystem zu überführen und
mit den vorhandenen Daten und der vorhandenen Logik so lange zu kommunizieren, wie dies nötig erscheint. Überdies sollte es auf effiziente und unkomplizierte Art und Weise mit Programmen in der neuen
Umgebung kommunizieren, die keine Abkömmlinge des Altsystems sind und aus architektonischer Sicht
deutlich anders ausgeformt sein können als die alten Programme.
Dieses Werkzeug muss entweder eine hochmoderne integrierte Entwicklungsumgebung mitbringen oder
Bestandteil einer solchen IDE sein, die nicht nur die Bearbeitung und das Debugging des von diesem Werkzeug erzeugten Codes erlaubt, sondern auch eine Verwaltung des Quellcodes, ein sprachenübergreifendes
Debugging und eine Möglichkeit zum Testen vorsieht. Vor allem aber sollte die Entwicklungsplattform es
ermöglichen, auf einfache und zuverlässige Weise durch den Altcode zu navigieren und diesen zu überarbeiten.
Die zur Verfügung gestellten Instrumentarien sollten in ihrer Ganzheit den Modernisierungsprozess vollumfänglich abbilden – von der Analyse der Altprogramme über das schrittweise Re-Hosting der vorhandenen
Funktionen mithilfe der Migration von Modulen, bis hin zum Austausch und der Integration von Funktionen
innerhalb einer Gesamtarchitektur, die auf einer Vielzahl moderner Paradigmen aufgebaut ist.
© 2016 EasiRun Europa GmbH
EasiRun_Whitepaper_Legacy Modernisation_D_Java-is_2016_.docx | Seite 3 von 8
Ein solches Werkzeug ist isCOBOL. Am Anfang der Entwicklung von isCOBOL stand das Bedürfnis nach einer
zuverlässigen und unverzichtbaren Technik, die in dieser Form noch nicht erhältlich war. Diese neue
Technik sollte es ermöglichen, vorhandenen COBOL-Code zu modernisieren und sich dabei auf die genannten Wahrheiten stützen, welche für derartige Zwecke grundlegend und unausweichlich sind. SoftwareDesigner, die über Jahrzehnte Erfahrung in der Entwicklung geschäftskritischer Systemsoftware verfügen
(darunter COBOL-Compiler und COBOL-basierte Compiler und -Systeme), machten sich ans Werk, das
ideale COBOL-Modernisierungswerkzeug zu erschaffen. Das Ergebnis ihres Schaffens ist isCOBOL, ein Javabasiertes System, das nunmehr als die zuverlässigste und effizienteste Lösung gelten kann, eine
vorhandene COBOL-Anwendung zu einer hundertprozentigen Java-Unternehmenssoftware-Umgebung zu
mirgieren.
Java
Warum Java? Java wurde gewählt, weil es sich technisch besonders gut für diesen Zweck eignet und abseits
der Technik über besondere Stärken verfügt. Aus technischer Sicht ist Java die ideale Plattform für
Migrationsprojekte. Java-Code lässt sich vollständig und mit überschaubarem Aufwand auf jede moderne
Plattform, auch die Microsoft-Windows-Umgebung, alle wichtigen UNIX- und Linux-Plattformen, IBMMainframe-Umgebungen und eine Vielzahl von Spezialsystemen portieren. Nie zuvor hat es in der
Computergeschichte eine Programmiersprache gegeben, die es erlaubt, ein einzelnes Programm sowohl für
sämtliche kommerziell verfügbare als auch für zukünftig zu entwickelnde Umgebungen zur Verfügung zu
stellen. Java ist modern. Als es gegen Ende des 20. Jahrhunderts erschaffen wurde, war das Goldene
Zeitalter der Programmiersprachen längst Geschichte und die Entwickler von Programmiersprachen hatten
es entsprechend schwer. In den drei der Java-Entstehung vorangehenden Jahrzehnten hatten sie praktisch
jeden denkbaren Versuch unternommen, die ultimative Programmiersprache zu entwickeln. Von der Erfahrung dieser Zeit profitiert heute Java. Innerhalb der vergangenen 15 Jahre, in denen Java sich entwickelte,
wurde es zunehmend zur Sprache der Wahl in der Lehre der Computer- und Programmierwissenschaft
sowie bei der Implementierung von objektorientierten Systemen. Als neuestes Mitglied im Pantheon nichtproprietärer, universeller Programmiersprachen steht Java daher für Modernität.
Java ist zudem performant. Bei Java hat man von Anfang an den Ansatz verfolgt, ein hohes Maß an
Portabilität mithilfe virtueller Maschinen zu erreichen. Anders als seine Vorgänger jedoch hat die JavaCommunity große Anstrengungen unternommen, die hierbei entstehenden Performance-Nachteile zu
minimieren oder gänzlich aufzuheben, unter denen andere Programmiersprachen leiden. Heute ist die
Java-eigene “Just-in-Time-Kompilierung” von virtuellen Anweisungen in native Maschinenbefehle wohl die
fortschrittlichste Kompilierung, die es gibt. Das Ergebnis ist, dass die meisten Java-basierten Programme,
die in einer repetitiven Umgebung (Server) ausgeführt werden, beinahe genauso performant sind wie
handgeschriebene direkte Kompiliersprachen wie etwa C. Wenn es bei Geschäftsprogrammen auf die
Performance ankommt, sucht Java seinesgeichen.
Am wichtigsten zu werten jedoch ist die hohe Akzeptanz, gar Präferenz für Java vonseiten der Entwicklergemeinde, wenn es um die Entwicklung wichtiger Geschäftsprogramme und Automatisierungslösungen geht.
Viele, wenn nicht gar die meisten Unternehmen, welche geschäftskritische Anwendungen entwickeln oder
wählen, haben bereits eine Langzeitstrategie für die Java-Migration ihrer Programme definiert. Die Zahl dieser Unternehmen dürfte in Zukunft sogar noch steigen. Sie haben die Vorteile von Java erkannt und sind
allesamt zu demselben Ergebnis gekommen. Dies bedeutet, dass die Entscheidung für isCOBOL sich in den
meisten Fällen mit dem Wunsch des Kunden deckt, COBOL-Anwendungen mit dem Ziel Java zu
modernisieren.
© 2016 EasiRun Europa GmbH
EasiRun_Whitepaper_Legacy Modernisation_D_Java-is_2016_.docx | Seite 4 von 8
COBOL beschreibt die neuen Spezifikationen
Jede Modernisierung dreht sich im Kern darum, sicherzustellen, dass im modernen neu zu entwickelnde
System die gleichen Geschäftsvorgänge implementiert sind und diese zu denselben Ergebnissen führen,
wie es bereits im Originalsystem der Fall ist. Auch wenn Änderungen und Verbesserungen der Programme
für die moderne Plattform in Aussicht gestellt werden, ist es nur in den seltensten Fällen erstrebenswert,
diese Änderungen in der Entwicklungsphase umzusetzen, es sei denn, es ist sichergestellt, dass das alte
und das neue System auf die gleiche Weise funktionieren. Wird diese Bedingung nicht erfüllt, erhöht sich
der Migrationsaufwand beträchtlich und die Aussicht auf einen Erfolg rückt in weite Ferne.
Leider lassen sich Änderungen an Geschäftsprozessen in der Praxis für gewöhnlich nicht bis zum Abschluss
der Migration aufschieben. In einem beliebigen nichttrivialen Projekt müssen Änderungen am
arbeitsfähigen System durchgeführt werden, um wichtige interne Geschäftsvorgänge oder externe
Spezifikationen abzubilden. Daher müssen in den meisten Projekten Änderungen am Produktionssystem,
das sich im Modernisierungsprozess befindet, eingeplant werden. Der Übergang zu einem arbeitsfähigen,
letztlich vollständig modernisierten System soll dabei nahtlos erfolgen. Ein Ausweg aus diesem Dilemma
tut sich auf, sobald man das COBOL-Erbe nicht als Ausdruck der Geschäftsregeln und -vorgänge einer
veralteten Programmiersprache betrachtet, sondern als ihre Abbildung innerhalb einer lebendigen
Beschreibungssprache, die sowohl Implementierungen für das Altsystem als auch für das moderne
Zielsystem produziert. Der Prozess wird klar, wenn wir die Schritte analysieren, welche in einem
Migrationsprojekt für gewöhnlich durchlaufen werden.
Schritt 1: Aufteilung der Problemstellung
Wenn wir mit einer Sammlung von COBOL-Programmen beginnen, besteht der erste Schritt darin, die Programme zu identifizieren, die vom Modernisierungsprojekt erfasst werden sollen. Dies können alle COBOLProgramme des Unternehmens sein oder nur die Programme einer bestimmten Abteilung, einer Reihe von
Abteilungen oder einfach eine Reihe von Programmen, aus denen ein Pilotprojekt oder eine taktische Modernisierungsumstellung besteht. Ganz gleich wie groß der Umfang der Umstellung ist – sobald der Satz
der zu migirerenden Programme identifiziert wurde, kann der Modernisierungsplan formuliert werden.
Oftmals ist der Projektumfang durch die strategische Wahl zugunsten von Java innerhalb des
Unternehmens bestimmt. In diesem Fall wurden die Java-basierten Funktionen bereits geplant und
implementiert, die Altprogramme werden dann im Rahmen des Projekts in die Java-Umgebung
implementiert. Wenn wir uns auf dieses Szenario konzentrieren, werden die Fragen und Maßnahmen zur
Lösung der grundsätzlichen Probleme klar erkennbar. Bei Abschluss des ersten Projektschritts sollte
feststehen, welche Reihe bestehender COBOL-basierter Programme in hundertprozentige Java-Funktionen
überführt werden sollen.
Schritt 2: Minimierung der Berührungspunkte zwischen dem alten und neuen System
Nachdem wir nun die zu migrierenden bestehenden Programme identifiziert haben, ist es wichtig, dass wir
uns zum einen mit den Wegen vertraut machen, auf denen diese Programme mit dem alten System, das ja
nun zumindest eine Zeit lang unangetastet bleibt, kommunizieren, als auch mit den Wegen der bereits bestehenden oder noch zu schreibenden Java-Programme. Normalerweise wird hier die Grenze um die gemeinsam genutzten Daten gezogen, die erhalten bleiben (einschließlich von Dateisystemen und Datenbanken). Hierzu gehören wahrscheinlich auch einige prozessuale Interaktivitäten, z.B. moderne Funktionen,
sprich Vorgänge, die von Komponenten des Altsystems iniziiert oder angefordert werden sowie zu
vererben-de Komponenten, die bestimmte Aufgaben für das moderne System übernehmen. Damit es zu
© 2016 EasiRun Europa GmbH
EasiRun_Whitepaper_Legacy Modernisation_D_Java-is_2016_.docx | Seite 5 von 8
keiner Reibung bei der Migration kommt, ist es wichtig, die Zahl dieser Berührungspunkte zwischen dem
alten und dem neuen System so gering wie möglich zu halten.
Taktisches Re-Engineering
Sobald wir nun eine Aufstellung aller interaktiven Punkte erstellt haben, sollte feststehen, ob es Punkte
gibt, die aus dem System entfernt werden können bzw. entfernt werden sollen oder die mit anderen
Funktionen zusammengelegt werden können. So ist es beispielsweise denkbar, dass ein Altprogramm über
Zugriffsrechte auf eine Datenbank verfügt, die kritische Informationen beinhaltet. Wenn nun einige oder
auch alle Zugriffe im Zielprogramm isoliert werden, kann es von Vorteil sein, die Programmlogik
dahingehend abzuändern, dass die Datenanforderungen auf die bestehenden Komponenten beschränkt
bleiben und nicht gleich das moderne System mit unmittelbaren Zugriffsrechten auf diese Daten
ausgestattet wird. Der Zeit- und Kostenaufwand für eine derartige Umstrukturierung des Altsystems sollte
abgewogen werden gegen den Aufwand, welcher entsteht, wenn der modernen Umgebung ein direkter
Zugriff auf diese Daten gestattet wird.
Eine weitere Kategorie des Schnittstellen-Re-Engineering entsteht, wenn Komponenten innerhalb einer
Reihe von Zielprogrammen auf eine Art und Weise miteinander kommunizieren, die in der modernen
Umgebung nicht gewünscht ist. Dies kann dann der Fall sein, wenn beispielsweise zwei der Zielprogramme
über einen proprietären oder nur im Altsystem vorhandenen Mechanismus miteinander kommunizieren,
der in der modernen Umgebung entweder nur mit großem Aufwand oder gar nicht bereitgestellt werden
kann oder dessen Einsatz nicht gewünscht ist. In diesen Fällen kann die vorhandene Schnittstelle oftmals
durch eine Äquivalente ausgetauscht werden, die sich mit geringerem Aufwand in die moderne Umgebung
übertragen lässt.
Ein dritter Bereich des taktischen Re-Engineerings betrifft die Konsolidierung problembehafteter
Funktionen zugunsten einer kleinen Zahl von Komponenten. Die meisten großen Projekte beinhalten eine
Reihe von Mechanismen, die idealerweise in die Modernität überführt werden, indem man sie vollkommen
neu gestaltet und implementiert. Um die Auswirkungen dieser Neugestaltung zu minimieren und das
Projekt mit einer möglichst geringen Anzahl kritischer Hürden voranzutreiben, lohnt sich oftmals die Mühe,
die erneut zu implementierenden Funktionen vorübergehend in der COBOL-Umgebung zu isolieren. Auf
diese Weise muss das Projekt nicht aufgeschoben werden, und die neugestaltete Komponente kann sobald sie fertig ist - mit minimalen Auswirkungen auf das Produktivsystem implementiert werden.
In jedem Fall muss sichergestellt sein, dass die modernen Komponenten mit den Altschnittstellen
harmonieren, die nach dem Re-Engineering weiterhin vorhanden sind. Zudem müssen etwaige zusätzliche
neue Schnittstellen identifiziert und ihre Funktionsweise festgelegt werden. Der wichtigste Aspekt dieses
taktischen Re-Engineerings ist, dass dessen Aufgaben vor oder während des Hauptmodernisierungsprojekts durgeführt werden können. Wird der bewährte bzw. modernisierte COBOL-Code als dynamische
Spezifikation betrachtet, der das korrekte Verhalten sowohl im alten als auch im neuen System definiert,
profitieren beide Systeme von den Änderungen, und ihre Funktionen können identisch bleiben.
Schritt 3: Implementierung der Anforderungen in Java
Nachdem wir die zu modernisierenden Anwendungskomponenten identifiziert und das zur Vorbereitung
auf die Modernisierung erforderliche Re-Engineering der alten Komponenten durchgeführt haben, erhalten
wir eine genaue Beschreibung des Verhaltens in COBOL, die sowohl auf das alte als auch das neue System
angewendet werden kann. Die Werkzeuge von isCOBOL erlauben es nun, aus denselben COBOLBeschreibungen heraus funktionsfähige, moderne Java-Komponenten (Java-Klassen) zu erstellen, deren
© 2016 EasiRun Europa GmbH
EasiRun_Whitepaper_Legacy Modernisation_D_Java-is_2016_.docx | Seite 6 von 8
Verhalten identisch ist mit den entsprechenden alten Komponenten, welche sie ersetzen. Dies bedeutet
nicht nur, dass das bestehende System und die modernen Komponenten während der Umstellung weiter
miteinander interagieren können, sondern auch, dass eine moderne Java-Implementierung der
Zielfunktionen sofort für den Produktiveinsatz zur Verfügung steht, sobald die notwendigen Validierungen
und Test abgeschlossen sind.
Schritt 4: Überprüfung der lauffähigen Version
Wir sind nun an einem Punkt angelangt, an dem die COBOL-Spezifikationen, die von den in isCOBOL produzierten Java-Klassen generiert wurden, auf einer beliebigen Computerplattform laufen können, die
Zugriff auf die erforderlichen Komponenten hat, die nicht in Java geschrieben sind (sofern diese
Komponenten überhaupt vorhanden sind). In vielen Fällen bedeutet dies, dass bereits zu diesem Zeitpunkt
eine hundertprozentig lauffähige Java-Version zur Verfügung steht. Der nächste Schritt besteht in allen
Projekten nun darin, die Funktionen dieser lauffähigen Java-Version mit der Funktionsweise der alten
Komponente zu vergleichen.
Neben den genutzten Routinetests verfügt isCOBOL auch über einmalige Fähigkeiten zur Nachverfolgung
von Programmzuständen. Hierdurch ist es möglich, die meisten Programmverhaltensweisen nicht nur hinsichtlich des durch einen Input erzeugten Output zu überprüfen, sondern auch entsprechend des genauen
Funktionsaufrufs und des Inhalts von Datenbereichen, die zwischen aufrufenden und aufgerufenen Programmen ausgetauscht werden. Durch die Nutzung dieser Fähigkeiten von isCOBOL kann eine Vielzahl von
schwer fassbaren und schwierigen Fehlermeldungen genau nachvollzogen und mit einem hohen Maß an
Sicherheit eine Aussage darüber getroffen werden, ob das Verhalten der Java-Komponenten mit dem des
alten Systems übereinstimmt.
Nach diesem Test und der Validierung steht nun zu Hundertprozent eine sofort ausbaufähige, moderne
Java-Anwendung zur Verfügung. Da diese Anwendung mithilfe der COBOL-Spezifikationen erstellt wurde,
kann sie überdies im Verlauf der Entwicklung des modernen Systems weiter modifiziert, erweitert oder
ersetzt werden. In der Praxis beschreibt dieses Szenario nur selten das Ende des Migrationsprozesses, es
sei denn, Ziel des Projekts wäre ein einfaches Re-Hosting der Anwendungen gewesen. Viel häufiger indes
ist dies der Anfang einer schrittweisen Wartung und kontinuierlichen Verbesserung der vom Altsystem ursprünglich bereitgestellten Geschäftslogiken, die nun in der vollkommen modernen Java-Welt ausgeführt
werden.
Schritt 5 und folgende
Abhängig von den strategischen Zielen des Modernisierungsprojekts können die anschließenden
Aktivitäten verschiedener Natur sein. Das weitere strategische Re-Engineering kann in der neuen JavaUmgebung mittels Java, COBOL oder einer Mischung beider Programmiersprachen erfolgen. Auf einfache
und saubere Weise kann das neue System mit anderen Java-basierten Systemen verbunden werden.
Vorhandene Benutzeroberflächen können wieder eingebaut oder eine beliebige grafische oder webbasierte
Technik kann ohne logische Brüche zwischen der Businesslogik und diesen Oberflächen implementiert
werden.
In vielen Fällen gibt es keinen zwingenden Grund, sich von den COBOL-Spezifikationen der grundlegenden
Geschäftsvorgänge zu verabschieden. Häufig gibt es überzeugende Argumente dafür, Schritt für Schritt jene
Logiken aus dem COBOL-Code zu extrahieren, die nicht die Kerngeschäftsprozesse erfassen, die hierdurch
immer detaillierter beschrieben werden können.
In einigen Fällen gibt es jedoch strategische oder politische Gründe dafür, die COBOL-Spezifikationen aus
den Betriebsprogrammen zu verbannen. Mit isCOBOL kann der COBOL-Code auf saubere und elegante Art
© 2016 EasiRun Europa GmbH
EasiRun_Whitepaper_Legacy Modernisation_D_Java-is_2016_.docx | Seite 7 von 8
und Weise mittels einzigartiger Funktionen wie Embedded Java und Modern Alternative Syntax eliminiert
werden. Diese Funktionen können bei Bedarf eingesetzt werden, um ein gezieltes Re-Engineering bestimmter Abschnitte vorzunehmen und in das Produktivsystem zu integrieren. Im Endeffekt können diese
Funktionen aber auch dazu genutzt werden, COBOL-Code komplett aus Anwendungen zu entfernen, sofern
dies das Ziel eines Projekts sein sollte.
Die Vorteile von isCOBOL in Kürze
Wenn ein Modernisierungsplan umgesetzt wird, welcher Elemente beinhaltet, die den vorstehenden
ähneln, und wenn dafür die richtigen Werkzeuge eingesetzt werden wie das isCOBOL Toolset, kann ein
System vollkommen moderner, wartbarer Java-basierter Geschäftsanwendungen entstehen. Hinzu kommt,
dass dies mit weit geringeren Risiken und geringerem Aufwand verbunden ist als der blauäugige (und in
der Regel realitätsferne) Versuch, Programme in manuellen Einzelschritten von COBOL zu Java zu migrieren
und anzupassen. Auch wenn die vollständige Eliminierung von COBOL das strategische Ziel des
Migrationsprojekts sein sollte, führt der in diesem Dokument dargestellte Ansatz in fast allen Fällen auf
schnelle und kostengünstige Art und Weise zum gewünschten Ziel.
Weitere Informationen über isCOBOL oder den Ansatz, COBOL als Spezifikation zu betrachten, erhalten Sie
bei:
EasiRun Europa GmbH unter www.easirun.de
Copyright 2016
EasiRun Europa GmbH und ihre Partner.
© 2016 EasiRun Europa GmbH
EasiRun_Whitepaper_Legacy Modernisation_D_Java-is_2016_.docx | Seite 8 von 8