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.

Offenheit versus Herstellerbindung

06.05.1988

Gibt es angesichts des weltweiten Standardisierungstrends auch einen Bedarf für SAA-Kompatibilität?

Das SAA-Konzept wird seit der Ankündigung im März vorigen Jahres mit Blick auf die Realisierungschance sehr konträr beurteilt. Den hohen Stellenwert in der Diskussion verdankt dieses Konzept allein der Tatsache, daß es aufzeigt, was der IBM-Anwender dringend braucht, aber bei IBM nicht bekommt.

Bei allem Zweifel, den Software- und Marktstrategien über SAA in den vergangenen zwölf Monaten verbreiteten, hat dieses IBM-Papier für den Markt auch positive Aspekte. IBM akzeptiert nämlich mit der Vorstellung dieses Konzeptes die Forderung nach portabler und - vom PC bis zum Mainframe - durchgängiger Software sowie die Notwendigkeit, unter Einbeziehung zentraler DV-Bereiche zu dezentralisieren. Gleichzeitig bestätigt die IBM mit SAA die Bedeutung der relationalen Datenbanktechnik.

Obwohl SAA wenig auf offene und standardisierte Schnittstellen setzt, wird diese Strategie den Trend zu herstellerunabhängigen Standards beschleunigen. Einige Elemente von SAA wie die Programmiersprachen C, Cobol und Fortran oder die Datenbankschnittstelle SQL bestätigen und nutzen den Standardisierungstrend.

SAA war kaum angekündigt, schon wurden die Vertriebsbeauftragten der Computerhersteller von den Anwendern nach "SAA-Konpatibilität" ihrer Produkte befragt - was immer das heißen mag.

Für einige Monate schien IBM, die mit dem Aufkommen der DV-Standardisierung ihren Einfluß schwinden sah, mit der SAA-Ankündigung gewohnte Abhängigkeitsverhältnisse wieder herzustellen. Mittlerweile weiß der Markt die SAA-Strategie besser einzuschätzen und erkennt, daß "SAA-Kompatibilität" nur bei Funktionen sinnvoll ist, die weitgehend herstellerunabhängig sind und zu einer breiten Marktakzeptanz führen. Identifizierbare Komponenten sind das Betriebssystem OS/2 sowie die Funktionalität des Presentation Managers und des LAN-Managers auf der Workstation-Ebene. Die Integrationsfähigkeit dezentraler Systeme in die Netzwerkarchitektur von SAA, also SNA, LU6.2, das Protokoll für "peer-to-peer"-Kommunikation oder DCA/DIA, ist heute bei nahezu allen großen Herstellern verfügbar.

So betrachtet haben die Themen SAA und Kompatibilität zu einem von vielen Beobachtern in Frage gestellten Zukunftskonzept an Brisanz vorloren. Denn eines ist unzweifelhaft: Künftige Informationstechnologien sind geprägt durch Offenheit. Die Produktstrategien vieler Computerhersteller folgen dem weltweiten Trend zu offenen Systemen mit herstellerneutralen Schnittstellen für Betriebssystem, Datenhaltung, Programmierung, Kommunikation und Benutzeroberfläche. Und die Basis ist durchweg Unix, das heißt konkret X/Open.

Parallel zu dieser Entwicklung sorgte die IBM mit SAA-Verlautbarungen im Markt für Verwirrung und bediente sich einer Darstellung, die sich verblüffend eng an die Argumentation von X/Open anlehnt. So ist verständlich, daß sich einige Kommentatoren veranlaßt sahen, die SAA-Idee mit dem X/Open-Konzept zu vergleichen - Offenheit versus Bindung. Um es vorweg zu nehmen: Das Ziel von X/Open ist Herstellerunabhängigkeit. Die Konsequenz der IBM/SAA-Strategie bedeutet für den Anwender langfristige Herstellerbindung in einer geschlossenen IBM-Welt.

SAA könnte der Aufbau marktstrategischer Barrieren sein - zum Beispiel zugunsten von DB2 gegen Third-Party-Datenbanken oder gegen konkurrierende Verteilungsarchitekturen, die durchgängig auf einem einheitlichen Betriebssystem und einer einheitlichen Anwendungsumgebung bestehen. Gleichzeitig ist es der Versuch, ein IBM-Problem zu lösen und die heute extrem heterogene und inkompatible Produktlandschaft der IBM irgendwann einmal zu homogenisieren.

Ein erster Schritt ist, bestimmte Produkte in dem Hardware- und Software-Wildwuchs der IBM (zum Beispiel zehn verschiedene Rechnertypen und fast ebenso viele Betriebssysteme) als "nicht-strategisch" auszugrenzen und andere als "strategisch wichtigen" zu positionieren. Und hier beginnt bereits die Unsicherheit und Abhängigkeit für den Anwender und für die Software-Industrie.

X/Open ist offener als SAA und vor allen Dingen eindeutig. Da ist kein Platz für individuelle Interpretationen. X/Open unterstützt jeden Hersteller, der dem Portability-Guide folgt und die offene Systemumgebung bereitstellt, die portable Anwendungen unterstützt. Zudem bietet X/Open Portabilität auf Betriebssystemebene. Sämtliche X/Open-Definition sind internationale Standards oder De-facto-Standards und wurden nicht von einem einzigen Hersteller diktiert. Im SAA-Konzept dagegen sind Betriebssysteme, Softwarewerkzeuge sowie Netzwerk- und Kommunikationskomponenten überwiegend IBM-spezifisch. Der allgemeine Markt hat keinen Zugriff.

Der Großteil der mit SAA beschriebenen Softwarebausteine entstammt der IBM-Mainframewelt und ist auch nur dort verfügbar. Der Anspruch von SAA, durch einheitliche Softwareumgebungen auf den drei Ebenen Mainframe, Abteilungsrechner und Workstation zukünftig portable Anwendungen zu ermöglichen, ist einerseits aufgrund der Historie der einzubindenden Produkte höchst fragwürdig und andererseits aufgrund der mangelnden Erfahrung im dezentralen Bereich auch sehr unsicher. Durch die unklare Produktpolitik der IBM im DDP-Bereich und durch die Betriebssystemvielfalt auf der mittleren Ebene werden die Anwender zusätzlich verunsichert.

Der zentralistisch orientierte Ansatz der SAA-Strategie mag einerseits attraktiv sein für zentrale DV-Organisationen. Andererseits steht dieses Konzept im krassen Gegensatz zum Trend offener Systeme mit herstellerunabhängigen Standards in der dezentralen Informationsverarbeitung.

Dennoch ist angesichts der unverträglichen IBM-Produktwelt verständlich, daß Anwender sich für SAA begeistern können. Aber SAA besticht nur auf den ersten Blick. Je mehr man sich mit diesem Konzept beschäftigt, desto fragwürdiger wird die Realisierung. SAA birgt massive Schwächen und Risiken:

- Herstellerabhängigkeit und Mainframe-Orientierung;

- unklare Produktstrategie für die mittlere Ebene;

- Komplexität für dezentrale Anwendungen;

- inhaltliche Unvollständigkeit und unklare zeitliche Verfügbarkeit;

- geringer Innovationsgrad.

Ein Problem liegt zum Beispiel in der unterschiedlichen Implementierung von SAA-Komponenten oder in der Vielfalt unverträglicher Betriebssysteme. Jeder Softwaretyp erzeugt fixe Kosten, da einerseits das Wissen darüber im Unternehmen gehalten werden muß und andererseits Schnittstellen-, Wartungs- und Tuningprobleme für jedes einzelne Produkt erneut auftreten. Aus wirtschaftlichen Gründen sollte es daher ein Ziel sein, möglichst nur ein einziges Betriebssystem zu unterstützen.

Als Fazit bringe ich das Thema "SAA-Kompatibilität" auf den Punkt: Die Hardware- und Betriebssystemabhängigkeit der meisten SAA-Komponenten, die Mainframe-Orientierung der Software-Tools und Architekturen sowie die ungewisse Verfügbarkeit konsistenter Versionen machen es zu diesem Zeitpunkt nicht sinnvoll, neben den oben erwähnten, eindeutigen Standardisierungsbereichen weitere Einschätzungen hinsichtlich potentialer Kompatibilitätsfelder abzugeben. Noch ist SAA nur eine wolkige Strategie mit zu vielen unbeantworteten Fragen. Produkt- und Praxisbeweis stehen ohnehin noch aus.