Salzburger Sparkasse realisiert Unix-Projekt (Teil 2 und Schluß)

Client-Server-Architektur: Eine Bank riskiert die DV-NeuordnungAls eines der ersten Bankinstitute überhaupt hat sich die Salzburger Sparkasse dazu durchgerungen, eine durchgängige Client-Server-Architektur auf der Basis des Betriebssystems Unix einzuführe

30.08.1991

- schwierigeren hier eine kleine Aufstellung:

- Der Anschluß von optischen Platten unter Unix mit entsprechenden Treibern kann hoffentlich nur mehr eine Frage der Zeit sein.

- Genauso vermissen wir die Existenz einer Informix-Front-end-Maschine in unserer Client-Server-Architektur (vielleicht meldet sich der Hersteller?).

- Das Thema der MS-DOS-Pakete, die im Netz nicht manuell, sondern über Softwareverteilung installiert werden sollen, bereitet aus der Sicht der Lizenznummern und -behandlung etc. Kopfzerbrechen.

- Das Halten sowie hauptsächlich das Überprüfen der Richtigkeit der Softwarestände auf allen Workstations muß noch verfeinert werden.

Zu den Perspektiven läßt sich feststellen: In einer sich ständig verändernden DV-Welt muß man schon bei einem frisch implementierten Vorhaben an die beeinflussenden Faktoren in der näheren und mittelfristigen Zukunft denken sowie Auswirkungen vorausahnen und Lösungsansätze parat haben. Die Wirklichkeit kann uns schnell überholen.

Manchmal vergehen bekanntlich bis zu fünf Jahre zwischen Systementwurf und Abschluß der Installationen. Die Umweltänderungen können uns in folgenden Punkten das Leben schwer machen, wobei die Aufstellung sicher nicht vollständig ist:

- Mainframe-Umgebung: Das Spektrum der Änderungen reicht von der möglichen Notwendigkeit, zusätzliche Mainframe-Umgebungen zu unterstützen, über den totalen Wechsel der Mainframe-Umgebung bis hin zur vollständigen Dezentralisierung ohne Mainframe.

Die Anpassungsfähigkeit an eine Mainframe-Umgebung setzt voraus: 1. eine Netto-Datenschnittstelle Mainframe-Server (Terminalemulationen wie zum Beispiel 3270 sind schwierig zu behandeln), 2. die Austauschbarkeit des Kommunikationsservers (im Sinne des Softwaremoduls), 3. das Vorhandensein der flexiblen Werkzeuge für die Bearbeitung der Host-Daten (wie zum Beispiel die erwähnten Tools Pack, Unpack, Report, Data Dictionary, 4GL-Sprache für Ablaufsteuerung).

Ein Systemdesign für eine völlig dezentralisierte Umgebung ohne Mainframe wirft eine Menge zusätzlicher Fragen auf, deren Diskussion im Rahmen dieser Abhandlung nicht möglich ist.

Der Trend zur Nutzung des Mainframes als leistungsstarken Datenbankserver ist aber nicht zu übersehen.

- Markttendenzen und neue Technologien für dezentrale Systeme. Sie sind nicht berechenbar - trotzdem wird von Systemarchitekten verlangt, daß kein Weg verschlossen bleibt. Es ist weniger ein Problem in hardwarenahen Bereichen (siehe Beispiele AT-EISA-Bus, Speichertechnologien), als die Frage der Lauffähigkeit verschiedener Produkte in zahlreichen Systemumgebungen.

Nicht alle Softwarehersteller haben das Zeichen der unsicheren Zeit erkannt, und schreiben ihre Pakete portabel. Oft lassen sie dies absichtlich, um die Anwender in einer proprietären Welt gefangen zu halten. Für die Nicht-Intel-Architekturen ist die Zukunft absehbar: Unix. Ähnliches gilt auch für die Intel 80X86-Architekturen, so weit wir MS-DOS, Windows und OS/2-Anwendungen außer Acht lassen. Das allerdings ist kaum zu verantworten.

Eine Lösung ist möglich, doch sie kann durch die politischen Interessen der Monopolisten verhindert werden.

Sogenannte Binary compiler (DOS-binary zum Beispiel im RISC-instruction-set von Hunter Systems) haben sich noch nicht durchgesetzt. Mehr Hoffnung gilt dem Dos Prodected Mode Interface (DPMI) als De-facto-Standard, auf dem Unix-Nachfolgeprodukte der Pakete "VPIX" und "DOS Merge" aufsetzen können.

Durch DPMI kann eine binäre Kompatibilität der MS-DOS-Programme über alle Intel-Betriebssystem-Plattformen gewährleistet werden. Dieser Standard wird von allen Größen der MS-DOS-Industrie getragen (einschließlich Microsoft und neuerdings auch IBM).

- Standards werden immer wieder ergänzt. Das ist zwar erfreulich, zwingt uns aber zu Systemanpassungen. Wenn die Anwendungen richtig entworfen wurden (Abkapselung!) und der Systemlieferant sich zum Nachvollziehen der Normen verpflichtet hat, liegen die damit verbundenen Probleme weit unter denen, die bei einem vollständigen Redesign entstehen würden. Und zu dieser Vorgehensweise muß dringend geraten werden, denn die Bedeutung der Standardanwendungen, die auf Normen beruhen, wird immer größer (siehe nur EDI, X.400, X.500, Sicherheitsnormen).

Als Fazit läßt sich eindeutig feststellen: Die Anforderungen an komplizierte (Bank-)Systeme der Zukunft übersteigen die Möglichkeiten der klassischen MS-DOS/LAN-Plattformen. Wir haben uns deshalb und aus weiteren Gründen für Unix entschieden. Diese Entscheidung war richtig.

Trotzdem ist zu betonen, daß am Erfolg oder Mißerfolg eines Projektes am Ende doch noch weitere Faktoren Teil haben: Dazu zählen genaue Vorgaben, die klare Artikulierung der Projektziele, eine detaillierte Projektführung, die Abschätzung der Risiken, die Bekenntnisse des Herstellers zum Konzept, Teamgeist und kompetente Fachleute. Und wie immer, wenn etwas gelingen soll, harte Arbeit.