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.

27.10.1989

Glanz und Elend bei der OSI-Normierung

Die Anwender müssen mit ins Boot des OSI-Normierungsprozesses, auch wenn sie dieses vielleicht nicht immer wollen. Doch selbst diejenigen, die von ihrer

Mitwirkungspflicht bereits überzeugt sind, handhaben ihr Ruder häufig nicht gerade

professionell, weshalb nicht klar erkennbar ist, ob diese kleine Gruppe der

OSI-engagierten User nun eigentlich beim Vorankommen des gemeinsamen Bootes

hilft oder hemmt.

Es gehört schon eine ganze Menge Manpower, Know-how und nicht zuletzt Unterstützung durch die Unternehmensleitung dazu, die Suppe auszulöffeln, die die Standardisierer im wohlverstandenen Interesse des Anwenders servieren. Die OSI-Architekten kommen nämlich in der Regel nicht aus der Praxis. Sie forschen und lehren an Hochschulen, sie tummeln sich in herstellerübergreifenden Gremien oder dokumentieren und ratifizieren in nationalen und internationalen Normierungsbehörden. Mit anderen Worten: Sie werden nicht dafür bezahlt, im Tagesgeschäft die Infrastruktur einer Unternehmenskommunikation aufrechtzuerhalten.

Der im Normierungsprozeß notwendigen Symbiose von Theorie und Praxis stehen also unter anderem sehr unterschiedliche Prioritäten und Erfahrungshorizonte der wesentlichen Protagonisten im Wege. Das stärkste Motiv der mehr oder weniger

OSI-engagierten Anwender ist eindeutig die Notwendigkeit klar definierter offener Standards und Schnittstellen für den wachsend Kommunikationsbedarf in einer von unterschiedlichen Proprietary-Systemen geprägten Unternehmenslandschaft. Multivendor-Installationen

sind gang und gäbe besonders dort, wo fusioniert wird - und wird nicht fusioniert?

Auch Anwender liefern bemerkenswerte Beiträge

Zwar liefern diese Anwender technisch nicht gerade den größten Input bei der Standardisierung, doch leisten einige bemerkenswerte Beiträge. Beispielsweise stellen sie sicher, daß die Anwenderbedürfnisse genau erkannt werden, speziell vom Timing her. Auch können sie die technischen und funktionalen Anforderungen am besten formulieren. Ein Beispiel eines derartigen Anwenders in der Bundesrepublik ist der Chemie-Gigant Hoechst. Der Konzern hat sich in geradezu firmenpolitisch bedeutsamer Weise für OSI entschieden. In Frankreich gibt es in Entsprechung dazu die Energieversorgungsunternehmen EDF/GDF;

sie verfolgen eine ähnliche Politik. Hinzu kommt der gewaltige Bereich der Öffentlichen Verwaltung, die sich unter dem Druck der EG-Ratsdirektive *) teilweise auch schon viel früher für die Verwendung von Normen - insbesondere von OSI - entschieden hat.

So richtig und untermauert die strategische Entscheidung für OSI gerade in Multivendor Umgebungen sein mag, so schwierig gestaltet sich ihre Umsetzung in Unternehmensrealität. Denn viele Applikationsprogramme sind heute technisch noch nicht auf Verteilung oder gar eine Multivendor-Umgebung vorbereitet. Das zeigt sich bei banalen Dingen, wie zu Beispiel Terminalzugriffen und endet bei konzeptionellen Fragen.

Diese Erfahrung hat jedenfalls "Ewos"-Repräsentant Ulrich Hartmann gemacht (siehe Was ist "Ewos"?). Aber gerade in diesen Anwendungen steckt ein großes Investment, und dieses in eine neue, standardisierte Welt hinüberzuretten, ist oft mehr als schwierig.

Bei Neuapplikationen sieht das ganz anders aus. Hier gibt es bereits genormte Verfahren und sie werden auch fleißig eingesetzt. Ein typisches Beispiel dafür ist Message-Handling aber auch FTAM (File Transfer). Ferner versprechen sich die europäischen OSI-Standardisierer im Bereich der verteilten Büroanwendungen einen relativ problemlosen Einstieg in die Welt offener Standards. Sie räumen indes ein, daß hier noch viel Zukunftsmusik gemacht wird.

Eine herkömmliche Migration findet nicht statt

Es deutet also vieles darauf hin, daß eine Migration im herkömmlichen Sinne nicht stattfinden wird. Vielmehr existiert die Tendenz, alles Neue gleich von vorneherein in offenen Standards aufzusetzen und die alten Proprietary-Anwendungen quasi austrocknen zu lassen.

Zentrale Bereiche der Normierung, wie zum Beispiel das Netzwerkmanagement, stehen zur Zeit im Mittelpunkt des Interesses von Betreibern großer Netze. Eine Ratifizierung dieses Standards wird für 1992 erwartet. Das komplexe Thema, das zudem nur von wenigen Spezialisten beherrscht wird, erfährt eine besonders langwierige Behandlung in den Gremien.

Dennoch sollten die Anwender nicht verzweifeln. Hoffen läßt eine Herstellerinitiative, die bereits im Vorfeld der Ratifizierung eine Annäherung ihrer unterschiedlichen Aktivitäten auf diesem Feld beabsichtigt. Diese Vereinigung macht zur Zeit unter der Bezeichnung Networkmanagement-Forum von sich reden. Eine der treibenden Kräfte ist Hewlett-Packard, mit von der Partie sind Amdahl AT&T, STC, British Telecom, Northern Telecom und andere mehr.

"Nist" flirtet mit Netzwerk-Forum

Bisher sind jedoch die beiden Schlüsselunternehmen DEC und IBM dem Forum noch nicht beigetreten das auf der Basis von bereits bei der ISO vorhandenem Netzwerkmanagement-Spezifikation erstellen und pilotartig implementieren und demonstrieren will.

Die Fachwelt schaut - wie das Kaninchen auf die Schlange - auf dieses Networkmanagement-Forum. Testorganisationen wie "Spag" und COS haben vor, die Forum-Spezifikationen zu testen. Auch der US-amerikansche Normierungsworkshop "Nist" (National Institute of Standards and Technology) flirtet dem Vernehmen nach mit dem Forum. Dem Anwender kommt in diesem Spiel vorerst nur die Rolle des Beobachters zu; er kann bei der geforderten Feinspezifizierung kaum mitwirken, jedoch ist das Netzwerkmanagement aufgrund seiner Komplexität im Normierungsprozeß ein spezieller Fall. Das jetzt zu registrierende gemeinsame Vorgehen mehrerer Hersteller zur Unterstützung dieses Prozesses ist deshalb aus Sicht des "Ewos"-Mitgliedes Ulrich Hartmann, der die Forumsaktivitäten nur am Rande verfolgt, bei Standardisierungsarbeiten, wie "Ewos" sie vorantreibt, nicht notwendig.

Ziel: Alle Systeme werden OSI-Systeme

Von einer schönen Vorstellung muß sich, so Hartmann, der hoffnungsvolle Anwender jedenfalls befreien, nämlich der, man könne an einem Silvesterabend von einer SNA- oder auch Transdata-Installation mit einem Handgriff auf OSI umschalten. Das wird nicht stattfinden. Hingegen bietet sich an, bestehende Proprietary-Inseln über OSI miteinander zu koppeln. Derartige Kopplungen existieren zur Zeit häufig noch auf der Basis einer Herstellerarchitektur. Doch kann man hier relativ einfach mit OSI beginnen, um diese Inseln dann schrittweise zu penetrieren; auf lange Sicht könnten die Inseln immer kleiner werden. Im Idealfall werden schließlich alle Systeme OSI-Systeme, so die Zielvorstellung.

FTAM gleich auf Basis von DSI installieren

Aber überall, wo enge Applikations- und Verfahrenskopplungen bestehen, wird der Einzug von OSI langsamer vonstatten gehen als sozusagen "von den Rändern" aus. Allerdings versprechen einige Anwendungen den Einzug von OSI mehr als andere zu beschleunigen zum Beispiel FTAM, eine klassische Anwendung, die man künftig gleich auf der Basis von OSI installieren kann. Auch der Einsatz von Workstations, die auf zentrale Server zugreifen, zum Beispiel für Drucker- und Ablagefunktionen, also typische neue Applikationen, sind für OSI prädestiniert, schon deshalb, weil sie in neue organisatorische Strukturen hineinwachsen. Auch für den Ablageservice wird jetzt eine OSI-Norm vorbereitet, die allerdings noch nicht ganz stabil ist und auch der Druckerservice steht bei der ISO im Arbeitsplan.

Hinreichendes Vertrauen erforderlich

Nun ist die Bearbeitung und Verabschiedung von Standards eine Sache, fertige Produkte eine andere. Vom Vorliegen eines Draft-International-Standards, also einer einigermaßen stabilen Spezifikation, bis zum fertigen Produkt vergehen zirka zwei Jahre. Schließlich müssen die Produktplaner ein hinreichendes Vertrauen in den Stabilitätsgrad eines Standards haben, genauso wie der Anwender, der auch nicht auf OSI setzt, wenn er befürchten muß, daß der Standard instabil und damit das Produkt unausgereift

ist. Hinzu kommt, daß - parallel zur Produktentwicklung kann dieses geschehen - Profile

entwickelt werden müssen. "Ewos"-Mann - Hartmann geht von Produktentwicklungszeiten

"von einem Jahr allemal" aus.

Immerhin sind bereits etliche Produkte vorhanden und werden durchaus angewandt, so ist Message Handling beispielsweise längst im Markt, ferner FTAM. Schwierig dagegen ist es in Europa mit dem Thema Virtual Terminal. Bei Transaktion Processing ist mit zirka einem weiteren Jahr bis zum Abschluß der Profilarbeit zu rechnen. Ähnlich sieht es bei Distributed Office Applications aus. Das Thema Directory, das orthogonal zu allem liegt, dürfte jedoch relativ bald vom Tisch sein.

Druck auf den Markt durch EG-Beschaffungsrichtlinien

Probleme bereitet die Vermarktung von OSI-Produkten. Druck durch EG-Richtlinien für Beschaffungsmaßnamen bewirkt sicherlich eine höhere Aufmerksamkeit, ja Akzeptanz bei den öffentlichen Verwaltungen. Für Unternehmen der privaten Wirtschaft sind diese Richtlinienien doch nicht maßgebend. Auch kann der zweifellos auch dort vorhandene große Bedarf nicht darüber hinwegtäuschen, daß, obwohl einige OSI-Produkte im Markt sind, "die Nachfrage danach an der einen oder anderen Stelle noch sehr zu wünschen übrig läßt", wie Hartmann bedauernd einräumt.

Dennoch seien für diese potentielle Kundenschicht aus der privaten Wirtschaft derartige Beschaffungsrichtlinien und ergänzende nationale Festlegungen auch wichtig. Sie könnten "zwangsweise Markt" etablieren.

Warten auf Gatewayprodukte

Experten sprechen davon, daß ungefähr 20 Prozent des Marktes für Informationstechnik in Europa auf die "Öffentliche Beschaffung" entfällt. Ein solcher großer Marktanteil wäre schon in der Lage, OSI einen gewaltigen Schub zu geben. Würde dieses Fünftel geschlossen in Richtung OSI marschieren, dann hätte dies auf alle Anwender von Informations- und Kommunikationssystemen erhebliche Auswirkungen, auch auf solche Zeitgenossen, denen es letztlich gleichgültig ist, auf welche Art und in welchem "Standard" sie kommunizieren. Wenn es OSI-Produkte sind, die ihnen das Leben leichter machen, dann werden sie diese nehmen, vermutet Hartmann. Gerade sie seien wahrscheinlich ein großer Teil der verbleibenden nicht öffentlichen Anwender. Viele auch warten, weil sie auf einer bestimmten Herstellerarchitektur quasi festsitzen, daß der Markt zu ihnen hinüberkommt beispielsweise mit Gatewayprodukten.

An ein herstellerübergreifendes Marketing, so wünschenswert dieses aus Sicht der Anwender gerade bei OSI wäre, glaubt Workshop-Koordinator Hartmann nicht, abgesehen von Initiativen wie "Spag" oder Demonstrationsprojekten. Je näher man an die Produkte herankommt, desto schwieriger nämlich wird es, zu konsolidierten Aktionen der Hersteller zu kommen.

Bleibt dem Anwender zunächst einmal nichts anderes übrig, als sich auf hoffentlich gut getestete Produkte zu verlassen. Gerade Interoperability-Tests werden deshalb mit dem Aufkommen normkonformer Produkte immer wichtiger. Kaufte früher der Anwender seine Produkte aus einer Hand, so konnte er sich meist auf deren Stimmigkeit verlassen. Diese "Systemintegratorfunktion" entfällt, wenn er künftig seine Produkte genormt und perfekt getestet im Laden um die Ecke einkauft.

Testen ist deshalb enorm wichtig, gleichzeitig aber schwierig und nicht zuletzt sehr teuer. Der Anwender kann zwar auf der einen Seite mit einer Kostendegression durch die normkonformen Produkte rechnen, weil eben mehr Wettbewerb stattfindet.

Testkosten nicht vernachlässigen

Die Testkosten sind indes, jedenfalls in der Anlaufphase und darin befinden wir uns nicht zu vernachlässigen. Noch sind sie sehr hoch; es wäre unfair, dieses zu verschweigen. Ein Netz von OSI-Prüflabors ist bereits installiert und die Tests laufen langsam aber sicher an.

Viel ist in letzter Zeit von der "Festung Europa" zu hören. Gerade in einer weltweiten Kommunikationslandschaft sollte es jedoch keine derartigen Abschottungen geben. Der Europäische Workshop for Open Systems hält deshalb mit koordinierenden Aktivitäten gegen dieses von Nicht-Europäern häufig vertretene Vorurteil. Um weltweite Spezifikationen neben den regionalen zu unterstützen, hat "Ewos" zusammen mit dem "Nist"-Workshop und dem entsprechenden süd-ostasiatischen Workshop einen zweistufigen Konsensbildungsprozeß etabliert, der einerseits die regionale Ebene berücksichtigt, andererseits in einem "Regional Workshop Coordinating Committee" die Ergebnisse zusammenführt. Ein Vorteil dieser Workshop-Organisation ist, daß viele Anwender, die Hochschulen aber auch kleine Beratungsunternehmen an dem Normierungsprozeß zumindest auf regionaler Ebene teilnehmen können und nicht durch hohe Kosten daran gehindert werden.

Das zweistufige Vorgehen hat ermöglicht, daß es in Europa bereits eine Reihe von Vornormen (ENVS) gibt. Für die neuen Themen ist, Hartmann zufolge, bereits jetzt eine sehr enge Zusammenarbeit der drei Workshops verabredet. Für ihn steht fest, daß man gleichzeitig sowohl regional als auch überregional normieren kann. Letzteres war von Anfang an Gegenstand der "Ewos-Carta". *

*) Beschluß des EG-Rates vom 22. Dezember 1986 über die Normung auf dem Gebiet der Informationstechnik und der Telekommunikation (87195/EWG).