Das Bild ist gespenstisch: Der Downsizing-David aus dem Client- Server-Land schleudert Steine im Kampf fuer das Wohl der datenverarbeitenden Welt. "Flexibilitaet", "Kostenkontrolle", "Anschluss an neue Technologien" heissen die Projektile. Ihr Adressat: der boese Riese, der Top-down-Dinosaurier - die Mainframe-basierte DV.
Eine Auseinandersetzung mit so biblischer Klarheit - "Entweder, oder" - kann nur theoretisch sein, ohne grossen praktischen Nutzen. Die, zu deren Wohl sie angeblich gefuehrt wird, stehen jedoch vor konkreten Herausforderungen. Die grundsaetzlichen davon decken sich durchaus mit dem, worauf die Client-Server-Puristen hinauswollen: Flexibilitaet, Kostenkontrolle und technologischer Anschluss. Das Problem der DV-Verantwortlichen indes: Mit den vorhandenen Strukturen funktioniert bei weitem nicht alles so, wie es die reine Client-Server-Lehre will. Alte User-Gewohnheiten etwa und fuer hohe Schulungskosten antrainiertes Know-how auf Anwenderseite verhindern, dass die DV/Org.-Abteilung ploetzlich eine Wundertuete neuer Applikationen mit nie gekanntem Look and feel hereinreichen kann. Ebenfalls bremsend wirken getaetigte Hard- und Software- Investitionen.
Trotzdem muss laufend neues Equipment angeschafft werden, weil die Leistung vorhandener Systeme nicht mehr ausreicht. Der Gebrauchtmarkt gibt gegenwaertig fuer relativ wenig Geld alles her, was den CPU-Bottleneck beseitigen kann. Teuer und unangenehm wird es erst, wenn Upgrade-Kosten fuer bestehende System- und Applikationssoftware faellig werden. Die oft geprobte Strategie der Verantwortlichen, um dieser Kostenfalle zu entgehen: Sie entlasten den Zentralrechner, indem sie "Workload" herunternehmen, also Computing-Aufgaben dezentralen Systemen uebertragen. Auf Neudeutsch heisst das Downsizing.
Ein radikaler David mit der Client-Server-Schleuder neigt dazu, an dieser Stelle des Entscheidungsprozesses alles zusammenzuschiessen, was hardwareseitig kanalbasiert und von der Betriebssoftware her zentralistisch organisiert ist. Liesse man ihn im Alltag gewaehren, gaebe es ein zumindest finanzielles Desaster. Deshalb wirft kein Organisationsverantwortlicher, kein DV-Chef, kein System- oder Datenbankadministrator mit einem Schwung alles zum Fenster hinaus, was sich ueber Jahre hinweg evolutionaer entwickelt hat und ein gewaltiges Investitionsvolumen repraesentiert. Gefragt ist auf Seiten der Praktiker vielmehr die Moeglichkeit des sanften Uebergangs von der einen in die andere Welt; ihre zugegebenermassen wenig revolutionaere Forderung richtet sich auf ein pragmatisches Sowohl-als- auch".
Auf die Benefits relationaler Datenbanktechnologie etwa kann auf Dauer kaum noch ein Anwenderunternehmen verzichten, ob das RDBMS jetzt dem User Daten am dummen Terminal anzeigt oder den dezentralen Zugriff zur Weiterverarbeitung durch PCs und Workstations ermoeglicht. Voraussetzung fuer das angestrebte Sowohl- als-auch ist eine homogene relationale Datenstruktur; mit einer VSAM- oder hierarchischen IMS-Datenhaltung kann keine Client- Applikation etwas anfangen.
Die gegenlaeufigen Anforderungen bilden zusammen die Crux, mit der sich viele DV-Abteilungen abplagen. Die Verantwortlichen muessen den Mainframe entlasten, muessen ihre Datenbestaende und Applikationen auf dezentrale Systeme herunterziehen, koennen dabei aber nicht ueber Leichen gehen. Faellige relationale Neuentwicklungen alter Datenbankanwendungen sind fuer viele DV- Chefs eine kaum loesbare Aufgabe, weil der hohe Aufwand fuer die Pflege hierarchischer Applikationen kaum Programmierkapazitaeten in ihren Abteilungen uebriglaesst. Auch darum ist der Uebergang von zentralistischen zu Client-Server-Architekturen so schmerzhaft.
Das Dilemma ist gleichwohl nicht ausweglos. Zu einer Loesung koennen Tools beitragen, die eine automatische Daten- und Programmumstellung von hierarchischen auf relationale Datenbanksysteme ermoeglichen. Die Erfahrung zeigt, dass damit parallel zum Migrationsprojekt der DV-Alltag weitgehend unbeeinflusst weitergehen kann. Die "frozen zone", also die Zeit, in der lebenswichtige Programme nicht gewartet werden koennen, schrumpft bei einer automatisierten Migration auf Tage oder wenige Wochen. Solche Tools existieren fuer den Uebergang von IMS und VSAM auf DB/2 sowie auf Unix-basierte SQL-Datenbanken. Sie erzeugen aus den alten Programmcodes ablauffaehige Programme, deren Performance durch eine vom konkreten Fall abhaengige Menge von Nachbearbeitung zu optimieren ist, und ermoeglichen damit einen weichen Uebergang anstatt des Sprungs ins kalte Wasser kompletter Neuentwicklungen.
Der Effekt einer automatisierten Migration von hierarchisch nach relational ist ein doppelter und dadurch frappierend: Der von hierarchischen DV-Strukturen ausgehende Leidensdruck verringert sich, der Grossrechner erscheint in einem freundlicheren Licht. Zugleich bietet relationale Technologie die Chance, den Mainframe auf ein vernuenftiges Mass zurueckzustutzen. Der Riese Goliath wird bescheidener und gewissermassen altersweise. Freiwillig steigt er von der Pyramide herunter, auf deren Spitze er lange sass, und fuegt sich ein ins neue horizontale Weltbild. Ohne die Anfechtungen durch die reine Client-Server-Lehre, das muss man dem radikalen Downsizing-David hierbei zugute halten, waere es dazu wohl nicht gekommen.