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.

Offene Systeme auf den Punkt gebracht

15.11.1991

Tony Percy, Vice President für Software Management Strategies bei der Gartner Group, Inc.

Kaum ein Wort wird so oft mißbraucht in der Datenverarbeitungsindustrie wie "Offenheit". Nicht nur den Experten ist es gelungen, eine respektable Definition zu geben. Die kürzlich ins Leben gerufene "User Alliance for Open Systems" hat den Anwendern explizit vorgeworfen, zu wenig Druck auf die Anbieter im Hinblick auf die Schaffung offener Systeme auszuüben, und sich dabei aber gleichzeitig als zweite "umfassende Aktion" die Definition von offenen Systemen aufs Papier geschrieben.

Inzwischen erscheinen Anbieterkonsortien auf dem Plan, die ihr Bekenntnis zu offenen Systemen verkünden, und jeder Anbieter, der etwas auf sich hält, stellt das Thema in seinen Marketingbroschüren und öffentlichen Stellungnahmen obenan. Für viele von ihnen ist "offen" gleichbedeutend mit Unix (das in Wahrheit schlicht ein weiteres proprietäres Betriebssystem darstellt), und sogar IBM, der schon klassische proprietäre Anbieter, sieht sich nun als der "Anbieter offener Systeme der Wahl" in den 90er Jahren. Die Diskussionen zu diesem Thema nehmen deutlich Orwellsche Formen an.

Das Problem ist, daß so viele verschiedene Ideen unter dem Begriff subsumiert wurden, als da wären proprietär und nichtproprietär und privat und öffentlich (will heißen veröffentlicht), die Verfügbarkeit und Zugänglichkeit andeuten. Es gibt Standard und Nicht-Standard, einschließlich der De-jure-Standards im Gegensatz zu den Defacto-Standards. Und es gibt Erfolg und Nicht-Erfolg, wobei Offenheit nur in bezug darauf gesehen wird, ob man die Wahl hat.

Die Marketingbotschaften der Unternehmen, die mit Offenheit werben, differieren erheblich. Für einen Hardwarehersteller ist Offenheit in erster Linie gleichbedeutend mit Unix-Support, mit Vorteilen der Interoperabilität mit Plattformen anderer Hersteller im Hintergrund. Die überwältigenden Botschaften lauten: 1) Kaufen Sie unsere Geräte und profitieren Sie von der Auswahl und der Skalierbarkeit dadurch, daß Unix auf unserer Plattform läuft, und 2) Kaufen Sie unsere Geräte, weil wir die Schnittstellen (TCP/IP, SQL etc.) unterstützen, mit denen Sie unsere Geräte in eine heterogene Umgebung einbinden können.

Für viele Softwarehäuser, die sich oberhalb des Betriebssystems (und der entsprechenden Schnittstellen) bewegen, war das Problem anders gelagert. Da es ihre Rolle gewesen ist, ein gewisses Maß an Konsistenz über eine Vielzahl von Plattformen zu bieten, bot ihre Interpretation von Offenheit im wesentlichen proprietäre Schnittstellen über diese multiplen Plattformen hinweg. Das Hardware-Lock-in wurde durch ein Software-Lock-in ersetzt. Dies hat sowohl Vor- als auch Nachteile, aber die Entscheidung muß bewußt getroffen werden.

Das Phänomen der Anbieterkonsortien ist vielleicht das verwirrendste überhaupt. Das monopolistische Risiko ist sehr deutlich, wie wir anhand der "Open Software Foundation" sehen können. Diese begann als ein Anbieterkonsortium, das Standards für Unix schaffen wollte und die Kontrolle durch die AT&T/Sun-Allianz brechen sollte. Dann begann man, Technologie anderer Hersteller für ein späteres Relicensing zu definieren (und zu akquirieren). Allerdings zog man sich den Zorn anderer Unternehmen zu, die eine Technologie vorschlugen, aber die Ausschreibung nicht gewannen und den Auswahlprozeß selbst in Frage stellten. Sind nun solche Anbieterinitiativen notwendigerweise unaufrichtig? Nein. Es gibt ein weites Feld von Funktionalitäten, wo der Standardisierungsprozeß vorangetrieben werden muß, wenn sich ein kräftigerer Markt entwickeln soll. Das war das erklärte Ziel dieser Konsortien, mit dem Risiko, weniger optimale, Technologie-basierte anstatt Schnittstellen-basierte Standards einzufahren. Der Prozeß des Request for Technology ist innerlich brüchig, da man Produkte sucht anstatt einer klaren Definition des Problems, was Standardisierungsgremien verfolgen.

Und darin liegt die Crux der ganzen Angelegenheit. Wenn Offenheit etwas bedeutet, dann ist das die konsistente und umfassende Implementierung eines De-jure-Standards. In den oberen Schichten des Open-System-Interconnection-Modells ist das nahezu unmöglich, da wir es dort mit eher abstrakten Vorstellungen und weit weniger stabilen Schnittstellen zu tun haben.

Nehmen wir SQL - das Protokoll für die Definition und das Aufrufen relationaler DBMSs. Jeder DBMS-Anbieter muß heute eine gewisse SQL-Strategie haben; SQL wird auf dem Anforderungskatalog praktisch jedes Anwenders stehen. Noch dazu wurden die Anwender davon überzeugt, daß SQL (manifestiert in einer bestimmten Produkt-Technologie) ihnen eine weit größere Portabilität und Interoperabilität als zuvor bieten wird.

Angesichts der Akzeptanz, die SQL bei Anbietern und Anwendern findet, sind diese Probleme zwar eher lösbar als zu Zeiten der hierarchischen und Codasyl-basierten DBMSs, doch die Realität ist vom Nirwana weit entfernt.

Der SQL-Standard bedarf noch einer erheblichen Verbesserung, läßt viele der Möglichkeiten, die SQL-basierte Produkte auf dem Markt aufweisen, vermissen, und es gibt eine neue Version (SQL2), die sich wahrscheinlich nicht vor dem nächsten Jahrhundert komplett in Produkten niederschlagen wird. Und darüber hinaus stellt sie nur einen Ausschnitt der Dienste dar, die von typischen kommerziellen Anwendungen genutzt werden.

Dabei liegt das Problem nicht bei den heldenhaften Leuten, die an den Standards mitarbeiten; der Prozeß selbst ist brüchig. Der Versuch, einen "Konsens" (was "absolute Zustimmung" und nicht "Mehrheitsvotum" bedeutet) zu erreichen, wenn die in solchen Gremien dominierenden Anbieter stets die Produkte und Pläne, die sie selbst entwickelt haben, im Hinterkopf haben, ist schon eine enorm komplexe Angelegenheit.

Nichtsdestotrotz ist seit kurzem eine neue Welle des Interesses in der Anwendergemeinde zu beobachten: Ein neues Gremium, die User Alliance for Open Systems, versucht, sich von den von Anbietern dominierten Initiativen und proprietären Technologien zu lösen. Proprietäre Systeme wurden angeklagt, "die Anwender und Daten als Geiseln zu halten". Eine der Aktionen, die empfohlen wurden, ist, einen "Prozeß für die Anforderungen der Anwender" zu definieren, mit dem die Bedürfnisse der "Anwender" voraussichtlich in einen Satz von Standards, die besser sind als die augenblicklichen Standards, umgewandelt würden.

Auch hier steht ein hoher Grad an Aufrichtigkeit (und vielleicht auch etwas an tiefer Frustration) hinter diesen Aktionen, aber der Prozeß ist brüchig. Die Ironie liegt darin, daß kein Unternehmen jemals gezwungen wird, eine Technologie zu kaufen, die nicht in seine Architektur-Vision oder den Katalog für die Übereinstimmung mit Standards paßt. Darüber hinaus vermuten wir, daß die Hindernisse für die in vielen Unternehmen gewünschte Portabilität und Interoperabilität ebenso in ihren eigenen Kulturen, Organisationen und Entscheidungsfindungsprozessen zu suchen sind wie in der Technologie, die sie am Markt eingekauft haben.

Kommen wir zurück zu den Vorzügen für den Anwender. Die Vorteile der Offenheit sind Portabilität, Interoperabilität, Austauschbarkeit und eine größtmögliche Auswahl. Portabilität meint die Möglichkeit, eine Reihe von Anwendungen von einer Plattform zu nehmen und auf einer anderen ablaufen zu lassen.

Interoperabilität ist die Möglichkeit, einzelne Funktionen in getrennten heterogenen Umgebungen ablaufen zu lassen, um Daten sinnvoll zwischen diesen Plattformen auszutauschen. Austauschbarkeit meint eine besondere Form der Portabilität: Der Anwender könnte eine Anwendung entwickeln und mit verschiedenen darunterliegenden Plattformen erproben, um die Zuverlässigkeit und die Performance zu prüfen, und dabei besonders darauf zu achten, sich nicht auf einen Anbieter festzulegen. Und größtmögliche Auswahl bezieht sich auf die Möglichkeit, auf einer einzelnen Plattform eine große Auswahl von Herstellern zur Verfügung zu haben.

Was damit gesagt werden soll, ist, daß die Unternehmen die Frage der offenen Systeme wieder selbst in die Hand nehmen müssen.

Dazu müssen sie wieder zurückkommen auf ihre eigene Geschäftsinfrastruktur, ihre Entscheidungsfindungsprozesse und technologische Investitionen und sich selbst fragen: "Was hindert uns daran, die Geschäftsvorteile (Portabilität, Interoperabilität, Austauschbarkeit oder größtmögliche Auswahl) zu bekommen, die wir uns von einer Hinwendung zu Standards, offenen Systemen oder proprietären Umgebungen eines einzigen Anbieters versprochen haben?"

Bevor man überall über die Unternehmens-Connectivity zu sprechen begann, wurden die meisten Entscheidungen für Technologien unabhängig getroffen. Architektur, unternehmensweite gemeinsame Daten und Standards beeinflußten die Entscheidungsfindung nicht. Die Suche nach mehr Technologie, ob offen oder nicht offen, bringt nicht die erwünschte Kohärenz in eine Umgebung, die nicht integriert entwickelt wurde.

Oft reichen die Fragen über Protokolle hinaus. Viele Banken haben zum Beispiel Kundeninformationen mehrmals in verschiedenen Datenbanken definiert vielleicht sogar auf ein Lind derselben Plattform. SQL wird hier kaum Abhilfe schaffen, selbst wenn alle Anbieter gewissenhaft eine vollständige Version des augenblicklichen Standards implementiert haben.

Der Begriff "Offene Systeme" sollte wahrscheinlich aufgegeben werden. Er trägt nicht länger produktiv zu irgendwelchen Diskussionen bei. Und die Assoziation mit Unix ist historisch und irreführend. Die Einhaltung von Standards ist eine weit bessere Definition des Problems, aber in der Praxis werden Faktoren wie Übereinstimmung, Umfang, Exklusivität, zeitliche Koordinierung und Lock-in auf Niveaus oberhalb des Standards selbst zusammen das Wasser beträchtlich trüben. Jeder Anbieter, der mit offenen Systemen wirbt, sollte dazu aufgefordert werden, den Gebrauch des Begriffs genau zu erklären, damit potentielle Käufer evaluieren können, ob die Strategie zu ihren Zielvorstellungen und Plänen paßt. Aber die Käufer selbst sollten sich dessen bewußt sein, daß der Schlüssel zu offenen Systemen darin liegt, exakt zu definieren, welcher Aspekt der "geschlossenen" Welt dem Erreichen von Geschäftszielen entgegenstand, und welche Prozesse intern entsprechend geändert werden müssen. "Anbieter halten die Anwender gefangen" ist jedenfalls keine präzise Aussage zum wahren Problem.