Was heißt denn offen? Beim Studium vieler Veröffentlichungen zum Thema offene Systeme drängt sich der Gedanke auf, daß für ein offenes System nur zwei

Ausprägungen ausschlaggebend sind: Unix (beziehungsweise eines der Derivate) als Betriebssystem und eine ISO/OSI-konforme Kommunikationssoftware. Bei genauerem Überlegen muß man dann leider feststellen, daß beide Voraussetzungen weder notwendig noch hinreichend sind, um Offenheit zu versprechen, geschweige denn zu garantieren.

Um die Parameter festzulegen, an denen sich eine Strategie zur Schaffung eines offenen Systems in einem Unternehmen orientieren muß, ist es notwendig, sich einige Gedanken über den Begriff Offenheit zu machen. Dem Duden nach bedeutet offen soviel wie zugänglich, aufgeschlossen, empfänglich oder unverhüllt. Ein System ist definiert als abgegrenzte Anordnung aufeinander einwirkender Elemente.

Eine Strategie zur Schaffung eines offenen Systems muß demnach den scheinbaren Widerspruch zwischen den Attributen zugänglich und abgegrenzt auflösen. Im Endergebnis soll ein System entstehen, das intern leicht erweiterbar an neue Gegebenheiten anpaßbar ist und nach außen hin mit möglichst geringem Aufwand kontrollierte Schnittstellen zur Kommunikation mit verschiedenen Partnern zur Verfügung stellt. Um dies zu erreichen, ist die Betrachtung von vier Aspekten der Unternehmens-DV notwendig. Mit Offenheit verbinden viele Entscheidungsträger die totale Abkehr von proprietären Hardwareplattformen und Betriebssystemen. Neben der recht primitiven Interpretation dieses Konzeptes (kein Gerät von IBM, kein Gerät von Siemens, etc.) ließe sich daraus aber auch einfach die Möglichkeit ableiten, verschiedene Maschinen und Betriebssysteme verschiedener Hersteller zu beschaffen, sofern ihnen nur der Ruf der Offenheit anhaftet.

Offenheit als totale Abkehr vom Proprietären

Es gibt einige Gründe, warum diese einseitige Sicht weder sinnvoll noch praktikabel ist. Der DV-Wildwuchs, der in einigen Organisationen vorherrscht, ist der beste Beweis dafür. Dadurch, daß Abteilungen das Recht und die Mittel erhalten, ihre (angeblich offene) DV nach eigenem Gutdünken selbst zusammenzustellen, entsteht ein Horrorszenario extremer Heterogenität. Negative Auswirkungen sind unter anderem in folgenden Bereichen zu finden:

- Wartung: Ab einer bestimmten Größe der DV muß entweder eine interne Wartungsgruppe geschaffen werden, die durch die Vielzahl der Systeme natürlich entsprechend aufgebläht und kostenintensiv ist, oder es werden viele spezielle. Serviceverträge notwendig. Diese sind natürlich in der Summe teurer und in der Abwicklung unhandlicher, als es bei einer großen Zahl gleicher Maschinen mit den daraus resultierenden wenigen, großvolumigen Verträgen der Fall wäre.

- Ausbildung: Eine Vielzahl von Systemen zieht einen erhöhten Schulungsbedarf für das beschäftigte Personal (Anwender und Operator) nach sich. Natürlich ist es möglich, Mitarbeiter bei externen Anbietern zu schulen, jedoch verzichtet das Unternehmen dadurch auf potentielle Spareffekte durch "Großabnehmerrabatte", Inhouse-Schulungen und interne Multiplikatorwirkung.

- Umstrukturierung: Bei Änderungen der betrieblichen Organisation werden unter Umständen Mitarbeiter oder ganze Abteilungen und deren Aufgaben mit einer neuen beziehungsweise anderen Rechnerausstattung konfrontiert. Dies führt - bedingt durch die notwendige Anpassungsphase - zu verminderter Effizienz, zu erhöhtem Ausbildungsbedarf und eventuell auch zu Kosten durch notwendige Portierung von Applikationen.

- Sicherheit: Immer mehr setzt sich in den Unternehmen die Erkenntnis durch, daß Information einen strategischen Wert besitzt und deshalb der Schutz dieser Information eines der Unternehmensziele sein muß. Eine Voraussetzung zur Erfüllung dieses Zieles ist die Erstellung von Schutzkonzepten, die auf bekannten Eigenschaften der verwendeten Systeme sowie klar definierten Schnittstellen und Datenflüssen zwischen den Systemen basieren.

Je heterogener die vorhandene Rechnerlandschaft ist, desto komplexen und verschiedenartiger werden die zu überblickenden Schwachstellen und desto schwieriger und unwahrscheinlicher wird die Erstellung von wirksamen Schutzkonzepten, etwa für die Übertragung von Daten und Applikationen auf Ausweichrechner im Falle einer "DV-Katastrophe" im Unternehmen.

Homogene Hardware und nur ein Betriebssystem

Alle genannten Gründe sprechen dafür, trotz des Strebens nach Offenheit eine möglichst homogene Hardware mit möglichst nur einem Betriebssystem zu schaffen. Auf den ersten Blick wird deutlich, daß dies in einem Großunternehmen selten möglich sein wird. Ein Kompromiß besteht darin, die DV zu segmentieren. Dazu werden möglichst große Bereiche des Unternehmens identifiziert, die mit derselben Systemarchitektur (nicht unbedingt mit demselben Rechner) ihre Aufgaben erfüllen können. Es ergeben sich einige wenige Segmente im Unternehmen, innerhalb derer die DV-Beschaffung, -Wartung, -Ausbildung und -Administration absolut homogen sein kann. Dazu ein Beispiel: ein Host-basiertes System für die gesamte Verwaltung und das Management, ein flexibles Unix-Netz für den Bereich Produktion und DOS-Laptops für den Außendienst.

Offenheit auf dieser Ebene bedeutet dann, daß innerhalb eines Segmentes mit einem System gearbeitet wird, das sich am Stand der Technik orientiert, das erweiterbar und an neue Aufgaben anpaßbar ist und das klar dokumentierte und möglichst standardisierte Schnittstellen nach außen besitzt.

Durch die Segmentierung ergibt sich eine überschaubare Zahl von internen und externen Schnittstellen, die - aufgrund der homogenen Hardware und Systemsoftware - leicht im Zuge evolutionärer Verbesserungen an neue Entwicklungen und Normen angepaßt werden können.

ISO/OSI: ein Sammelsurium

Offene Kommunikationssoftware wird häufig mit ISO/OSI konformer Software gleichgesetzt. Dabei wird unglücklicherweise zu oft übersehen, daß ISO/OSI

- vor allem ein Konzept für die sinnvolle Strukturierung von Protokoll-Stacks nach dem Gesichtspunkt "Diensteangebot" ist und

- aus einem Sammelsurium on (untereinander durchaus inkompatiblen) Normen besteht.

Zusätzlich kann man sich sicher sein, daß die Implementierungen eines OSI-Protokolls verschiedener Anbieter nicht die gleiche Funktionalität bieten. Man denke hier nur an normales X.400 und Gosip X.400. Das Problem wird durch die seit der ersten Vorstellung im Jahr 1983 ständigen Änderungen an den Normen auch nicht kleiner (Beispiel: X.400-1984 versus X.400-1988). Mit einem Zitat von Andrew S. Tannenbaum 1): "Das Schöne an Normen ist, daß es so viele gibt, von denen man sich eine aussuchen kann. Und wenn einem gar keine gefällt, wartet man einfach auf die Ausgabe des nächsten Jahres."

Ziel muß es deshalb sein, sich innerhalb eines Unternehmens auf den Einsatz von wenigen Protokollen zu einigen. Typischerweise könnten dies X.400 für das Message-Handling und FTAM für die Übertragung von größeren Datenmengen sein.

Die hierfür angebotenen Produkte müssen auf ihre Zusammenarbeit mit der Hardware, der Software der niedrigeren OSI-Ebenen und der OSI-Software der Kommunikationspartner überprüft werden. Neben der Möglichkeit von internen Tests gibt es mehrere Testzentren (in Deutschland zum Beispiel die Projektgruppe Roland), die Software auf Konformität mit einheitlichen Testszenarien

hin prüfen. In einem weiteren Schritt muß die Software auf die Fähigkeit zur Interoperabilität mit den potentiellen Partnern überprüft werden.

Denn es nützt nichts, wenn ein Produkt die Norm hundertprozentig erfüllt, aber zum Beispiel auf dem Zielsystem Antwortzeiten verursacht, die nicht tolerierbar sind.

Die Beschränkung auf wenige Protokolle und damit Produkte macht diese Evaluierung von Konformität und Interoperabilität handhabbar.

Während die reine Kommunikation durch die Auswahl eines passenden OSI-Produktes mit Konformitäts-Zertifikat in den Griff zu bekommen ist, wird die Herstellung von Interoperabilität zwischen mehreren Systemen eines der beherrschenden Themen der Zukunft sein.

Interoperabilität ist definiert als die Fähigkeit von Systemen, Dienste anzubieten und Dienste anderer Systeme in Anspruch zu nehmen, um dadurch eine effektive und effiziente Zusammenarbeit zu ermöglichen. Zusammenarbeit ist auf den drei verschiedenen Ebenen notwendige die in diesem und den zwei folgenden Abschnitten angesprochen werden.

Die unterste Stufe des Miteinander von mehreren Systeme regelt die technische Interoperabilität.

Sie spezifiziert funktionale, elektrische und physikalische Charakteristiken, die notwendig sind, um Informationen zwischen verschieden aufgebauten Systemen zu übertragen. Durch gut genormte Typen von Übertragungsmedien, Steckerformen und Lowlevel-Protokollen sind auf dieser Ebene die wenigsten Probleme zu erwarten.

Trotzdem versuchen viele Hersteller unnötigerweise, durch eigenwillige und unübliche Kreationen die Arbeit der Techiker zu erschweren.

Man denke nur an die unzähligen verschiedenen Auslegungen einer simplen V.24-Schnittstelle.

Regel: Das Attribut der OSI-Konformität einer Kommunikationssoftware ist zwar eine gute Basis für Offenheit, durch die Vielzahl der Normauslegungen jedoch leider kein Garant für den sorgenfreien Einsatz.

Eine konsistente Dateninterpretation für alle

Auf der nächsthöheren Stufe ist es erforderlich, daß transferierte Daten und die verarbeitenden Programme auf den verschiedenen Systemen die gewünschten Resultate produzieren.

Die prozedurale Interoperabilität spezifiziert die Form, in der Information übertragen und interpretiert wird, sowie deren strukturellen Aufbau. Es müssen Absprachen (als Menge von Regeln) zwischen den Partnern getroffen werden, die sicherstellen, daß alle Beteiligten sämtliche Daten auf konsistente Weise interpretieren.

Im einfachsten Fall kann das die Festlegung eines gemeinsamen Zeichensatzes sein. Komplexere Probleme tun sich auf, wenn zum Beispiel Maßeinheiten in technischen Dokumenten nicht eindeutig festgelegt oder länderspezifische Eigenheiten beim internationalen Datenaustausch nicht berücksichtigt werden, zum Beispiel "zuzüglich Umsatzsteuer" in Buchhaltungsdaten.

Erforderlich ist die globale Beschreibung aller Daten, die übertragen werden sollen, inklusive ihrer Bedeutung und ihrer Beziehungen untereinander in einem gemeinsamen Data Dictionary. Global bezieht sich hierbei auf die Menge aller potentiellen Kommunikationspartner.

Zusätzlich wird eine globale Datenmanipulationssprache benötigt, mit der sich festlegen läßt, welche Daten wie verarbeitet werden.

In der kommerziellen Welt hat sich mittlerweise SQL als Standard etabliert, der von allen größeren Datenbankherstellern unterstützt wird. Aber auch für SQL gilt leider, daß jeder Hersteller - verständlicherweise - bemüht ist, sich durch diverse Features von seinen Konkurrenten abzusetzen und dadurch unverständlicherweise - den Standard verwässert.

Neben SQL als reiner Datenbanksprache werden üblicherweise auch andere Programmiersprachen eingesetzt, die ebenfalls ihren Beitrag zur Interoperabilität leisten sollten.

Vom definitiv veralteten Cobol abgesehen, existieren zwei Standardsprachen, die Offenheit versprechen: Ada, als Entwicklungssprache des Militärs entworfen, aber wirtschaftlich unbedeutend geblieben, und auch C beziehungsweise Cii, als Stammsprachen der Unix-Systeme. Sie sind weitestgehend maschinenunabhängig, was sie für den Einsatz in heterogenen Systemen geradezu prädestiniert. Unabhängigkeit von der verwendeten Hardware ist nicht nur für die Portierung von Applikationen interessant. Im Hinblick auf offene Kommunikation können zum Beispiel Protokolle, die im Quelltext verfügbar sind (zumindest theoretisch), mit geringem Aufwand, auf verschiedenen Zielsystemen implementiert werden. Offen kann in diesem Zusammenhang auch bedeuten, daß es geringen Aufwand verursacht, ein Nicht-OSI-Protokoll, zum Beispiel Kermit, auf allen beteiligten Rechnern zu implementieren und dadurch mit einfachen und billigen Mitteln Kommunikation zu ermöglichen.

Voraussetzung dafür ist allerdings die Offenheit der Schnittstellen der eingesetzten Software. Dazu gehört nicht nur, daß die Datenformate gekaufter Programmsysteme vom Hersteller bekannt gemacht werden, sondern auch, daß die Schnittstellen von Eigenentwicklungen ausreichend dokumentiert werden. Hier ist besonders bei den Softwarefirmen ein deutlicher Nachholbedarf erkennbar. Regel: Nur die Existenz einer konsistenten Interpretation der Daten im gesamten Systemverbund, der Einsatz standardisierter Programmiersprachen und -verfahren sowie das Vorhandensein dokumentierter Softwareschnittstellen und Datenformate versprechen ein interoperables System.

Operationelle Interoperabilität bezieht sich auf die Verwendung übertragener Daten. Um den maximalen Nutzen aus den Informationen zu ziehen, ist es notwendig, sie in die innerbetrieblichen Abläufe zu integrieren.

Dadurch kann eine Umstrukturierung der Aufbauorganisation nötig werden. Zum Beispiel erübrigen sich bei der Einführung eines E-Mail-Systems gewachsene Elemente wie Büroboten, andere Abteilungen, etwa interne und externe Poststellen, lassen sich verkleinern. Voraussetzung ist die Schaffung von Mechanismen, die eine automatische Auswertung und Zuordnung ankommender Daten vornehmen. Es nützt dem Unternehmen nicht allzuviel, wenn ein großer Anteil der hereinkommenden elektronischen Post von Mitarbeitern durchgesehen und anhand des Inhaltes an die betroffenen Personen/Abteilungen (möglichst noch in Form eines Ausdruckes auf Papier) weiterverteilt werden muß.

Ein wichtiger Schritt in diese Richtung ist die unternehmensneutrale Spezifikation von Dokumentenstrukturen (Edifact, ODA), die es nicht nur gestattet, anhand des Dokumententyps die richtigen Bearbeitungsinstanzen zuzuordnen, sondern auch eine automatische Verarbeitung begünstigt.

Gewachsene Formen der Ablauforganistion müssen an eine offene Kommunikationsarchitektur im Unternehmen angepaßt werden. So hat es unter Umständen wenig Sinn, eine Aufgabe zur Bearbeitung von Teilaspekten von einem Sachbearbeiter zum nächsten weiterzureichen, wenn alle Sachbearbeiter auf dieselben Informationen (zentrale Ablage als Datenbank) und Kommunikationskanäle zugreifen können.

Gerade durch E-Mail und die dadurch möglichen direkten Daten- und Meldeflüsse werden hierarchische Strukturen aufgebrochen. Gleichzeitig können interne und externe Daten, deren Aufbau und Bedeutung definiert ist (siehe oben), auf verschiedenen Ebenen automatisch konsolidiert werden. Dem Management steht dadurch eine ständig aktuelle und unverfälschte Wissens- und Entscheidungsbasis zur Verfügung.

Unternehmen, die zum Beispiel an Großprojekten als Konsortialmitglieder beteiligt sind, bieten sich neuartige Möglichkeiten der Bildung von unternehmens- und standortübergreifenden Teams. Diese könnten alle nötigen Kommunikationsmittel und Datenbestände konsortialweit in Anspruch nehmen, um bestmögliche Zusammenarbeit zu gewährleisten. Regel: Die Einführung eines auf operationeller Ebene interoperablen Systems erfordert ein Überdenken vorhandener Organisationsstruktur und eine Anpassung der Arbeitsverfahren.

Ein letzter Gedanke sollte nicht außer acht gelassen werden: Offenheit ist kein Zustand, den man nach Bereitstellung eines bestimmten Systems und ein wenig Reorganisation erhält, sondern das dauernde und evolutionäre Bestreben, die eigene Organisation zur effizienten Zusammenarbeit mit anderen Unternehmen fähig zu machen und diese Fähigkeit zu erhalten.