Ablehnende Haltung resultiert häufig aus fehlenden Detailkenntnissen

Auch bei Großprojekten lassen sich offene Systeme realisieren

20.03.1992

Während für kleine und mittlere DV-Projekte der Einsatz offener Systeme beinahe schon zur Selbstverständlichkeit geworden ist, sind viele Anwender bei Großprojekten derzeit noch zurückhaltend. Die proprietäre /370-SNA-Tradition scheint sich nicht auf Anhieb mit neuen Unix-OSI-Konzepten zu vertragen. Jedoch ist der Einsatz offener Systeme heutzutage auch bei Großprojekten sinnvoll und möglich.

Mehr als 70 Prozent der in Deutschland installierten DV-Leistung befindet sich auf oder unter Schreibtischen - als Personal Computer, Workstation, PC-Server oder Workstationserver. Mit anderen Worten: Weniger als 30 Prozent der in Deutschland erbrachten Verarbeitungsleistung findet noch auf Minicomputern, Großrechnern oder Supercomputern statt. Mit der Dezentralisierung einher geht der Trend in Richtung offene Systeme.

Das Phänomen der IBM-PC-Architektur mit der Kompatiblen-Branche hat zusammen mit dem weit verbreitetsten Betriebssystem MS-DOS den Anwendern die Vorteile aufgezeigt, die mit der Unabhängigkeit von bestimmten Hardwareherstellern verbunden sind. Das weit über die PC-Welt hinausgehende Unix geht noch einen Schritt weiter: Es bietet Unabhängigkeit nicht nur von der Hardware, sondern auch vom Betriebssystem-Lieferanten. Dieses grundsätzliche Konzept wird auch durch die - mittlerweile ohnehin nachlassenden Grabenkämpfe von Organisationen wie X/Open, Open Software Foundation (OSF) und Unix International (UI) nicht ernsthaft in Frage gestellt.

Dennoch haben die Auseinandersetzungen zwischen OSF und UI sicherlich dazu beigetragen, daß Unix und generell offene Systeme bei Großprojekten noch verhalten eingesetzt werden. Allerdings sind auch hier erste Anzeichen einer Trendwende unübersehbar.

Die technischen und noch mehr die wirtschaftlichen Vorteile offener Systeme sind derart gravierend, daß sich ihnen immer weniger Anwender entziehen können. So ist das Preis-Leistungs-Verhältnis bei offenen Systemen um ein Vielfaches besser als bei proprietären Systemen: Schätzungen schwanken je nach Definition und Quelle zwischen dem Faktor 500 und dem Faktor 1000.

Hierbei spielt eine wichtige Rolle, daß die Investitionen der Anwender in Eigenentwicklungen bei offenen Systemen wesentlich besser geschätzt sind.

Der Anwender ist nicht auf die Strategie eines Herstellers, seine Marktpolitik und seine Entwicklungszyklen für Hardware und Systemsoftware angewiesen.

Unsere Erfahrungen belegen eindeutig, daß bessere Portierbarkeit der Eigenentwicklungen und ein besseres Mix und Match unterschiedlicher Systemkomponenten der Produkte verschiedener Hersteller auch bei Großprojekten realisierbar ist. Für den Anwender bedeutet dies eine längere Lebensdauer der Produkte bei gleichzeitig besserer Ausnutzung des Leistungsspektrums und niedrigeren Anschaffungskosten.

Letzteres ist insbesondere bei konsequentem Einsatz nichtproprietärer Plattformen gegeben, da der Anwender hierdurch maximale Führungsmöglichkeiten in der Beziehung zum Hersteller erreicht. Dieser wird somit gezwungen, sich immer wieder im Wettbewerb mit anderen Anbietern zu behaupten. Auch die Investitionen in den Ausbildungsstand der eigenen Mitarbeiter können bei offenen Systemen wesentlich vielfältiger genutzt werden.

Das Know-how ist hierbei nicht - wie in vielen Organisationen heute immer noch üblich - ausschließlich auf die Nutzung einer spezifischen Plattform eines Herstellers ausgerichtet. Daß die System Anwendungs-Architektur (SAA) der IBM als Antwort auf diese Problematik nicht ausreicht, ist mittlerweile deutlich geworden.

Bereits seit einiger Zeit zeichnet sich ein neuer Trend ab, der den Wandel zu offenen Systemen weiter fördern wird. State-of-the-art-Entwicklungen, fortschrittliche Entwicklungswerkzeuge und neuartige Möglichkeiten einer verteilten Systemumgebung erscheinen heute schon beinahe in der Regel zuerst auf offenen Systemen. Natürlich gibt es hier bekannte Ausnahmen, die Tendenz ist jedoch eindeutig.

So deutlich der Trend in Richtung offener Systeme geht, so schwer tun sich viele Großanwender, ihm zu folgen. Rund 80 Prozent aller MVS-Benutzer behaupteten in einer kürzlich durchgeführten Umfrage, an dem Betriebssystem als Basis ihrer Strategie festhalten zu wollen. Das liegt häufig daran, daß die Organisationen sich bereits hoffnungslos in den proprietären Strukturen verfangen haben oder aber - was in der Regel nach näherer Untersuchung zutrifft - überhaupt nicht über das Know-how verfügen, die gegenwärtige zentralisierte Struktur durch verteilte offene Systeme abzulösen. Beides wird sich allerdings mittel- bis langfristig negativ auf der Kostenseite auswirken.

Vor diesem Hintergrund entbrennt der Streit um die Chancen und Risiken offener Systeme heute in vielen Großunternehmen mit äußerster Heftigkeit. Mangelnde Detailkenntnisse werden oftmals durch um so massiver dargebotene Glaubensbekenntnisse ausgeglichen. Natürlich ist die Umstellung auf offene Systeme oder der Einsatz bei Großprojekten mit einem gewissen Risiko verbunden. Nur: Diese an sich richtige Aussage muß gegenüber den angeblich sicheren Investitionen in proprietäre Systeme positioniert werden.

Selbstverständlich bedeutet der Eintritt eines Anwenders in den Bereich der offenen Systeme, wenn er die damit verbundenen Chancen konsequent nutzen möchte, ein gehöriges Stück Eigenverantwortung. Der "schützende Schirm" eines Anbieters, der für den "unmündigen" Benutzer Spezifikationen durch Systemlimitierungen ersetzt, entfällt.

Der Anwender muß sich selbst darum kümmern, was er will und was möglich sein soll. Diese Selbstverständlichkeit an sich ist durchaus nicht überall üblich. Häufig findet man gerade bei Großunternehmen eine DV-Strategie vor, die an den nächsten geplanten Ankündigungen eines Herstellers ausgerichtet ist.

Eine grundlegende Voraussetzung für die erfolgreiche Einführung offener Systeme in Großunternehmen ist eine umfassende Schulung der DV-Mitarbeiter, da sich die vorhandenen Kenntnisse zumeist nicht mehr sinnvoll nutzen lassen. Dabei ist vorherzusehen, daß einige der Betroffenen diesen Schritt nicht schaffen werden.

Denn die Umschulung hört nicht bei der Administration der neuen Systeme auf, sondern umfaßt in der Regel auch den Umgang mit moderneren Konzepten für die Anwendungsentwicklung, mit neuartigen Vorgehensweisen und neuen Tools. Dennoch ist die Sicherstellung des benötigten Know-hows im Haus unabdingbare Voraussetzung für den erfolgreichen Wechsel zu offenen Systemen.

Das hängt unter anderem damit zusammen, daß der Markt der offenen Systeme für den unerfahrenen Benutzer, der eine Umstellung in größerem Ausmaß beabsichtigt, praktisch intransparent ist. Anwender, die versuchen, sich ohne den entscheidenden internen Know-how-Aufbau oder Hilfe von außen im neuen Terrain zu bewegen, haben meist schon verloren, bevor sie zu tieferen Erkenntnissen vorgedrungen sind.

Das liegt nicht daran, daß die Materie an sich kompliziert ist. Vielmehr sind die mit offenen Systemen verbundenen Konzeptionen und Fragestellungen einfach von den traditionellen Vorstellungen, wie Datenverarbeitung funktionieren sollte, derart stark abweichend, daß der gewohnte "Proprietär-Denker" dabei geistig rasch aufs Glatteis gerät.

So kann beispielsweise die richtige Hardware- oder Systemsoftware-Selektion zum Lotteriespiel werden, wenn man die Anbieter nicht zwingt, anhand von Tests ihre Übereinstimmung mit den geforderten Standards zu beweisen. Nicht selten steht bei den Herstellern nämlich mehr auf dem Marketing-Papier, als in der Praxis gehalten werden kann. Dabei muß es sich nicht einmal um eine Fehlinformation handeln, sondern die Defizite können dem Marketing oder dem Vertrieb nicht einmal bekannt sein, da die Abweichung vom Standard nur in bestimmten Konstellationen auftritt. Beispiele hierfür gibt es genug.

Ein weitere "Hürde" auf dem Weg zu offenen Systemen stellt in der Diskussion oft das Thema Netzwerksicherheit dar. Selbst Experten führen in diesem Bereich "Glaubenskriege", um nachzuweisen, daß zum Beispiel ein TCP/IP-Netzwerk a priori unsicher ist oder sicher gemacht werden kann.

Sieht man genauer hin, geht die Diskussion meist mehr um das Verschlüsseln von Paßwörtern, um Replay einer Bit-Sequenz, die dem Netz "abgelauscht" wurde, und um verfeinerte Mechanismen für einen gesicherten Login-Prozeß. Nach unseren Erfahrungen sind die Sicherheitsmerkmale der TCP/IP-Implementierungen auf den unterschiedlichen Plattformen sehr verschieden ausgeprägt.

In der Regel entstehen Probleme in diesem Bereich entweder durch Implementierungsfehler von Anbieter oder schlichtweg durch Schlampigkeit bei der Administration der Systeme. Beide Problemquellen lassen sich in den Griff bekommen.

"Auch bei bestem Willen läßt sich mein MVS-Anwendungsszenario nicht auf offene Systeme abbilden" - dieses oftmals letzte Argument von DV-Leitern stimmt nur in wenigen Fällen, aber in diesen wenigen Situationen stimmt es eben doch. Häufig wird dabei außer acht gelassen, daß ein schrittweises Downgrading der Mainframes über die Nutzung offener Schnittstellen auf den Großrechnern unter Anwendung einer Koexistenz-Strategie ohne weiteres möglich ist.

In vielen Fällen sind den Benutzern die hier gegebenen Möglichkeiten einfach nicht bekannt und werden ihnen von den betroffenen Herstellern auch nicht ohne Druck bekanntgegeben. Hier gilt einmal mehr: Der mündige Anwender muß sich selbst darum kümmern.

Allerdings genügt es dabei nicht, nur die DV-Aspekte zu betrachten. Gerade die Einführung offener Systeme, wenn sie im Sinne einer größer dimensionierten Ablösung sinnvoll sein und die hierarchische Rolle der zentralen DV aufheben soll, bringt unter Umständen erhebliche Änderungen der Aufbau- und der Ablauforganisation mit sich.

Der einfache 1:1-Ersatz eines Großrechners ist im allgemeinen nicht die Lösung für eine offene Systemgestaltung. Hier muß oftmals die Lösungsfindung von einem Reorganisationsprojekt begleitet werden. Unter Umständen ist die Reorganisation sogar die Voraussetzung, bevor über die Einführung offener Systeme sinnvoll nachgedacht werden kann.

Ein gutes Beispiel für ein komplexes Großprojekt, das von Andersen Consulting weitgehend auf Basis offener Systeme realisiert wurde, stellt die Deutsche Terminbörse (DTB) dar. Sie wurde im Januar 1990 als zweite vollautomatische Computerbörse der Welt eröffnet und verfügt neben dem zentralen Börsen-RZ in Frankfurt am Main über ein bundesweites Börsennetz mit mehr als 130 sogenannten User Devices für die Marktteilnehmer.

Bei den User Devices handelte es sich ursprünglich um DEC/VAX-Rechner. Um den Marktteilnehmern eine flexiblere Wahl der User-Device-Plattform zu ermöglichen, erhielt Andersen Consulting von IBM den Auftrag, die User-Device-Anwendungssoftware auf das Unix-Derivat AIX zu portieren. Viele Analytiker hielten diesen Kraftakt für unmöglich, da eine völlig neue und von der DEC/VAX Vorlage abweichende technische Architektur zur Konzeption und Realisation anstanden. Viele der Elemente wurden erstmalig auf einer AIX-Plattform eingeführt. Eine modulare Strukturierung der Anwendungssoftware, die Auslagerung von Plattform-spezifischen Softwarekomponenten in Bibliotheken und die strikte Einhaltung von Design- und Programmierstandards ermöglichten es, einen gemeinsamen Sourcecode-Satz für die DEC/VAX- und die IBM-6150-Plattform zu generieren. Inzwischen wurden die 6150-Rechner durch die RS/6000-Workstations von IBM, die unter der neuen AIX-Systemsoftware laufen, abgelöst.

Die zu AIX kompatible User-Device-Software steuert die Händlerbildschirme, die in Echtzeit alle Preisbewegungen des Börsenmarktes auf den Terminals der Händler anzeigen. Zudem übernimmt sie die Steuerung der. Netzwerkkommunikation mit den Rechnern der DTB und die Integration der Börsenschnittstellen zu den bankinternen Anwendungssystemen.

Die Umstellung auf Unix/AIX erforderte die Portierung von über 1000 Cobol-Anwendungsprogrammen, die die rund 100 Bildschirmmasken der User-Device-Anwendung steuern. Zeitweise arbeiteten mehr als 50 unserer Mitarbeiter daran.

Die technische Basis der DTB bildet ein verteiltes Online-Transaktionssystem nach dem Client-Server-Modell. Die Anbindung der über Token Ring vernetzten AIX-Systeme an das Börsennetz erfolgt auf Basis von TCP/IP. Auch alle sicherheitsrelevanten Anforderungen zum Schutz des Netzwerkes, der Börsencomputer, Anwendungen und Daten sind vollständig auf der Unix-Plattform abgedeckt.

Ohne die Details der DTB-Installation weiter aufzuführen, zeigt dieses Projekt mustergültig, daß auch extrem komplexe Lösungen hinsichtlich Anwendungsintegration, Vernetzung, Performance und Sicherheit auf Unix-Plattformen portiert werden können.

Mit der zunehmenden Verbreitung der offenen Systeme auch in Organisationen, in denen bisher zentral und Mainframe-orientiert gedacht wurde, ist immer weniger eine Diskussion über die Risiken des Einsatzes offener Systeme vonnöten. Die Universitätsabgänger von heute und Manager von morgen werden die Zögernden im nächsten Jahrzehnt ablösen. Diese Gruppe dürfte überwiegend von den Möglichkeiten einer Workstation-orientierten und offenen Systemumgebung überzeugt sein.

Schon in naher Zukunft wird es keinerlei Bereiche mehr geben, die technisch und funktional nicht vollständig auf offenen Systemen abgebildet werden können. Das heißt nicht, daß alle Anforderungen ausschließlich auf der Basis von Standards und Quasi-Standards realisiert werden. Doch das sich immer günstiger gestaltende Preis-Leistungs-Verhältnis wird die offenen Systeme rasch in Kategorien bringen, die einen Mainframe-Einsatz in einem Unternehmen über kurz oder lang zu einer sehr erklärungsbedürftigen Angelegenheit werden lassen.