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.

23.11.1990 - 

Ein offenes Betriebssystem ist lediglich die halbe Miete

Auf der Ebene der Anwendungen sind Standards noch Zukunftsmusik

MÜNCHEN - Der Name Unix galt lange als Synonym für "offene Systeme" Doch immer deutlicher tritt zutage, daß sich diese Offenheit nicht auf die Betriebssystemebene beschränken läßt. Folglich wurden und werden Standards für den Datenzugriff, das Netzmanagement und die Benutzerschnittstelle entwickelt; auf der Ebene der Anwendungen hingegen tut sich in dieser Hinsicht bislang wenig; dort herrschen immer noch geschlossene Systeme vor.

"Auch die Anbieter von Standardsoftware müssen lernen, was Offenheit bedeutet - nicht nur die Hardwarehersteller", so forderte Reinhold Thurner, Geschäftsführer der Delta Software Technologie AG in Schwerzenbach bei Zürich, kürzlich auf dem diesjährigen Software-Forum der IDG-CSE in München. Damit brachte der Schweizer auf den Punkt, was über dem immer noch schwelenden Unix-Streit nur zu oft vergessen wird: Ein offenes Betriebssystem stellt an und für sich noch lange kein "Offenes System" dar.

Nahezu jeder Hersteller in der DV-Welt versucht derzeit, seinen Umsatz zu steigern, indem er sein System als "offen" deklariert. "Wer etwas verkaufe n will, muß behaupten, daß er ein offenes System hat", bestätigt Werner Andraschko, DV-Koordinator im Geschäftsbereich Wehrtechnik der Krauss-Maffei AG, München, "denn wer kauft schon ein geschlossenes System - mal abgesehen von den integrierten Paketen!"

Es gibt also nicht nur eine Nachfrage, sondern sogar eine explizite Forderung nach offenen Systemen von seiten der Kunden. "Wir wollen offene Systeme keineswegs als Selbstzweck", begründet Thomas Kahlhardt, Hauptabteilungsleiter für Organisation beim Gerling-Konzern in Köln, diesen Anspruch, "sondern aus handfesten betriebswirtschaftlichen Gründen", als da wären: günstige Preise aufgrund erweiterter Konkurrenz und höhere Sicherheit in bezug auf die technologische Weiterentwicklung.

Hardwareproduzenten auf der einen und Software-Anbieter auf der anderen Seite bezeichnen mit dem Begriff "offenes System" zwei verschiedene Sachverhalte: Verstehen die einen darunter zumeist eine Maschine, auf der Unix oder eines seiner Derivate ablaufen kann, so meinen die anderen eine Software-Architektur, die es erlaubt, gewisse - nach den Architektur-eigenen Regeln erstellte - Anwendungen relativ problemlos von einer Umgebung in eine andere zu übertragen.

In beiden Fällen verdienen die so bezeichneten Systeme das Etikett "offen nur mit mehr oder weniger großen Einschränkungen. Zwar gilt Unix nach wie vor als der Prototyp eines offenen Betriebssystems; doch ist ein Unix-Derivat von DEC oder HP/Apollo keineswegs von kompatibel zu einer Unix-Ausführung von IBM oder Siemens-Nixdorf. Die Ursachen für diese Portabilitätsprobleme liegen vor allem in den herstellereigenen Add-on-Funktionen begründet.

Ansätze zur Lösung werden bereits diskutiert: So geistert seit einiger Zeit der Begriff des Application Binary Interface (ABI) durch die Branche. Mit Hilfe einer solchen Standardschnittstelle wäre es möglich, Anwendungen eins zu eins im Binärcode zu portieren. Die Vorschläge, wie sie bereits vom 88 Open Consortium sowie von Santa Cruz Operations vorgestellt wurden, beziehen sich allerdings immer nur auf jeweils einen Prozessortyp (Motorola 88 beziehungsweise Intel 386/486).

Darüber hinaus darf nicht vergessen werden: Auch wenn Unix vielfach als das Betriebssystem der Zukunft tituliert wird, mag wohl niemand zu behaupten wagen, daß in absehbarer Zukunft alle DV-Anwendungen auf ein und dem selben Betriebssystem ablaufen können. "Im Großrechnerbereich sind proprietäre Systeme weiterhin im Einsatz", konstatiert Hermann Lossau, Referent für Informationstechnik in der Staatskanzlei des Landes Nordrhein-Westfalen, "und sie werden es wegen des hohen Umstellungsaufwandes wohl auch noch längere Zeit bleiben."

Die Verbindung zwischen den Unix-Systemen und den Großrechner-Anlagen muß derzeit noch auf der Ebene des Netzmanagements gesucht werden. "Eine Chance" sieht Lossau in Kommunikationsprotokollen wie den von der International Standards Organization (ISO) normierten Funktionen X.400 oder FTAM. "Weitergehende Ansätze wären natürlich wünschenswert", räumt der Düsseldorfer ein, "sie sind zur Zeit aber in ihren Strukturen noch nicht erkennbar."

Auf der Softwareseite hat fast jeder der großen Anbieter innerhalb der letzten Jahre die Integration seiner unterschiedlichen Produkte in einer "offenen" Umgebung angekündigt. Beispiele hierfür sind SAA von IBM, CA 90s von Computer Associates, ISA von der Software

AG und OSE von Oracle. Aufgrund ihrer schichtweise aufgebauten Architekturen sollen diese Umgebungen dem Kunden die Portierung seiner Anwendungen erleichtern.

Genau genommen handelt es sich dabei jedoch einmal mehr um geschlossene Systeme, deren Offenheit sich im allgemeinen auf die herstellereigene Produktwelt beschränkt. Fremde Software kann nur sehr sporadisch eingebunden werden meist dort, wo der Anbieter eine Lücke bei den eigenen Entwicklungen ausgemacht hat. Kahlhardt: "Wenn ich zum Beispiel Oracle einsetze, begebe ich mich wiederum in eine proprietäre Welt, nämlich die des Oracleeigenen Entwicklungssystems."

Was aber ist eigentlich ein "Offenes System?" Wer eine Antwort auf diese Frage sucht, dem begegnet zunächst eine Reihe von Schlagworten: Durchgängigkeit, Herstellerunabhängigkeit, Portabilität, Connectivity, Standardisierung etc.

Versuche einer präzisen Definition sehen sinngemäß etwa so aus: Offene Systeme sind Systeme, die problemlos mit anderen Systemen, auch Systemen anderer Hersteller, kommunizieren können - und zwar in beiden Richtungen und ohne Schnittstellenprogramme. "Ein Schnittstellen-Programm ist nämlich immer ein Engpaß", moniert der Münchener DV-Manager Andraschko.

Voraussetzung für die Kommunikationsfähigkeit von DV-Systemen ist, so erklären Anbieter, Anwender und Analysten übereinstimmend, die Existenz von "offenen" Standards. Solche Standards können von einem der internationalen Normierungsgremien wie ISO, IEEE oder X/Open formuliert werden oder sich aufgrund der Lizenzpolitik eines Herstellers am Markt durchsetzen (System V von AT&T oder NFS von Sun); in bezug auf das Ergebnis ist die Entstehungsgeschichte einer international akzeptierten Norm wenig relevant.

Einen ambivalenten Fall stellen allerdings diejenigen Produkte dar, die ihren Status als "Standard" nur aufgrund ihrer großen Verbreitung im Markt erlangt haben. Zwar konnte sich der Microsoft-Intel-PC auf diesem Weg zu einem echten "lndustriestandard mausern, der den Kunden Angebote mit gutem Preis-Leistungs-Verhältnis bescherte. Andere IBM-Produkte (/370-Welt) oder auch die integrierten Pakete der SAP werden hingegen als "Standards" bezeichnet, ohne deswegen auch offen zu sein.

Tatsache ist, daß die in den Anwenderunternehmen realisierten Informationssysteme derzeit allesamt höchstens in Teilbereichen offen sind. Komponenten, die sich an weltweite Normen anlehnen, stehen herstellerspezifischen Produkten gegenüber. "In dieser Hinsicht wäre es ideal, wenn man alles aus einer Hand beziehen könnte", meint Andraschko, "aber dafür müßte man zu viele Konzessionen machen."

Wie die Realität in den Betrieben aussieht, schildert Rainer Hochkoeppler, Projektleiter Klinische Forschung bei der Hoffmann-La Roche AG in Basel: "Jedes System ist ein komplexes Konstrukt, basierend auf einer Hardwareplattform, auf der ein bestimmtes Betriebssystem sitzt, unter dem ein Datenbank-Managemt-System läuft, auf dem wiederum Anwendungen programmiert werden. Dieser Turm von Software ist eine in ihrer Gesamtheit absolut nicht standardisierte Konstruktion."

Wie Kahlhardt ergänzt, wird sich daran in absehbarer Zeit auch nichts ändern. "Die Vision einer völligen Unabhängigkeit läßt sich nicht verwirklichen", prophezeit der Organisationsleiter des im X/Open-Anwenderbeirat vertretenen Versicherungsunternehmens. "Es kommt allerdings darauf an, die Abhängigkeit mit Hilfe weltweit akzeptierter Standards nach und nach auf ein Minimum zu reduzieren."

In Hinblick darauf ist in den vergangenen Jahren sicher allerhand erreicht worden: Die von der ISO verfolgte Idee einer Open Systems Interconnection (OSI) nimmt allmählich Gestalt an, für viele Ebenen der Informationssysteme wurden bereits Standard-Schnittstellen definiert - so für Betriebssysteme (Posix) und Datenbankzugriff (Ansi-SQL) -, auf der Ebene der Benutzeroberfläche gibt es eine ganze Reihe von Normierungsvorschlägen, und X/Open bemüht sich um eine über die Betriebssystemebene hinausgehende "Common Application Environment" (CAE).

Zwischen User-Interface und Datenbankebene befindet sich jedoch nach wie vor ein Normen-Vakuum, eine Schicht, die, so Hochkoeppler, "sehr problematisch ist", nämlich die Schicht der eigentlichen Anwendungen. "Diese Schicht ist heute weit entfernt davon, standardisiert zu sein", bestätigt der Basler.

Vordergründig muß hier zunächst zwischen den selbstentwickelten und den fertig gekauften Anwendungen unterschieden werden: Während das Standardisierungsproblem bei reinen Eigenentwicklungen unternehmensintern lösbar ist, leiden die DV-Abteilungen oft erheblich unter der mangelnden Offenheit der integrierten Pakete oder "Standard-Software", also unter den Schwierigkeiten, fremde und eigene Programme zu verbinden.

Erläutert Thurner: "Wenn der Anwender sich heute für ein bestimmtes System entscheidet, verschreibt er sich ihm mit Leib und Seele - bis hin zur Datenhaltung." Sollte der Kunde eine Änderung vornehmen wollen, so müsse er sich "in die Schlange des Herstellers einreihen" und diesem die Entscheidung überlassen, ob die Änderung sinnvoll sei oder nicht. (Vergleiche hierzu auch CW Nr. 37 vom 14. September 1990, Seite 7: "Thema der Woche".)

Trotz dieses Leidensdrucks glauben viele Anwender offenbar nicht an die Durchsetzbarkeit von internen Standards für die Anwendungssoftware: "Es wäre unrealistisch, im großen Maßstab eine komplette Normierung dieser Anwendungsprogramme zu fordern", beschreibt Lossau die vorherrschende Meinung.

Eine lösbare Aufgabe sieht der mit Standardisierungsfragen vertraute IT-Referent lediglich in der Normierung der Schnittstellen zum Datenmanagement und zum Benutzer. Folglich rät er den Anwendern dazu, sich auf Programme zu konzentrieren, die über derartige Schnittstellen verfügen.

Im übrigen würden die Kunden "schon aus Wirtschaftlichkeitsgründen" darauf achten müssen, eine "zu große Vielfalt unterschiedlicher Anwenderprogramme" zu vermeiden. Dafür, daß viele Anwender diese Ansicht teilen, spricht die gute Marktdurchdringung der integrierten Pakete Ó la SAP.

Auch Thurner räumt ein, daß "bestimmte Komplexe geschlossen bleiben" müssen, weshalb die Kombination einzelner Module aus Paketen unterschiedlicher Anbieter wohl kaum zu verwirklichen sei. "Ich kann mir nicht vorstellen, daß man die Einanzbuchhaltung von dem einen und die Anlagenbuchhaltung von einem anderen Hersteller nimmt", erläutert der Schweizer Software-Experte.

Auf der anderen Seite gebe es jedoch viele eigene Anwendungen, die für den Betrieb von wettbewerbsentscheidender Bedeutung seien. Dazu gehöre beispielsweise die Vertriebssteuerung oder auch das Platzreservierungssystem einer Fluglinie. "Der Anwender sollte in der Lage sein, solche Dinge in eine Standardumgebung zu integrieren", fordert der Software-Experte, "und zwar ohne daß er den Code der Standardsoftware ändern oder komplizierte Parameter einarbeiten muß."

Derzeit sei der Aufwand für die Integration solcher Funktionen in die Software von der Stange "unverhältnismäßig hoch". Die Inflexibilität ihrer Software koste die Unternehmen bisweilen mehr, als ihnen der Rationalisierungseffekt einbringe.

Auf dem Weg dahin, den Anspruch der Offenheit einzulösen, kann die Standardisierung der Betriebssystem- und Datendienste sowie der Benutzeroberfläche nur ein erster Schritt sein. Als nächste Stufe schlägt Thurner die Standardisierung der Datenmodelle und Methoden für die einzelnen Anwendungskomponenten vor. So hält er es durchaus für möglich, sich beispielsweise im Bereich Finanzbuchhaltung zunächst auf ein normiertes Datenmodell und anschließend auf eine Standardmethode festzulegen.

Derartige Standards müßten dann allerdings auch für die kommerziellen Softwareschmieden verbindlich sein. "Es gibt keinen Grund, so etwas auf die selbstentwickelte Software zu begrenzen," beteuert der Eidgenosse. Vielmehr müßten seiner Ansicht nach die Standardsoftware-Anbieter selbst "das größte Interesse" an einer solchen Entwicklung haben, da sie ihnen helfen würde, die K.o.-Kriterien vieler Kunden zu erfüllen.

Eine Lösung erhoffen sich viele Branchen-Insider auch von den Vordenkern des sogenannten objektorientierten Ansatzes. Die Rede ist von "Standard-Objekt-Bibliotheken", in denen wiederverwendbare Softwarefunktionen gespeichert werden. (Vergleiche hierzu CW Nr. 14 vom 6. April 1990, ab Seite 29: "Der Entwickler fängt nicht mehr bei Adam und Eva an"). Dabei handelt es sich laut Hochkoeppler allerdings um ein "Versprechen, das erst noch eingelöst werden muß".