Ein staendiges Thema unter DV-Planern sind heute die Probleme mit den Endbenutzern, die sich ploetzlich vehement dagegen wehren, den ganzen Tag mit ihren PCs in der Terminalemulation zu verbleiben. Sie wollen Winword, grafische Oberflaechen, Fenstertechnik und Farbe. Darum ging es bei der AOK Berlin, bei der Zentrale der Deutschen Bundesbahn in Frankfurt, beim Europaeischen Patentamt, beim ADAC in Muenchen und bei der OEMV in Wien, um nur einige zu nennen.
Waehrend sich das Problem ueberall zu gleichen scheint, sind die denkbaren Loesungen unterschiedlich kompliziert. Es war in praktisch keinem Fall moeglich, einen Weg zu finden, der durch niedrige Kosten und Benutzerkomfort zugleich ueberzeugt haette. Fuer die Suche nach verbesserter Connectivity wirkt es erschwerend,
- wenn im Verhaeltnis Terminals zu PCs die Terminals ueberwiegen (etwa bei der OEMV und der AOK);
- wenn es maPC-Applikationen unter zeichen-orientierter Oberflaeche gibt wie beim ADAC;
- wenn die PCs mit speziellen 3270-Adapterkarten ausgeruestet wurden, die nicht vernuenftig unter Windows funktionieren (zum Beispiel bei der OEMV);
- wenn es zeichenorientierte Host-Applikationen gibt, fuer die ein grafisches Front-end nicht wirtschaftlich ist (unter anderem beim Europaeischen Patentamt).
Der Preis fuer die optimale Anbindung der PCs an den Host ist hoch. Bei einer Alternativkalkulation bis zum Jahr 1998 fuer eine sehr DV-abhaengige mittelstaendische Firma in Nordrhein-Westfalen ergaben sich fuer die drei durchgespielten Moeglichkeiten folgende Kosten:
- unter Beibehaltung des Status quo (Host mit Terminals und ein separates LAN) zirka 20 000 Mark pro Benutzer und Jahr;
- bei einer Anbindung aller PCs an den Host und dem schrittweisen Ersatz der Terminals durch PCs etwa 28 000 Mark pro Benutzer und Jahr;
- bei Abschaffung des Hosts zugunsten einer Unix-Multiprozessor- Maschine mit Unix-RISC-Clients ungefaehr 22 000 Mark pro Benutzer und Jahr. Hier sind die Kosten fuer ein komplettes Re-Engineering der Host-Anwendungen zu beruecksichtigen.
Fuer alle Alternativen wurden jaehrliche Steigerungsraten beim Ressourcenverbrauch, Wartungs- und Beschaffungkosten
sowie Personalkosten eingerechnet. Entgegen der ueblichen Annahmen stellte die vorhandene Host-Loesung vordergruendig die preisguenstigste Alternative dar.
Doch wenn man die Rechnerleistung pro Mitarbeiter einbezieht, veraendert sich das Bild dramatisch. Durch die viel hoeheren MIPS- Raten bei einer rein dezentralen RISC-Superserver-Loesung haetten pro Benutzer im Falle drei nur noch etwa 3700 Mark pro MIPS bezahlt werden muessen gegenueber zirka 15 600 Mark bei der zweiten und ungefaehr 66 900 Mark bei der reinen Host-Loesung.
Auch wenn die Rechnervergleiche in MIPS-Werten angezweifelt werden duerfen, auch wenn solche Kostenstudien fiktiv, weil zukunftsbezogen sind, kann man hier jedoch eines deutlich ablesen:
Definition von offenen Systemen
Der Ersatz von Terminals durch PCs und die haeufige Uebernahme der alten Kabelstruktur (Coax sternfoermig an Controller, keine LAN- Verkabelung) sind mit Abstand die schlechtesten Loesungen. Der Betreiber verliert Geld, der Benutzer Lust und Nerven durch in aller Regel aeusserst kompliziertes Handling.
Wo immer heute neue DV-Verfahren implementiert werden, so empfahl selbst der konservative DV-Berater Frederic Lamond auf seiner Deutschland-Tournee im vergangenen Dezember, sollten offene dezentrale Maschinen geplant werden. Das setzt aber die Beschaeftigung mit den offenen Standards des dezentralen Umfelds voraus.
Ein System ist dann "offen", wenn es andere Systeme gleicher Funktionalitaet gibt und alle denselben De-facto- oder De-jure-Standards genuegen.
Anwendungen, die auf einem offenen System laufen, koennen auf ein anderes offenes System portiert werden. "Portabel" ist eine Anwendung dann, wenn sie auf andere Hardware-Software- Kombinationen uebertragen werden kann.
"Skalierbar" ist ein Programm, wenn es auf verschieden grossen Rechnern einer Architektur laeuft.
"Interoperabel" nennt man eine Anwendung, die Daten von anderen Applikationen unmodifiziert weiterverarbeiten kann.
"Interconnected" (verbunden) koennen nur Hardware und Software auf den untersten Levels sein.
Portierbare Anwendungen sind das eigentliche Ziel der Offenheit. Die Reisekostenabrechnung etwa soll einmal entwikkelt werden und dann unternehmensweit auf jedem Client oder Server laufen, egal, ob Macintosh, Sparcstation, Intel 286, 486 oder RISC. Die Textverarbeitung soll einmal gekauft und ueberall installiert werden koennen und dabei moeglichst die jeweiligen Spezifika der Hardware voll ausnutzen. Eingesetzt werden soll Allerwelts- Hardware, die jederzeit austauschbar ist.
Davon verspricht man sich Kostenvorteile und ein Ende der Abhaengigkeit von einem Hersteller bezueglich Preis, Verfuegbarkeit und Leistung.
Eine amerikanische Studie kommt zu dem Schluss, dass die offenen Systeme fuer Firmen heute die groessten finanziellen Vorteile im Bereich der Midrange-Rechner bringen. Das gelte vor allem dann, wenn man eine Mainframe-Anwendung auf offene Systeme portieren will. Am erfolgreichsten seien die kleinen Loesungen, nicht die Mammutprojekte. Die Studie empfiehlt, die Grenzen fuer Projekte unter Unix bei 2500 Benutzern und etwa 50 GB Datenbank zu setzen. Unter DOS liege die Grenze bei 800 Benutzern mit maximal 10 GB Datenbankvolumen. Ab 1995 werde man unter Windows NT mit 2500 Benutzern und Datenbanken mit 150 GB innerhalb offener Systeme arbeiten koennen. Ich halte diese Werte fuer ausserordentlich hoch - vor allem unter dem Aspekt der Sicherheit.
Anwendungsportabilitaet scheint eine realistische Zielsetzung zu sein, wenn der Grad der Portierbarkeit sorgfaeltig definiert wird. Verschiedene Studien weisen darauf hin, dass absolute Portabilitaet unwirtschaftlich sein kann und normalerweise nicht notwendig ist. Interoperabilitaet reiche im allgemeinen aus. Einige Firmen haben es tatsaechlich geschafft: Der Uebergang auf offene Systeme brachte ihnen eine Senkung der Betriebskosten und eine groessere Auswahl an Loesungen. Beispiel ist die Portierung einer /36-Anwendung auf Sparc unter Motif. Auf jeden Fall ist es einfacher, zwischen sogenannten offenen Systemen zu portieren als zwischen geschlossenen.
Fruehe Anwender berichten ueber technische Probleme der eingesetzten Hardware und Systemsoftware, ueber mangelnde Stabilitaet der neuen Anwendungen, ueber Produktverzoegerungen im Zusammenhang mit der Implementierung und vor allem ueber die unzureichende Performance der neuen Loesung. Von HP stammt die Angabe, dass eine Datenbankanwendung unter Unix um zirka 7 bis 15 Prozent langsamer ist als unter dem hauseigenen proprietaeren MPE- Betriebssystem.
Diese Zahl ist nur auf den ersten Blick verwunderlich. Die offene Software nutzt die Systemspezifika der Maschine viel weniger aus als eine proprietaere Loesung. Offene Loesungen sind grundsaetzlich weniger effizient und benoetigen mehr Speicherkapazitaet. Dies muss entweder als Leistungseinbusse hingenommen oder durch groessere Hardware kompensiert werden. SQL-Anwendungen sind hier nach Angaben von Spezialisten besonders gefaehrdet. Die interessantesten SQL-Funktionen seien zudem oft herstellerspezifisch. Auf sie gelte es nun zu verzichten.
Qualifiziertes Personal: Schwer zu finden und teuer
Aus Gespraechen mit Anwendern wird deutlich, dass es sehr schwer ist, Personal zu finden, das sich einerseits mit der fraglichen Anwendungsproblematik, andererseits mit der Quell-Systemumgebung und auch mit der Zielumgebung bestens auskennt. Wer hat schon zehn Jahre Erfahrung mit MVS und NT? Solche Leute sind natuerlich auch sehr teuer. Obendrein werden die Kostenvorteile der offenen Systeme immer geringer, da auch die proprietaeren Boxen billiger werden muessen, um ueberhaupt noch verkauft werden zu koennen. Rechnet man die Umstellungskosten dazu, dann kann die Schlussrechnung hoeher ausfallen als erwartet.
Die Befuerworter von offenen Systemen tun das Uebliche: sie waehlen ueber die Definition und Befolgung von Standards die richtigen Produkte aus. Danach planen sie ihre Migrationsschritte. Hier kommt der kritische Begriff "Standard" ins Spiel.
Firmen, die Standards gesucht und gesetzt haben, haben sich entweder fuer Infrastruktur-Standards entschieden, die fuer alle oder grosse Unternehmensbereiche gelten, zum Beispiel Ethernet, oder fuer spezifische, Geschaeftsprozess-bedingte Standards, die fuer die Abwicklung eines Verfahrens gelten, wie etwa Edifact.
In jedem Fall sollte man, wenn man schon auf offene Systeme umstellt, gleich grafische Oberflaechen, SQL-Datenbanken und eventuell neue Netzwerk-Architekturen einfuehren, falls nicht schon vorhanden.
* Susanne Mueller-Zantop ist Herausgeberin des PC-Newsletters "Tidbits". Ihr gehoert die Beratungsfirma MZ Projekte in Muenchen.