Proprietäre Systeme kosten viel Geld - vor allem das der Anwender. Etwa 50 Prozent aller DV-Aufwendungen, schätzt Bernard R. Bachmann, verschlingt der Kampf mit den offenen und subtielen Inkompatibilitäten. Ohne eine umfassende Standardisierung werden die Systeme in wenigen Jahren nicht mehr beherrschbar sein.

Wenn die klassischen Unternehmensfunktionen wie zum Beispiel Produktion und Verkauf auf gleich chaotische, duldsame und schicksalsergebene Art und Weise geführt würden wie der Informatik-Einsatz, dann wären Firmenkonkurse an der Tagesordnung. Es ist - milde gesagt - erstaunlich und unglaublich, was Firmenchefs sich von ihren Informatik-Verantwortlichen alles bieten lassen (müssen), wie schnell hartgesottene Manager - wenn mit Informatik-Problemen konfrontiert - ihre angebotenen Reflexe unterdrücken, zu zweifeln, nichts für gegeben zu halten, das Unmögliche für machbar zu halten und es auch zu verlangen. Es scheint, daß es weit verbreitet und normal ist, den Informatik-Spezialisten alles abzunehmen. Es scheint auf den obersten Führungsetagen nicht schick zu sein, sich mit Informatik-Problemen echt auseinanderzusetzen; das wären ja technische, führungsunwürdige Details. Ich kann mir dies nur damit erklären, als daß die Informatik insgesamt als Disziplin noch zu jung ist, daß sich in den rund 30 Jahren - Informatik-Geschichte kein allgemeiner Schatz von Manager-Reflexen für den qualifizierten Umgang dann mitgebildet hätte, und daß die heutigen Führungsschichten ihre ganze Ausbildung und die ersten Berufsjahre "unbeleckt von Informatik absolviert haben und von Berührungsangst gelähmt sind.

Als Insider - in diesem Fall habe ich auch als Angehöriger einer Bank keine Hemmung, von meinem Insiderwissen Gebrauch zu machen - weiß ich, daß im Schutz dieser permanenten Schonfristen Informatik-Kulturen entstanden sind, deren Effizienz und Effektivität im Vergleich zu den klassischen Unternehmensfunktionen äußerst problematisch sind. Ich behaupte - kann es allerdings nicht beweisen - daß in allen typischen Firmen Mindestens 30 Prozent, im Durchschnitt eher 50 Prozent aller Informatik-Aufwendungen nicht Nutzleistung produzieren, sondern nur der Beherrschung der "Tücke des Objekts" dienen. Und ich behaupte zusätzlich, daß dieser Mißstand ursächlich direkt mit der Dominanz proprietärer Systeme zusammenhängt. Lassen Sie mich diese Behauptung mit dem Alptraum eines IT-Verantwortlichen illustrieren. Ich wähle als praktischen Hintergrund dieser Illustration eine vereinfachte schematische Darstellung der Struktur der Informationssysteme der Schweizerischen Bankgesellschaft.

Diese Struktur ist durch folgende Merkmale gekennzeichnet:

- klarer Unterschied zwischen der Welt der ODV (operätionelle Datenverarbeitung) und der IIV (individuelle Informationsverarbeitung),

- drei Ebenen der sogenannten "Intelligenz"; nämlich Hosts, Abteilungsrechner und intelligente Arbeitsstationen, - Heterogenität der Systemgrundlagen (unterschiedliche Hersteller-Hardware, Betriebs- und Datenbanksysteme),

- mehrere, unterschiedliche, aber miteinander verbundene Netzwerke,

- durchwegs proprietäre Teilsysteme und Systemarchitekturen.

Ist eine solche System-Struktur qualitativ repräsentativ und geeignet, fundamentale Probleme der Informatik zu illustrieren? Ich bin fest davon überzeugt. Ich bin auch davon überzeugt, daß auch kleine Informatik-Benutzer mehr und mehr die mit solchen Systemstrukturen verbundenen Alpträume erleben werden.

Mein Alptraum ist die Vorstellung, ein solches Gesamtsystem führen zu müssen. Unter "führen" verstehe ich hier alle Prozesse, die für die Entwicklung nützlicher Applikationen und für den sicheren Betrieb solcher Systeme notwendig sind.

Die IT-Gemeinde muß radikal umdenken

Für die IT-Gemeinde ist es Heute noch typisch und selbstverständlich, daß alle Entwicklungs- und Betriebstätigkeiten auf den sogenannten Zielmaschinen durchgeführt werden, das heißt auf den Maschinen, für die Programme entwickelt werden sind die betrieben werden müssen. Vereinzelte Schwalben wie Netzwerkmanagement-Werkzeuge, Performance-Monitore und "Programmers Workbenches" machen zwar noch keiner Frühling, bestätigen nur die Regel. Dieses Zielmaschinen-Paradigma führt groteskerweise dazu, daß alle Führungs- und Managementprozesse in einem solchen heterogenen System ebenfalls maschinenspezifisch geplant, realisiert und betrieben werden müssen. Die Konsequenzen sind ein unwahrscheinlicher teurer Verschleiß von Ressourcen, kostspielige Zeitverluste, generelle Intransparenz der einschlägigen Managementprozesse, Immobilität des Personals, verspätete und mangelhafte Unterstützung der Unternehmungsstrategie mit Informatik. Lösungen, Unfähigkeit der Informatik-Organisationen, die Produktdifferenzierung der Unternehmungen wirksam mitzuprägen. Die bekannteste Konsequenz dieser Problematik ist wohl der sprichwörtliche Applikations-Backlog.

Wenn die IT-Gemeinde hier nicht radikal umdenkt und neue Wege einschlägt, wird die Gesamtheit der Prozesse, die für die Entwicklung und den sicheren Betrieb solcher Systeme erforderlich sind, vielleicht, im nächsten - Jahrzehnt, sicher aber ins nächsten Jahrhundert, nicht mehr führbar sein.

Dies alles ist nicht etwa naturgesetzlich festgelegt, unabänderlich und als permanenter Schicksalsschlag zu ertragen. Mein Wunschtraum bestellt darin, daß jemand hingeht und sich vom Zielmaschinen-Paradigma befreit und endlich auch die Informatiker selbst als End-User anerkennt und sie mit, brauchbaren Applikationen versorgt.

Konkret wünsche ich nur, daß alle Werkzeuge, die zur Führung der Informatik-Prozesse notwendig oder mindestens nützlich sind, aus den Ziel-Maschinen herausgelöst, verselbständigt und unabhängig von ihnen realisiert werden.

Ich wünsche mir das umfassende und integrale Entwickler. System, auf dem Systementwickler in einer homogenen und Zielmaschinen-unspezifischen Umgebung Anwendungen entwerfen, entwickelte, dokumentieren und testen können. Dieses Entwicklungssystem soll aber nicht nur den einzelner Entwickler Integral unterstützen, sondern auch die Organisation, in die der Entwickler ein, gebettet ist. Das heißt, daß auch die für eine Entwicklungsorganisation typischen Planungs-, Kommunikations- und Führungsprozesse unterstützt werden müssen; hierzu zähle ich ohne Anspruch auf Vollständigkeit - beispielsweise Methodenbanken, firmenweite und Zielmaschinen-unabhängige aktive Data Dictionaries, Produktivitäts- und Qualitätsdatenbanken, Unterstützung für Softwareverwaltung und -Installation, Planungs- und Reporting-Werkzeuge sowie Lehr- und Lernmodule.

Im weiteren wünsche ich mir das Betriebersystem, das - wiederum Zielmaschinen-unabhängig - den Betreiber komplexen und heterogener Systeme integral unterstützt. Etwas vereinfacht gesehen, stelle ich mir das gewünschte Betriebersystem als Kommandoposten vor, von dem aus beliebig konfigurierbare Teile eines verteilten Gesamtsystems geführt werden können.

Auch konkrete Informatik-Produkte

Die Funktionen dieses Kommandopostens umfassen die Betriebsunterstützung im engeren Sinne ebenso wie die Unterstützung des Änderungs- und Installationswesens, der Störfalltbehebung und -verwaltung, der Betriebsadministration, des Help-Desks und der Auslastungs-Optimierung sowie die Gewährleistung der Systemsicherheit und -integrität.

Natürlich bin ich ironisch, wenn ich solche Vorstellungen als Wunschtraum bezeichne. Nach meiner Überzeugung ist es bitter und dringend notwendig, die Realisierung dieser Vorstellungen anzupacken, wenn die Führbarkeit der bestehenden und erst recht der entstehenden komplexen Informationssysteme auf Dauer gesichert werden soll. Aus einer systematischen Auseinandersetzung mit diesen Zielvorstellungen resultieren wesentlich besser strukturierte Vorstellungen über die Informatik-Tätigkeiten an sich und schlußendlich hoffentlich ein Selbstverständnis der Informatiker, das dem beispielsweise der Bau- oder Maschineningenieure vergleichbar sein wird. Daraus resultieren aber nicht nur abstrakte Vorstellungen, sondern auch konkrete Informatik-Produkte, die den Prozeß der Entwicklung von Informationssystemen und deren Betrieb umfassend unterstützen, und zwar ausgelagert auf für solche Zwecke dedizierte Systeme.

Der Markt ist noch weitgehend offen

Hier liegt ein riesiger Zukunftsmarkt für offene Systeme. Dieser Markt ist noch weitgehend eine grüne Wiese, offen für alle Mitspieler, für Informatik-Hersteller und vor allein auch für Softwarehäuser, die sich durch Offenheit ihrer Produkte abheben und auszeichnen wollen. Generell sind hier Systemintegratoren gefragt. Nachdem es gegenwärtig zahlreiche Hersteller gibt, die den Anspruch "Systemintegration" auf die eigene Fahne geschrieben haben, bin ich gespannt ob einer von ihnen diesen Ball aufnimmt und sich zur Aufgabe stellt, den von mir skizzierten Wunschtraum zu erfüllen.

Dies ist allerdings leichter gesagt als getan. Denn es kann ja nicht darum gehen, den Teufel mit dem Beelzebub auszutreiben, das heißt heutige proprietäte Hard- und Software-Architekturen durch die postulierten Entwickler- und Betreibersysteme zu ersetzen, die dann selbst wiederum proprietär wären. Das bedeutet, daß die Grundlage für die Erfüllung meines Wunschtraums eine neue Architektur sein muß, nämlich die in meiner achten These angesprochene Systems Management Architecture.

Diese umfassende Architektur - oder auch der achte Layer - regelt alle Schnittstellen, die - über den gesamten Lebenszyklus von Informationssystemen - zwischen den Entwicklungs- und Betriebsprozessen gelten sollen. Sie regelt diese Schnittstellen nicht nur aus der Sicht des einzelnen Entwicklers oder Betreibers, sondern auch und insbesondere aus der Sicht der Führung der Organisationen, in denen Entwickler und Betreiber tätig sind. Damit wird langfristig die Führbarkeit oder und Beherrschbarkeit komplexer Informationssysteme wieder gesichert.

Wir müssen nüchtern Rechenschaft ablegen

Diese Systems Management Architecture besteht in meiner Vision aus drei Unter-Architekturen:

- die Systems Development Architecture definiert alle Spielregeln für Entwurf, Entwicklung, Installation und Unterhalt von Informationssystemen, die in einer verteilten, heterogenen Umgebung rund um die Uhr betrieben werden sollen; ebenfalls definiert sie die Grundmechanismen für die Führung und Verwaltung einer Entwicklungs-Organisation;

- die Systems Operations Architecture definiert alle Spielregeln für Planung, Installation, Betrieb und Unterhalt von Netzwerken und Hosts oder Applikations-Servern sowie von weiteren Trägern verteilter Intelligenz (Abteilungs-Rechner oder intelligente Workstations); die Operations Architecture berücksichtigt insbesondere die Anforderung, daß alle verteilter Komponenten eines solchen Systems sicher, robust, integer, koordiniert und wenn erforderlich synchron miteinander kooperieren, rund um die Uhr; ebenfalls definiert sie die Grundmechanismen für die Führung und Verwaltung einer Betriebs- oder Produktions-Organisation;

- die Systems Security Architecture definiert alle Spielregeln für Entwurf, Entwicklung, Installation und Unterhalt von Sicherheitsfunktionen, die ein verteiltes heterogenes System besitzen muß, damit es verantwortungsvoll betrieben werden kann.

Ich bin mir bewußt, daß ich damit meinen Mund ganz schön von nehme, und daß die Gefahr des Sich-Verschluckens und des dabei Erstickens recht groß ist. Ich bin mir aber auch bewußt, daß das, was ich postulieren, licht aus dem Boden gestampft werden kann. Ich möchte mit meiner Anregung, eine umfassende Systems Management Architecture zur technischen, organisatorischen und führungsmäßigen Grundlage aller System-Entwicklungs- und System-Betriebsaktivitäten zu machen, einen Prozeß anstoßen, der die dazu führt, daß wir uns nüchtern darüber Rechenschaft ablegen, daß wir - nun spreche ich insbesondere die Informatiker selbst an - die Erwartungen, die unsere Unternehmungen an uns stellen, die Ansprüche, die wir selbst großzügig immer wieder in die Welt hinausposaunen, gar nicht erfüllen können, wenn wir nicht radikal umdenken und uns von der Attitude der Extrapolation, des "mehr vom Selben" emanzipieren und die Gesamtheit unserer Informatiktätigkeiten - endlich! - rational durchdringen und dadurch verstehen und beherrschen lernen.

Muß es immer IBM sein?

Ich plädiere nicht dafür, daß, jetzt ein Standardisierungsgremium hingeht und die postulierten Architekturen definiert. Ich plädiere jedoch dafür, daß ein Informatik-Hersteller oder ein großes Softwarehaus sich der aufgeworfenen Problematik annimmt, seine Marktchance erkennt und damit beginnt, die Architekturen zu definieren und zu implementieren. Ich stelle mir vor, daß ein Prozeß beginnt, der durchaus der Definition und Implementierung anderer Architekturen, wie zum Beispiel SNA oder SAA, vergleichbar ist. Aber muß es immer IBM sein? Meines Erachtens steckt hier eine ganz große und wohl einmalige Chance für einen der kleineren Hersteller, die langfristig wichtigste Systemarchitektur zu entwerfen, dem "public domain" zu übergeben und sich damit zu profilieren und zu differenzieren, der erste Anbieter von Produkten zu werden, die unsere immer komplexer werdenden Informationssysteme wieder beherrschbar machen.

Was hat dies alles mit meinem Thema "Bedeutung offener Systeme für die Informationswirtschaft" zu tun? Sehr viel, meine ich. Einmal beruht das Konzept der Systems Management Architecture auf der Sicht, daß diese Architektur a priori Teil und Träger der offenen Systeme sein muß: aber auch auf der Überzeugung, daß die Probleme, die mit der Systems Management Architecture gelöst werden sollen, wirklich genetische Probleme sind, die weder branchenspezifisch noch etwa gar herstellerspezifisch sind; deswegen eignen sie sich ideal für eine Lösung in einer Umgebung offener Systeme; und letztlich hin ich fest davon überzeugt, daß im Interesse der Benutzer eine Lösung der skizzierten Probleme nur in einer offenen Umgebung angestrebt werden darf. Denn es ist nicht akzeptabel, daß die Informatik, die - wie in meinem Szenario aufgezeigt mehr und mehr zur Basisinfrastruktur der Unternehmungen gehört und wesentliche Beiträge zur Wettbewerbsfähigkeit im weitesten Sinne leisten soll, von einem einzelnen Hersteller dominiert wird.

Ich glaube auch, daß die blinde Ergebenheit, mit der teilweise noch heute oberste Führungskräfte den heutigen Zustand der Informatik als schicksalhaft gegeben, akzeptieren, ausstirbt; und daß - gerade wegen der für die Wettbewerbsfähigkeit der Unternehmungen strategisch wichtigen Rolle der Informatik - die Unproduktivität, mit der wir Informatiker unsichere und kaum mehr mit normalen Risiken betreibbare Informationssysteme entwickeln, bald nicht mehr akzeptiert wird. Es besteht akuter Handlungsbedarf. Und der aus meiner Sicht einzig richtige und produktive Lösungsansatz besteht in offenen, der Allgemeinheit gehörenden Architekturen.

Damit vertrete ich ganz klar den Standpunkt, daß offene Systeme eine fundamental wichtige, Rolle für die ganze Informätionswirtschaft haben und haben sollen. Ich betrachte das Aufkommen offener Systeme als das wichtigste einzelne Informatikereignis der 80er Jahre, dessen konkrete Auswirkungen die Entwicklung der Informatik die 90er Jahre deutlich prägen werden.

Die ganze Informatik-Gemeinde ist aufgefordert, sich an der Lösung der gewaltigen, noch vor uns stehenden Probleme, zu beteiligen:

- an vorderster Front natürlich die Produzenten von IT-Produkten, sowohl Hardware- als auch reine Softwareproduzenten, indem sie sich konsequent zur Ansicht durchringen, daß es bestimmte Gebiete der Informatik gibt, bei denen auch im ureigensten kommerziellen Interesse langfristig nur offene Lösungen sinnvoll sind;

- die Benutzer der IT, indem sie sich bewußt mit der Frage befassen, was es eigentlich braucht, um die wirklichen Unternehmensbedürfnisse mit Informatik-Lösungen optimal befriedigend damit der unselige Zustand, daß der "Schwanz mit dem Hund wedelt", endlich aufhört; aber auch, indem sie den Standardisierungsprozeß per Portemonnaie, via eine buchstäblich offene Einkaufspolitik, beeinflussen und beschleunigen;

- alle Standardisierungs-Gremien, in denen die Benutzer eine viel aktivere Rolle übernehmen sollten;

- sowie natürlich die Wissenschaft, Lehre und Forschung, dem sie anerkennt, daß nicht nur zum Beispiel "elegante" Programmiersprachen lohnende Forschungsobjekte sein können, sondern auch die produktive, zielgerichtete Entwicklung sowie der sichere Betrieb realer komplexer Informationssysteme.

Diese Herausforderung, mit der die Informatik-Gemeinde konfrontiert ist - nämlich die Wiederherstellung der Beherrschbarkeit unserer Systeme -, läßt sich nur dann wirksam und dauerhaft bewältigen, wenn die Lösung aus der Vogelperspektive - "top down" - erfolgt; aus der Froschperspektive läßt sich nichts Großes unternehmen.