Am 17. März 1987 kündigte die IBM ihr Integrations-Konzept System-Anwendungs-Architektur (SAA) an. Die Software-Szene geriet in Aufruhr. Knapp acht Monate später haben sich die Gemüter zwar beruhigt, doch Fragen und Unsicherheiten bleiben bestehen. Der Rahmen der SAA-fähigen Produkte ist noch nicht eindeutig abgesteckt; welche Datenbank beispielsweise unterstützt werden soll, rätselt der Anwender: DB2 oder IMS? Wie verhält sich das auf Herstellerunabhängigkeit zielende Unix zu der neuen Einheitlichkeits-Philosphie des Marktführers, da SAA ebenfalls den Datenaustausch zwischen heterogenen Systemen gewährleisten soll - so diese den IBM-Spezifikationen entsprechen. Einig sind sich die Benutzer im Augenblick lediglich darin, daß die Umsetzung der Integrations-Strategie aufwendiger wird als geplant. "Aber das haben wir ja immer schon gewußt . . .", resümiert ein DV-Verantwortlicher aus Stuttgart.
Dr. Peter Buchen DV-Leitung, Allianz Lebensversicherungs-AG, Stuttgart
Bei der Allianz Lebensversicherung als großem "Produzenten von Informationen" hatte die Informationsverarbeitung sowie die Informations-Technologie schon sehr früh eine zentrale und strategische Bedeutung. Ergebnis heute sind hochintegrierte und leistungsstarke Anwendungen.
Dabei machen wir große Anstrengungen, um für den Außendienst der Allianz (über das gemeinsame deutschlandweite Terminalnetz der Allianz-Sach und -Leben) eine möglichst weitgehende Anwendungsportabilität zu erreichen, und zwar sowohl horizontal zwischen den verschiedenen Großrechnern im Allianz-Rechnerverbund als auch vertikal bis hin zum Bildschirm beziehungsweise PC. Daher war die Selbstverpflichtung der IBM zur durchgängigen Normierung und Standardisierung von Anwendungssystemen aus unserer Sicht mehr als überfällig. Spannend allerdings wird die Implementierung von SAA.
Nur drei Punkte greife ich heraus:
1. Anwendungsunterstützung Hierzu erscheint es uns wesentlich, daß über lange Zeit
- sowohl SAA-fähige Anwendungen,
- als auch bestehende 370-Anwendungen
von einheitlichen leistungsfähigen "Entwicklungs-Tools " gleichermaßen unterstützt werden (Thema: Verträglichkeit). Diese Tools sollten für alte wie neue Anwendungen sehr bald ein umfassendes Data Dictionary bereitstellen (Thema: Überführbarkeit).
Die derzeitige Ausklammerung von PL/1 und APL2 aus dem SAA-Konzept macht unruhig, hier sollte bald eine Klarstellung seitens IBM erfolgen.
2. Benutzerunterstützung
In der Schaffung einheitlicher Benutzeroberflächen für
unterschiedliche Anwendungssysteme liegt sicherlich ein großes Rationalisierungspotential. Wir sind hier sehr gespannt darauf, wie die Implementierung der Vereinheitlichung - insbesondere hinsichtlich der "Altlasten" - arbeitsmäßig bewältigt werden soll (durch den Kunden oder herstellerseitig durch leistungsfähige Werkzeuge oder zum Beispiel Umsetzer in den Tastaturen).
3. Kommunikationsunterstützung
Gemäß dem SAA-Konzept kann ein Datenaustausch (einschließlich Text, Grafik, Bilder) Anwendungsprogrammunabhängig erfolgen, das heißt aber auch Datenaustausch zwischen Knoten verschiedener Hersteller, wenn diese sich an die SAA-Spezifikationen halten. Die Implementierung des "Austausches strukturierter Informationsobjekte" ist somit entscheidend für die Wettbewerbssituation im DV-Markt. Daher sollte diesem Aspekt in der allgemeinen Diskussion über SAA mehr Aufmerksamkeit zukommen. Auch die Unix-Position hierzu ist uns bisher nicht deutlich.
Zusammenfassend hat IBM mit SAA einen strategisch längst erforderlichen Schritt getan. Die Umsetzung wird aufwendiger als wir alle uns das derzeit vorstellen können; aber das haben wir ja immer schon gewußt . . .
Wilfried Pohl DV-Leiter, Rheinisch-Westfälisches Elektrizitätswerk AG, Essen
Die SAA-Ankündigung der IBM vom Frühjahr 1987 ist in erster Linie eine - längst überfällige - Reaktion auf die latent immer vorhandene, aber in den letzten Jahren wachsende Kritik an den inkompatiblen Rechnerfamilien der IBM PCs, Abteilungsrechner und Großrechner. Dasselbe gilt für die Fülle verschiedener Benutzeroberflächen, Bildschirme, Tastaturen etc. Aus der Sicht von IBM-Großanwendern ist dieser Schritt grundsätzlich zu begrüßen. Die durchgängige Portabilität von dem neuen Personal System /2 hinauf zum Großrechner unter MVS/XA eröffnet neue Perspektiven, zum Beispiel Entwicklung von Anwendungen und Texten auf dem PC, produktiver Einsatz auf dem Großrechner unter völlig gleicher Oberfläche.
Der Zugewinn an Bequemlichkeit und Funktionalität durch SAA dürfte aber durch ein mehr an System-Overhead und damit auch ein Mehr an Hardwareleistung erkauft werden müssen.
Die Ankündigung von SAA wird die Produktwelt von Hardware, Betriebssoftware, Subsystemen und Standardsoftware zweiteilen und zwar in Produkte, die künftig von SAA unterstützt werden und solche, die es nicht werden. Leider ist die Palette der SAA-fähigen Produkte auch ein gutes halbes Jahr nach der SAA-Ankündigung für den Anwender noch nicht hinreichend deutlich. Insbesondere ist aber unklar, welche Produkte endgültig nicht SAA-unterstützt sein werden. Grundsätzlich wird sich der Anwender darauf einrichten müssen, daß pro Funktion (zum Beispiel bei Datenbanken DB2 oder IMS) nur ein Produkt durch SAA unterstützt wird.
Man darf aber wohl davon ausgehen, daß die IBM, wie in der Vergangenheit, Produktlinien mit großen Anwenderzahlen und damit entsprechenden Investitionssummen auch dann für eine längere Zeit weiterführt und weiterentwickelt ,wenn sie sich nicht oder noch nicht auf der Liste der künftig in SAA eingebundenen Systeme befinden sollten.
Bei allen Betrachtungen zum Thema "SAA" sollte man im Auge behalten, daß SAA von der IBM als langfristiges Projekt anzusehen ist, das in die neunziger Jahre hineinreicht. Der Anwender ist gut beraten, SAA zwar als strategische Perspektive im Auge zu behalten, die SAA-Auswirkungen auf die Tagesentscheidungen von heute jedoch mit Gelassenheit zu sehen.
Stefan Becker Geschäftsführer, RZplus GmbH, Böblingen
Wie überall in der Architektur ist das Fundament, auf dem der ganze Plan ruht, von größter Bedeutung. Als Fundament hat die IBM das relationale Datenbank-System gewählt und damit, so meine ich, die wichtigste Grundlage für die Dauerhaftigkeit der Architektur gelegt. Ein relationales Datenbank-System wird den Nutzen und die Qualität der Daten und damit auch die Datenverarbeitung steigern.
Ich habe noch eine ganze Reihe von Erwartungen bezüglich der Implementierung dieser relationalen Datenbank-Systeme.
Erstens meine ich, wäre es wichtig dafür zu sorgen, daß diese Systeme Daten untereinander austauschen können, ohne daß der Benutzer das steuern muß. Er müßte in der Lage sein, alle Daten als eine Einheit zu betrachten und zu verarbeiten, und die Systeme sorgen für den Transport und die Integrität. Eine weitere Erwartung wäre, daß das komplette relationale Modell im relationalen DBMS abgebildet wird.
Ein weiterer wichtiger Bestandteil der SAA ist SQL als universelle Datensprache in dieser Architektur. SQL ist in Teilen heute bereits genormt und die SAA-Entscheidung wird sicher dazu beitragen, daß die Normierung weiter vorangetrieben wird zum Nutzen aller Anwender.
In der Rubrik der Programmiersprachen war ich überrascht, Fortran zu finden. Sehr positiv finde ich, daß "C" Eingang in die Architektur gefunden hat. So könnte man sicher Detail für Detail alle Elemente der Architektur abklopfen und Zustimmung oder Ablehnung zu einzelnen Produkten anbringen.
Betrachtet man SAA als ganzes, nämlich als einen Plan, nach dem systemnahe Software so zusammengesetzt wird, daß der Anwender mit einheitlichen Werkzeugen und einheitlichen Oberflächen seine Anwendungsprobleme lösen kann, so kann ich darin nur Positives sehen, und ich warte eigentlich ungeduldig darauf, daß die noch offenen Lücken mit noch verfügbaren Produkten gefüllt werden.