Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

12.03.1993 - 

PC-INTEGRATION

Die Zukunft gehoert den offenen Schnittstellen

Als die DV-Welt noch halbwegs in Ordnung war, definierte die IBM immer wieder ganz alleine ein Protokoll fuer die Verbindung von bestimmten Systemen, zum Beispiel die Systems Network Arcitecture Distribution Services (SNADS). Natuerlich galt es nur in der blauen Welt, und die IBM-Vertriebsbeauftragten lenkten ihre Kunden in die gewuenschte Richtung, wie etwa beim Synchronous Data Link Control (SDLC). Andere Hersteller beeilten sich, die IBM-Protokolle nachzuempfinden.

Offenheit wurde erst geuebt, als die IBM erkannte, dass die Offenlegung ihrer Protokolle fuer eine bessere Akzeptanz und Durchsetzung im Markt unverzichtbar war. Der Begriff bedeutet jedoch im PC-Markt, der das Geschehen an der Basis vorantreibt, etwas ganz anderes: "Offen meint ersetzbar", formuliert Roel Pieper, der Chef der Unix System Laboratories, die kuerzlich an Novell verkauft wurden. Wirklich offene Systeme zu bauen, ist daher fuer die Hersteller in aller Regel nur ein Lippenbekenntnis. Denn wer sich selbst ersetzbar macht, der laeuft auch Gefahr, tatsaechlich ersetzt zu werden. So, wie es IBM derzeit erfahren muss.

Der klassische Fall der IBM-Connectivity ist tatsaechlich der: ein teuer erworbener Macintosh wird mit einer aufwendigen Softwareloesung auf dumm getrimmt, das heisst an die AS/400 als Terminal angehaengt.

IBM-Connectivity war in den 80er Jahren Pflicht

Die Software dafuer ist uebrigens nicht etwa fuenf Jahre alt, sondern wurde soeben stolz von IBM und Apple als eines der ersten Ergebnisse der Zusammenarbeit auf dem Gebiet der Integration von Apple-Maschinen in die IBM-Welt angepriesen. Firmen wie BMW haben bereits 1987 solche und aehnliche Konzepte realisiert, und die Frage stellt sich zu Recht, ob das Denken, das Produkten wie dem genannten zugrunde liegt, noch zeitgemaess ist.

IBM-Connectivity war in den 80er Jahren Pflicht, als man sich oeffentlich zu gemischten Host-Strategien bekannte, als die ersten PC-Netze wuchsen. Zu dieser Zeit gewann der Tandem-Host neben der IBM an Bedeutung, und die VAXen draengten sich aus der technisch- wissenschaftlichen DV in die kommerziellen Anwendungsbereiche. Damals musste man als Terminal- oder PC-Benutzer in die Lage versetzt werden, an alle Host-Systeme heranzukommen. Einzige Moeglichkeit war in der ueberwiegenden Zahl der Faelle das Ueberstuelpen der 3270-Maske ueber das Endgeraet, eine wenig elegante, fehlertraechtige und kostenintensive Variante.

Die Einfuehrung von OSI-Protokollen stellte sich als noch viel teurer als unvollstaendig und gelegentlich fehlerbehaftet dar. Eine Verbindung aller zentralen sowie Endgeraete ueber ISDN lag und liegt in weiter Ferne.

Der Begriff der Connectivity impliziert neben der Ausrichtung auf die IBM immer auch eine hierarchische Denkweise. Daher ueberrascht es nicht, dass mit dem schwindenden Einfluss der IBM und der Durchsetzung des dezentralen, nicht-hierarchischen Denkens die Frage der Connectivity in den Hintergrund tritt.

Dass IBM bei der Durchsetzung des Advanced-Peer-to-Peer-Networking (APPN)-Gedankens gescheitert ist, hat also eine technische und auch eine historische Dimension. In dem Moment, wo Big Blue den hierarchischen Systemgedanken aufgab und eine dezentrale Alternative praesentierte, trafen

die Armonker auf massiven Widerspruch aus der Industrie und sahen sich sogleich mit einer Gegeninitiative bedroht (APPI). Dies waere noch 1987 nicht denkbar gewesen, als IBM die System Applications Architektur (SAA) definierte. Das Scheitern von APPN ist tatsaechlich in sich selbst begruendet.

Doch was tritt an die Stelle der Connectivity? Wenn die DV- Installationen sich nicht mehr an IBM-Protokollen ausrichten und wenn heterogene Netze das Schlagwort des Jahres sind, was tritt an die freigewordene Stelle? Sind es tatsaechlich temporaere Gruppierungen von einzelnen Herstellern, die Standards schneller definieren und wieder einstampfen, als die Presse sie erlaeutern kann wie im Falle APPI, wo sich Cisco, Alcatel, British Telecom, DEC, HP und einige andere einig wurden?

Abkehr von den Gremien

Wie das vergangene Jahr zeigte, hat das Geschehen im PC-Markt erheblichen Einfluss auf das gesamte DV-Geschaeft. Dies bezieht sich nicht nur auf den Siegeszug des Microprozessors bis in die Host- Systeme, sondern vor allem auf das Tempo. Alle sechs Monate soll die Produktpalette nach dem erklaerten Willen der Hardware- und Softwarehersteller erheblich erweitert werden. Unter dieser Voraussetzung bleibt aber garantiert keine Zeit, in Gremien wie der ISO oder der CCITT herumzusitzen und ueber Offenheit und Standards zu diskutieren.

Das Jahr 1992 brachte dementsprechend im PC-Markt eine fast voellig Abkehr von der Mitarbeit an Gremienstandards. Bei den PC-Bussystemen erleben wir gerade, wie die Quasistandards EISA und Microchannel von teilweise chaotischen Local-Bus-Designs ueberrollt werden, die Intel nachtraeglich zu standardisieren versucht. Mathias Zahn vom PC- Softwarehersteller Fast Electronics: "Ich habe einen grossen Respekt vor den Leuten, die in Komitees darueber reden, was ein guter Standard ist und was nicht. Ich glaube aber, das ist ein sehr undankbarer Job, bei dem man viel Zeit und vielleicht sogar seinen Wettbewerbsvorteil verliert."

Betriebssystem-inhaerente APIs wie zum Beispiel eines fuer Mail wurden nicht etwa als reine X.400- Implementation oder als ein Superset davon praesentiert, sondern im Gegenteil als Marketing-Werkzeug zur Kundensteuerung missbraucht. Lotus (erst OMI, dann VIM) und Microsoft (MAPI) lieferten sich hier eine besonders haessliche Schlacht, bis feststand, dass zwar jeder an seinem Mail-Standard festhalten wird, dass Lotus aber eine Bruecke von hier nach da anbieten wird beziehungsweise muss. Auch X.400, dem letzten der Gremienstandards, der noch einigermassen Gefolgschaft fand, droht bald das Aus.

Solche Auseinandersetzungen sagen viel ueber den Stellenwert der propagierten Offenheit fuer die Hersteller und auch ueber den Stellenwert des Standards an sich: Er ist gering.

Wer also gehofft hatte, dass an die Stelle der wohlgeordneten Connectivity-Welt eine neue Welt der geordneten Offenheit und der verantwortungsbewussten Hersteller trete, der muss erkennen, dass die rauhen Sitten aus dem PC-Sektor uebergreifen in die ehemals ruhigen Gefilde der Minicomputer- und Host-Welt. Und dort wird von eiligen PC-Protagonisten natuerlich auch eine Menge Unruhe, wenn nicht sogar Unheil gestiftet.

Standards sind unverzichtbar in Zeiten der Offenheit, aber unzuverlaessig. Sie dienen als Macht- und Marketing-Instrumente, sie werden wie Koeder in den Markt geworfen, um zu schauen, wie viele Leute anbeissen. Auf die Frage: "Was ist ein Standard?" antwortet ein Bill Gates sehr einfach: "Kritische Masse".

Standards kann man auch so sehen: Sie sind der Versuch des Herstellers, den Markt mit einer proprietaeren Technologie zu dominieren. Denn wenn jeder seinen eigenen Standard propagiert, dann hat das Wort Offenheit seinen Sinn verloren.

Stehen wir vor der Rueckkehr in die proprietaere Welt? Ist sie im Unterschied zu frueher lediglich unendlich segmentiert? Ich meine: ja.

Doch es gibt noch Hoffnung fuer die Verfechter der offenen Systeme. Es scheint sich naemlich herauszustellen, dass Herstellergruppierungen, die keinen Gremienanspruch haben und nicht als reaktive, sondern als proaktive Gruppe zusammenarbeiten, eine gewisse Lebensdauer und einen gewissen Erfolg haben.

So zum Beispiel die Object Management Group (OMG) auf dem Gebiet der Objektorientierung oder die Open Software Foundation (OSF) beim Distributed Computing Environment (DCE) beziehungsweise Distributed Management Environment (DME).

Offene Schnittstellen statt offener Systeme

Offenheit wird in Zukunft nicht etwa offene Systeme bedeuten, sondern offene Schnittstellen. Denn im Kern der Systeme liegt der Wettbewerbsvorteil des Herstellers verborgen. Und wer diesen aufgibt, der gibt sich selbst auf.

Was aber soll man tun in einer Welt ohne IBM-Dominanz, ohne Connectivity, wo die Standards sich jeden Tag aendern koennen? Einige Empfehlungen fuer Anwender:

- Hoffen Sie nicht mehr auf verlaessliche oeffentliche Gremienstandards - es gibt keine.

- Waehlen Sie die von Herstellern propagierten Standards nicht nach ihrer Funktionalitaet aus, sondern danach, ob sich die strategisch- politische Intention des Anbieters mit Ihren Plaenen deckt.

- Akzeptieren Sie die Tatsache, dass Standard inzwischen soviel heisst wie: kleinster gemeinsamer Nenner.

- Schreiben Sie die Standards jedes Jahr mindestens einmal fort.

- Haben Sie den Mut, sich wieder in die Haende eines oder mehrerer Hersteller zu begeben. Auch offene Systeme erfordern eine gewisse Hingabe.

- Standards zu beachten ist kein Schutz vor Fehlentwicklungen, reduziert aber das Risiko erheblich.

* Susanne Mueller-Zantop ist Herausgeberin des PC-Newsletters "TidBits". Ihr gehoert die Beratungsfirma MZ Projekte in Muenchen.