Was die Gemüter in der PC-Welt schon seit langem erhitzt, greift jetzt auch auf die Mainframe-Szene über: die Diskussion über das Thema "Integration" versus "Verbund von Einzellösungen" . Anders als bei den PCs, wo es vor allem um die Integration von Hilfsfunktionen geht wie Dateiverwaltung, Textverarbeitung oder Grafik, führt der Streit bei den "Großen" schon auf eine höhere Ebene; es handelt sich nämlich um die Integration von unternehmensweiten Anwendungen.

Zu den unternehmensweiten Anwendungen zählen in erster Linie alle Bereiche des Finanz- und Rechnungswesens (Buchhaltung, Kontokorrente, Anlagen, Controlling) sowie andere Aufgaben der kaufmännischen Administration wie Personalwesen, Einkauf, Lagerhaltung bis hin zu stark technisch ausgeprägten Bereichen wie Produktionsplanung, Fertigungssteuerung, Lagerhaltung und Materialwesen.

Kurz gesagt, die "lntegrationalisten" sind bestrebt, letztlich die gesamte Palette an elektronisch verarbeitbaren Aufgabenstellungen in einem Unternehmen zu einem einzigen gigantischen Anwendungssystem zu verschmelzen.

Die Grundlinie der Argumentation ist bekannt: Die integrierten Systeme werben mit einheitlicher Benutzeroberfläche und gemeinsamer Datenhaltung (Behauptung: nonredundant); dagegen nehmen die dedizierten Funktionssysteme für sich eine erhöhte Leistungsfähigkeit jedes Einzelsystems in Anspruch.

Unterschiede zwischen PC- und Mainframe-Welt

Man könnte mit Hinweis auf die bereits lebhafte Diskussion im PC-Bereich dieses Thema hier auf sich beruhen lassen, gäbe es nicht einige signifikante Unterschiede zwischen der PC- und der Mainframe-Welt:

- Die DV-Landschaft in einem Großunternehmen ist fast ausnahmslos historisch gewachsen, und die innewohnenden Organisationen sind alles andere als integriert.

- Die zur Integration anstehenden Anwendungen im Großunternehmen sind über einen breiten Personenkreis gestreut (während auf dem PC in der Regel eine einzige Person Nutznießer von Integrationseffekten sein kann).

- Die Anforderungen an die Qualität der Funktionserfüllung in jedem einzelnen Teilbereich sind ungleich höher als in der " persönlichen" Sphäre der Mikro-DV, wo Leistungsschwächen einzelner Komponenten leichter "wegsaldiert" werden können.

Insofern erscheint es durchaus erklärlich, daß es jahrzehntelang in der Groß-DV keinen erkennbaren "Trend" zu überintegrierten Systemen, zur Verschmelzung von Anwendungen ganz unterschiedlicher Aufgabenstellungen, gegeben hat. Ein Blick in den ISIS-Katalog zeigt eindeutig die Vorherrschaft leistungsstarker einzel- beziehungsweise teilintegrierter Systeme.

Insofern ist auch heute, da an manchen Stellen der DV-Landschaft ein Trend zur fortgesetzten Integration zu beobachten ist, die Frage geboten, wie weit Integration getrieben werden kann (technisch) beziehungsweise sollte (ökonomisch).

Damit kein Mißverständnis aufkommt: Die "Schokoladenseite" eines vollintegrierten Anwendungssystems soll hier gar nicht in Abrede gestellt werden. In der ausführlichen Abhandlung von SAP-Geschäftsführer Plattner in der COMPUTERWOCHE Nr. 41 (Titel: Der Integrations-Manager wird gefordert) findet der interessierte Leser eine lückenlose Aufstellung aller "Pros" zur Totalintegration. Dieser Aspekt des Themas braucht hier also nicht wiederholt zu werden.

Immerhin wird auch der Schlüssel zu den " Contras" beim Namen genannt; Zitat: "Der Bedarf an Hauptspeicher, Plattenplatz und Rechnerleistung ist erheblich." Es folgt der Hinweis, daß "diese Ressourcen ... heute in nahezu beliebiger Größe beschafft werden" können.

Ist aber für einen verantwortlichen DV-Manager die Frage nach der Wirtschaftlichkeit eines technischen Hilfsmittels allein schon deshalb irrelevant, weil dieses Hilfsmittel am Markt verfügbar ist?

Wenn das so wäre, gäbe es nur noch MVS/XA-Installationen, gäbe es keine florierende Industrie der Performance-Tools, und gäbe es auch keine genervten Systemprogrammierer, die sich mit VSAM-Bufferoptimierung, Transient-Analysen und anderen Tätigkeiten herumschlagen, die kein anderes Ziel verfolgen müssen, als die völlig überlastete Anlage für die Installation eines weiteren Anwendungspaketes freizuschaufeln.

Sicherlich: Letzten Endes wird eine fortschrittliche Anwendungs-Technologie nicht durch ihren Verbrauch an materiellen Ressourcen aufgehalten. Wohl aber durch ihre Inanspruchnahme an finanziellen Mitteln, und dies ist eine Binsenweisheit. Der Wankelmotor verschwand wegen unwirtschaftlichen Umgangs mit Treibstoff vom Markt; Solarenergie kommt nicht vom Fleck, weil sie zu teuer ist, obgleich sie sämtliche Umweltprobleme lösen würde. Nur in der DV führt isoliertes Technokraten-Denken bisweilen zu einer Investitionspolitik, als ob "das Blech heute nichts mehr kostet".

Wie wenig trivial die Betrachtung der Kostenseite auch in der DV ist, zeigt allein die folgende Überlegung: Aufgrund der bekannten architektonischen Begrenzungen der 370-Systeme ist ein linearer Wachstumspfad, auf dem man Durchsatz und Hauptspeicher-Kapazität sukzessive aufstocken könnte, einfach nicht mehr gegeben: Wachstum ist für einen mittleren (VSE-)Anwender nur noch über Quantensprünge möglich, sprich: MVS-Umstellung, mindestens aber Installation der nächsthöheren Systemfamilie.

Dennoch bleibt festzuhalten, daß Integration grundsätzlich ein nützliches Konzept ist, jedenfalls dort, wo bislang künstlich, das heißt, durch desintegrierte DV-Systeme, ein logisch zusammengehöriger Bearbeitungsvorgang zertrennt worden ist. So ist beispielsweise die Zusammenfassung aller die Belegverbuchung betreffender Vorgänge zu einem integrierten Finanzbuchhaltungssystem mit den Subsystemen Hauptbuch, Debitoren, Kreditoren als sinnvoll anzusehen. Die hierbei entstehenden DV-technischen Probleme sind aufgrund von homogener Problemstellung, verwandter Datenstrukturen und gleichartiger Sachbearbeiter-Kenntnis gering.

Wo aber sind die Grenzen für ein "überintegriertes" System, bei dem die Nachteile der Schwerfälligkeit und Leistungsschwäche im Grenzbereich überwiegen?

Einen entscheidenden Hinweis zur Beantwortung dieser Frage liefert die von Plattner eingeführte sehr treffende Unterscheidung in "integriertes System" einerseits und nur "integrierter Betrieb" (von Einzelsystemen) andererseits. Zeigt sie doch auf, daß die Alternative zu schwer beherrschbaren Totalsystemen nicht etwa eine unkoordinierte Sammlung von desintegrierten Einzelsystemen ist, sondern ein flexibles Gesamt-Anwendungssystem aus optimal dimensionierten Funktionssystemen, auch von unterschiedlichen Herstellern, die aber jedes für sich das Maximum an Leistungserfüllung bieten und durch flexible Schnittstellen miteinander in Harmonie gebracht werden können.

Flexible Schnittstellen für die Harmonie

Vor diesem Hintergrund ist festzustellen, daß das an sich löbliche Integrationsbestreben, sofern im Übermaß betrieben, über das ursprüngliche Ziel hinausschießt und dem Anwender (und auf den kommt es an, der muß es bezahlen) mehr Nachteile als Vorteile beschert. Ausschlaggebend hierfür ist eine Reihe von spezifischen Problemen, die wir hier Gravitätsprobleme nennen wollen, da sie aus der schieren Masse des Systems herrühren. Nachfolgend werden diese Gravitätsprobleme, die der Anwender bei seinem Integrationsstreben auf jeden Fall zu beachten hat, kurz dargestellt:

Problem 1: Heterogene Teilsysteme

Der Aufwand zur Wahrung einer Totalintegration bei Teilsystemen, die sich aperiodisch zueinander verhalten und zudem noch von unterschiedlichen Personenkreisen bedient werden, ist überflüssig und nützt allenfalls dem Softwarehersteller.

Problem 2: Leistungseinbuße durch Nivellierung

Der Zwang eines totalintegrierten Systems, jedes Teilgebiet über das im Systemnukleus vorhandene Instrumentarium, wie Dialogsteuerung, Verarbeitungskonzepte, Dateiorganisation etc., abzuwickeln, führt zwangsläufig zu Leistungseinbußen in einzelnen Teilsystemen (wenn auch nicht notwendigerweise in allen). Dies ist insbesondere dann der Fall, wenn die Integration um einen Systemkern herum stattfindet, der ursprünglich für operative Aufgabenstellungen, wie Finanzbuchhaltung, entwickelt wurde und späterhin auch für rein dispositive Anwendungen (zum Beispiel Controlling, Planungsrechnungen) adaptiert wird.

Problem 3: Systemwartung

Der gigantische Wartungsaufwand eines totalintegrierten Systems wird zumeist bei weitem unterschätzt, sowohl was die Häufigkeit wie auch den Umfang anbelangt. Die Abhängigkeit aller Teilsysteme voneinander oder - im technologisch fortgeschrittenen Fall - von einem zentralen übermächtigen Schnittstellen-Handler führt ganz einfach in der Praxis zu einer erhöhten Anzahl von Release-Wechseln. Nicht jeder Anwender hat Verständnis dafür, wenn er seine gesamte Fibu-Beleg-Datenbank reorganisieren muß, weil in der Bestellabwicklung ein neues Feld hinzugekommen ist. Theoretisch kann hier Abhilfe durch dynamische Schnittstellen und ein umfangreiches Repository (wer wartet dieses?) geschaffen werden. Die dadurch eintretenden Performance-Einbußen sind aber in jedem Fall erheblich, und es gibt ein weiteres Subsystem, das in allen Anwendungsteilen mitgezogen werden muß.

Problem 4: DDP-Konzept

Die sich abzeichnende Entwicklung hin zu den Abteilungsrechnern (beispielsweise IBM 9370), die dem Schlagwort von der dezentralen Datenverarbeitung wohl endgültig zum Durchbruch verhelfen wird, wirft für ein totalintegriertes System ganz neue Probleme auf. Es ist evident, daß die konzeptionellen Vorteile einer abteilungsorientierten Datenverarbeitung dem Integrationsgedanken, der immer einen Zentralrechner erfordert, entgegenstehen. Spätestens vor diesem Hintergrund ist die (serielle) Integrierbarkeit von Einzelsystemen hilfreicher als der monolithische Gigantismus einer "beherrschten" Totalintegration.

Problem 5: Das "höhere" Ziel

Integration an sich ist vorteilhaft - die Frage ist jedoch, wo das sinnvolle und wirtschaftlich vertretbare Maß überschritten wird. Ein Kriterium für "sinnvolle" Integration ist die organisatorische Arbeitseinheit, innerhalb derer Geschäftsvorfälle oder Informationsanfragen abschließend bearbeitet werden. Solche Arbeitseinheiten sind durch einen homogenen Personenkreis sowie gleichartige Arbeitsmittel und zeitlich koordinierte Abläufe gekennzeichnet. Hierbei unterstützende DV-Systeme sollen integriert sein im Sinne der von Plattner aufgestellten Eigenschaften. Eine weitergehende (Total-)Integration aber, die vom Anwender die Bereitschaft fordert, "auf manche Spezialisierung ihrer Systeme zu verzichten, um dem höheren Ziel der Integration zu dienen" (Plattner), ist im Interesse gesamtunternehmerischer Zielsetzungen nicht nur aus Kostengründen nicht anzustreben.

Problem 6: Komplexität

Die Beherrschbarkeit findet ihre Grenzen vor allem in den systembetreuenden Personen. Die Komplexität eines zu großen Gesamtsystems übersteigt den Überblick jedes einzelnen Mitarbeiters bei weitem; selbst führende Programmautoren beziehungsweise Projektleiter der ersten Stunde haben die Kenntnis aller Wirkungszusammenhänge der Teilsysteme untereinander verloren.

Die Personengruppe, die erforderlich ist, um zumindest in Summe ein übergreifendes Know-how beisammen zu haben, wird immer größer und ist selten zusammen verfügbar.

Problem 7: Modifizierbarkeit

Je größer ein System wird, desto dringlicher die Forderung nach unmodifizierter Verwendung des (Standard-)Systems. Darin sind sich auch (fast) alle Beteiligten einig: Management, DV/Org., Anbieter. Auch der Anwender? Tatsache ist, daß die Notwendigkeit aus fachlicher Sicht, an der einen oder anderen Stelle im System Anpassungen vorzunehmen, um so größer ist, je breiter die Abdeckung der Anwendungsfälle. Es ist zwar wünschenswert, aber praxisfremd, zu glauben, man könne ohne schmerzhafte organisatorische Verrenkungen ein System einführen, das praktisch alle fachlichen Anforderungen im Unternehmen abdeckt, ohne es modifizieren zu müssen. Damit beginnt das eigentliche Problem: Die Stabilität des gesamten hochintegrierten Systems ist gefährdet, weil niemand in der Lage ist, die Auswirkungen einer Änderung in Komponente 1 auf alle übrigen Komponenten abzusehen.

Allen vorgenannten Problempunkten kann entgegengehalten werden, daß sie nicht notwendigerweise zwingend mit Hochintegration verbunden sind, also nicht gewissermaßen mit naturgesetzlicher Logik aus ihr folgen.

Dem ist zuzustimmen; somit sind die aufgeführten Punkte nicht als Argumentationskatalog gegen Integration anzusehen, sondern sie geraten zum Maßstab für gute beziehungsweise schlechte Implementierung von Hochintegration. Allerdings ist dann in der Praxis festzustellen, daß es - ab einer gewissen Größenordnung - in diesem Sinne keine guten hochintegrierten Systeme gibt.

Die oben beschriebenen Problemfelder machen deutlich, daß es in der Entwicklung jedes integrierten Systems den Punkt gibt, an dem die Synergie-Effekte, die ohnehin mit abnehmender Grenzrate wachsen, von der Summe der hyperbolisch wachsenden Gravitätsprobleme überholt werden. Diesen Punkt zu erkennen und rechtzeitig vor ihm zum Stehen zu kommen, ist die Aufgabe, die es zu meistern gilt.

Ständig an der Grenze des noch Beherrschbaren

Vor die Wahl gestellt, ein totalintegriertes System mit einer ständig an der Grenze des noch Beherrschbaren navigierenden Technologie zu installieren oder einen integrierten Betrieb von hochleistungsfähigen Einzelsystemen einzurichten, werden viele Firmen bei einer objektiven Abwägung aller Aspekte letzterer Alternative den Vorzug geben, falls diese im konkreten Anwendungsfall verfügbar ist. Dies mag ein Knackpunkt sein: Die geforderte Integrierbarkeit (hierin sind sich alle einig) setzt ein gewisses Maß an Zusammenarbeit der Software-Hersteller voraus, vor allem aber die Berücksichtigung der Integrierbarkeit im Software-Design jedes Einzelpaketes von Anfang an.