Die Fenstertechnik ist nicht mehr aus unserem Leben wegzudenken. DOS ist tot - so sagt man -, und das Graphical User Interface (GUI) lebt. Ueber Windows NT, OS/2 und LAN Manager streben die etablierten Autoritaeten der PC-Software-Industrie neue Betriebssysteme an, die eine offene, prozessorunabhaengige Applikationsbasis bilden sollen. Das hoert sich wunderbar an, aber die Schlange beisst sich in den Schwanz. Nachdem wir uns - dank des Aufschwungs, den die Programmiersprache C in den vergangenen zehn Jahren genommen hat - endlich von den hardware- und markengebundenen Plattformen freigemacht und uns auf ein einziges kompatibles Betriebssystem geeinigt haben, werden wir im naechsten Jahrzehnt wieder auf neue firmenspezifische Systeme stossen, die heute ausgearbeitet werden, zum Beispiel Pink und Cairo.
Alte Stammesfehden werden erneut - und heftiger - angefacht. Sie werden Opfer fordern. Wer als Sieger auf dem Podest erscheinen wird, laesst sich noch nicht abschaetzen. Gewiss ist jedoch, dass das Leben der Applikationsentwickler und Benutzer nicht einfacher wird. Dies laesst sich bereits an den letzten Zahlen aus der Wall Street ablesen, wo der Kurs saemtlicher Softwarebetriebe, die sich mit Fensteranwendungstechnik befassen, um 25 bis 75 Prozent gesunken ist.
Die Grossen der Branche, Lotus, Aldus, Sympatec, Borland und Wordstar, sind stark geschrumpft; nur Microsoft waechst weiter, wenn auch etwas langsamer als im vergangenen Jahr. In der Fachpresse laesst sich hier und da ein Raunen in den Reihen der ausgefuchsten PC-Benutzer vernehmen, die der Fenstertechnik muede sind und munkeln, dass das Arbeiten mit dem DOS-Platten- Betriebssystem wesentlich schneller vonstatten gehe. Das ist durchaus moeglich. Die Wirklichkeit zeigt aber, dass das einheitliche GUI seine Anerkennung in der Wirtschaft gefunden hat, und die untergliederte API-, OLE- und DDE-Technologie eine Errungenschaft ist, auf die wir nicht mehr verzichten koennen.
Eine (GUI-)Schwalbe macht jedoch noch keinen Sommer. Die grundsaetzlichen Probleme des DV-Einsatzes in der Wirtschaft bleiben bestehen.
Sicher, die horizontalen Anwendungspakete wie Textverarbeitung, Bildschirmtabellen und Desktop publishing (DTP) werden schoener, besser, einheitlicher und vor allem groesser sein. Aber die Applikationen, mit denen die taeglichen Broetchen verdient werden und die sich unter dem Begriff des Online Transaction Processing (OLTP) zusammenfassen lassen, sind an sich nicht horizontal. Zu ihnen gehoeren etwa die Bearbeitung und Aktualisierung von Bestaenden sowie Bestellungen, Einkaufsauftraege, Kundenlisten und Rechnungen. Jeder Betrieb hat hier seine eigene Arbeitsweise und Problematik, und die OLTP-Software muss auf diese individuellen Beduerfnisse zugeschnitten werden - mit oder ohne GUI.
Vor zwanzig Jahren mussten ausschliesslich Grossbetriebe mit diesen Problemen fertig werden. Dort wurden sie durch Einsatz eines Grossrechners und eines Teams hauseigener Programmierer geloest.
Noch vor zehn Jahren versuchten die mittelgrossen Betriebe, den Schwierigkeiten mit Minicomputern und teurer Beratung durch Systemhaeuser beizukommen. Heute ist OLTP Realitaet fuer alle Betriebe, die mit einer kleinen Anzahl von vernetzten PCs fuer Thekenverkauf, Lager, Buchhaltung und Verwaltung versuchen, das Geschaeft so effizient wie moeglich zu fuehren. Fuer diesen gewaltigen Markt muessen flexible, wirksame und individuelle Loesungen geschaffen werden - und auch heute ist das horizontal nicht machbar.
Wie sollte OLTP vom Standpunkt des Software-Entwicklers aus definiert werden? Einerseits muss ein relationales Datenbanksystem vorhanden sein - ein Kapitel fuer sich -, andererseits die Benutzer-Schnittstelle. Beim DOS-Platten-Betriebssystem war das ein einfacher, funktioneller, aber nicht besonders aufregender Dateneingabe-Bildschirm, der wenig Moeglichkeiten bot fuer Kreatives wie etwa eine huebsch aufgemachte Rechnung. Dies hat sich nun geaendert: Bei der Fenstertechnik ist die Benutzer-Schnittstelle ebenso zweckmaessig und benutzerfreundlich gestaltet wie die anderer, horizontaler Anwendungssysteme und laesst sich integrieren (Textverarbeitung, Zeichnung, Aufmachung). Dazwischen liegt das Herz der Anwendung: die "Application engine", die Programme, die die Vorgaenge und Transaktionen regeln und fuer die Kommunikation zwischen den Datenstationen und dem Server sorgen. An dieser Stelle wird Grundlegendes geleistet, hier liegen somit die groessten Probleme.
Obwohl man von allen Seiten kraeftig daran arbeitet, die Technologie zu verbessern, nehmen die Schwierigkeiten nicht ab. Ein Netz mit einer verteilten Datenbank fordert eine intelligente Client-Server-Technologie, die zeitgleiche Datenverarbeitung ueber mehrere Stationen ermoeglicht und bewaeltigt und dabei die Bearbeitungsgeschwindigkeit der Datenbank nicht abbremst.
Wie lobenswert das Streben der grossen Softwareverleger auch sein mag, ein X-base-Protokoll zu entwickeln, und wie schoen die Maerchen vom SQL-Server und Object Vision auch sein moegen, die bittere Wahrheit ist, dass der OLTP-Anwendungsentwickler, um diese Technologie realisieren zu koennen, seine Fertigkeiten in C ausdruecken muss. Und C ist nicht gerade die geeignete Sprache fuer das Schreiben von OLTP-Programmen.
"Give us high-level-tools", rufen die OLTP-Entwickler auf der ganzen Welt. Diese Tools gab es zwar in der Grossrechner-Welt, aber bedauerlicherweise fehlen sie in den vorhandenen Datenbank- und den konventionellen Programmiersprachen. Fuer diese Probleme muessen Loesungen bereitstehen, die einer staendigen Weiterentwicklung unterliegen.
Beispielsweise sollte ein speziell auf OLTP-Anwendungen ausgerichtetes Client-Server-Programmiersystem die Moeglichkeit bieten, objektorientierte und ereignisgesteuerte Applikationen herzustellen, die individuell angepasst sind, aber auf einer grossen Anzahl universell anwendbarer Module aufgebaut werden.
Eine integrierte Datenbank sorgt dafuer, dass die Applikationen viel schneller sind als bei Systemen, die mit gesonderten Datenbanken arbeiten und durch die Benutzeroberflaeche bedingte Schwaechen gleich mit eingebaut haben. Der Entwickler, der sich etwas weniger den Kopf zerbrechen und ein besseres Produkt liefern moechte - dies gilt im uebrigen auch fuer die Systemverwalter in Grossbetrieben und -einrichtungen -, koennte Nutzen daraus ziehen, sich aus der Abbhaengigkeit von seiner muehsam gewonnenen und somit teuren Programmiererfahrung zu loesen.