Der Übergang von der Bastelarbeit zur Verwirklichung von Konzepten

14.02.1992

Von Jaroslav Blaha Projektmanager im Nato-Hauptquartier in den Niederlanden

Für mich ist kaum mehr ein Zweifel vorhanden. Nachdem in den vergangenen Monaten die Worte "offen" und "Windows" in aller Munde waren, wird die nächste Generation der Anstrengungen im DV-Bereich von der "Interoperabilität" geprägt sein. Zugegeben, "Windows" ist, vor allem wenn ins Deutsche übersetzt, kein allzu phantasievoller Begriff und "offen" hat immer einen Hauch des Anrüchigen, des Unvollendeten und Undefinierten mit sich herumschleppen müssen. Doch sind beide immer für einen Hochglanzprospekt gut gewesen, und selbst der unbedarfte Anwender konnte sich darunter etwas vorstellen. Und nun das: Interoperabilität.

Dein Worte nach bedeutet Interoperabilität die "Fähigkeit zur Zusammenarbeit", also die Fähigkeit von Systemen, durch das Anbieten eigener und das Inanspruchnehmen fremder Dienste Informationen auszutauschen und so zu verwenden, daß eine effiziente Bearbeitung der Daten gewährleistet wird. Wohlgemerkt: Damit sind Systeme unterschiedlicher Bauart und verschiedener Hersteller gemeint, denn "Synergie at Work" in einem homogenen System sollte man eigentlich schon für selbstverständlich halten können.

Doch warum hadern - die Universal-Lösung wird ja mittlerweile in jeder Schulung zum Thema "Datenkommunikation" vorgestellt. Oder kennen Sie einen Lehrgang, in dem nicht mindestens die ersten zwei Stunden von "ISO/OSI und den sieben Schichten" handeln? Ähnlichkeiten mit anderen Märchen sind rein zufällig. Mit diesem wohldurchdachten und bis zum Letzten ausspezifizierten Standard sollte es doch ein Kinderspiel sein - nehmen wir etwas aus der Praxis - einen BS2000-Host mit einem Novell-Netz zu verbinden und fröhlich auf dem Siemens-Terminal (natürlich character-basiert) Windows-Applikationen auszuführen. Das nenne ich wahrlich interoperabel.

Zurück zur Realität: Spätestens bei dem - zugegebenermaßen naiven - Versuch, zwei seit Jahren gewachsene, aber leider völlig unterschiedliche Systeme mit Hilfe OSI-konformer Software zu verbinden, stößt man an die Grenzen seiner Beherrschung. Der eine Hersteller hält sich sklavisch an die Norm (leider eine alte Version - aber immerhin), ein anderer nutzt seine Interpretationsfreiheit voll aus, um das eine oder andere werbewirksam Feature doch noch unterzubringen, und der nächste implementiert nur ein Subset mit dem beruhigenden Gedanken, vor dein nächsten Norm-Update wenigstens nicht allzuviel falsch gemacht zu haben. Das Resultat ist in allen Fällen dasselbe - Ärger.

Ich will nicht übertreiben; auf der technischen Ebene, also der eigentlichen Informationsübertragung mit ihren funktionalen, elektrischen und physikalischen Charakteristiken, ist Interoperabilität heutzutage eigentlich kein Thema. Steckerformen lassen sich bekanntlich gut normieren und an der Elektronik arbeiten Ingenieure, die es gelernt haben, nach Standards zu verfahren.

Die nächste Ebene ist die prozedurale Interoperabilität. Sie definiert die Verfahren, mit denen Nutzdaten übertragen werden, ihren strukturellen Aufbau und ihre inhaltliche Bedeutung. Doch hier wird es häßlich. Es soll ja tatsächlich Systeme geben, die ihre Daten datei- und nicht messageorientiert bearbeiten oder gar eigene Zeichensätze verwenden (Windows), die eben nur fast kompatibel zu anderen sind.

Auf operationeller Ebene wird Interoperabilität zum Ausdruck der Hilflosigkeit. Die Systeme sollen nicht nur einfach Daten austauschen, sondern sie sogar in aufeinander abgestimmten Verfahren automatisch verarbeiten. Das allerdings setzt voraus, daß einheitliche Vorgaben, Ziele und daraus abgeleitet Verfahren für die operative Nutzung vorhanden sind, die auch mit Begriffen gleichen Sinninhaltes für alle Beteiligten beschrieben werden (IBM-"often" ist nicht gleich ACE-"offen"). Spätestens hier wird es müßig, proprietäres beziehungsweise normfremdes Terrain abzustecken, denn ohne Kooperation kann es auch keine Interoperation geben.

IBMs SAA-Ansatz, der quer durch die angebotene Produktpalette reichen sollte, war ein Schritt in die richtige Richtung. Er blieb jedoch, wie etliche andere Initiativen auch, in einem Filter aus Mißtrauen und proprietärem Selbstbehauptungswillen der übrigen Anbieter und Entwickler stecken. Im Falle IBM ist das den, nicht nur OS/2-geschädigten Firmen kaum zu verübeln.

Etwas erfolgreicher war Microsoft mit Windows auf der Ebene der PCs. Hier ist es gelungen, eine Vielzahl von Programmen in das Mäntelchen eines einheitlichen "Look-and-Feel" zu stecken, sie so weit wie möglich Hardware-unabhängig zu machen und ihnen die Möglichkeit des transparenten Datenaustausches zu geben. Doch gerade die Beschränkung auf PCs ist ein Grund für Zurückhaltung. Solange es keine einfache Möglichkeit gibt, mit nicht-kompatiblen Rechnern aller Art Daten auszutauschen und vor allem Systemdienste anzubieten beziehungsweise in Anspruch zu nehmen, kann man anstatt von Interoperabilität auch nur von einer Benutzeroberfläche sprechen. Selbstverständlich gibt es Software, die eine Anbindung von Windows an andere Systeme erlaubt. Nur - von einem komfortablen, problemlosen und transparenten Austausch von Daten und dem Bereitstellen von Ressourcen kann keine Rede sein. Was früher eine VT52-Emulation unter DOS war, ist heute die X-Windows-Emulation unter MS-Windows.

Gerade DV-Großanwender mit massiv heterogenen Systemen benötigen eine Möglichkeit, die nun einmal vorhandenen Systeme operationell so zu integrieren, daß sich die Anwendung und Bedienung vereinheitlicht, die Ressourcenauslastung beziehungsweise -verteilung optimiert und die Verwaltung vereinfacht. Viel nähergekommen sind wir diesem Ziel noch nicht.

Allgemein wird sich an diesem Zustand frühestens etwas ändern, wenn die Unternehmen ihrerseits zu mehr Kooperation untereinander und mit dem Kunden übergehen. Eine gute Basis bestünde zum Beispiel darin, die Schnittstellen der Systeme zu veröffentlichen, anstatt eifrige Entwickler, die es sich angemaßt haben etwas darüber herauszufinden, zu verklagen.

Der Blick in die einschlägigen Zeitschriften offenbart, wohin das Gerangel der Mitglieder von Normungsgremien, Vereinen, Gruppen und großen Unternehmen bis jetzt geführt hat. Für jedes Problem, das dank Nicht-Standardisierung und Nicht-Offenheit ungelöst bleibt, entsteht hier ein Tool, da ein Hilfsprogrämmchen und dort ein Treiber.

Anstatt auf einer sauber definierten und auch eingehaltenen Norm basieren die heutzutage interoperablen Systeme auf Flickwerk. Warum wird von dem oben aufgezählten Kreis von Institutionen (und damit Menschen) eigentlich nicht das vorgelebt, was er ins Leben rufen möchte - Interoperabilität, Kooperation und Kommunikation.

Dabei darf nicht vergessen werden, daß die Standards und auch die Arbeit an ihnen nicht Selbstzweck sein sollen. Erst die Umsetzung durch koordinierte Implementierung in die Systeme führt zum Ziel verbesserter Interoperabilität und damit zum operativen Nutzen. Es bleibt zu hoffen, daß in naher Zukunft der Übergang von der Bastelarbeit zur Verwirklichung von Konzepten vollzogen wird. Denn Innovationsfähigkeit kann bestimmt auch sinnvoller zum Ausdruck gebracht werden, als im Schreiben von Progrämmchen, die die Kommunikation zwischen genau den Systemen x und y doch noch ermöglichen.

Ansonsten bleibt einem nur noch der bewährte Griff zum guten alten Kermit - da weiß man, was man hat!