Seit der Entwicklung preiswerter Mini- und Mikrocomputer, die Im Netzwerk in Verbindung mit einem Großcomputer arbeiten kennen, Ist die verteilte Datenverarbeitung (DDP) wieder voll In der Diskussion. Vorher hatten viele Anwender - trotz machtvoller Vertriebsanstrengungen der IBM mit Ihrer Rechnerserie 8100 - den Weg in eine DDP-Lösung gescheut. Kosten, technische Risiken und die Frage "Was bringt's wirklich?" waren die hemmenden Faktoren.

Diese Punkte können heute allerdings ganz anders gesehen werden. Die geradezu sensationelle Preis-/ Leistungsentwicklung bei Minis und Mikros hat hier völlig neue Dimensionen eröffnet. Die Bundespost hat mit Datex-P und -L ein bißchen diese Entwicklung in Richtung DDP unterstützt - nur ein bißchen, wenn man sich mit den USA und den dort gegebenen preiswerten Netzwerkmöglichkeiten vergleicht.

Der Begriff "verteilte Verarbeitung" - die Computerintelligenz an den Ort zu bringen, an dem sie gebraucht wird - besagt bereits, daß die eigentlichen Nutznießer dezentral organisierte Unternehmen sein werden. Im wesentlichen gibt ein DDP-Konzept folgende Vorteile her:

- Unabhängigkeit von Leistung und Verfügbarkeit des Zentralrechners vor Ort

Ausfälle und Überlastung des Großrechners sollen nicht bis in die dezentrale Betriebsstätte durchschlagen, Arbeits- und Betriebszeiten vor Ort lassen sich individuell organisieren.

- Spezielle Lösungsmöglichkeiten für die dezentrale Einheit

DDP ermöglicht eigens für die Nieuderlassung gestaltete Programme und Anwendungen. Besonders vorteilhaft ist das bei funktionaler Dezentralisierung, wenn also eine Betriebsstätte individuelle Aufgaben wahrnimmt, die sonst nirgends im Gesamtbetrieb durchgeführt werden. In dieser Hinsicht kann auch eine "Inhouse-DDP-Lösung" sinnvoll sein, wenn man zum Beispiel Spezialabteilungen wie der Vermögensverwaltung oder der Plankostenrechnung eigene Minis als Vorrechner hinstellt, auf denen deren spezielle Anwendungen laufen. Ideal ist es, wenn man dann gleichzeitig auch Programmentwicklung und -pflege dezentralisiert und der Betriebsstätte dies überläßt.

- Komfortablere und nutzenorientiertere Dialoglösungen

Die Entlastung des Zentralrechners durch die Vorrechner macht unter bestimmten Bedingungen umfangreichere Dialoglösungen mit mehr Unterstützungsfunktionen für den Nutzer möglich.

- Kostengesichtspunkte

Durch eine DDP-Lösung lassen sich unter Umständen sprundfixe Kosten (kleinerer Zentralrechner, weniger Standleitungen für DFÜ etc.) einsparen. Möglicherweise kann ein DDP-Gesamtsystem sogar billiger sein als eine reine Zentrallösung mit DFU.

- Größere Flexibilität bezüglich zukünftiger Entwicklung

Hier seien als Beispiele nur genannt:

- raumlich begrenzter Rechnerverbund, zum Beispiel zwischen dem Vorrechner und der örtlichen Bank im Wege des Zahlungsverkehrs,

- gebietsbezogene Vernetzung agentureigener Computer mit dem Vorrechner der zuständigen Filialdirektion einiar Versicherungsgesellschaft etc.

Grundsätzliches Umdenken erforderlich

Wie haben sich diese Vorteile nun bisher in die Praxis umsetzen lassen? Anfänglich schwer, denn DDP ist nun mal nicht irgendeine EDV-Lösungsalternative, sondern sie kann nur als generelle Unternehmensstrategie verstanden werden. Dafür sind ein grundsätzliches Umdenken in der Anwendungsentwicklung, völlig neue Anforderungskategorien für den zentralen Rechenzentrumsbetrieb sowie ein tiefes Verständnis und die Mitarbeit auf seiten des Nutzers notwendig.

Auf breiter Basis mußten deshalb Anfangsinvestitionen getätigt werden, die in ihrer Höhe oft unerwartet und auch nicht vorauskalkulierbar waren. Die technische Basis für DDP, die zum Beispiel Siemens mit der Transdata-Serie, IBM mit der 8100 geschaffen hatten, waren nur ein kleiner, zu Beginn manchmal auch technisch unvollkommener Schritt auf dem weiten Weg zu einer funktionierenden DDP-Lösung.

In der Anfangszeit,traten folgende Probleme auf:

- Das Konzept

Wenn im DDP-Konzept keine sinnvolle Möglichkeit für verteilte Datenbanken besteht - überwiegend bei Versicherungsgesellschaften und bei Banken das große Problem -, muß schon das Grobkonzept viele Zugeständnisse bezüglich des Datenaustausches zwischen Vorrechner und Zentralrechner machen. Damit ist auch der Vorteil der Unabhängigkeit vom Zentralrechner weitgehend eliminiert.

Für diese Kommunikation muß Software entwickelt werden - sie wird oft nicht vom Hersteller geliefert -, außerdem sind viele Anwendungsprogramme dafür zu schreiben. Das ist ein zusätzlicher beträchtlicher Entwicklungsaufwand, der die "Piloten" der DDP-Strategie auch vor höchste qualitative Leistungsanforderungen gestellt hat.

- DieProgrammierung

Die gleiche für den Großrechner hausintern benutzte Programmiersprache für den Vorrechner, zum Beispiel Cobol für die IBM 8100v täuscht oft. Es gibt Unterschiede in den Sprachelemente für die Ein-/Ausgabeprozeduren - Vorrechner haben natürlich keine Datenbanksoftware, vergleichbar zum Beispiel mit IMS. Sie haben meist nur simple Zugriffsmethoden, die den früheren DAM- oder ISAM-Zugriffen ähneln.

Das wesentlich größere Problem besteht aber in den technischen Anforderungen des Vorrechners an Programmgröße, Programmstruktur und insbesondere den modularen Aufbau eines Programmsystems. Hier muß man nun lernen. Außerdem gibt es völlig andere Verfahren für Programmentwicklung und Archivierung. Das führt fast zwangsläufig zum Aufbau einer eigenen Programmentwicklungsmannschaft für Vorrechnerprogramme.

Die personelle Unterscheidung von "Host-Programmierern" und "Vorrechner-Programmierern" geht dann bis in die Projektgruppe der Anwendungsentwicklung. Insbesondere der notwendige Erfahrungsaufbau bei der Mannschaft für die Vorrechner ergibt einen meist nicht vorherkalkulierbaren Mehraufwand in der Entwicklung.

- Keine dezentrale Anwendungsentwicklung

In der Anfangszeit ist man sicher gut beraten, Entwicklung und Änderung von Programmen aus Sicherheits- und Homogenitätsgesichtspunkten nach außen zu verlagern. Damit war die individuelle Entwicklungsmöglichkeit für einzelne Betriebsstätten jedoch praktisch nicht vorhanden.

- Vorrechner sind keine idealen Entwicklungsmaschinen

Die Leistung der Vorrechner ist meist insbesondere bei der Programmentwicklung sehr begrenz. Wenn man nicht auf den Host ausweichen kann, was natürlich die Existenz entsprechender Compiler voraussetzt, muß man der Entwicklung mehrere Maschinen zur Verfügung stellen, will man dort nicht in Engpässe geraten.

- Probleme der Praxisanwendung

Die anfängliche DDP-Praxis bei den "Piloten" bot einige Enttäusch ungen, auch für den Nutzer:

- Leistungsfähigkeit der Vorrechner

Nicht die Leistung der Hardware, die Software ist bei Vorrechnern meist das Problem. So waren zum Beispiel zwar Hauptspeicher und Zykluszeit hardwaremäßig auch bei den früheren Maschinen IBM 8140 keineswegs knapp bemessen. Jedoch nahm das enorm große Betriebssystem DPPX - eigens für den DDP-Modus entwickelt - verhältnismäßig viel Rechnerleistung in Anspruch. Der übrigbleibende Teil für die Anwendungsseite war insbesondere für größere dezentrale Betriebsstätten oft nicht ausreichend, so daß statt einer geplanten Maschine mehrere installiert werden mußten.

Das beeinträchtigte die Wirtschaftlichkeit - höhere Kosten auf der dezentralen Seite -, es stellte aber auch das Anwendungskonzept vor neue Probleme. Da Vorrechner sich nun mal nicht einfach zu einem Multiprozessor zusammenschließen lassen, gab es Aufteilungsprobleme dezentral gespeicherter und online aktualisierter Daten, wenn mehr als ein System zum Einsatz kam.

- Die Anwenderverfügbarkeit

Vorrechner sind keineswegs anfällig. Bei einem DDP-Konzept mit zentraler Datenbankführung aber stellen sie einfach eine zusätzliche Komponente im Gesamtsystem dar, die hard-, insbesondere aber auch softwaremäßig ausfallen. Ist der Vorrechner also abhängig von der Kommunikation mit dem Host, wird die dezentrale Betriebsstätte nicht unabhängig vom zentralen Rechner. Statt dessen sinkt umgekehrt die Anwenderverfügbarkeit zwangsläufig durch die Zwischenschaltung des Vorrechners. Das Problem kann man natürlich durch Konzepterweiterung verringern.

- Wartezeiten am Bildschirm

Bei zentral geführten Datenbanken beginnt die Bearbeitung eines Geschäftsvorfalls am Bildschirm der dezentralen Betriebsstätte normalerweise zunächst damit, daß der Vorrechner sich aufgrund eingegebener Schlüssel vom Zentralrechner alle notwendigen Daten zur Bearbeitung des Falles holt und zwischenspeichert. Für das erste Dialogbild, auf dem Daten angezeigt werden, muß der Sachbearbeiter die schönen, früher gewohnten Antwortzeiten von meist unter drei Sekunden vergessen und sich an solche mit bis zehn Sekunden und auch darüber gewöhnen. Erst die Folgebilder ohne Hostzugriff kommen wesentlich schneller.

- Komplizierte Abwicklung im zentralen Rechenzentrum

Vorrechner sollten normalerweise bedienerlos sein. Ein Operator in der dezentralen Einheit ist nicht nötig. Zum Beispiel ist die 8100 der IBM bedienerlos betreibbar. Dafür ist jedoch der Betrieb der Vorrechner mit allem, was dazu gehört, vom zentralen RZ aus gesteuert worden. Dazu gehört auch die Fehleranalyse von Hard- und Softwareabbrüchen im Vorrechner, auch das Abholen der Daten zum nächtlichen zentralen Update und das Rücksenden aktualisierter Daten, Tabellen und Fehlermeldungen am nächsten Morgen vor Betriebsbeginn in der dezentralen Betriebsstätte.

Die strenge Einhaltung des 24-Stunden-Zyklus in diesem Kreislauf setzt höchste Anforderungen an Fehlerbeseitigung bei nächtlichen Abbrüchen oder Netzwerkschwierigkeiten. Welche hohen und völlig neuen Anforderungen dadurch auf den RZ-Betrieb zukommen, braucht hier sicher nicht weiter ausgeführt zu werden.

In der Praxis blieben wenige Vorteile übrig

Insgesamt gesehen blieb also in der Anfangszeit wenig von den erwarteten Vorteilen der verteilten Verarbeitung in der Praxis übrig, für den Fachmann sicherlich nicht unerwartet. Daß eine solche Strategie sich erst langfristig positiv auswirkt und daß zu Beginn über Jahre von allen Seiten - EDV und Anwender - große Investitionen durchgeführt werden müssen, hat sicher nur von der Höhe der Investitionen her überrascht.

Für die Anfangszeit des Betriebs eines DDP-Konzepts kann man zusammenassen:

(1) höhere Entwicklungskosten sowie Aufbau eines eigenen Entwicklungsteams für Vorrechner;

(2) wahrscheinlich keine Gesamtkostenreduzierung durch den Einsatz von Vorrechnern, eher eine Kostensteigerung;

(3) zu Anfang keine Nutzerzufriedenheit, da die Nacheile teilweise längerer Antwortzeiten und geringerer Verfügbarkeit die anfänglich für den Nutzer erzielbaren Vorteile zumindest subjektiv überwiegen;

(4) Unabhängigkeit vom Zentralrechner ist bei zentraler Datenbankführung nicht zu erreichen; redundante Datenspeicherung auf dem Vorrechner in größerem Umfang ist sicher nicht wirtschaftlich;

(5) individuelle Lösungsmöglichkeiten für den dezentralen Benutzer wird es in der Anfangszeit kaum geben - Insbesondere wird man aus Sicherheitsgründen zunächst keine dezentrale Programmänderung und -entwicklung zulassen;

(6) Die Flexibilität ist im Moment noch eine Zukunftsperspektive.

Lösung aufgeschoben

Diese Gesichtspunkte haben zunächst viele potentielle Anwender von DDP davon abgeschreckt, diesen Weg zu gehen. Allerdings haben die meisten eine solche Lösung nicht aufgehoben, sondern nur aufgeschoben; man wollte zunächst die Erfahrungen, die andere damit machen, abwarten. Die Erfahrungen liegen nun vor. Der Grund, weshalb heute doch merkbar einige der großen Anzahl von "Zentralisten" sich in Richtung DDP bewegen, hat aber in erster Linie wohl die folgenden Ursachen:

(1) Die Preise für Minis und Mikros sind - bei gestiegener Leistungsfähigkeit - derart in den Keller gegangen, daß plötzlich selbst für so kostenempfindliche dezentrale Einheiten wie Versicherungsagenturen der Einsatz eines eigenen Computers im Büro wirtschaftlich geworden ist. Die Anzahl der Interessenten und potentiellen Nutzer einer DDP-Lösung ist deshalb immens gestiegen.

(2) Bisher wurden diese Minis und Mikros meist als Stand-alone- beziehungsweise Offline-Geräte geliefert. Nunmehr weisen viele Hersteller die Netzwerk- beziehungsweise SNA-Fähigkeit ihrer Systeme aus. Allerdings muß man hier noch aufpassen. Vor Kaufabschluß sollte man den Anschluß an den Großrechner sind die Kommunikation des Minis oder PCs mit dem Rechner testen: Nicht jeder Hersteller kann das halten, was er zur Zeit verspricht.

(3) Eine sensationelle Entwicklung hat sich fast unbemerkt bei der Programmentwicklung vollzogen. Die Programmiersprachen (meist auf Basic-Basis), Software-Tools und Entwicklungshilfen haben dazu geführt, daß zumindest einfachere und ein-/ ausgabeintensive sowie dialogorientierte Programme auf diesen Minis in wesentlich kürzerer Zeit entwickelt werden können, als dies bisher für Cobol- oder PL/1-Programme für den Großrechner der Fall war.

So konnte zum Beispiel ein Agentursystem für Nixdorf 8870 mit vier großen Subsystemen (Kunden-, Bestands- und Schadenanzeigen, Inkasso, Computer-Textverarbeitung, Außendienststeuerung einschließlich Stammdatenpflege sowie Datenträgeraustausch) in knapp einem halben Jahr - einschließlich Detailentwurf - realisiert werden, ohne dabei eine größere Entwicklungsmannschaft zu bemühen; sicherlich eine vor Jahren noch für unglaublich gehaltene Leistung.

Außerdem ist die Programmsprache und Progrämmierung so einfach geworden, daß selbst ein EDV-Laie, wie zum Beispiel ein Agenturinhaber, sie erlernen und für eigene Anwendungen benutzen kann. Allerdings muß man sich zur Zeit noch an einen Hersteller binden, wenn man die spezifischen Entwicklungshilfen in Anspruch nehmen will. Das Betriebssystem CP/M, das herstellerunabhängig ist, bietet das nicht in dem vorgenannten Umfang.

(4) Die amerikanische Tendenz, Minis gleich komplett mit Anwendersoftware zu liefern, beginnt sich auch bei uns durchzusetzen. Hersteller, vor allem aber Softwarehäuser bieten fix und fertige Systeme zusammen mit der Hardware an, die auch an Großrechner anschließbar sind.

(5) Die Bundespost bietet mit Datex-P und -L sowie ab 1984 mit Btx endlich Netzwerkmöglichkeiten an, die bei DDP zu echten und bedeutenden Leitungskostenreduzierungen gegenüber einer zentralen Lösung mit Standleitungen führen können, Preisgünstige Netzwerke haben in den USA schon seit vielen Jahren DDP in ganz anderem Maße unterstützt als bei uns.

Zusammenfassend läßt sich daher Folgendes feststellen:

- Für dezentral organisierte Unternehmen - selbst wenn nur der Vertrieb dezentral arbeitet - ist verteilte Verarbeitung die richtige Langfriststrategie der Zukunft. Wie das DDP-System jedoch konzipiert ist, das heißt, welche dezentralen Rechner eingesetzt werden und was man mit ihnen macht, ist Sache jedes Unternehmens selbst und stellt eine neue Herausforderung für das EDV-Management in der Systementwicklung dar.

- Das riesige Rechenzentrum mit Superrechnern im zentralen Konzept ist nicht mehr in jedem Fall die kostengünstigste Alternative, zu sehr sind die Preise von Minis und Mikros verfallen.

- Minis und Mikros als Vorrechner bieten auch eine ideale Möglichkeit, EDV-Entwicklungsaktivitäten zu dezentralisieren und diesen Flaschenhals abzubauen. Einen Mini in Basic zu programmieren, werden bald unsere Kinder im Schulunterricht lernen; teilweise gibt es das sogar schon. Damit ist die Zielsetzung der Anwendungsindividualität bei einem DDP-Konzept meines Erachtens in optimaler Form unterstützt worden.

- Selbst kleine dezentrale Einheiten wie zum Beispiel eine Versicherungsagentur werden 1990 überwiegend mit einem eigenen Kleincomputer ausgestattet sein, der an das zentrale Rechenzentrum angeschlossen ist.

Man muß heute wohl sagen: Die Vorreiter der verteilten Verarbeitung, die in der Vergangenheit oft sehr kritisch gesehen, ja belächelt wurden, sind sicher auf dem richtigen Weg gewesen.

Sicher sind bei diesen Anwendern oft enorme Summen in diese Strategie investiert worden, die auch unternehmensintern teilweise zu Kontroversen geführt haben. Diese Investitionen aber führen heute zu einem Erfahrungs- und Wissensvorsprung gegenüber dem übrigen Markt, der in Zukunft diese hohen Investitionen mehr als nur rechtfertigen wird.

Dr. Peter Naumann trug in verschiedenen Großunternehmen als DV/Org.-Leiter oder Vorstandsmitglied die Verantwortung für die Einführung von DDP-Konzepten.