Im Prinzip klappt die Integration heterogener DV- Welten, aber

Aufbau offener Systeme braucht Entschlossenheit und Augenmaß

05.06.1992

"Die Diskussion um Betriebssysteme haben wir satt." Mit diesem knappen Satz faßte Hilde Faleschini, bei der Nürnberger Bundesanstalt für Arbeit für die Planung der informationstechnischen Infrastruktur verantwortlich, die Meinung vieler DV-Anwender zusammen. Ein alljährlich in Zürich veranstaltetes Seminar "Unix in heterogenen Umgebungen" zeigte, daß den Anwendern der Schuh von den Mühen der offenen Ebenen drückt.

Die früher den Unix-Apologeten unentwegt vorgehaltene Frage, ob ihr Lieblingsbetriebssystem auch dies oder das könne, was die proprietären Betriebssysteme vermögen, traut sich heute kaum einer mehr zu stellen. Stück für Stück holt Unix auf und gleicht technische Defizite aus.

So widersprach Peter Litschig von der Hewlett-Packard AG Schweiz, einem Unternehmen, das in beachtlicher Zahl Anwender des proprietären Systems MPE hat, auf dem von Unix Transparent, München, veranstalteten Seminar der Ansicht, das Standard-Betriebssystem werde nicht in der Lage sein, in Bereiche einzudringen, in denen heute noch geschlossene Systemwelten dominieren.

Unix hat einen Sog zu offenen Systemen ausgelöst - kein Herstellervertreter, der sich auf der Podiumsdiskussion nicht beeilt hätte, die neue Offenheit herauszustreichen.

Proprietären Systemen gilt wenig Aufmerksamkeit

Die Vertreter von IBM, DEC, HP und SNI betonten die Bedeutung ihrer Arbeiten an Unix und ihre Aufwendungen, die proprietären Umgebungen durch zusätzliche Posix-Schnittstellen zu öffnen.

Insbesondere bei der aktuellen Verteilung der Entwicklungsgelder wurde seitens der Herstellervertreter - ohne konkrete Zahlen auf den Tisch zu legen - ein mächtiges Übergewicht für die Seite der offenen Systeme behauptet. Damit würde sich erfüllen, was der BMW-DV-Manager Herbert Laib als Anwendervertreter forderte:

"Keiner verlangt von den Herstellern die Aufgabe ihrer proprietären Systeme, sondern lediglich ein Angebot an jene Kunden, die es zu offenen Systemen hinzieht."

Klaus Ebert, von der ABB Netzleittechnik AG im schweizerischen Turgi, hält die Forderungen der Anwender für erheblich, darüber hinausgehend. Die Kunden möchten "off the shelf kaufen", wie sie es mit Standardsoftware im PC-Markt tun. Das habe Konsequenzen vor allem für die großen Anbieter, die ihr Schwergewicht auf Dienstleistungen, auf Beratung, Integration und Organisation legen müßten.

Zu diesem Punkt aber waren auf dem Seminar mehrfach Bedenken zu hören. Schon zu Seminarbeginn hatte Lutz Richter, Professor an der Universität Zürich, eingewandt, die Anwender seien den Anforderungen durch offene Systeme oft nicht in vollem Umfang gewachsen. Das bestätigte Hans Strack-Zimmermann, Geschäftsführer des Münchner Softwarehauses Ixos.

Er meinte, ein Anwender sei überfordert, wolle er versuchen im Alleingang die Aufgaben der Integration heterogener Systeme zu erledigen. Dazu bedürfe es schon der auf Integration spezialisierten Unternehmen.

Derlei sei nicht nur eine teure Alternative, kamen Einwände aus dem Publikum. Durch offene Systeme würde möglicherweise nur die Abhängigkeit von einem Hardwarehersteller gegen die Abhängigkeit von Softwarehäusern und Systemintegratoren eingetauscht. Tatsächlich gestand ein DV-erfahrener Anwender, schon bei der Konfiguration eines Unix-Systems ein Desaster erlebt zu haben. Was einen weiteren Teilnehmer der Debatte auf die Palme brachte: "Ich kann nicht akzeptieren, daß offene Systeme Gurus und Geheimwissen verlangen."

Ganz aussichtslos und verfahren ist die Lage jedoch nicht. Auf der Züricher Tagung wurden nicht nur die seit Jahren immer wieder präsentierten guten Gründe für Unix und offene Systeme zum Beispiel hinsichtlich Preiswürdigkeit, Entwicklungsgeschwindigkeit und Investitionssicherheit bemüht. Vielmehr kam eine Reihe Empfehlungen, Erfahrungen und Tips für den Ausbruch aus der proprietären Enge zur Sprache.

Solch ein Ausstieg setzt zunächst einmal einen detaillierten Plan voraus - "aber bei den Anwendern fehlen Strategien", glaubt Professor Richter festgestellt zu haben. Einige Gründe stellte er seiner übrigens nicht unbestrittenen These voran: Anwender seien schon beim Wort "offen" irritiert, "denn die Gruppe der Anbieter spricht leider noch mit zu vielen Zungen". Auch, so bedauerte er, hätten die Käufer "über die letzten 30 Jahre zu akzeptieren gelernt, was die Anbieter ihnen verkaufen wollen".

Bei den großen Herstellern sei die Tendenz zu beobachten, offene Systeme als Ablösung ausgedienter proprietärer Systeme anzubieten. Daß es aber darum nicht gehen könne, sondern sich schon heute ein evolutionärer Übergang zu offenen Systemen anbiete, zeigten die Beiträge aus den Kreisen jener Anwender, die diesen Weg beschritten haben.

Keine Spur von der eierlegenden Wollmilchsau

Nur die Forderung "Ich will alles - und zwar jetzt!" ist zum Scheitern verurteilt. Es ist eben nicht alles standardisiert, Mut sei schon noch gefragt, wie der universitäre Beobachter Richter meinte: " Wir können nicht immer auf die Standardisierungsgremien warten. Im Zweifelsfall sind am Markt akzeptierte Standards wichtiger als offizielle Definitionen."

Daß derlei vom Anwender Fingerspitzengefühl verlangt, offenbarten die wenig erbaulichen Erfahrungen, die die Informationsplanerin von der Bundesanstalt für Arbeit, Faleschini, mit OSI/ISO gemacht hat. Die Nürnberger sind zum guten, alten Kommunikationsstandard TCP/IP zurückgekehrt. "OSI-Dienste wären ja schön," gibt Helmut Schäfer, Geschäftsführer des Ingenieurbüros Intercom aus Horb, zu bedenken, "aber diese eierlegende Wollmilchsau ist komplex."

So riet dann auch Faleschini, bei allem Mut zur Veränderung Vorsicht walten zu lassen. Man solle nie warten, bis die Hersteller ihre Versprechungen in Sachen zukünftiger Systeme erfüllten, sondern lieber ein weniger großartiges, dafür aber stabiles System kaufen. Auch von Sonderwünschen und Zusatzfeatures sei abzuraten, wenn sie nicht genau auf der Linie eines Anbieters liegen. Denn Zusätze bergen nicht nur die Gefahr neuer proprietärer Umarmungen, sondern lassen auch bis zu ihrer Verwirklichung auf sich warten und erfahren meistens einen schlechteren Service.

Insbesondere das Thema Netze hat es in sich, wenn es um Integration und verteilte DV in heterogenen Umgebungen geht. Die Anforderungen an ihre Leistungsfähigkeit werden weit schneller wachsen als in jedem anderen Teilbereich im Netz. Vor allem die Online-Transaktionsverarbeitung bleibe keine Angelegenheit für zeitkritische Datenverarbeitung bei Banken und Versicherungen, sondern werde auch in Bereichen wie der Auftragsbearbeitung bei wesentlich kleineren Unternehmen Fuß fassen, so der Tenor einer Arbeitsgruppe.

Der gegenwärtige Zustand der Unternehmensnetze ist vor solchem Hintergrund nicht gerade berauschend. Der knappe Befund von Intercom-Mann Schäfer: "Durcheinander statt miteinander" mit dem Effekt eines "Machtverlustes des DV-Managements".

Aber die Situation ist keineswegs hoffnungslos, denn im Netzsegment gibt es reichlich Standards, für die Zukunft zeichnet sich eine Vereinfachung dadurch ab, daß zunehmend ohne fundierte Netzkenntnisse bei der Programmierung die Application Programming Interfaces adressiert werden können.

Vereinfachung in komplexeren Umgebungen könnte man es nennen, was sich da vollzieht. Diese Tendenz läßt sich auch bei den grafischen Benutzeroberflächen und den Tools feststellen. Aus beiden werden Endanwender wie DV-Fachleute viel Nutzen ziehen können - aber nicht immer, wie das Unix-Seminar feststellen konnte.

So laufen die Runtime-Elemente mancher Tools nur in bestimmten Hardware-Umgebungen, bringen folglich neue Bindungen mit sich. Und wer den Endanwendern die Frage stellt, ob sie grafische Benutzeroberflächen, Mäuse etc. wollen, braucht sich, so die Erfahrung von DV-Planerin Faleschini, nicht zu wundern, wenn die sich für die teuerste Lösung entscheiden.

Absage an die Modetrends

Jaromir Smerda, Abteilungsleiter EDV-Anwendungsentwicklung und Konzepte bei der Salzburger Sparkasse Bank AG, warnte vor Modetrends. So sei eine schicke Benutzeroberfläche mit Mausbedienung beispielsweise für den Schalterangestellten an seinem Bankterminal ein teurer und kontraproduktiver Fehler. Davon hätten nur die Hardwaredrücker was - ausgerechnet unter Unix.