Ein kleineres TP-System mit wenigen Abfrage-Terminals auf einem Universal-Rechner zu realisieren, ist beinahe ebenso schwierig. wie ein großes Datenfernverarbeitungs -Netz zu entwerfen zu programmieren, zu testen und in Betrieb zu nehmen. Trotzdem macht man sich beim ersten Start nicht die notwendige Mühe und überläßt das Klein-Projekt dem Nächsten, der gerade einen ClCS-Kurs besucht hat und ansonsten gute Cobol-Anwendungen schreibt. Andererseits Die Mehrheit des Wissens, das für die Realisierung von Batch-Systemen gilt, ist irrelevant für Online-Projekte, und davon ist die Mehrheit wohl im Online-Kontext geradezu gefährlich. Ein entsprechend horrendes Antwortzeitverhalten findet man dann vielfach bei TP-Dialog-Anwendungen mit bis zu zehn Terminals- und das sind wohl immer noch die meisten.
Daß aller Anfang schwer ist, zeigt sich auch auf der Hardware-Seite. Wer an eine 370/158 ein erstes Terminal anhängen will, bezahlt erst mal eine Viertel Million für die Hardware. dazu dann noch den Preis für die Datenstation.
Je einfacher also eine geplante TP-Anwendung ist, desto schwieriger ist es, die Kosten zu rechtfertigen, desto mehr wird der Aufwand für die Realisation unterschätzt, desto schlechter ist schließlich das Gesamtergebnis.
Peter-Prinzip
Wenn aber letztlich eine TP-Anwendung zufriedenstellend läuft. dann meistens nicht lange. Denn erfolgreich arbeitende Online-Systeme expandieren in entsprechend großen Unternehmen, bis sie ineffizient werden. Je mehr Vorteile ein Online-System den Benutzern bringt. desto mehr werden damit arbeiten wollen, und die EDV-Abteilung wird so lange neue Möglichkeiten und Anwendungen hinzufügen bis alles zusammenbricht. Denn das überempfindliche System reagiert überproportional. Bei doppeltem Nachrichtenverkehr werden sich die Antwortzeiten weit mehr als verdoppeln - man weiß es genau erst. wenn es zu spät ist. Erfolg wird das Motiv für Mißerfolg. Man fühlt sich an das "Peter-Prinzip" erinnert. das bekanntlich besagt, daß Manager so lange befördert werden, bis sie die Stufe erreichen, auf der sie ihren Aufgaben nicht mehr gewachsen sind. Mit TP-Systemen ist es ganz ähnlich.
Peripherie im Mittelpunkt
Grund für Mißerfolge ist ferner, daß üblicherweise TP-Anwendungen in falscher Reihenfolge geplant werden. Man denkt zunächst an die Zentralarbeit und arbeitet sich dann nach außen vor. Terminals stehen als letzte Hardware-Hierarchie-Stufe irgendwo am Rande. Aber für den Anwender ist seine Datenstation alles, was er vom System sieht. Das Terminal sollte also im Mittelpunkt der Anwendung stehen. Allein wenn sein Einsatz und die damit verbundene organisatorische Umstellung mehr Effizienz und letztlich mehr Profit versprechen, rechtfertigt sich zunächst von außen nach innen zu planen.
Aus dieser neuen Sicht erscheint auch Reinrassigkeit der Gesamtlosung weniger als eine Tugend, denn das optimale Terminal ist zusammen mit der Anwendungssoftware wichtigste Systemkomponente. Auch wer auf Reinrassigkeit bedacht ist. hat ohnehin immer einen zweiten Partner - nämlich die Bundespost. Warum dann nicht auch bei den Modems oder Konzentratoren oder Steuereinheiten mixen.
Es ist einfach nicht wahr daß die Zahl der Probleme quadratisch zur Zahl der in einem TP-System einbezogenen Lieferanten wächst. Das ist zwar eine griffige Formel - aber sie wird nur von Mainframe-Herstellern vorgetragen .