Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

19.10.1979

Distributed Processing: Zentral oder dezentral programmieren?

"Ich halte es für einen Unsinn, zu glauben, daß sich DV-Chefs durch Distributed Processing selbst wegrationalisieren", wettert Kurt Brühl, EDV-Leiter bei den Westdeutschen Gipswerken in lphofen. Die Ja/Nein-Entscheidung ist in vielen Unternehmen bereits zugunsten verteilter Intelligenz geklärt. Im Mittelpunkt der Diskussion steht mittlerweile vielmehr die Frage, ob zentral oder dezentral programmiert werden soll. "Zentrale Systeme haben den Vorteil größerer Flexibilität", meint Klaus Wiegand, Abteilungsleiter Betriebssysteme bei der DFVLR in Oberpfaffenhofen. Wiegand schwelgt jedoch nicht in Euphorie, sondern sieht auch hier Probleme, die seiner Meinung primär in der Verfügbarkeit bei Online-Systemen lägen. ha

Robert Coppens, Manager EDV und Organisation, CBS Schallplatten GmbH, Frankfurt

Zur Problematik der, zentralen oder dezentralen Programmierung bei Distributed Processing möchte ich vorab bemerken, daß ich sowohl in der Vergangenheit als auch in den Gegenwart mit diesem Thema konfrontiert wurde und werde. Auch in der Zukunft muß ich mich dieser Frage immer wieder erneut stellen. In der Vergangenheit begegnete ich dem Problem bei einem Vertragshändler in der Automobilbranche. Es stand zur Diskussion, ein zentrales System zu dezentralisieren. Gleichartigkeit war sowohl in den Produkten als auch in der Strukturierung der Kunden und des Marktes gegeben. Zusammen mit dem Hersteller, begannen wir, das DP-System zu entwickeln. Aber beiseite in der Entwicklungszeit stellte sich heraus, daß Dezentralisierung der, Programmierung nicht sinnvoll war. Wir entschieden uns erneut für, die zentrale Entwicklung und stellten das Softwarepaket den einzelnen Betrieben zur Verfügung. Dieses System hat sich bewährt. Auch die halbjährige Kontrollphase zeigte, daß es noch immer möglich war, eine Programmpflege im Nachhinein zentral durchzuführen.

Zum DP möchte ich grundsätzlich sagen, daß die technologische Entwicklung und auch das Preis-Leistungs-Verhältnis auf dem EDV-Markt, vor allem, was die Klein- und Mittelbetriebe betrifft, sich nicht nur total verändert, sondern auch enorme Fortschritte gemacht hat. Noch vor einigen Jahren arbeiteten sogar Kleinbetriebe verstärkt dezentralisiert. Dies mußte in einigen Branchen völlig neu bedacht werden.

Als wir bei CBS Distributed Processing einführten, wurde die Programmentwicklung dezentral durchgeführt. Wir, arbeiteten mit einem freien Rechenzentrum in Kopenhagen zusammen, welches die reine Programmierung übernahm. Von unserem Unternehmen wunden die Systemanalytiker, und Organisatoren gestellt. Die Entwicklung wurde also dezentralisiert: zentral wurde nur die Programmierung in Kopenhagen übernommen. Dort war einfach das entsprechende Programmierungs-Know-how speziell für unsere Anlage vorhanden. Während der, Entwicklungsphase hatten wir, neben zusätzlichen Kosten vor allem die durch die dezentrale, Programmierung enstandene Reibungsverluste zu beklagen. Diese entstanden hauptsächlich durch die räumliche Distanz.

Hans-J. Kusenbach, Leiter der EDV und Organisation, Gierling Bremsen GmbH, Koblenz

Ob bei der Entwicklung von Distributed Processing zentrale oder dezentrale Programmierung bevorzugt werden soll, kann nur in Abhängigkeit von definierten Voraussetzungen beantwortet werden. Grob analysiert sind dies primär zwei Dinge: der jeweilige Organisationsstand eines Unternehmens im EDV-Bereich (Standardisierung) und die Unternehmenspolitik bei der Delegation von Verantwortung an zentrale oder dezentrale Stellen (Abteilungen, Zweigwerke, Tochterunternehmen). Danach zeigt sich von selbst, ob gemeinsam genutzte Informationen, also Daten oder Programme, zentral oder dezentral angewandt werden sollen. Die Frage nach einer gemeinsamen Datenbank wäre hier ebenfalls angebracht.

Grundsätzlich bin ich der Meinung, daß die Frage nach dezentraler oder zentraler Programmierung bei DP leicht zu beantworten ist, wenn es sich nur um einen Unternehmensort handelt. Komplexer wird allerdings das Problem bei örtlich getrennten Unternehmen mit ähnlichen, gleichen und verschiedenen Anwendungssystemen. Wenn man von der Unternehmenspolitik einmal absieht, die sich ja meist immer noch einer rationalen Betrachtung aus der Sicht der Datenverarbeitung entzieht, so würde ich unter organisatorischen Aspekten das Problem zentrale oder dezentrale Programmierung bei DP folgendermaßen sehen: Bei einem Unternehmensort wäre die Zielsetzung immer zentrale Programmierung - bei mehreren Unternehmensorten mit gemeinsamem Management käme sowohl zentrale als auch dezentrale Programmierung in Frage.

Eine Realisierung des Projektes müßte in folgenden Phasen ablaufen:

1. Standardisierung von Codes, Schlüsseln und Datenfeldern bei Stammdateien (Feldaufbau und -nahme) im Falle einer Mehrfachnutzung und zentrale Verwaltung (Handbuch).

2.Festlegung von gemeinsamen Datenfeldern in Stammdateien (von der Auftragsdatei bis zur Teilestammdatei) für zentrale und einoder mehrfache dezentrale Nutzung als Voraussetzung für Standardisierung von Programmen und mehrfache Nutzung sowie Festlegen von einfach benutzten Datenfeldern (zentral oder dezentral), die später eventuell einmal den Status eines gemeinsamen Datenfeldes erreichen können.

3. Bildung von gemeinsamen Anwendungsarbeitskreisen besetzt aus EDV-Koordinatoren der Abteilungen und den Systemanalytikern der Programmierung.

4. Aufbau einer zentralen Programmierung (Gruppe aus Systemanalytikern und Programmierern) und bei örtlich getrennten Unternehmen Abbau oder Aufbau der dezentralen Programmierung auf eine arbeitsfähige Mindestgruppe sowie Trennung der Aufgabenbereiche nach zentralen und dezentralen Anwendungen.

Klaus Wiegand, Abteilungsleiter Betriebssysteme, DFVLR Deutsche Forschungs- und Versuchsanstalt für Luft- und Raumfahrt, Oberpfaffenhofen

Die Beantwortung der Frage, ob bei der Entwicklung von Distributed Processing zentrale oder dezentrale Programmierung bevorzugt werden soll, enthält sicherlich kein Patentrezept. Prinzipiell sollte eine Entscheidung jedoch vorerst immer unter Berücksichtigung der, spezifischen Umgebung eines Anwenders gefällt werden. Beide Lösungsansätze bieten Vor- und Nachteile, auf die ich nachstehend eingehen möchte Die zentralen Systeme beinhalten den Vorteil einer größeren Flexibilität und in der Regel durfte ein umfangreicheres Angebot an unterstützender Software vorhanden sein. Alle Zugriffsmethoden und sämtliche Datenorganisationsmethoden sind verfügbar. Unter Berücksichtigung, daß heute die Software pro Zentraleinheit lizenzpflichtig ist, ergeben sich im Einsatz oder bei der Programmerstellung auf Großsystemen Kosteneinsparungen, wenn die Software ausschließlich auf einer zentralen Anlage gemietet werden muß. Ein weiterer Vorteil liegt darin, daß mehrere Leute eine gemeinsame Datenbasis vorfinden.

Probleme gibt es hier jedoch vor, allem in der Verfügbarkeit bei Online-Systemen. Weiterhin gibt es häufig Komplikationen im Antwortzeit-Verhalten, wo also die Reaktionszeiten für den einzelnen Benutzer letztendlich relativ langsam sind. Die Nachteile bei Großsystemen wirken sich schließlich als Vorteile bei dezentralen Systemen aus. Hier besteht durch den relativ geringen Anschluß von Terminals ein gutes Antwortzeit-Verhalten. Der Benutzer hat eine hohe Verfügbarkeit des Systems und ist nicht auf Bundespost, TP-Equipment oder Zentralanlage angewiesen. Probleme treten hier, allerdings wieder auf, wenn man umfangreiche unterstützende Software benötigt, um die einzelnen Programme zu schreiben. Da außerdem auf jedem zentralen Rechner letzlich die gleichen Lizenzprogramme installiert werden müssen, führt dies zu zusätzlichen Kosten.

Weitere Probleme treten dort auf, wo mehrere Gruppen von Mitarbeitern an verschiedenen dezentralen Standorten an gemeinsamen Projekten arbeiten und untereinander, kommunizieren müssen. Die dezentralen Datenbestände sind im Regelfall nicht synchronisiert. so daß die Leute mit unterschiedlichen Versionen konfrontiert werden.

In unserem Unternehmen sehen wir einen Lösungsansatz in der, Verwendung beider Verfahren.

Kurt Brühl, Leiter der Organisation und EDV, Westdeutsche Gipswerke, lphofen

Grundsätzlich stehe ich der Distributed-Processing-Entwicklung sehr positiv gegenüber. Ich halte es für einen ausgemachten Unsinn zu behaupten, daß sich damit die EDV-Chefs selbst wegrationalisieren wurden, wie es verschiedentlich in der COMPUTERWOCHE behauptet wurde. Ich bin der Meinung, daß die Distributed-Processing-Entwicklung neue Aufgaben schafft und nur die EDV-Chefs hiervon negativ betroffen werden, die sich selbst seit längerer Zeit nur für die EDV, und zwar für das "Zentrale Rechenzentrum", verantwortlich hielten. Heute ist es notwendiger denn je, sich mit dieser Entwicklung zu beschäftigen, da gerade auf diesem Markt von der Hardware-Seite her Preiseinbrüche zu verzeichnen sind, wie wir sie in der Groß-EDV bisher noch nicht gekannt haben, Leider ist der Verbund der "kleinen Geräte" sowie die Software-Herstellung nicht immer standardisiert noch liegen gesicherte Erfahrungen im umfangreichen Einsatz vor. Ich spreche hier nicht von der mittleren Datentechnik.

Prinzipiell bin ich für eine zentrale Programmentwicklung. AIlerdings mit der Einschränkung, daß die Außenstellen zumindest branchenähnliche Probleme haben, so daß die eigentlichen Vorteile, nämlich Multiplizieren des zentralen EDV-Wissens mit minimalem personellen Einsatz auf die Außenstellen. erhalten bleiben. Ich denke hierbei nicht nur an die Software-Entwicklung, sondern auch an die Ablauf- und Büroorganisation, die als frankierende Maßnahmen in den Außenstellen unerläßlich sind, Auch von der Revisionsseite ist eine zentrale Programmentwicklung zu begrüßen.

Die weitere Frage bei Distributed-Processing: Mixed-Hardware ja oder nein, möchte ich mit einem " jein" beantworten. In unserem Falle haben wir der zentralen Programmiersprache RPG den Vorzug gegeben, so daß wir insgesamt bei einem Hersteller geblieben sind.

Da hier jedoch RPG im Online-Teil auch eine Art eigene Programmiersprache darstellt, gilt diesei Vorteil nur mit Einschränkung. In unserem Falle wäre ein Umschreiben der bisherigen Programme auf ein anderes System zeitraubend und teuer gewesen.

Als Idealfall wäre natürlich anzusehen, wenn man sowohl für die zentrale EDV als auch für die dezentralen Stellen mit einer einheitlichen Programmiersprache und mit kompatiblen Betriebssystemen auskäme. Dieser Wunschtraum durfte aber nur für absolute Neuanwender erfüllbar sein.