Auch wenn in Großunternehmen COBOL seine Stellung behauptet, neue Technologien wie Java halten auch hier Einzug. Die Integration der IT-Welten wird daher zu einem zentralen Thema auch für die Anwendungsentwicklung, und auch eingefleischte COBOL-Entwickler sollten beizeiten über den Gartenzaun blicken. Die Verbindung von COBOL und Java ist keineswegs trivial, dafür aber sehr lohnend. Zuletzt sorgte die Umstellung der Anwendungssysteme auf den Euro noch einmal kurzfristig für eine große Nachfrage nach Know-how im Bereich Großrechner-Anwendungen und nach Erfahrungen in der COBOL-Entwicklung. Da aber junge Programmierer und Informatiker, die von den Hochschulen kommen, COBOL meist nur vom Hörensagen kennen, mussten sich die Unternehmen kurzfristig anderweitig behelfen; so konnten reaktivierte COBOL-Veteranen für Aufsehen sorgen. Mittlerweile hat sich die Lage normalisiert: COBOL scheint wieder vergessen, die Welt der Software-Entwicklung dreht sich wieder ganz um „die wirklich wichtigen Dinge“, also um Java, J#, C#, EJB, J2EE, .NET, JDBC, ADO, SOAP usw.

COBOL behauptet seine Position

Doch da sind noch die Anwendungen. Je größer und wichtiger diese sind, desto öfter sind sie COBOL-Anwendungen – trotz allem und offenbar immer noch unverwüstlich. Insbesondere in Großunternehmen wie Banken und Versicherungen, aber auch in zahlreichen Industriekonzernen laufen die zentralen Applikationen noch immer auf Großrechnern unter COBOL. Und dabei kann von „noch“ gar keine Rede sein, denn diese Unternehmen denken auch langfristig nicht an einen Ausstieg aus COBOL. In punkto Stabilität, Verfügbarkeit und Performance gibt es für die meisten keine Alternative zur Kombination Großrechner und COBOL-Anwendungen. „Wir werden COBOL noch viele Jahre einsetzen“, erklärt etwa Christoph Schmallenbach, als Mitglied der Geschäftsführung bei AMB-Informatik, der IT-Tochter des Aachen Münchener Konzerns, für den Bereich Anwendungsinfrastruktur verantwortlich. Viele große Anwender sind in dieser Situation. Laut einer Untersuchung der Gartner-Group wurden weltweit etwa fünf Billionen Dollar in COBOL-Programme investiert, es existieren mehr als 200 Milliarden Zeilen COBOL-Code und noch immer kommen jedes Jahr etwa fünf Milliarden neue Code-Zeilen dazu. Dazu passt eine Information von IDC, der zufolge 60 Prozent aller Unternehmen weltweit weiterhin auf COBOL als Grundlage ihrer Anwendungen setzen.

Außenstehende haben denn auch nur selten eine Vorstellung von der Bedeutung, die die COBOL-Entwicklung in Großunternehmen einnimmt. Dort sind, vor den Augen der IT-Welt versteckt, teilweise Hunderte von COBOL-Entwicklern beschäftigt. So arbeiten beispielsweise von den insgesamt etwa 600 Software-Entwicklern der AMB-Informatik rund 450 im COBOL-basierten Großrechnerbereich. Bei diesen Unternehmen sind denn auch COBOL-Entwickler gefragt – zumal der Nachwuchs nicht von den Universitäten geholt werden kann, wo COBOL längst ins Abseits gestellt wurde. Vielen Unternehmen bleibt da nur übrig, Software-Entwickler von anderen Plattformen umzuschulen, insbesondere aus dem Unix- und Java-Umfeld.

Aber auch passionierte COBOL-Anwender entwickeln heute nicht mehr ausschließlich mit COBOL. Alle Unternehmen haben heute stark heterogene IT-Landschaften, neben den großen, geschäftskritischen Anwendungen gibt es auch noch die anderen: abteilungsweite Client Server-Lösungen, Management-Informations-Systeme und natürlich die Web-Anwendungen. Zu den wichtigen Aufgaben der nächsten Jahre gehört es, diese unterschiedlichen Systeme zu verbinden. Und dazu ist es unerlässlich, dass auch COBOL sich mit anderen Technologien – insbesondere mit Java – verständigt. Häufig werden heute ja COBOL-Anwendungen in Web-Anwendungen integriert, damit die Geschäftslogik des Großrechners auch via Web genutzt werden kann. Dabei lässt sich nebenbei auch ein Manko von COBOL beheben, denn so leistungsfähig diese Sprache für die Formulierung von Geschäftsprozessen ist, hinsichtlich der Frontendgestaltung weist sie deutliche Defizite auf. Damit drängt sich aber eine Verbindung der auf den ersten Blick so fremden Welten geradezu auf: so können die bewährten Prozesse unter COBOL auf den Großrechnern bleiben, während die Anwender nicht nur mit aktuellen Oberflächen, sondern vor allem mit beliebigen Endgeräten arbeiten können – bis hin zum Palmtop oder Handy.

Java als Option für COBOL-Entwickler

Wer aber soll solche Lösungen entwickeln? Die Java-Entwickler, die etwas von COBOL verstehen, passen vermutlich in einen VW-Bus, und umgekehrt dürfte es kaum besser aussehen. Eine Zeitlang kann jede Seite vielleicht ihre eigenen Wege gehen und ihren Teil an der gemeinsamen Aufgabe unabhängig programmieren. Da es unbestritten Integrationsbedarf zwischen vorhandenen und neuen Systemen gibt, werden Fachleute benötigt, die in der Lage sind, über die jeweilige Mauer zwischen den Programmiersprachen zu blicken. Die Probleme sind nicht gering: Klassische strukturierte COBOL-Programmierung bedingt eine ganz andere Denkweise, als sie für das objektorientierte Java verlangt wird. Aber die COBOL-Welt kommt um entsprechende Kommunikationstechnologien nicht herum, wenn sie sich zum Beispiel für Themen wie Multi-View-Controller-Architekturen oder Connectoren offen halten will.

Abbildung 1: Eine Umfrage von Micro Focus unter 320 Unternehmen ergab, dass auch heute viele Gründe für den Einsatz von COBOL sprechen. (Angaben in Prozent, Mehrfachnennungen möglich. Quelle: Micro Focus)

Schwierig ist für den COBOL-Programmierer nicht so sehr das Java-Programmieren an sich. Hier ist genauso wie bei COBOL oder jeder anderen Programmiersprache eine Syntax zu lernen. Allerdings ist COBOL prozedural und Java objektorientiert. In COBOL beschreibt man einen Workflow in Form von Prozeduren, in Java entsteht ein Workflow durch das Interagieren von Objekten. Und in der kleinsten Einheit, der Funktion bzw. Methode, programmiert man in einer bestimmten Syntax, die in beiden Sprachen angenehm einfach ist. Andere Aspekte unterscheiden sich schon deutlicher: So sind Zugriffe auf Systemebene und Speichermanipulationen in Java aufgrund der umfangreichen Sicherheitskonzepte gänzlich ausgeschlossen. Selbst COBOL-Programmierer müssen hier – in Maßen – umlernen. Früher verhielt sich COBOL ähnlich, aber in den letzten Jahren wurden – nicht zuletzt unter dem Eindruck von C – in COBOL Möglichkeiten eingebaut, auch systemnah zu programmieren. Obwohl dies im Vergleich mit der Pointer-Arithmetik von C nur eingeschränkt möglich ist, ist COBOL ja auch die Sprache für kommerzielle Lösungen.

Darüber hinaus muss sich der COBOL-Fachmann mit den neuen Begriffen der Java-Welt befassen, auch wenn er dabei oft entdecken wird, dass sich hinter einigen „J-Worten“ altbekannte Techniken verbergen. So entspricht JMS (Java Messaging System) dem guten alten Ansatz, über Messages unterschiedliche Systeme miteinander zu verbinden. Wichtiger aber ist, dass die Anwendungsarchitekturen bei COBOL und Java völlig unterschiedlich aussehen. Hier heißt es für den COBOL-Entwickler: Er muss loslassen können. Man muss zunächst alles vergessen, was man vorher gelernt hat und sich dann – ohne zu vergleichen und ohne zu werten – auf das neue Konzept einlassen.

Dazu gehört nicht zuletzt das grundsätzlich anders geartete Programmiermuster. COBOL-Entwickler programmieren strikt nach Vorgaben, aber erstellen Anwendungsdesigns manchmal mehr aus dem Bauch heraus; in ihrer Welt gibt es nur wenig Designrichtlinien. In Java gibt es hingegen mit den Design-Patterns Muster für alle möglichen Anwendungsaufgaben, um eine saubere Architektur und Performance sicherzustellen. Ein anderes Beispiel ist die strikte Trennung zwischen den verschiedenen Verarbeitungsschichten, die auch für die COBOL-Welt von Vorteil wäre. So wird in der J2EE-Architektur klar getrennt zwischen Dialogebene, Businesslogik und Datenzugriffs- und Integrationsschicht. Java bietet außerdem eine Fülle von Standardobjekten, die immer wieder benötigte Aufgaben übernehmen und jederzeit eingebunden werden können.

Abbildung 2: Viele Unternehmen setzen COBOL auch für die Entwicklung von Web-Applikationen ein. (Angaben in Prozent, Mehrfachnennungen möglich. Quelle: Micro Focus)

Gemeinsamkeiten und Berührungspunkte

Oft liegen Java und COBOL aber gar nicht so weit auseinander. Die Welt der Java-Application Server, in der sich die großen Java-Applikationen tummeln, ist von der Mainframe-Welt gar nicht so weit entfernt. Die Security- und Transaktionskonzepte dieser Welt sind bei näherer Betrachtung denen des Hosts sehr ähnlich.

COBOL-Programmierer können hier mit ihren Erfahrungen aus der Großrechnerwelt eine große Hilfe sein. Im Java-Umfeld bewegen sich oft junge Techniker, die sich mit der Sprache Java an sich, mit grafischen Oberflächen usw. hervorragend auskennen. Geht es aber um Fragen wie Security und Transaktionen, fehlen ihnen jedoch die Erfahrungen mit großen, geschäftskritischen Anwendungen. Hier drängt sich eine enge Zusammenarbeit geradezu auf.

Es ist für einen gestandenen COBOL-Guru gewiss nicht einfach, sich die Denkweise und die Terminologien in der Java-Welt zu erarbeiten, er hat schließlich oft seine besten Jahre in völlig anderen Strukturen gedacht und gearbeitet. Andererseits ist es auch für einen Java-Programmierer nicht so einfach, sich in die fremde COBOL-Welt hineinzudenken. Die eigentlichen Probleme liegen aber vermutlich in der psychologischen Barriere zwischen den beiden Welten. Da ist nicht nur die Angst vor neuen Dingen, vor neuen Welten und Technologien, in denen man nicht zu Hause ist. So gibt es auf beiden Seiten eine gewisse Arroganz und Hochnäsigkeit, die die eigene Welt für die grundsätzlich bessere hält. Der eine hält Java für überdrehten Kinderkram, und der andere COBOL für einen uralten Staubfänger. Und beide merken gar nicht, dass sie sich gerade in ihrem Hang zur Abgrenzung schon wieder recht ähnlich sind.

Warum ein COBOL-Programmierer Java können sollte

– Weil Java heute einen sehr hohen Verbreitungsgrad hat.

– Weil Java mittlerweile die wichtigste Sprache für die Aufgaben der Kommunikationstechnik ist.
– Weil viele der neuen Architekturen auf Java aufbauen.
– Weil Java die Schwächen von COBOL im Bereich der Darstellung von Informationen ausgleichen kann und sich damit hervorragend als Präsentationsschicht für COBOL-Applikationen einsetzen lässt.
– Weil von Kunden immer häufiger eine Anbindung bestehender COBOL-Module an Java gewünscht wird.

Warum ein Java-Programmierer COBOL können sollte

– Weil viele der bestehenden Anwendungen in COBOL geschrieben sind.

– Weil viele geschäftskritische COBOL-Anwendungen auch in Zukunft nicht abgelöst werden.
– Weil der Aufwand einer Neu-Codierung der gleichen Funktionalität in Java nicht zu rechtfertigen ist (zeitlich, geldlich).
– Weil Java-Programmierer mit Kenntnissen über COBOL und Hostarchitekturen eine zentrale Rolle in großen Integrationsprojekten übernehmen können.
– Weil auch COBOL eine plattformunabhängige, stabile und standardisierte Sprache ist, die einfach zu lernen, zu verstehen und zu integrieren ist.
– Weil COBOL sehr schnell ist und rechenintensive Teile in COBOL deutlich schneller abgearbeitet werden als im Java-Interpreterformat.
– Weil die wenigsten Projekte vollkommen neu aufgesetzt werden, sondern bestehende Teile miteinbezogen werden müssen.

Micro Focus Deutschland

85737 Ismaning

Telefon: 089/420940

www.microfocus.de