"Opas zentralistische Datenverarbeitung ist tot, es lebe Distributed Processing", sagen die einen. "Alles Kinkerlitzchen", behaupten dagegen die saloppsten Verfechter von Greßrechner-Lösungen. Wenn dreist Welten dazwischen zu liegen scheinen, können beide Gruppen gleichwohl dasselbe meinen. Zumal es noch keine allgemein anerkannte Definition von "verteilter Datenverarbeitung" gibt. Definition hin oder her und mal das Pferd nicht vom Schwanz aufgezäumt: Welche Gründe sprechen denn dafür, Funktionen nach "draußen" zu verlagern, zu verteilen? CW befragte dazu vier Anwender.
Dipl. - Kfm.Ing. Hans Becher Leiter der Hauptabteilung Datenverarbeitung, Vereinigte Papierwerke, Schickedanz & Co.
Der sich ständig ausweitende Geschäftsumfang sowie die steigenden Anforderungen an den Lieferservice, der eine stark dezentralisierte Auslieferungsstruktur erfordert, werden die kundengerechte Auftragsabwicklung in Verbindung mit einer gesteuerten Warendistribution zu immer wichtigeren Voraussetzungen für den Erfolg am Markt.
Im Hinblick darauf daß die Distributionskosten in unserem Hause einen bedeutenden Kostenfaktor darstellen, geht es selbstverständlich auch darum, den erforderlichen Lieferservice auf wirtschaftliche Weise zu erfüllen. Das voluminöse Artikelsortiment schlägt sich nämlich in besonderem Maße auf die Frachtkosten (Werke-Lager-Kunden) sowie auf die Kosten der Lagerhaltung nieder.
Nach eingehenden Untersuchungen, wie man den genannten Zielsetzungen insbesondere auch im Hinblick auf zukünftige Entwicklungen gerecht werden kann, kam man zum Ergebnis, daß durch einen erweiterten Einsatz des Zentralcomputers in Verbindung mit eventuell konventionellen organisatorischen Maßnahmen nur noch in begrenztem Umfang Verbesserungen erwartet werden können. Die Kluft zu den echten Bedürfnissen der Benutzer würde damit nicht kleiner werden.
Auch gegen einen Ausbau des Zentralcomputers und den Anschluß "unintelligenter Terminals" über Standleitung sprachen wichtige Gründe, nämlich die höheren Hardware
und Leitungskosten sowie vor allem die kaum kalkulierbaren Nachteile, die bei einem Totalausfall des Systems eintreten können.
So fiel fast zwangsläufig die Entscheidung zugunsten eines Rechner-Verbundsystems im Sinne von "distributed processing", bei dem die dezentralen Benutzer ihre sämtlichen operativen Funktionen selbständig vor Ort im Dialog abwickeln können und der Informationsaustausch mit den zentralen Planungs- und Dispositionsstellen über Datenfernübertragung mit Wählleitung bewerkstelligt wird.
Unseres Erachtens wurde mit dieser Entscheidung ein wichtiger Grundstein für ein zukunftsorientiertes Vertriebs- und Distributionssystem gelegt.
Ministerialrat Adolf Jändl Leiter des Referats EDV im bayerischen Landwirtschaftsministerium
Distributed Processing sehe ich weniger als Konsequenz irgendeiner Anwendung. Da steckt mehr das Problem dahinter: Ist der Enduser im Umgang mit EDV erfahren? Und wenn er es nicht ist: Ist dann das Handling so einfach, daß der Benutzer am Terminal damit zurechtkommt, wenn ich vermeiden will, doch wieder teure Spezialkräfte einsetzen zu müssen. Die Bedienung der Geräte selbst ist unproblematisch.
Wir haben nun hier das Problem, daß wir verschiedene Softwarepakete haben. Einmal können wir unter IMS, TSO oder STAIRS abrufen, dann können wir mit selbstgestrickten Programmen bestimmte Dinge abrufen. Man kann dem Mann draußen aber nicht zumuten, daß bei IMS eine andere Log on Prozedur als bei Stairs abläuft. Es muß gewährleistet sein, daß mit einer Log on Prozedur die verschiedensten Softwarepakete aufgerufen werden können. Der Bediener selbst weiß doch nicht, womit welches Programm unterstützt wird. Da fängt das Problem an, und wir sind zu der Erkenntnis gekommen, daß wir eine "Übersoftware" brauchen, die das, was der Endbenutzer will, in die richtigen Kanäle steuert.
Wir haben dazu das Lingua-Konzept (Landwirtschaftliches Information-Gewinnungs- und Auswertungssystem) entworfen, das es dem Mann draußen ermöglicht, mit einem einheitlichen Verfahren am Bildschirm zu arbeiten. Dies sind Probleme, die von den Herstellern doch zu sehr unter den Tisch gespielt werden, die aber beim praktischen Betrieb hochkommen. Vor allem muß die Software eben die Terminals mit den verschiedenen Leistungsanforderungen unterstützen: Da müssen Dialog- und Batch-Terminals mit einheitlicher Software abgedeckt werden, und ich glaube, daß die meisten Rechenzentren dazu noch nicht in der Lage sind, so etwas überhaupt zu machen. Es wäre aber sicher unsinnig, jedes Endgerät über eine eigene Leitung für eine Anwendung ans RZ anzuschließen. Man wird also verschiedene Terminalarten bündeln und - auch für verschiedene Anwendungen - über eine Leitung bedienen müssen (Terminal- und Linesharing).
Dr. Horst Kiesow Geschäftsführer DVO (DV-Service-Oberhausen-GmbH) Deutsche Babcock
Wenn die Entscheidung ansteht, Distributed Processing anstelle von zentraler Verarbeitung einzuführen, kann es dafür überhaupt nur drei Gründe geben: Technische, wenn geglaubt wird man könne etwas realisieren, was zentral nicht geht - wirtschaftliche, daß man glaubt, mit Distributed Processing billiger zu fahren - und zeitliche, um gewisse Probleme in kürzerer Zeit lösen zu können. Diese drei Gründe müssen an zwei Fällen getestet werden: erstens beim Distributed Processing "lokal" ohne Benutzung öffentlicher Informationsübertragungswege. und zweitens beim Distributed Processing "entfernt" (remote) mit Benutzung öffentlicher Informationsübertragungswege. Für den ersten Fall spricht eigentlich keiner der drei Gründe. Es gibt weder technische noch - wie vielfach angenommen wird - Kostengründe. Wenn Kostengründe für Distributed Processing sprechen sollten, dann verhält sich das zentrale Rechenzentrum nicht marktgerecht. Es kann aber gelegentlich Zeitprobleme geben, wenn das Rechenzentrum sehr wirtschaftlich gefahren wird und Wert auf gleichmäßige Auslastung legt. Ein extremer Ausnahmefall ist beispielsweise der Anschluß eines Prozeßrechners - sicherlich können einer zentralen Rechenanlage nicht auch noch Prozeßrechnerprobleme aufgebürdet werden. Beim zweiten Fall gibt es wegen der nicht gerade TP-freundlichen Politik der Deutschen Bundespost Anlaß, hin und wieder gewisse Probleme von der Zentrale an die Peripherie zu verlagern. Zwei Dinge sind zu erwähnen: Beispielsweise kann es sinnvoll sein, die formale Prüfung der Daten vor Ort vorzunehmen, um nur "richtige" Daten zur Zentrale zu schleusen. Außerdem könnten Abfragesysteme für Vor-Ort-Dateien installiert und die Dateien nur einmal, etwa nachts, zur Zentrale überspielt werden. Generell gilt aber, je größer die Außenstelle, desto geringer wird der Anlaß, dort Distributed Processing einzusetzen.
Tilo Steinbrinck Vorstandsmitglied bei der Datenzentrale Schleswig-Holstein
Unter dem Schlagwort "Distributed processing" wird von vielen vieles, Unterschiedliches, Schillerndes verstanden. In der Datenzentrale verstehen wir darunter einen abgestimmten Verbund zwischen zentraler und dezentraler Verarbeitung. Dieser Verbund braucht nicht über DFV oder DFÜ zu laufen. Die Hauptsache ist, daß das organisatorische Konzept, das bis zur Programmkonzeption reicht, auf die zentralen und dezentralen Bedürfnisse abgestimmt ist. Die Kosten der DFV und DFÜ lassen nach unseren Untersuchungen in der Mehrzahl von vielen untersuchten Arbeitsgebieten nur eine Offline-Lösung zu, also einen Datenträgertransport über Kassette, Floppy Disk, Lochstreifen etc.
Das Wichtige bei "Distributed-Processing" ist, daß die DV-Maschine bzw. das DV-Verfahren wie eine Schreib- oder Rechenmaschine nahtlos in den normalen Ablauf eines Arbeitsplatzes integriert wird. Wenn man das jeweilige Arbeitsvolumen an den Arbeitsplätzen untersucht, stellt man fest, daß manche für DV geeignete Arbeit spezifisch dezentral, z. B. Datenerfassung mit Fehlererkennung und -bereinigung oder sofortige Auskunftsbereitschaft aus einem nicht zu großen Datenbestand, anfallen.
Andere Typen von Arbeiten, die besonders maschinen- oder rechenintensiv sind gehören weiterhin auf den Zentralrechner, z. B. umfangreiche Rechnungsschreibungen, monatliche Gehaltsberechnungen monatliche Bilanzen, Betriebsabrechnungen. In jedem Arbeitsgebiet muß das zweckmäßige Mischungsverhältnis zwischen dezentralem und zentralem Verfahren analysiert und befunden werden.
Die Datenzentrale Schleswig-Holstein setzt zur Zeit fünf Großcomputer in drei Rechenzentren im Verbund mit rund 50 dezentralen Lochstreifenerfassungsgeräten, rund 170 dezentralen OCR-A-Schreibmaschinen bei zentralem Beleglese-Verfahren, rund 65 dezentralen Terminalcomputern (Offline) mit Schwerpunkten im Einwohnermeldewesen bei rund 170 Stadt- und Amtsverwaltungen, im Finanzwesen des Landes und der Kommunen bei rund 100 Verwaltungen, im Krankenhausinformations-System bei über 20 Krankenhäusern, bei der Berechnung von Gehältern und Löhnen und anderen Arbeitsgebieten ein. Bei einer Reihe dieser Arbeitsverfahren zeigt sich, daß ein weiterer Rationalisierungserfolg im Sinne des Distributed Processing durch den Einsatz von COM-Mikrofiche erreicht werden kann, wenn aus umfangreichen Datenbeständen mit hoher Änderungsintensität regelmäßig Auskünfte gegeben werden müssen; dies gilt vor allem für das Einwohnermeldewesen, aber auch für das Finanzwesen und andere Arbeitsgebiete.