Die Installation von Mikrocomputern in mittleren und großen Unternehmen ist nicht nur eine Frage der Hardware-Auswahl. Es gehört ein durchgängiges, geschlossenes Konzept zur Einführung von Kleinstrechnern in Fachabteilungen und Außenstellen, das die bisherige Infrastruktur berücksichtigt und neue Funktionen behutsam anbietet. Der folgende Bericht analysiert eine Umfrage in amerikanischen Unternehmen über Mikro-Installationen und setzt die Erfahrungen, die bei der Einführung von Arbeitsplatzrechnern in einer deutschen Bank gemacht wurden, dazu in Relation.
Am 11. Januar 1985 veröffentlichte die COMPUTERWOCHE das Ergebnis einer Umfrage bei mittleren und großen amerikanischen Unternehmen über Installationsgewohnheiten in Sachen Mikrocomputer. Diese Umfrage zeigt Entwicklungen auf, die sich aller Voraussicht nach auch in Deutschland vollziehen werden. Dabei zeichnet sich einerseits eine Vereinheitlichung der Aufgabenstellungen und deren Lösung in Hard- und Software ab, andererseits ist eine Änderung der Entscheidungswege bei der Beschaffung von Mikrosystemen festzustellen Betrachtet man die Aufgaben, die mit einem Mikrocomputer erledigt werden sollen, so steht mit 95,6 Prozent die Tabellenkalkulation einsam an der Spitze. Ihr folgen Textverarbeitung mit 84,8 Prozent, Geschäftsgrafik mit 63 Prozent, Finanzplanung mit 51,4 Prozent und Großrechneranschluß mit 52,2 Prozent, wobei letzterer sich auf IBM-Anlagen beschränkte. Die ersten vier Plätze der "Hitparade" erklären sich daraus, daß sie im kommerziellen Bereich immer wiederkehrende Tätigkeiten darstellen, die durch einen Kleinrechner leicht automatisiert werden können. Das breite Angebot von entsprechender Software zeugt davon, daß viele Softwarehäuser diese Herausforderung angenommen haben. Interessant ist, daß der Anschluß an Großrechner bereits von 52,2 Prozent der Befragten als wichtig angesehen wird, denn solche Verbindungen können ohne zentralisiertes Organisationskonzept nicht gewinnbringend eingeführt werden. Offensichtlich sind die befragten Firmen bereit, sich diesen Herausforderungen zu stellen.
Ein Blick auf die bestehende EDV-Infrastruktur zeigt, daß 89,1 Prozent der befragten Unternehmen über einen Großrechner, 93,4 Prozent über Mikrocomputer verfügen, wobei der Schwerpunkt bei einer Zahl zwischen 5 und 14 Mikros liegt. Schlichte Folge aus diesen Zahlen: Praktisch jeder Großrechnerbetrieb setzt auch Mikros ein, aber - und das ist ein weiteres Ergebnis der Umfrage - 80,4 Prozent der Kleinstrechner werden nur als "Einzelkämpfer" genutzt auch wenn 17,3 Prozent in lokale Netze integriert sind und 27,1 Prozent auf Großrechner zugreifen könnten. Die letzte Zahl zeigt deutlich, daß es mit der organisierten Anbindung von Mikrocomputern an Großrechner wohl doch noch ein wenig hapert. Aber die Unternehmen geloben Besserung. Innerhalb von drei Jahren wollen 58,1 Prozent die installierten Arbeitsplatzrechner im Verbund mit dem Großrechner betreiben.
Mikro-Wildwuchs neigt sich dem Ende zu.
Eindeutige Aussagen gibt es über die eingesetzten Betriebssysteme: 73,3 Prozent nutzen MS-DOS und 51,3 Prozent Unix. Berücksichtigt man, daß MS-DOS ein Single-User-Betriebssystem, Unix hingegen mehrplatzfähig ist, so kann wohl behauptet werden, daß MS-DOS (und sein Ableger PS-DOS) bei den Einplatzsystemen und Unix bei den Mehrplatzsystemen die dominierenden Betriebssysteme sind. Das hat offensichtlich, auch IBM erkannt und kündigte im Februar für Rechner der /370-Architektur unter den Betriebsystemen MVS, VM und VSE eine Unix-Oberfläche an, die es gestattet, Unix-basierende Anwendungen auf IBM-Systeme zu transferieren.
Für Auswahl, Kauf, Installation und Betrieb der Systeme ist die zentrale EDV-/Organisationsabteilung verantwortlich. Die Zeiten des Mikro-Wildwuchses gehen ihrem Ende entgegen. Eine einheitliche Organisationsstruktur mit einheitlicher Hard- und Software ist gefragt und notwendig, wenn tatsächlich Systeme zu einem großen Verbund zusammengeschlossen werden sollen.
Doch wie sieht es in Deutschland aus? Die deutschen Unternehmen sind besser als ihr Ruf. Zwar geht die Einführung verteilter Systeme immer noch zögerlich voran, doch erfolgt die Installation in aller Regel bereits heute unter Federführung der zentralen DV-Abteilung. Daß nicht alle Probleme bei der Einführung verteilter Systeme gelöst sind, darüber legt ein Projekt Zeugnis ab, das eine deutsche Bank in Zusammenarbeit mit dem Echinger Hersteller eines Unix-basierenden Mehrplatzsystems (Kontron Mikrocomputer GmbH) realisierte.
Vor etwa zwei Jahren wurden Kontakte zwischen den EDV-Verantwortlichen und dem Vertrieb besagten Unternehmens geknüpft, die zu dem Beschluß führten, in gemeinsamer Anstrengung multifunktionale Arbeitsplätze in der Zentrale und den Außenstellen der Bank einzuführen. Diese Arbeitsplätze sollten im Zuge eines Stufenplans
þZugriff auf das Bilanz-Analysesystem auf der zentralen Siemens-Anlage haben,
þDatenfiles zwischen der Zentrale und der Außenstelle transferieren sowie
þTexte verarbeiten.
Mit dieser groben Spezifikation wurde begonnen und zunächst einmal die adäquate Maschine ausgesucht. Die Wahl fiel auf eine mehrplatzfähige Unix-Maschine mit dem M6800 als Zentralprozessor. Folgende Gründe führten zu dieser Entscheidung:
þEin Mehrplatzsystem bietet für kleine Gruppen wie Software-Entwicklungsteams oder -Abteilungen eines größeren Ganzen organisatorische Vorteile.
þMehrplatzsysteme gestatten eine zentrale Haltung von Daten, die von allen Mitarbeitern der Gruppe genutzt werden müssen. Für die Konsistenz der Daten sorgt das eingesetzte Betriebssystem.
þMehrplatzsysteme verfügen in der Regel über große Massenspeicher, heute sind einige hundert Megabyte kein Problem mehr.
þFür Mehrplatzsysteme stehen mächtige Datenbanken zur Verfügung, die zum Beispiel Terminkalender oder Projektverfolgungssysteme zu realisieren gestatten.
þUnter Unix stehen alle gängigen Hochsprachen zur Verfügung (Cobol war in diesem Fall conditio sine qua non) einschließlich "C", das, wenn es auf Geschwindigkeit ankommt, auch maschinennahe Programmierung gestattet.
þUnix verfügt über einen komfortablen Screen-Editor.
þUnix kann unter einer Benutzeroberfläche verborgen werden. Der Anwender muß sich also nicht mit den Betriebskommandos auseinandersetzen.
þUnix bietet mit dem SCCS (Source-Code-Control-System) bereits ein Hilfsmittel zur Ablaufsteuerung bei der Softwareentwicklung.
þAuf die zentrale Siemens-Anlage sollte über öffentliche Netze zugegriffen werden. Mehrplatzsysteme können in diesem Fall Kosten dadurch reduzieren, daß eine Anzahl von Teilnehmern gleichzeitig nur eine Leitung nutzt. Zudem muß auf der zentralen Seite nur ein Leitungspuffer zur Verfügung gestellt werden.
þWerden vier oder mehr Arbeitsplätze realisiert, sind Mehrplatzsysteme in der Anschaffung billiger. Zudem wird optionale Software in der Regel pro Maschine und nicht pro Arbeitsplatz lizensiert.
Nach der Entscheidung für ein Mehrplatzsystem mit dem (damals keineswegs populären) Unix-Betriebssystem wurde zunächst innerhalb der DV-Abteilung der Bank eine Projektgruppe gebildet. Diese hatte zur Aufgabe, den dezentralen Teil des auf dem Großrechner im wesentlichen vorhandenen Bilanz-Analysesystems zu definieren und zu realisieren. Um mit der ausgewählten Maschine und dem Betriebssystem vertraut zu werden, wurde eine Maschine in der DV-Abteilung installiert. Parallel dazu lief die Entwicklung von Hard- und Software für den Siemens-Anschluß. In die Maschine wurde eine intelligente Baugruppe integriert, auf der die von einem Kirchheimer Softwarehaus realisierte Siemens-Leitungsprozedur MSV-1 abläuft. Der Hardwarearchitektur folgend wurde für den Zentralprozessor M68000 Software geschrieben, die die Siemens-Datensichtgeräte 8160, 8161 und 9750 emuliert. Kommunikation von Programm zu Programm
Diese hard- und softwaremäßige Trennung zwischen Leitungsprozedur und Emulation sollte sich als entscheidender Vorteil herausstellen. Zum einen ist ein dedizierter Prozessor eher in der Lage, die Realtime-Anforderungen der Prozedur zu erfüllen als ein Prozessor, der darüber hinaus Anwendersoftware bedienen muß. Zum anderen kam, als die Terminalemulation zufriedenstellend von vier Sichtgeräten lief, der Wunsch auf, von Anwenderprogrammen aus auf die Leitungsprozedur zugreifen zu können. So sollte Programm-zu-Programm-Kommunikation ermöglicht und die Benutzer-Schnittstelle zum Bilanz-Analysesystem unabhängig vom Großrechner beziehungsweise der Terminalemulation gestaltet werden. Dieser Wunsch könnte bei der gegebenen Hard- und Softwarearchitektur kurzfristig erfüllt werden: Es wurden Subroutinen in "C" geschrieben, die auf die Leitungsprozedur zugreifen und es gestatten, Verbindungen zum Großrechner zu öffnen, Verbindungen zu schließen, Daten zu schreiben, Daten zu lesen und den Leistungsstatus abzufragen.
Diese Subroutinen sind aus jeder Hochsprache mit entsprechender Parameter- und Datenübergabe aufzurufen. Unabhängig von dieser Programm-zu-Programm-Kommunikation war ein Filetransfer entwickelt worden (ablauffähig auf der Siemens-Anlage als TIAM-Anwendung), der es gestattet, innerhalb einer Terminalemulation Daten mit hoher Geschwindigkeit zwischen Zentrale und Außenstellen auszutauschen. Damit standen zu Beginn des vergangenen Jahres folgende Komponenten zur Verfügung: - ein Multiprozessor-Mehrplatzsystem,
- die Terminalemulation von Siemens-Datensichtgeräten,
- ein schneller Filetransfer und
- eine Schnittstelle zwischen Leitungsprozedur und Hochsprachen.
Neue Tätigkeiten erfordern neue Hilfsmittel
Während der Entwicklungszeit der vorgenannten Komponenten war die erwähnte Projektgruppe nicht untätig geblieben. Sie hatte auf der Großrechneranlage das Bilanz-Analysesystem fertiggestellt und auch den größten Teil der Software bereits in Cobol geschrieben, der auf der dezentralen Seite ablaufen sollte. Dieser dezentrale Teil sollte jedoch schlaflose Nächte verursachen. Als diese Software nämlich per Filetransfer auf die dezentrale Seite transferiert worden war und neu übersetzt werden sollte, stellte sich heraus, daß der dezentrale Cobol-Compiler lediglich 64 Kilobyte adressieren konnte. Das Anwenderprogramm mußte folglich in Module aufgeteilt werden - angesichts einer installierten Speicherkapazität von einem Megabyte eine frustrierende Tätigkeit. Doch es standen zu der Zeit keine leistungsfähigeren C-Compiler zur Verfügung, so daß in diesen sauren Apfel gebissen werden mußte. Und wie es so geht: Neue Tätigkeiten erfordern neue Hilfsmittel. Als die jetzt dezentral vorhandene Software bearbeitet werden mußte, wurde deutlich, daß bei der Erstellung der Software auf dem Großrechner dessen Interaktiver Format Generator IFG intensiv genutzt worden war. Auf diese Möglichkeit sollte auch auf dezentraler Seite nicht verzichtet werden. So wurde ein Produkt geschaffen, daß es erlaubt, zentral erstellte Masken dezentral abzuspeichern und mit derselben Benutzeroberfläche, wie sie auf dem Großrechner existiert, weiterzuverarbeiten sowie dezentral bearbeitete Masken an die Zentrale zurückzugeben.
LEX löst
Textverarbeitungsprobleme
Im Herbst des vergangenen Jahres war es soweit: Das Bilanz-Analysesystem lief zur allgemeinen Zufriedenheit. Aber was war mit der Multifunktionalität, was war mit der Textverarbeitung? Für diesen Themenkreis hatte sich im ersten Quartal des Jahres 1984 ein Arbeitskreis etabliert, der die Anforderungen an die Textverarbeitung definieren sollte.
Ein hochauflösender Schwarzweiß-Bildschirm, höhenverstellbar, kipp- und drehbar, sowie eine frei bewegliche Tastatur mit separatem Zehnerblock und frei programmierbaren Tasten waren die Anforderungen an die Hardware. Die Software sollte WordStar-ähnlich sein, und so wurde XED als Textpaket ausgewählt. Doch bald wurde deutlich, daß der XED nicht alle Anforderungen erfüllen konnte. So mußten
- der Gebrauch von Dezimalkomma und -punkt deutschen Verhältnissen entsprechen,
- alle vier Grundrechenarten unterstützt werden, innerhalb einer Seite unterschiedliche Zeilenabstände definierbar sein,
- Tabulatoren innerhalb einer Seite veränderbar und abspeicherbar sein,
- Akzente druckbar sein,
- unveränderliche Blöcke definierbar und vor allen Dingen eine mächtige Adreßverwaltung vorhanden sein.
Diese Punkte unterstützte der XED mehr schlecht als recht. Der Grund, von diesem Textpaket abzusehen, lag jedoch in der Tatsache, daß während der Eingabe von Texten beziehungsweise während des Blätterns in Texten unendlich viele Zugriffe auf die Platte erfolgen. Der Effekt dieser Plattenzugriffe ist ein drastischer Leistungsverlust, so daß bei schneller Texteingabe die eingegebenen Zeichen nur mit Verzögerung am Bildschirm sichtbar werden. Als das Bilanz-Analysesystem zusammen mit der Textverarbeitung auf einer Maschine lief, wurde dieses "Nachhinken" unakzeptabel.
Den Ausweg aus diesem Dilemma bot das Textverarbeitungssystem LEX: Es erfüllt einen großen Teil der oben aufgeführten Punkte und ist zudem wesentlich schneller bei der
Eingabe und beim Blättern. Dafür hat dieses Paket andere Schwachstellen (die Darstellung am Schirm entspricht zum Beispiel bei Fettdruck oder Unterstreichen nicht dem Druckbild), so daß von Fall zu Fall entschieden werden muß, welches das optimale System ist.
Nachdem der Übergang auf LEX erfolgt und mittlerweile auch der Anschluß der Systeme an das Telex-Netz realisiert worden war, folgte mit Beginn dieses Jahres die Installation der Systeme in den Außenstellen. Unter Leitung der zentralen Org./DV-Abteilung wurde parallel zur Installation eine Schulung durchgeführt, die die Mitarbeiter mit Computersystemen vertraut machen sollte und sie in die Handhabung des Bilanz-Analysesystems einführte. Nur diese Funktion wurde zunächst eingeführt, die Textverarbeitung folgt, wenn zentral die Arbeitsabläufe abschließend definiert sind und eine gewisse Gewöhnung an die neuen Systeme eingetreten ist.
Abgeschlossen ist das Projekt damit jedoch noch nicht. Es ist die Textverarbeitung, die neue Bedürfnisse kreiert: Serienbriefe erfordern eine Datenbank, Jahresabschlüsse erfordern Kalkulationsprogramme und Statistiken werden durch Balken- oder Tortendiagramme lesbar. Datenbanken und Kalkulationsprogramme stehen unter Unix zur Verfügung; kritisch jedoch wird es bei grafischen Darstellungen, da dafür grafikfähige Terminals notwendig sind. Und welches Terminal hat schon den geforderten Schwarzweiß-Bildschirm, höhenverstellbar, drehbar, kippbar, mit einer flachen Tastatur, die über 44 Funktionstasten verfügt?
Es gibt noch viel zu tun
Diese Anforderungen und die Erfahrung, daß die Textverarbeitung selbst in abgemagerter Form für eine Maschine eine enorme Belastung darstellt, lassen die Frage zu, ob es nicht besser ist, auch innerhalb einer Abteilung die Intelligenz zu verteilen und Texte lokal zu verarbeiten, während die Datenhaltung und die Programmentwicklung auf der Abteilungszentrale erfolgt. Doch dafür sollte eine einheitliche Benutzeroberfläche auf dem Arbeitsplatzsystem und der Abteilungszentrale vorhanden sein, die Arbeitsplätze sollten, per Knopfdruck", eigenständige Systeme oder Terminals der Abteilungszentrale sein und auch weiterhin mit dem Großrechner kommunizieren können.
Das Projekt hat folglich eine ganze Reihe von Erkenntnissen gebracht:
1. Die Einführung verteilter Systeme sollte zentral erfolgen, vor allem bei Zugriff auf Systeme der Zentrale. 2. In der Zentrale sollten Projektgruppen gebildet werden, die Aufgaben definieren, gegebenenfalls realisieren, immer aber Ergebnisse überprüfen.
3. In der Zentrale sollte eine Gruppe von Anwendern die neuen Arbeitsmittel testen, da davon ausgegangen werden kann, daß auch die Projektgruppen nicht alle Bedürfnisse der Anwender kennen.
4. Die zentralen Projektgruppen sollten die Installation und die Schulung in den Außenstellen übernehmen.
5. Neue Funktionen sollten schrittweise an den Anwender gebracht werden.
6. Textverarbeitung stellt eine zentrale Aufgabe dar, da sie Tabellenkalkulation, Datenbanken und Grafik mit sich bringt. Die reine Texterstellung sollte dezentral und der Ausdruck von Texten abteilungszentral erfolgen ebenso wie die Haltung zentraler Daten wie Adreßdateien oder Terminkalender.
7. Mehrplatzsysteme stellen für Fachabteilungen ein wichtiges Arbeitsmittel zur Programmentwicklung, zur Datenhaltung, zur Projektverfolgung, zur Terminalemulation und -konzentration beim Großrechneranschluß dar.
8. Unix hat sich als mächtiges Betriebssystem auch im kommerziellen Bereich erwiesen.
Damit hat sich der Kreis zur anfangs erwähnten Untersuchung geschlossen. Offensichtlich sind die Anforderungen deutscher Unternehmen denen der amerikanischen sehr ähnlich, und offensichtlich gehorcht auch der Organisationsablauf allgemeingültigen Prinzipien. Dennoch: Es gibt noch viel zu tun.
o Dr. Rüdiger Both ist Produktleiter Datacom bei Kontron Mikrocomputer GmbH, Eching bei
München.