Nachdem Raymond Treß
* im ersten Teil seiner Beschreibung des Downsizing-Großprojektes beim Heise-Verlag über die Kriterien von Hardware- und Software-Auswahl berichtete, geht es in Teil 2 um die Realisierung. Beschrieben werden nicht nur die einzelnen Projektphasen sondern auch die Zusammensetzung der gesamten Systemlandschaft. Der Autor endet mit einer Beurteilung der Wirtschaftlichkeit.
Auf der Basis des verabschiedeten Pflichtenheftes begann nun die reale DV-technische Umsetzung. Wesentlich ist hier bei der logische Entwurf des gesamten Anwendungsgerüstes und seine Übertragung auf die Datenbankschemata. Auf diese Weise ließ sich die gesamte Datenbankstruktur konsequent auf Redundanzen und Integritätsprobleme überprüfen. Methodisch haben wir uns hierbei an die "structured analysis" gelehnt.
An diesem Punkt hat das Projekt seinen ersten und einzigen Rückschlag erlitten. In der gesamten Projektplanung sind wir davon ausgegangen, daß wir vom Design bis zur Realisierung die Oracle-CASE-Tools einsetzen könnten. Wir haben uns davon eine erhebliche Entlastung gerade bei den oben erwähnten Normalisierungsmechanismen versprochen. Der Einsatz dieser grafikgestützten Oracle-CASE-Tools auf unseren Sun-Workstations ließ sich aber nur nach erheblichen Schwierigkeiten bewerkstelligen.
Es stellte sich heraus, daß die CASE-Tools zu der von uns eingesetzten RDBMS-Version 6. xx inkompatibel waren. Dieser völlig überflüssige Ausflug in die Try-and-error-Welt der Oracle-CASE-Implementierung auf Sun-Workstations hat uns im Projektablauf ein halbes Zeitjahr gekostet.
An dieser Stelle sei deutlich angemerkt, daß die Qualität der CASE-Tools durchaus zufriedenstellend ist. Allerdings sind die Werkzeuge dann nutzlos, wenn der generative Output inkompatibel zur Zielversion des Datenbanksystems ist. Support und Beratungsschwächen der deutschen Oracle-Division waren an dieser Stelle unübersehbar.
Noch einmal sei daran erinnert, daß die RDBMS-Version 6. xx erhebliche Verbesserungen bezogen auf Performance und Tuning-Eigenschaften für Multiprozessor-Unix-Systeme mit sich gebracht hat, ohne die unsere Performance-Anforderungen nicht lösbar gewesen wären. Bedauerlicherweise konnte Oracle bei den CASE-Tools diese Versionsunterschiede nicht zeitgleich realisieren.
Die klare Erkenntnis hieraus ist, daß CASE-Werkzeuge, die nur teilweise einsetzbar sind keinen Wert haben - es sei denn, der Anwender beschränkt den Nutzen auf ein elegantes Datenbank -Dokumentationsinstrument, was im DV-Alltag leider oft genug geschieht. Hierfür eignen sich jedoch auch wesentlich preiswertere Outline-Programme, zum Beispiel aus der Apple-Macintosh-Welt.
In diesem Zusammenhang sei kritisch angemerkt, daß die Kenntnis über strukturelle und funktionale Unterschiede zwischen Unix-Monoprozessoren und -Multiprozessoren bezogen auf Datenbankaspekte auch bei angesehenen Unix-Software-häusern kaum vorhanden ist. Das haben wir unter anderem beim Zukauf administrativer Software für die Bereiche Lohn und Gehalt sowie Finanzbuchhaltung festgestellt. Es war erschreckend, wie leichtfertig wir Angebote erhielten, diese Softwarepakete unter der ungeeigneten Version 5. xx von Oracle auf den Unisys-6000/80-Maschinen zum Einsatz zu bringen.
Da sich unsere CASE-Tools nicht sinnvoll nutzen ließen, drohte das gesamte Projekt vom zeitlichen Ablauf her zu platzen. Wir entwickelten daher unter Unix eigene Tools, die die Aufgaben Data Dictionary, Integritätsprüfung und Normalisierung übernahmen. Bei der Normalisierung kam uns zugute, daß wir bereits im konzeptionellen Entwurf der Datenbankstrukturen die Anwendung der 3. Normalform zur Zielregel erklärt hatten. (Für die Interessierten sei hier ein Literaturhinweis gestattet auf ein umfangreiches und unserer Meinung nach didaktisch gut aufbereitetes Buch von Finkenzeller/ Kracke/ Unterstein: Systematischer Einsatz von SQL-Oracle, Verlag Addison-Wesley, ISBN 3-89319-117-8. )
Für die systematische Programmentwicklung unter objektorientierten Gesichtspunkten ist bekanntlich nichts wichtiger als die Einhaltung bestimmter Ordnungsprinzipien. Nun bietet Unix dafür bereits hervorragende Mechanismen und Utilities wie SCCS (Source Code Control System) oder Make. Das reichte uns jedoch nicht, um eine jeweils aktuelle Integrität bei der Programmentwicklung zu gewährleisten.
Deshalb haben wir uns bereits am Anfang des Projektes entschlossen, eine eigene integrierte Oberfläche über die Summe der verfügbaren und selbst entwickelten Tools zu schaffen. Damit konnten wir gewährleisten, daß vom ersten Programmentwurf bis zur Produktionsfreigabe alle Ressourcen wie Libraries, Data Dictionary, System und Anwenderdokumentation jeweils aktuell und konsistent sind.
Diese Produkte konnten (mußten) wir nun mit unseren selbstgeschribenen Database-Tools (in Ermangelung der Oracle-Case-Tools) zu einem homogenen Gebilde zuzammenfügen. Damit haben wir aus der Not eine Tugend gemacht.
Ein Wort noch zu den Oracle-Tools. Im Gegensatz zu den Case-Tools, die designerische und generative Aufgaben erfüllen, sind hiermit die Programmierhilfen, zum Beispiel für die Maskenerstellung (Oracle Forms 3) und Reportgenerierung gemeint. Ehemaligen Mainframern erscheinen diese Werkzeuge zunächst wie ein Geschenk des Himmels.
Bei näherer Betrachtung stellt sich heraus, das auch komplizierte Aufgabenstellungen schnell und effektiv mit diesen Instrumenten gelöst werden können - allerdings geht das immer zu Lasten der Performance. Die objektorientierte Programmierung von Triggern und das Event-handling erleichtern vieles, verführer aber auch zu einer Art Guerilla-Programmierung bei der niemand mehr weiß, wer am Ende eigentlich gegen wen programmiert ( kämpft). Besonders Oracle Forms 2 ist in diesem Punkt sehr mangelhaft, da sinnvolle und vollständige wie zum Beispiel Feldreferenzen etc. nicht in einer hilfreichen Form zur Verfügung stehen.
Erst mit Oracle Forms 3 wird ein Tool angeboten, das diese Mängel beseitigt und entsprechend aussagekräftige Informationen für den Entwickler verfügbar macht. Darüber hinaus werden hier erstmals Mechanismen unterstützt, die die Entwicklung geeigneter Benutzeroberflächen gestatten, zum Beispiel Sub-Windows, Popup-Windows oder die vollständige Unterstützung von Scroll-Mechanismen.
Obwohl diese Möglichkeiten schon sehr weitreichend sind, genügen sie doch längst nicht dem Standard, der auf intelligenten Workstations möglich ist.
Deshalb haben wir uns entschlossen, für einen großen Teil unserer Anwendungen Macintosh-Rechner mit den Datenbanksystemen Omnis 5 und 4D als Front-ends für die Oracle-Datenbanken einzusetzen. Die Vorteile liegen auf der Hand: - vollständige Verfügbarkeit geeigneter Benutzeroberflächen wie zum Beispiel - Verwendung von Maus, Checkbuttons, Radiobuttons oder die - volle Grafikunterstützung der Feldinhalte, - Anbindung an Oracle-SQL-
*Net-like, - einfache Programmierung durch intelligentes Oracle-Interface-Kit, - preisgünstigere Lizenzen.
Selbstverständlich ist, daß für zeitkritische Anwendungen die Benutzung von Embedded SQL unumgänglich ist. Aber schließlich wurden ja früher zeitkritische Zugriffe in Cobol-Programmen sinnigerweise auch über Assembler-Routinen abgebildet. Der entscheidende Unterschied ist, daß im Gegensatz zur wildwuchsfördernden Assembler-Programmierung (die Tricks mit
*-Adressierungen und Befehlsmodifikationen sind allgemein bekannt) der gemeinsame verbindliche Nenner der SQL-Sprachumfang ist.
In fast allen relevanten Systembereichen verwenden wir Self-made-Utilities. Dies erscheint zunächst nachteilig, ist aber in Wirklichkeit vorteilhaft weil man durch die Offenheit des Systems in keiner Weise eingeschränkt wird und alle Möglichkeiten zum eigenen Vorteil ausnutzen kann. Dieser Aspekt macht deutlich, was gemeint ist, wenn von Unix als einem offenen System die Rede ist. Der Anwender hat die Chance, Einfluß nehmen zu können, ohne durch Restriktionen im Bereich Job-Control, Geräteschnittstellen etc. eingeschränkt zu sein. Zu jedem Zeitpunkt muß er einen kontrollierten Ablauf der unterschiedlichen Anwendungsprofile sicherstellen.
Um zum Beispiel typische Batch-Aufgaben sinnvoll nutzen zu können, haben wir einen Batch-Handler geschrieben, der die Kontrolle über die I/O-Datenflüsse und Geräte dynamisch durchführt. Damit konnten klassische Batch-Aufträge mit geeigneter Benutzeroberfläche in den Verantwortungsbereich der Fachabteilungen verlagert werden. Der Vorteil drückt sich klar in der Reduzierung zentraler klassischer Operating-Aufgaben aus und verlagert die Einflußnahme an den Ort des Bedarfs und der fachlichen Kompetenz. Vorteile durch Online-Backup
Ein wesentlicher Gesichtspunkt ist das gesamte Backup-Konzept des Systems. Es gliedert sich in zwei Bereiche: Datenbank-Backup und Backup normaler Files. Auch hierüber wacht ein eigens geschriebener Handler, um die Konsistenz sicherzustellen. Wesentliche Vorteile bieten sich durch die Online-Backup-Mechanismen von Oracle und durch die Rekonfigurierbarkeit der gesamten Plattenperipherie beider Systeme.
Damit sind wir letztlich in der Lage, im Crash-Fall die gesamte Systemverfügbarkeit in weniger als 30 Minuten wiederherzustellen. Als Backup-Medium benutzen wir EXA-Tapes in der Größenordnung von zwei Gigabytes, die über eine Workstation angeschlossen nach einem video-ähnlichen Verfahren die Daten aufzeichnen. Der Durchsatz beträgt etwa ein Megabyte in zwei Sekunden.
Als Archivierungsmedium werden wir wiederbeschreibbare Optical Disks verwenden, die über vernetze Workstations angeschlossen sind. Diese Technik hat zusätzlich den Vorteil, das die so archivierten Daten ebenfalls wieder über Workstation in einigen Fachabteilungen zu Recherchezwecken oder zur Wiederbenutzung schnell zur Verfügung stehen und die zentralen Systeme damit nicht belastet werden. Besonderen Nutzen werden wir aus der Langzeitarchivierung buchhalterischer Daten und sämtlicher Grafikdaten der Photosatzbelichter ziehen.
Ein unschätzbarer Vorteil von Unix sind die kommunikativen Fähigkeiten des Betriebssystems. Die verblüffende Einfachheits, mit der unterschiedlichste Hard- und Software komfortabel miteinander vernetzt werden kann, hat unserem Unternehmen organisatorische Vorteile verschafft, von denen wir vorher nicht zu träumen wagten.
So konnten in den einzelnen Fachabteilungen bedarfsgerechte Endgeräte und Workstations installiert werden, ohne daß auf die Nutzung zentraler Ressourcen verzichtet werden mußte. Bei uns ist heute zum Beispiel selbstverständlich, daß sich kein Mitarbeiter von seinem Arbeitsplatz wegbemühen muß, um eine Belichtung seines Dokuments auf einem an anderer Stelle lokalisierten Belichter zu veranlassen. Ebenso selbstverständlich ist, daß der Belichter dem Zentralsystem zu Archivierungszwecken das Belichtungsmaterial über das Netz wieder zur Verfügung stellt. Durch Verwendung von NFS (Network File System) und entsprechender Router-Software gestaltet sich die Nutzung aller Ressourcen beliebig komfortabel. Mehraufwand beträgt maximal zehn ProzentEin besonderes Augenmerk möchte ich hier noch einmal auf die Netzfähigkeiten von Oracle richten. Die Netzkomponente SQL
*Net ermöglicht die beliebige Verteilung von Datenbanken oder Teilen daraus auf unterschiedliche Rechnersysteme im Netzwerk. Entscheidend dabei ist, daß darauf bei der Programmentwicklung keine Rücksicht genommen werden muß, weil Oracle die jeweils aktuelle Datenbank-Netzwerktopologie kennt. Die Erfahrung hat gezeigt, daß der dadurch bedingte Performance-Mehraufwand maximal fünf bis zehn Prozent beträgt.
Da wir ein heterogenes Netzwerk betreiben, an das zusätzlich Rechner mit öffentliche Zugängen (Telefon, X. 25) angeschlossen sind, dann stellt sich sofort die Frage nach der Datensicherheit. Unix gilt bekanntlich als nicht besonders sicher - das ist auch ganz klar, denn Offenheit und Sicherheit sind zunächst einmal Gegensätze. Durch Einsatz am Markt befindlicher Sicherheitskomponenten kann der Level B2 nach dem Orange Book des US-Verteidigungsministeriums erreicht werden.
Wir sind einen anderen Weggegangen durch Erstellung eigener Security Software, über deren Funktionsweise ich mich an dieser Stelle verständlicherweise bedeckt halte. Diese Software betreiben wir mit dem Cosmonet- Mailboxsystems seit Januar 1988. Natürlich gab es immer wieder Einbruchsversuche, die wir zum Teil auch zurückverfolgten. Es war jedoch keiner davon auch nur ansatzweise erfolgreich.
Zusammenfassen lassen sich die Nachteile unseres Projektes wie folgt beschreiben: - verschiedene Derivate des Unix-Betriebssystems, - keine Standard-Applikationsoberflächen verfügbar, - keine professionelle Oberfläche für Massen-Datensicherung verfügbar, - keine Oberfläche für Hintergrund-Jobs verfügbar, - keine Oberfläche für Standard-Entwicklungstools verfügbar, - zusätzliche Security-Maßnahmen notwendig, - Systemadministration will gelernt sein.
Die Vorteile: - offene Systeme, - Herstellerunabhängigkeit, - exzellente Entwicklungsmöglichkeiten, - leistungsfähige Hardware, - umfangreiche Standardsoftware, - wenig Operating-intensiv. Systemadministration ist nicht zu unterschätzenBei der Aufzählung der Nachteile sticht besonders hervor, daß für den sinnvollen kommerziellen Einsatz die geeigneten Oberflächen fehlen. Das sind aber nur scheinbare Nachteile, da die Benutzerschnittstellen mit hervorragenden Entwicklungswerkzeugen relativ schnell geschaffen werden können. Dabei können ganz individuelle Oberflächen gestaltet werden - ein großer Vorteil.
Mit Entschiedenheit möchte ich darauf hinweisen, daß die Bedeutung der Systemadministration in keinem Falle zu unterschätzen ist. Beim Einsatz heterogener Netze mit verteilten Datenbanken ergibt sich die Notwendigkeit dafür ohnehin.
Die Vorteile, so läßt sich im nachhinein feststellen, überwiegen bei weitem, denn ein Unixbasierendes Anwendungssystem kann sehr individuell und bedarfsgerecht zugeschnitten werden, ohne daß diese Mechanismen bei einem Hardwarewechsel verloren gehen. Die wirtschaftliche Betrachtung läßt sich am besten anhand der reinen Hardwarekosten im Verhältnis zu den Produktionszeiten darstellen. Erhebliche Zugewinne durch optimalere Organisationsabläufe etc. sind letztendlich nur grob abzuschätzen und nicht in konkreten Geldbeträgen darstellbar.
Eine Beispielrechnung gibt Aufschluß über die Wirtschaftlichkeit unserer Downsizing-Lösung (vergleiche Abbildung). Zu beachten ist dabei die erhebliche Ausbaufähigkeit der Unix-Systeme, deren Prozessorleistung ebenfalls noch durch Aufrüsten von 386er- auf 486er-Prozessoren steigerungsfähig ist.
Die betrachteten Kosten beinhalten für beide Systeme die komplette Nah- und Fernperipherie einschließlich Vernetzung mit den dazugehörigen Servern, jedoch ohne Grafik-Workstations und High- End-Photosatzmaschinen. Dadurch ist sichergestellt, daß dieser Vergleich nicht hinkt, da diese Art Peripherie bei der Mainframe Konfiguration nicht vorhanden war und die Amortisation in diesem Fall durch den Wegfall externer Dienstleistungen gegeben ist.
Die Produktionszeiten beziehen sich auf wesentliche Bereiche der Telefonbuch-Produktion, das heißt Umbruch und Satzberechnung-die sowohl I/O-, als auch rechenintensiv sind. Neben dieser rein rechnerbezogenen Betrachtung fallen zusätzlich noch folgende Komponenten ins Gewicht: - starke Reduzierung von Laufwegen durch Vernetzung; - optimale Informationsqualität an allen Arbeitsplätzen; - Reduzierung des Operating-Bedarfs um eine Schicht; - wesentlich sichereres Systemverhalten durch Online-Backup; - geringerer Wartungsaufwand für Hard- und Software.
Die Risiken bei einem Projekt dieser Größenordnung möchte ich in einer Gesamtbeurteilung so zusammenfassen: - das "Bewährte" wird grundsätzlich infrage gestellt, - eine kurzfristige Amortisation kann es nicht geben, - während des Übergangs sind erhebliche personelle Mehrbelastungen zu erwarten, - hohe Aufwendungen für die Qualifikation des Stammpersonals müssen erbracht werden, - die Anwender sind vorübergehend verunsichert.
Diesen Faktoren steht ein "Zugewinn" gegenüber, der kaum noch Zweifel zuläßt: - erhöhte Wettbewerbsfähigkeit durch Flexibilität, - verbesserte Produktivität durch schnelleren Durchsatz, - langfristige Absicherung der Investitionen durch Standards (C, SQL, SVID, X-Open), - Freiheit und Mündigkeit des Anwenders, der sich vom Diktat der Mainframer abnabelt, - Motivation des Personals (EDV & Fachabteilung) durch zeitgemäße Arbeitsweisen, - erhebliche Kostenreduzierung, - schnellere Durchlaufzeiten, - geringerer Wartungsaufwand, - optimale Organisation.
Wir wissen heute, daß wir mit unserem Anwendungssystem optimale Freiheitsgrade erreicht haben. Die inzwischen noch weiter erhöhte Ausbaubarkeit der eingesetzten Hardware wird unseren Bedarf bis weit in die 90er Jahre hinein abdecken. Durch die wesentlich bessere Kostenstruktur unserer heutigen Systemlandschaft und die sehr guten Vermarktungschancen unserer Anwendungssoftware steht fest, daß wir den Zeitpunkt des Return of investment wesentlich schneller erreichen werden als ursprünglich angenommen. Ganz entscheidend trägt dazu auch die Tatsache bei, daß die getätigten Software-Investitionen in der Unix-Welt langfristig abgesichert sind.
Als Abschluß dieses Praxisberichtes möchte ich allen Interessierten empfehlen, die Möglichkeiten des Unix-Einsatzes ernsthaft zu erörtern Sicherlich sind (noch) nicht alle Größenordnungen bisheriger Mainframe-Anwendungen 1: 1 ablösbar. Im Zweifelsfalle können hier individuelle Benchmarks sachliche Erkenntnisse liefern. In jedem Falle bringt ein Redesign vorhandener Anwendungen einen erheblich besseren Funktions und Qualitätsstandard.