MÜNCHEN (COMPUTERWOCHE) - Als Programmiersprache für die Formulierung von Geschäftsregeln hat Cobol über Jahrzehnte seine zentrale Position in der Unternehmens-IT behauptet. Mit den neuen Geschäftsmodellen des E-Business könnte diese Stellung nun wanken. Entscheidend für die weitere Zukunft von Cobol, so Rainer Doh*, ist daher dessen konsequente Integration in die neuen Architekturen.

Cobol, die Programmiersprache für kommerzielle Anwendungen, stirbt zwar schon seit 20 Jahren, aber nun scheint es endgültig so weit zu sein. Angesichts neuer Programmiersprachen wie Java oder C# - objektorientiert und geradezu maßgeschneidert für die Welt des Web und E-Business - kräht offenbar kein Hahn mehr nach Cobol. In Fachbuchhandlungen sucht man heute vergeblich nach Cobol-Literatur, und wenn man einen jungen Entwickler der Web-Generation auf Cobol ansprechen würde, mehr als ein mitleidiges Lächeln wäre kaum zu erwarten.

Dass 1999 zahlreiche Unternehmen fieberhaft nach Cobol-Entwicklern gesucht haben, um ihre Jahr-2000-Projekte bewältigen zu können, hat keinen grundsätzlichen Stimmungsumschwung auslösen können. Im Gegenteil: "Ein Strohfeuer - wenn Y2K und Euro-Umstellung erledigt sind, ist es mit Cobol endgültig vorbei", so die weitgehend übereinstimmende Meinung in der IT-Welt.

Cobol noch immer weit verbreitet

Dabei hätte man bei dieser Gelegenheit zwei wichtige Dinge lernen können: Zum einen ist die betagte Sprache offenbar noch immer so stark verbreitet, dass eine grundlegende Anpassung im Bereich kommerzieller Software vor allem in einer Cobol-Anpassung besteht, zum anderen haben die Unternehmen, zumindest eine nennenswerte Anzahl, die Gelegenheit einer massiven Anpassung ihrer Programme nicht dazu benutzt, ihre Cobol-Anwendungen auch gleich abzulösen.

Cobol scheint als eine Art IT-Zombie nicht wirklich sterben zu können. Dies belegen auch die Zahlen einiger Marktforscher: 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 immer noch kommen pro Jahr etwa fünf Milliarden neue Codezeilen hinzu. IDC geht davon aus, dass weltweit 60 Prozent aller Unternehmen weiterhin auf Cobol als Grundlage ihrer Anwendungen setzen. Für die Mehrzahl der Java-Entwickler und Web-Designer dürfte das Gehalt von einer Cobol-Applikation abgerechnet und von einer weiteren auf der Bank verbucht werden.

Wie kommt es zu dieser auffallenden Divergenz zwischen dem Nimbus der Programmiersprache und ihrer tatsächlichen Bedeutung? Zunächst ist einmal festzuhalten, dass Cobol auch in die moderne Welt des E-Business und Web durchaus etwas einbringen kann. So handelt es sich wie bei Java um eine plattformübergreifende Sprache - und das schon seit zwanzig Jahren. Moderne Sprachen wie C++ haben trotz Ansi-Definition die Reichweite von Cobol nicht erreicht.

Auf Mainframes ist Cobol vor Assembler noch immer die dominierende Sprache. Demgegenüber hat C in diesem Sektor nur geringe Verbreitung gefunden, nicht zuletzt aus dem ganz praktischen Grund, dass C oder C++ erst zu einem Zeitpunkt zur Verfügung standen, als die wichtigsten Mainframe-Anwendungen längst fertig waren.

Neben der sehr breiten Unterstützung von Plattformen und Systemumgebungen ist ein oft entscheidendes Plus von Cobol, dass es sowohl als Interpreter-Sprache als auch kompiliert als Maschinencode eingesetzt wird. Cobol ist also nicht nur universell, sondern in allen Umgebungen auch mit ausreichender Performance verfügbar. Zumindest für die damit erstellten Anwendungen, denn niemand wird ein CAD- oder Bildverarbeitungssystem in Cobol schreiben. Wo die beiden Anforderungen von weitgehender Plattformunabhängigkeit und hoher Performance zusammenkommen, ist Cobol erste Wahl, denn kompilierter Cobol-Code ist bis zu dreimal schneller als kompiliertes Java.

Cobol arbeitet meist unauffällig im Hintergrund

Dass Cobol für kaufmännische Anwendungen eingesetzt wird, trifft den Kern der Sache nicht ganz: Mit Cobol werden nämlich meist nicht komplette Lösungen von der ersten bis zur letzten Programmzeile geschrieben, sondern vor allem diejenigen Teile, die heute so genannten Geschäftsregeln abbilden. Meist betrifft das die Verarbeitungen von Transaktionen auf Host-Systemen, eventuell mit CICS oder IMS. Die ganzen Ein- und Ausgabe-Operationen - heute Frontend-Systeme - werden dagegen seit geraumer Zeit nur in Ausnahmefällen über Cobol realisiert.

Für die Frontend-Operationen greift Cobol schon lange auf verschiedenartige Drittsysteme zurück. Hier zahlt sich seine Offenheit aus: 4GL-Systeme, Maskengeneratoren oder auch andere Programmiersprachen ließen sich immer sehr einfach mit Cobol-Anwendungen verknüpfen. Außerdem hat Cobol immer schon den Multitier-Ansatz verfolgt: Bereits vor 20 Jahren wurde konsequent zwischen Ein- und Ausgabesystem, Geschäftsregeln und Datenbank unterschieden, so dass eine Übertragung von Aufgaben an andere Entwicklungswerkzeuge nur selten den Kern einer Cobol-Anwendung tangierte.

Der langjährige Erfolg von Cobol im Back-Office-Bereich wäre anders auch gar nicht denkbar: Während die Frontends vom Character-Bildschirm über die Windows-Oberfläche bis zum Browser mit der aktuellen Entwicklung der IT mitwuchsen, wurden die Geschäftsregeln über Jahre und Jahrzehnte ohne umfangreiche Veränderungen in Cobol gepflegt. Die aufsehenerregende Einführung grafischer Oberflächen und benutzerorientierter Bedienungskonzepte ging an Cobol weitgehend vorbei. Dass für die Pflege wichtiger Programme plötzlich keine Entwickler mehr verfügbar waren, 1999 aber händeringend gesucht wurden, bedeutete auch, dass die in zentralen Bereichen eingesetzten Cobol-Anwendungen offenbar seit Jahren nahezu ohne Pflegeaufwand stabil vor sich hin arbeiteten.

Offen für Neuerungen

In vielen Bereichen hat sich jedoch auch Cobol an neue Entwicklungen anpassen müssen. Modernes Cobol gibt es durchaus, und es hat kaum noch etwas mit dem streng prozeduralen Programmen der Lochkartenzeit gemein. Objekt-Cobol kann heute ohne weiteres mit den Leistungen anderer Entwicklungsumgebungen mithalten, ohne dabei auf die klassischen Vorzüge verzichten zu müssen. Es verfügt über umfangreiche Klassenbibliotheken, einen flexiblen Cross-Compiler, Schnittstellen zur Technologie der Object Request Broker (ORB), einen leistungsfähigen Maschinencode, der für unterschiedliche Hardwareplattformen optimiert werden kann, über alle heute üblichen Analyse- und Testwerkzeuge. Es lässt sich sehr einfach auf alle neuen Plattformen portieren, beispielsweise auf Unix, Windows 2000 sowie Linux, und ist trotz allem immer noch skalierbar vom Stand-alone-Rechner über Multiprozessorsysteme bis zum Mainframe.

Allerdings geht die unverändert große Verbreitung von Cobol in Business-Anwendungen im Wesentlichen nicht auf derartige Neuerungen zurück. Normalerweise legt ein Unternehmen eine Neuentwicklung heute nicht mehr in Cobol auf. Ausnahmen bestätigen die Regel: So gibt es Beispiele dafür, dass nagelneue Web-Portallösungen im Business-to-Business-Bereich in Cobol umgesetzt und dabei gegenüber einer Programmierung in Java rund 80 Prozent Zeit gespart wurden.

Neue Anforderungen durch neue Geschäftsmodelle

Mit dem Paradigmenwechsel des E-Business ergibt sich jedoch eine grundlegend neue Situation: Nun planen die Unternehmen genau das, was sie über Jahrzehnte nicht gemacht hatten und was die stabile Rolle von Cobol erst begründen konnte - sie beginnen, die Geschäftsregeln selbst zu verändern. Es geht auf einmal nicht mehr bloß um ergonomische Bedienung, um schnelle Datenbanken, um Schnittstellen zu Objektmodellen etc., also um meist technische Fragen, die man immer mit dem vorhandenen Werkzeugkasten beantworten konnte. Nun sind neue Geschäftsmodelle im Gespräch, die Anwendungen selbst sollen sich den Kunden und Geschäftspartnern öffnen. Die gesamte IT soll nicht mehr nur ein elektronisches Verwaltungswesen sein, sondern ein aktiver Bestandteil neuer flexibler, dynamischer Geschäftsmodelle. Damit scheint man sich auch Cobol tatsächlich "wegdenken" zu können. Denn wenn die Unternehmen erstmals nach Jahrzehnten die alten Geschäftsregeln aus den Tiefen des Codes hervorholen, um daran herumzuschrauben, dann ist es zumindest eine Überlegung wert, ob man die Neuformulierung nicht gleich in einer aktuellen Programmiersprache wie Java vornimmt.

Der Wunsch, aus der Legacy-Ecke herauszukommen, mag groß sein. Niemand wird es schaffen, die in Cobol abgebildeten Geschäftsregeln in anderen Sprachen von Grund auf neu zu formulieren. Das ist zum großen Teil einfach ein quantitatives Problem. Die Player der New Economy, so zeigt es sich inzwischen, sind hauptsächlich die Großen der Old Economy - und die sind nicht in der Lage, das Know-how von 200 Milliarden Zeilen Cobol-Code von heute auf morgen einfach über Bord zu werfen. Für langfristige Transformations- und Migrationsprozesse aber räumt die Welt des E-Business keine Zeit mehr ein.

Entscheidend ist deshalb, wie man die vorhandenen Geschäftsregeln ohne großen Aufwand in andere Systeme einbringen kann, die flexibel, dynamisch und Web-orientiert sind. Konkret geht es also darum, Cobol-Code in Enterprise Javabeans (EJBs), Corba, COM+ etc. umzusetzen. Die Kommunikation über Sprachgrenzen hinweg ist dabei keineswegs einfach. So verfügt Java nicht über saubere Schnittstellen zu anderen Programmiersprachen - native Schnittstellen sind daher nicht plattformunabhängig.

Die Cobol-Industrie hat die Bedeutung dieser Problematik erkannt und ist an dieser wichtigen Schnittstelle zwischen alter und neuer Programmierwelt sehr aktiv. So hat die Firma Merant unter anderem ein Tool vorgestellt, das vorhandene Cobol-Applikationen analysiert, darin enthaltene Business-Logik identifiziert und daraus eigenständige Cobol-Komponenten generiert, die sich beliebig weiterverarbeiten lassen. Sie können zum Beispiel in COM- oder EJB-Architekturen integriert werden. Unternehmen können so den Kern bestehender Anwendungen für neue E-Business-Lösungen nutzen. Ähnliche Pläne verfolgt auch der Cobol-Anbieter Acucobol, der Plug-ins für 4GL-Umgebungen und Internet liefert.

FAZIT

Wer heute über Cobol spricht, tut dies nicht, um der Sprache eine Lanze zu brechen oder einer Cobol-Renaissance das Wort zu reden. Ob Cobol gut oder schlecht ist, veraltet oder zukunftsorientiert, ist im Grunde irrelevant. Der Code dieser Sprache existiert in Tausenden von Anwendungen, er ist eine der Grundlagen der IT-Welt und wird das aus ganz pragmatischen Gründen bleiben. Die Kapazitäten, die nötig wären, um die fraglichen Cobol-Anwendungen generell abzulösen, sind nicht im Ansatz vorhanden. Nicht einmal im Y2K-Umfeld wurde das ernsthaft diskutiert, und da hätte man einen Grund und eine passende Gelegenheit gehabt. Daher wird Cobol unter neuen Prämissen auch im E-Business weiterleben - ein klassischer Zombie.

*Rainer Doh ist Journalist in München