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.

25.09.1992

Die Unabhängigkeit des Anwenders bleibt Vision

Konrad Sommer Leiter Informationstechnologie-Zentrum Offene Systeme, Bull AG, Köln

Nun glaubten wir, es endlich geschafft zu haben, mag mancher Anwender behaupten, der sich jahrzehntelang über schwerfällige und zumeist überteuert anbietende Hardwarehersteller geärgert hatte. Endlich gab es die offenen Systeme, welche dem Anwender die große Freiheit bescheren sollten. Tatsächlich ist nicht von der Hand zu weisen, daß die meisten Hardwarebauer in der Blüte ihrer Geschäftsentwicklung ein Verhalten an den Tag legten, das nur unter den typischen Bedingungen eines oligopolistischen Verkäufermarktes funktionieren konnte.

Vor diesem Hintergrund ist der kontinuierliche Versuch der Mainframer zu sehen, sich und ihren Kunden die Unix- und PC-Welt so lange wie möglich vom Hals zu halten. Letztlich war der Gedanke der Herstellerunabhängigkeit im Sinne von Entscheidungsfreiheit bei der Hardware-Auswahl für alle Marktteilnehmer etwas Neues. Zwar versuchten die meisten Anbieter, sich durch aktive Auseinandersetzung mit dem Thema über mögliche Chancen und Risiken Klarheit zu verschaffen. Doch letztlich war es einfach bequemer, in einer Art kollektiver Ignoranz darauf zu beharren, daß einmal errungene Pfründen nicht einfach durch eine Modeerscheinung wie Unix in Gefahr zu bringen sein dürften.

Nur den wenigsten Hardware-Anbietern ist es in dem zwischenzeitlich entstandenen Überlebenskampf gelungen, sich rechtzeitig auf die kontinuierliche und an Markterfordernissen orientierte Entwicklung des Software- und Servicegeschäfts zu konzentrieren. Für viele von ihnen wird ihre Fähigkeit, sich von den eigenen Produkten und deren Entwicklung, Fertigung und Vermarktung sukzessive zu trennen und statt dessen in der Frage des Make or Buy bis zum Level des Einzelprojekts hinunter immer häufiger für den Zukauf von Produkten und Leistungen zu entscheiden, von entscheidender Bedeutung sein.

Die besten Voraussetzungen zum Überleben haben dabei jene, die nicht nur die richtigen Bezugsquellen zur rechten Zeit kennen, sondern insbesondere die komplizierte Klaviatur technischer, ökonomischer und juristischer Schnittstellen kennen.

Bei technischen Standards und Normen gilt es, institutionalisierte Normen mit hauseigenen und De-facto-Schnittstellen-Standards bei kalkulierbarem Risiko innerhalb eines Projekts zu mischen. Bei diesem Bemühen ist die Verabschiedung und Durchsetzung standardisierter Schnittstellen auf der Ebene der Hardware, der Betriebssysteme und der Tools förderlich.

So sehr man in dieser Situation für die Hardwarehersteller aufkeimende Vorteile durch die fortschreitenden Standardisierungsaktivitäten identifizieren kann, so sehr muß letztlich auch die Frage nach dem effektiven Nutzen dieser Standards für den Anwender gestellt werden. Dieser ist sicherlich gut beraten, sich nicht auf die unter Herstellern und in der Presse heftig geführten Diskussionen über Technologien des Typs CISC oder RISC einzulassen, zumal hier mit dem Intel P5 in Form der sogenannten CRISC-Technologie schon wieder ein neuer Möchtegern-Standard am Horizont erkennbar ist.

In einem von den Anforderungen der Anwendungslösung bestimmten Umfeld kann und darf die Mikroprozessortechnologie nicht das ausschlaggebende Kriterium sein. Ähnliches gilt prinzipiell für die Bestimmung des Basis-Betriebssystems.

Hier sollte es den nach Lösungen suchenden User mittlerweile nicht mehr interessieren, ob das von ihm eingesetzte Betriebssystem OSF/1, Unix oder AIX heißt. Ebenso sind fruchtlose Diskussionen über Vor- und Nachteile von V.3 gegenüber V.4 beziehungsweise Mach- versus Chorus-Kernel im Hinblick auf die Lösung eines gegebenen Problems eher als kontraproduktiv zu bewerten. Wer bei der Auswahl der geeigneten Betriebssystem-Basis heute Sicherheit gewinnen will, der zieht sich am besten auf die gerade in diesem Umfeld gegebenen Standards, also auf den X/Open Portability Guide beziehungsweise die entsprechenden Posix-Normen des IEEE, zurück.

Wer seine Lieferanten langfristig auf diese Standards eicht und darüber hinaus bereit ist, sich auch noch selbst aktiv mit den Inhalten dieser Standards auseinanderzusetzen, der kann sich getrost aller Diskussionen über heutige Möchtegern- und zukünftige Wäregern-Standards entziehen.

Problematischer wird die Situation allerdings auf der Ebene der Tools. Hierunter sind vorwiegend solche Systemsoftware-Produkte zu verstehen, welche die Schnittstelle zwischen einer gegebenen Anwendung und dem Betriebssystem realisieren, also Datenhaltungssysteme Benutzer-Schnittstellen, Transaktionsmonitore, Netzwerk- und CASE-Produkte. Hinsichtlich dieser Komponenten gewann der Anwender mit zunehmender Unabhängigkeit vom einzelnen Hardwarehersteller auch eine gößere Wahlfreiheit hinsichtlich der Auswahl der von ihm präferierten Einzel-Tools nicht zuletzt deshalb, weil die genannten Tools ihrerseits portabel und damit auf unterschiedlichen Hardware- und Betriebssystem-Plattformen verfügbar sind.

Leider haben viele Anwender ihre Probleme im Umgang mit dieser Wahlfreiheit. Zum einen fehlt es meistens an verbindlichen Kriterien und entsprechenden Erfahrungen, um zu beurteilen, welches Datenbanksystem, welches CASE-Environment oder welches der gerade als standardisierungswürdig diskutierten Benutzer-Interfaces denn nun für ein bestimmtes Projekt tatsächlich die geeigneten sind. Zum anderen wird, wie aktuelle Beispiele im Umfeld der Objektorientierung oder der Multimedia-Verarbeitung zeigen, auf der Tool-Ebene noch heftigst darüber gestritten, was bereits ein Standard ist und wer vielleicht zukünftig einen bauen könnte.

Letztlich verbirgt sich hinter jedem Tool aus innovativem Hause ein nicht zu unterschätzendes Risiko, sowohl für das Tool, als auch für dessen Erzeuger. Andererseits entsteht trotz aller sich auf diesem Gebiet abzeichnender Standards und Normierungsaktivitäten bei jeder Auswahlentscheidung auch eine neue Abhängigkeit. Für den konsequent in Richtung offener Systeme planenden Anwender ändert sich eigentlich nicht viel, da er letztlich nur die bisherige Abhängigkeit von einem Hardwarehersteller durch eine entsprechende von seinen Tool-Lieferanten austauscht.

Ob in dem sich hier ergebenden Anbieterumfeld, das an Dynamik und sich daraus ergehendem Chaos kaum mehr zu überbieten ist, eine kostenminimierende und flexibilitätssteigernde Wahlfreiheit für alle Anwender zu erlangen ist, darf auf die Dauer durchaus bezweifelt werden.

Immerhin bietet sich in diesem Umfeld eine neue Einsatzchance für die bisherigen Hardware-Anbieter: Wer es versteht, die durch die geschilderten Sachverhalte beim Anwender entstehende Verunsicherung aufzugreifen und in ein quasiunabhängiges und auf eigener Projekterfahrung basierendes Beratungsangebot umzumünzen, steht dem Markt vielleicht nicht mehr vorrangig als Boxenlieferant, jedoch als durchaus ernst zu nehmende Entscheidungs- und Umsetzungsgehilfe zur Verfügung.