Vor einigen Jahren veränderte sich die Hardwareszene durch die Entwicklung preisgünstiger Workstations und PCs entscheidend. Marktsegmente, die bis dabin fest in der Hand der großen Main- frame-Hersteller waren, wurden von den Konkurrenten mit kleineren Systemen erobert. Bis jetzt ist dieser Markt nicht wieder zur Ruhe gekommen. Ein Ende der Entwicklung ist nicht in Sicht.
Jeder Mainframe-Hersteller, von DEC bis IBM und von Hewlett-Packard bis Bull, hat versucht, mit einer proprietären Architektur, die sowohl Hard als auch Software umfaßte, die Kunden fest an sich zu binden. Wer sich für einen Hersteller entschied, war gezwungen, alles bei ihm zu kaufen. Sobald jedoch derartige Zwänge zu stark werden, regt sich im Markt Widerstand. Mit Gene Amdahls steckerkompatibler CPU begann das Ende der Ära der DV Monopole. Inzwischen steckt die DV-Industrie in einer schweren Krise, die die Hersteller zu einer Neubesinnung zwingt.
Kein Anbieter bildet sich heute mehr ein, er könne die Anwender mit einem Hardwaremonopol an sich fesseln. Es wurde notwendig, nicht mehr nur neben, sondern auch mit den Systemen der Konkurrenten zu leben. Das bedeutete insbesondere, miteinander zu kommunizieren. Zu diesem Zweck wurden Schnittstellen geschaffen, allerdings meist im Alleingang. Einige davon setzten sich als Standards durch, andere blieben auf der Strecke. Allerdings gab es auch einige, die als "Standard by committee" beschlossen wurden und sich dann doch nicht behaupteten.
Der Zwang zu standardisierten Schnittstellen trifft sowohl die Hard- als auch die Software-Industrie; jede ist von der anderen abhängig, keine kann ohne die andere leben. Da Hardwarehersteller vor allem Kisten, Softwarehersteller aber Lösungen anbieten, waren es zunächst mehr die Hardwarefirmen, die Organisationen für Standards und Intersystem-Kommunikation gründeten und förderten. Die rasante Entwicklung der Technologie hat jedoch dazu geführt, daß alle Resultate vor ihrem Abschluß veralteten. Bei den Software- Anbietern drängt der Technologiefortschritt weniger, so daß auch der Zwang zu einer Einigung geringer ist. Hier gilt eher die normative Kraft des Faktischen.
Jeder Hersteller ist bemüht, die zur Entwicklung seiner Produkte getätigten Investitionen zu schützen. Das geschieht durch besondere Fertigungsmethoden, Werkzeuge oder auch Patente. Softwerker setzen hier vor allem auf modulare Programm-Architekturen. Sie erhalten den Entwicklern ihr geistiges Eigentum und lassen gleichzeitig die erforderliche Offenheit nach innen und außen zu.
Auch der Kunde einer Softwarelösung muß seine Investition sichern. Schließlich erfordern alle Softwareprodukte eine mehr oder weniger komplizierte Einführung. Der Käufer bezahlt die Installation eines Listverteilsystems, die JCL-Veränderungen beim Einsau eines Job-Schedulers sowie die Ausbildung seiner Mitarbeiter. Wenn ferner ein Rechenzentrum sich entschließt, die Daten auf dem weitverzweigten Netz seiner Workstations durch ein Abstimmsystem zu kontrollieren müssen diese Systeme miteinander kommunizieren.
Nun ist es einmal so, daß Produkte ständigen Erweiterungen, Erneuerungen und Anpassungen unterliegen. Zusätzlich zu der erforderlichen Kommunikationsfähigkeit sollte eine Anwendung also so beschaffen sein, daß sie noch nach vielen Jahren den aktuellen Entwicklungen entsprechen kann. Mit anderen Worten: Offene Architekturen sind gefordert.
Ein Schlagwort in der gegenwärtigen Fachdiskussion sind Client-Server-Konzepte. Ein Merkmal dieser Architekturen ist die Wandlungsfähigkeit ihrer Bestandteile. Wenn ein Server verändert wird, wirkt sich das auf die Wartbarkeit des gesamten Produkts nur begrenzt aus. Besteht nun ein Produkt aus einem Zusammenschluß vieler solcher Clients und Server, so sind Interaktionsfähigkeit mit anderen Plattformen, leichte Wartung und Flexibilität gewährleistet.
Die Zukunft gehört sehr komplexen Architekturen
Die Offenheit aller Systeme ist ein hehres Ziel und eine beliebte Forderung der jeweils nicht am System Beteiligten. Sobald die Kritiker jedoch selbst von einem System profitieren, versuchen sie, dieses nach außen hin abzuschotten. Als Paradebeispiel kann IBMs offene PC-Architektur gelten, die der Hersteller im nachhinein mit der Micro-Channel-Architektur zu einem proprietären, geschlossenen System umgestalten wollte.
Es ist aber auch nicht sinnvoll, jede Struktur und jede Funktion der Öffentlichkeit zugänglich zu machen. Eine derartige Vorgehensweise würde die Entwicklung blockieren, weil einmal veröffentlichte Richtlinien sich nicht mehr einfach ändern lassen, will man nicht den empörten Aufschrei jener riskieren, die auf Basis der offengelegten Funktionen entwickeln.
Nützlich und machbar ist lediglich die Festlegung einer Schnittstelle und die Einhaltung von Standards. Diese sollte keine externe gesetzgebende Versammlung vorschreiben. Sie entstehen vielmehr, wie bereits oben ausgeführt, auf den Markt.
PC-Markt hat sich für Windows entschieden
Der PC- Markt, insbesondere der für Einplatz- Rechner, hat sich weitgehend für Windows entschieden. Im PC- Markt mit IBM-Host-Anbindung sind sich die Käufer noch nicht schlüssig, dafür ist OS/2 2.0 noch zu neu Ein Softwarehersteller, der Mainframe-Produkte anbietet muß daher die Benutzeroberflächen MS-Windows für die DOS- Welt und Presentation Manager für OS/2 unterstützen. Vieles spricht allerdings dafür, daß sich OS/2 besser an große Mainframes anbinden läßt. Der Mainframe fungiert als überdimensionaler Server, und LU 6.2 ist das verbindende Protokoll zum PC-Client. Auch der Sicherheitsaspekt scheint bei OS/2 besser berücksichtigt zu sein.
Auch wenn es zahlreiche Probleme und Hindernisse bei der Entwicklung von offenen Systemen gibt, liegen deren Vorteile auf der Hand. Die Zeiten der Dominanz eines monopolistisch auftretenden Herstellers sind endgültig vorbei.
Die multikulturelle Gesellschaft hat auch in der DV-Industrie Einzug gehalten. Damit haben sich die Aufgaben des IS Managers gewandelt. Wie ein Dirigent muß er alle Instrumente seines DV-Orchesters zu einer gemeinsamen Aufführung bringen, so wie im Orchester die Instrumente auf den Kammerton A gestimmt werden müssen, damit nicht aus der Aufführung ein Happening wird. Obwohl viele Hard- und Softwarekomponenten, die Instrumente der DV-Aufführung, recht billig er scheinen, ist der finanzielle Aufwand für eine angestrebte Lösung insgesamt sehr viel höher als der für ihre Einzelteile. Die dafür verantwortlichen hohen Integrationskosten werden oft unterschätzt.
Ein Unternehmen, das seine Workstations nicht zentral koordiniert, weiß möglicherweise nicht, welchen Preis es für den Wildwuchs bezahlt. Unseres Erachtens wird der Trend zur DV: Abteilung mit nur einem oder zwei Hardwareherstellern zurückweisen, und zwar aus Gründen der Überschaubarkeit: Ein Hersteller kann einen Standard für sich setzen, und zwei Hersteller können sich über einen derartigen Standard einigen. Viele Hersteller aber bilden ein Chaos oder ein Komitee, und in beiden Fällen wird nur selten ein gemeinsames Ziel erreicht.
Koexistenz von offenen und geschlossenen Systemen
Das Gedankengut hinter den Open-System-Architekturen ist entstanden, nachdem eine Hardwarerevolution ein neues Denken gefordert hat. Welche Veränderungen werden unsere Methodologie in Zukunft beeinflussen? Nur wenige Menschen beherrschen die hohe Kunst des Kaffeesatzlesens, aber einige Entwicklungen sind bereits jetzt absehbar. Erstens werden schnelle und sehr billige Lichtfaserübertragungswege einen entscheidenden Einfluß auf die DV-Welt ausüben, und zweitens kommen Parallel- Prozessor-Maschinen auf uns zu, die sowohl preiswert als auch unvorstellbar schnell sein werden.
Gehen die DV-Anwender dann auf den Zentralrechner zurück? Vielleicht, denn wo gerechnet und gespeichert wird, ist im Grunde völlig unwichtig. Die Daten eines Unternehmens nicht nur zentral zu kontrollieren, sondern auch so zu speichern, hat den Reiz von Sicherheit und Integrität. Hier wird eine Koexistenz von Mainframes und Workstations, von Clients und Servern, von offenen o und geschlossenen Systemen entstehen, deren Komplexität wir uns heute nur schwer vorstellen können. Schnittstellen und Protokolle werden über die Lebens- und Überlebensfähigkeit von Systemen entscheiden.
*James Henderson ist Leiter Forschung und Entwicklung bei der Beta Systems Software AG.