Man stelle sich einmal vor, ein Hersteller wuerde Autos mit dem Attribut "besonders benzinsparend" auf den Markt bringen, bei denen sich hinterher herausstellt, dass sie mehr Kraftstoff als die bisherigen Typen verbrauchen. Diese Automarke waere sehr schnell aus dem Geschaeft.
Ganz anders in der Computerbranche. Hier werden sogar ganze Technologien unter falschem Etikett eingefuehrt, ohne dass jemand daran Anstoss nimmt. Die Rede ist vom Client-Server-Computing. Nahezu jede DV-Abteilung stellt konkrete Ueberlegungen an, auf Client-Server-Loesungen zu wechseln. Als Begruendung werden nahezu einhellig die unkontrollierbar ansteigenden IT-Kosten genannt, welche man damit verringern wolle - und genau darin liegt das Missverstaendnis. Schliesslich wurden Client-Server-Loesungen nicht entwickelt, um Kosten zu reduzieren. Ziel war, die Produktivitaet und die Portabilitaet der Anwendungen zu erhoehen und gleichzeitig die Qualitaet sowie die Anzahl der verfuegbaren Programme am Arbeitsplatz zu steigern.
Greift man die Frage auf, ob es ueberhaupt echte Client-Server- Loesungen gibt, ist dies auch ein Ansatzpunkt, um einmal ueber den Begriff "Open Systems" nachzudenken. Dass Unix heute automatisch in diese Kategorie eingeordnet wird und als Hauptumgebung fuer echtes Client-Server gilt, ist eine klassische Marketing-Erfindung. Sie stammt aus den fruehen 80er Jahren, als AT&T und Sun die Terminologie erfolgreich verkauften.
Die Unix-Gemeinde kann sich jedoch wahrhaftig nicht als Urheber oder gar Erfinder von Cross-Platform-Portability hervortun. Lange vorher waren Standards wie Ansi Cobol, Ansi Fortran und Codasyl DBMS fuer die Aufgaben in einer offenen Welt vorbereitet worden. Aber es war die Unix-Gemeinde, die sich der Marke Open Systems bediente und unter diesem Label Hardware-Unabhaengigkeit durch Portierbarkeit auf unterschiedliche Betriebssysteme zum Kriterium machte.
Diese Vision von offenen Systemen war allerdings lange Zeit nicht richtungsweisend und konnte die Anforderungen der IT-Abteilungen hinsichtlich 4GL, TP-Monitoren und DBMS nicht befriedigen. Schliesslich liess sich kein Unterschied hinsichtlich der Portierbarkeit einer Anwendungsentwicklung unter Unix oder VMS und MVS auf einer einheitlichen Datenbank feststellen. Zudem sind einige Unix-basierte Produkte ohne Sourcecode und vollstaendige Dokumentation ebenso geschlossen, als waeren sie proprietaer. Hinzu kommt, dass es Softwareprogramme gibt, die aufgrund ihrer virtuellen Adaption der herrschenden Standards auch in der Nicht- Unix-Welt ueber viele Plattformen hinweg portierbar sind.
Wir muessen deshalb ernsthaft mit Mythen aufraeumen, die da heissen: "Downsizing ist gleichzusetzen mit Unix", "MVS-Mainframes unterstuetzen keine Client-Server-Architekturen", "Unix-Systeme bieten automatisch Client-Server-Voraussetzungen" oder "Client- Server bedeutet Open Systems". Die Realitaet sieht anders aus. So wird Unix zum Beispiel als Downsizing-Praemisse aufgebaut, steht aber nur fuer weniger als 50 Prozent aller Downsizing-Projekte. Die restlichen Downsizing-Vorhaben schliessen AS/400-Rechner, PC-LANs und VAX-Systeme ein. Die wohl am weitesten verbreitete Art der Client-Server-Anwendungen besteht jedoch ohne Frage aus PC- Clients, die mit MVS-Mainframes verbunden sind.
Die aggressive Adaption einer Client-Server-Strategie kann heutzutage nur realisiert werden, wenn die Grenzen des Quasi-Open- Systems-Standards erheblich ausgedehnt werden. Ohne Implementation der Industriestandards ist das kaum durchfuehrbar. Cobol ist ein Standard, der sich nicht einfach beiseite schieben laesst, wenn man Anwendungen in eine offene Client-Server-Architektur ueberfuehren will. Ueber 80 Prozent der bestehenden "Legal Software" ist nun einmal in Cobol geschrieben.
Aus historischer Betrachtung heraus muss festgestellt werden, dass Cobol der am meisten eingesetzte Open-Systems-Standard ist. Cobol ist seit 1964 offizieller ANSI-Standard und gilt fast seit dem gleichen Zeitpunkt als De-facto-Standard. Durch seine Verfuegbarkeit ueber viele Betriebssysteme und Maschinenarchitekturen hinweg hat Cobol mehr fuer Anwendungs- und Programmierportabilitaet geleistet als jeder andere Standard.
Die Portabilitaet ist wohl das wichtigste Kriterium, das fuer offene Systeme spricht. Sie ermoeglicht es den Anwendern, mit Daten und Programmen zwischen heterogenen Systemen zu kommunizieren. Unbestritten sind auch die Vorteile bei der Anwendungsentwicklung auf Workstation-Ebene und damit verbunden die tatsaechlichen Kosteneinsparungen bei den Mainframe-Zeiten. Eine reine Datenerfassungsanwendung wird wohl niemand ernsthaft in eine Client-Server-Loesung umwandeln wollen, denn das kommt teurer als die bisherige Mainframe-Applikation, die mit Hilfe dummer Terminals genutzt wird.
Ob sich mit einer Client-Server-Loesung ueberhaupt Kosten sparen lassen, steht in enger Relation zum Status quo: Wie geschlossen und ineffektiv war der IT-Bereich in der Vergangenheit? Unternehmen, die sich strikten Codierungsstandards unterworfen sowie eine ausgewogene Konfiguration aus anerkannten Schnittstellen und Produkten von vertrauenswuerdigen Herstellern installiert haben, die Standardsprachen und -protokolle einsetzen, ein gutes Anwendungsentwicklungs-Design praktizieren und ueber eine leistungsfaehige Datenadministration verfuegen, profitieren eigentlich schon laengst von allen Vorteilen offener Systeme. Nur nennen sie es nicht so. Dagegen wird sich bei Unternehmen, die vorher niemals ernsthaft ueberprueft haben, was die Implementierung von nichtstrategischen, einzigartigen und herstellerabhaengigen Produkten auf lange Sicht tatsaechlich kostet, der Wechsel auf offene Systeme sofort positiv auswirken.
IT-Abteilungen, die nur wenige Standardsprachen wie C, Cobol oder Fortran einsetzen, sparen gegenueber DV-Bereichen, die mehr als ein Dutzend Sprachen bedienen muessen - darunter womoeglich noch exotische, fuer die es kaum Programmierer am Markt gibt -, erheblich an Personal- und Ausbildungskosten. Die Verwendung von Standards kann auch die Langzeitkosten fuer die Wartung erheblich reduzieren. Als Beispiel sei der Nichtstandard Quel als relationale Datenbanksprache genannt. Anwender, die diese Sprache einsetzten, mussten zum Teil unter erheblichen Kosten auf den spaeteren SQL-Standard konvertieren.
Die Strategie der modular entwickelten Anwendungen nutzt die Regeln und Prinzipien der offenen Systeme konsequent aus, indem die Programmierer C oder Cobol als Standardsprachen verwenden. Wo es machbar und sinnvoll ist, verwenden sie APIs und Hilfsmittel, die ueber die offiziellen Standards wie Motif oder SQL adaptierbar sind, oder sie gehen einen Schritt weiter und nutzen das Distributed Computing Environment (DCE) der OSF. Lassen sich keine Standards verwenden, werden Programm-Module auf jeden Fall herstellerunabhaengig unter Einsatz eines portierbaren Anwendungscodes modular angelegt.
Hersteller von Standardsoftware praktizieren diese Art des modularen Designs seit Jahren, um ihre Programmpakete unter heterogenen Systemen portierbar zu machen. So laeuft dieselbe in S/38 Cobol geschriebene kommerzielle Software - ein bekanntes Finanzpaket - mit nur winzigen Routineaenderungen auch auf einer VAX. Was bei Anbietern von Standardsoftware schon aus kaufmaennischen Erwaegungen heraus geschieht, hat sich auch fuer viele IT-Abteilungen bewaehrt, da die Programme haeufig in heterogenen DV-Landschaften eingesetzt werden.
Eine uebliche Variante dieser modularen, herstellerunabhaengigen Software-Entwicklung ist der Einsatz von Entwicklungswerkzeugen, die mit separater Run-Time-Umgebung und Compiler-Time ausgestattet sind. So kann der Entwickler, um die groesstmoegliche Portierbarkeit auf heterogene Windowing-Systemen zu erreichen, die entsprechenden Grafik-Schnittstellen mit einem GUI- unabhaengigen Tool wesentlich einfacher spezifizieren. Vor der Compilierung reicht ein Klick, um zu bestimmen, ob Motif-, Open- Look-, Windows- oder Macintosh-Code zu generieren ist. Dieses Beispiel soll deutlich machen, warum Offenheit mehr davon abhaengt, wie IT-Abteilungen die Anwendungen gestalten, als von herstellerabhaengigen Werkzeugen.
So kann ein portierbares relationales Datenbank-Management- System wie Ingres, Oracle oder Sybase durchaus in jedem der drei aufgefuehrten Szenarien problemlos Verwendung finden. Werden lediglich ANSI-SQL-APIs benutzt, koennen sie sogar Teil einer absolut offenen Systemstrategie sein. Werden aber die 4GLs, CASE- Tools oder DBMS-Extensionen dieser Datenbankanbieter verwendet, haben diese einen proprietaeren Anspruch.
Aufgrund der geschilderten, insgesamt unterschiedlichen Ansaetze und Ausgangssituationen duerfte jedem IT-Verantwortlichen klar sein, dass Client-Server-Computing nicht nach dem Prinzip "Egal wie, Hauptsache Client-Server" eingefuehrt werden kann. Auf keinen Fall duerfen nennenswerte Kosteneinsparungen erwartet werden.
Allerdings kann man mit echten Qualitaetsverbesserungen und spuerbaren Entlastungen der Mainframes bei der Anwendungsentwicklung unter Client-Server-Loesungen rechnen.