Geoff Norman, Unabhängiger Unternehmensberater
Die Entscheidung für offene Systeme garantiert noch keineswegs die Unabhängigkeit von proprietären Produkten. Diese Warnung hörten die Teilnehmer an Xephons Multivendor-Connectivity-Konferenz.
Sprecher Martin Healey wies darauf hin, daß die Käufer von Unix-Systemen eine herbe Enttäuschung erleben werden, wenn sie glauben, sich mit Unix aus der Abhängigkeit von einem einzigen Hersteller lösen zu können. Natürlich gibt es eine ganze Reihe von Plattformen, auf denen Unix läuft, doch wenn man damit irgendwelche sinnvollen DV-Anwendungen realisieren will, muß das nackte Betriebssystem um eine Reihe zusätzlicher Systemdienste erweitert werden, vor allem um ein Datenbanksystem (DBMS).
Soll eine Anwendung auf verschiedenen Unix-Rechnern laufen, ist es immer noch erforderlich, das gleiche DBMS auf jeder Maschine zu installieren, weil die Hersteller sich dagegen sträuben, ein einheitliches Protokoll für Datenbankaufrufe zu implementieren. Aus diesem Grund tauscht der Unix-Anwender die Abhängigkeit von einem bestimmten Hardwarehersteller gegen die von einem bestimmten Systemsoftware-Anbieter ein - und das ist nicht unbedingt besser.
Ende der achtziger Jahre entwickelten sich offene Systeme von einer Mode - der lediglich einige Spinner anhingen, die glaubten, daß Unix die Welt erobern würde - zu einer etwas plausibleren Alternative, mit der es eventuell gelingen könnte, die diversen proprietären Architekturen durch Unix-Systeme von der Stange abzulösen. Und heute, zu Beginn eines Jahrzehnts, in dem die wirtschaftliche Lage die IT-Strategen zwingen wird, immer kostengünstigere Lösungen zu suchen, sind offene Systeme noch ein
wenig reizvoller geworden. Jetzt versteht man darunter den Aufbau von leistungsfähigen heterogenen Umgebungen, die, wo sie
passen, Standardplattformen enthalten, zugleich aber die bestehenden proprietären Bestandteile beibehalten.
Unternehmen, die sich eigentlich gerne in Richtung offener Systeme bewegen würden, sehen sich einer Reihe von Problemen gegenüber. So ist Unix für eine ernsthafte Datenverarbeitung noch immer ziemlich wacklig. IBMs AIX, das weithin als eine der robustesten Unix-Implementierungen gilt, wurde kürzlich als "biologisch abbaubare DV" beschrieben. Diese Formulierung stammt vom DV-Leiter eines internationalen Unternehmens, das kürzlich seinem Bestand von 3090-Rechnern, AS/400 und DEC VAXen eine RS/6000 hinzugefügt hat, und dürfte somit also eine kompetente Aussage sein.
Abgesehen von diesen Zweifeln an Unix selbst, gibt es noch einen Faktor, der offene Systeme auf den Sankt-Nimmerleinstag zu verschieben droht, nämlich die uneinheitliche OSI-Implementierung (OSI = Open Systems Interconnection). Tatsächlich sind OSI-Features inzwischen auf proprietären Plattformen aufgetaucht: Decnet ist der offensichtlichste Fall, doch auch IBMs OSI/CS ist gut eingeführt, und IBMs strategisches Produkt für das Netzwerk-Management-Netview - kann eine wachsende Zahl von OSI-Komponenten aufweisen. OSI muß sicherlich ernstgenommen werden, allerdings reduzieren, wie Healey anmerkte, die Unterschiede zwischen den nationalen OSI-Spezifikationen, die Wahrscheinlichkeit, daß es sich einmal als Industriestandard durchsetzt, erheblich. Selbst wenn diese Probleme gelöst werden sollten, wird OSI nicht mehr rechtzeitig kommen, um die wachsende Nachfrage nach heterogenen Netzen zu befriedigen. Zusätzlich erschwert wird die Sache noch dadurch, daß SNA und OSI von ihrer Konzeption her so verschieden sind, daß eine Annäherung zwischen den beiden unmöglich ist.
Wie üblich in der Computerbranche fand man eine Notlösung. In diesem Fall entpuppte sich der TCP/IP-Standard, der aus der Unix-Welt stammt und nicht Bestandteil des OSI-Konzepts ist, gerade rechtzeitig als ein ideales Peer-to-Peer-Protokoll für Client-Server-Architekturen. Bemerkenswert dabei ist, daß es funktioniert und über genügend eingebaute Funktionalität verfügt, um eine echte Basis für heterogene Netzwerke darzustellen. Ob Zufall oder Absicht - Tatsache ist, daß IBM auf allen ihren Systemplattformen solide TCP/IP-Implementierungen vorweisen kann.
Ein wesentliches Hindernis jedoch bleibt: Wie implementiert man Offene-System-Versionen der bestehenden TP-Anwendungen (TP = Transaction Processing), die einen erheblichen Teil der kommerziellen Datenverarbeitung ausmachen.
Man geht zunehmend davon aus, daß neue Anwendungen eher als Client-Server-Systeme entwickelt und auf einer speziell dafür ausgewählten Plattform implementiert werden, als daß sie auf den Mainframe gelegt werden, nur weil der schon da ist. Das bedeutet, daß zum Beispiel EIS-Anwendungen wahrscheinlich auf kleineren, vermutlich Unix-basierten Systemen liegen, da diese ein ausgezeichnetes Preis-Leistungs-Verhältnis bieten und ihre Tendenz zum "biologischen Abbau" unter diesen Umständen nicht so entscheidend ist. Wichtig werden Mechanismen für eine gemeinsame Datennutzung in Produktionssystemen sein, aber hier dürften relativ simple Verfahren ausreichen, zumindest vorerst, wodurch die Chancen noch weiter sinken, daß die TP-Systeme jemals neu geschrieben werden.
Die Alternative zum Neuschreiben der TP-Systeme ist es, CASE-Tools einzusetzen und sich schon mal in Reverse Engineering und anschließender Neugenerierung zu üben, ein Vorgehen, das bei größeren IBM-Installationen immer üblicher werden wird - vor allem dort, wo AD/Cycle zum Einsatz kommt und man gezwungen sein wird, diese Prozedur jedes Mal auszuführen, wenn ein weiterer Schritt in der Evolution des Repositories erfolgt ist. Wenn man das Reverse Engineering für eine komplette Anwendungslösung durchgeführt hat, kann man die Neugenerierung auch auf einer anderen Plattform durchführen - warum also nicht auf einem offenen System? Hier ist das große Problem, daß die CASE-Umgebung auf der Ziel-Plattform identisch sein müßte mit derjenigen auf der abzulösenden Plattform, einschließlich der Implementierung des jeweiligen Repositories. Das ist natürlich nicht unmöglich, aber es ist dem Ermessen eines jeden Systemherstellers überlassen. Beispielsweise wäre eine komplette Migration von einer /390 auf die AS/400 möglich, wenn das AD/Cycle-Repository auch auf dem Mini verfügbar wäre, doch IBM zeigt keine Anstalten, eine solche Entwicklung anzupacken. Eine AIX-Implementierung des AD/Cycle-Repositories ist allein schon deshalb ausgeschlossen, weil IBM anstelle von DB2 den OS/2-Datenbank-Manager als Basis ihres künftigen relationalen Datenbanksystems für die RS/6000 wählte. Es scheint, als bräuchte eine offene Systemumgebung, die AD/Cycle als Kanal für die Anwendungsmigration verwenden will, zusätzlich eine ES/9000 zur Unterstützung des Repository Manager/MVS (und Systemview mit seinem eigenen Repository).
In der Zwischenzeit hat IBM seine MVS/ESA-Umgebung weiter aufgewertet, indem sie System-Features wie Local Shared Resources oder Hiperbatch integriert hat, die einen speziellen Code in den Anwendungen erfordern, wodurch die Migration auf eine andere Plattform noch komplizierter wird. So kann IBM das Problem des Überlaufens zu AIX allein dadurch im Griff behalten, daß es die Fähigkeit der AIX-Umgebung kontrolliert, MVS zu simulieren. Eine Zusammenarbeit zwischen MVS und AIX oder anderen Unix-Derivaten wird noch bis zum DCE-Industriestandard (DCE = Distributed Computing Environment) der OSF auf sich warten lassen. Dieser wird vermutlich Mitte 1992 erscheinen, wenn die IBM, wie Healey erwartet, ihre vollständigen CICS-Implementierungen für OS/2 und Unix (nicht nur für AIX) vorstellen wird.
Solange keine heterogenen Client/Server-Mechanismen (insbesondere Verfahren und Werkzeuge zur Anwendungsentwicklung) installiert sind, kann man immer noch davon profitieren, daß man die vorhandenen Anwendungen immer auf den neuesten Stand bringt. Eine gute Gelegenheit dazu ist die Entwicklung grafischer Front-ends für bestehende 3270-Anwendungen mit Hilfe von Produkten wie "Easel" oder "Choreographer" - nicht als eine langfristige Lösung, sondern um die Programmierer auf die Arbeit in GUI-Umgebungen vorzubereiten.
Es ist noch ein weiter Weg, ehe offene Systeme Wirklichkeit werden, sogar in der weniger puristischen Form, aber einige ihrer Mechanismen tauchen bereits auf. Unternehmen, die sich ihre Optionen "offen" halten wollen, während sie auf das warten,
was IBM echte Produktionslösungen nennt, können jetzt schon einige Fortschritte erzielen, indem sie Know-how in der Anwendungsentwicklung aufbauen und ihre Netzpläne auf TCP/IP gründen.