CICS, Cobol und C, DB/2 und Oracle als Basis einer DV-Struktur klingen zunächst nicht spannend. Doch wenn die Konzerntöchter und die Muttergesellschaft Volkswagen AG eine "virtuelle IS- Gesellschaft" gründen, die daraus eine strategische Plattform für den gesamten Konzern zimmert, verspricht diese Kombination, über den Konzern hinaus richtungsweisend zu werden. Die Automobilbauer wollen alles: eine robuste Grundlage ihrer DV und eine Spielwiese für technische Neuerungen, heterogenes Umfeld bei einheitlicher Bedienung, die Einbindung und die Ablösung von Legacy-Systemen, Herstellerunabhängigkeit, Wiederverwendbarkeit sowie Standardsoftware ohne Zwang zum DV-technischen und betriebswirtschaftlichen Einheitsbrei.
Erbe aus der Vergangenheit
Einen der Anfänge nahm die Entwicklung in der Audi-Abteilung Systemplanung in Ingolstadt, die von Klaus Amthor geleitet wird. Mit 0,6 Prozent des Audi-Umsatzes (1995 waren das 16, 678 Milliarden Mark) stellen die Kosten für die Informationsverarbeitung zwar kein unmittelbares Investitionsrisiko für die VW-Konzerntochter dar, erreichen aber jährlich immerhin knapp 100 Millionen Mark. Zudem ist die DV- Struktur gekennzeichnet durch eine hohe Zahl an Benutzern und Transaktionen. "Wenn durch eine DV-Inkonsistenz eine Stunde lang die Bänder stehen, verlieren wir fünf Millionen Mark Umsatz", so Amthor.
Trotz dieser offensichtlichen Brisanz des Themas DV gab es bisher keinen bindenden Unternehmensleitfaden für das Zusammenspiel der Hard- und Softwarekomponenten. Zur Kompensation der Kostennachteile vor allem gegenüber asiatischen Herstellern begann Audi ab Ende der 80er Jahre, das Unternehmen zu verschlanken. Die Informationsverarbeitung mußte signifikant zur Zielerreichung der einzelnen Geschäftsbereiche beitragen, wobei zeitgleich die Mitarbeiterzahlen auch in der DV sanken. Diese wirtschaftlichen und organisatorischen Prämissen sowie die Möglichkeiten einer Dezentralisierung der Informationsverarbeitung durch die Client- Server-Technik forcierten die Entstehung werksstandort- und bereichsbezogener Insellösungen nach dem Motto: Wer zahlt, schafft an.
Damit verschwanden zwar die letzten weißen Flecken in der DV- Landschaft, doch gleicht diese heute einem Flickenteppich. "Arbeiter in der Produktion müssen zum Teil mehrere, verschiedene Systeme bedienen", klagt Amthor. Um die Rechnereigenschaften auszunutzen, mußte früher gezielt für einzelne Plattformen entwickelt werden. Da sich die Software-Erstellung jedoch als erheblich teurer erwies als die Anschaffung der zugrundeliegenden Hardware, waren Anpassungen an die sich rasant ändernde Rechnertechnik nicht mehr nachvollziehbar. Die Systeme veralteten schließlich.
Dort, wo Software neu entwickelt wurde, entstand sie aus fachspezifischen Sollkonzepten mit Maximalanforderungen. Das Ergebnis: viele Funktionen in monolithisch codierten Blöcken. Dadurch blieb eine Mehrfachverwendung von Softwaremodulen nahezu ausgeschlossen, während Funktionen und Daten häufig redundant vorgehalten werden mußten. "Immer wieder haben auch wir uns von den Herstellern mit neuen Produkten und Versprechungen einwickeln lassen, statt auszusuchen, was tatsächlich zu uns paßt und was wir brauchten", wundert sich Amthor im nachhinein. So stammen die Systeme aus verschiedenen DV-Zeitaltern und sind mit unterschiedlichsten Werkzeugen erstellt. Amthor spricht dabei aus heutiger Sicht von Anwendungsruinen, Technologieleichen und DV- Inseln, die permanenter Pflege von Spezialisten bedürfen.
Virtuelle Gesellschaft für IS-Synergien
Laut Amthor läßt sich diese in der Industrie überall vorhandene Misere nur überwinden, wenn die wesentlichen Geschäftsprozesse verbessert und konzernweit vereinheitlicht werden, Standardsoftware in nicht wettbewerbsrelevanten Prozessen zum Einsatz kommt und wenige, dafür weitreichende, verbindliche Richtlinien für die eigene Software-Entwicklung geschaffen werden. Das sieht auch die Muttergesellschaft Volkswagen so. Bereits 1994 haben sich deshalb alle IS-Stellen des Konzernbereichs Führungsorganisation und Systeme, Wolfsburg, zu einer virtuellen IS-Gesellschaft zusammengeschlossen, die weltweit wie eine organisatorische Einheit agiert.
Unter der Maßgabe, Synergien zu nutzen, sind zwei Hauptrichtlinien entstanden, die eine Wiederverwendung von Modulen und die Konfigurierbarkeit von Software sicherstellen sollen. Beide Ziele sind auch in der Objektorientierung klassisch. Deshalb gilt diese Technologie seit Anfang 1996 als Motor für die weitere Entwicklung und ist eine der beiden Richtlinien.
Die andere bereits wirksame Hauptlinie soll gewährleisten, daß die Vorgaben auch im heutigen Technologieumfeld erreicht werden. Der IBM-Transaktionsmonitor CICS, die Programmiersprachen Cobol und C sowie die Datenbanken DB/2 und Oracle bilden dafür die Basiskomponenten.
Zunächst spielte CICS nicht diese herausragende Rolle. Der Transaktionsmonitor wurde 1988 MVS-basiert im Zusammenhang mit einer Bürokommunikationsanwendung eingesetzt. Erst seit 1993 erhielt die Middleware bei Audi eine tragende Funktion, als die IBM-Labore die Unterstützung weiterer Plattformen ankündigten. "Übrigens ist Client-Server für uns kein Selbstzweck, sondern unabdingbare Voraussetzung für die Flexibilität, die wir erreichen wollen. Mit der Middleware CICS wird die DV-Welt nun auch auf der Applikationsebene offen", schwärmt Amthor, "denn ein Application Programming Interface (API) entkoppelt sie von den darunterliegenden Protokollen, Plattformen und Kommunikationstechniken."
Je umfangreicher und geschickter die Software modularisiert sei, desto besser könne sie je nach Bedarf auf entsprechend viele Stufen verteilt werden. Fast alle CICS-Produkte verfügten über Interkommunikationskomponenten, die ermöglichen, daß sich im CICS- Verbund alle beteiligten Rechner trotz unterschiedlicher Betriebssysteme gegenüber der Applikation wie ein einziger Rechner verhalten. Zudem ermögliche der Transaktionsmonitor eine Sessionszuordnung, die eine bessere Auslastung der vorhandenen Speicher und Rechnerleistungen sowie eine Kostenreduktion garantiere.
Amthor hält die Transaktionsverarbeitung für die sicherste Art der Informationsverarbeitung.
Ein Vorgang werde auch über mehrere Programmschritte, Datenbanken, Rechner und Adreßbereiche hinweg entweder komplett oder gar nicht ausgeführt. Dies verhindere Schieflagen und Inkonsistenzen im Fehlerfall, zum Beispiel bei Systemabstürzen (siehe Kasten).
Etliche CICS-Produkte verfügten über komfortable externe Schnittstellen zu anderen einschließlich objektorientierten Umgebungen. Das sichere die Integration fremder Produkte zur Laufzeit und erlaube die Adaption von Eigenschaften, die CICS selbst nicht besitze.
Eine Möglichkeit, objektorientierte Welten mit CICS zu verbinden, biete der ECI/EPI-Call (External Call Interface/External Programming Interface). Voraussetzung hierfür ist derzeit die IBM- Corba-Implementation SOM sowie C- oder C++-Programme. Eine zweite Integrationsmöglichkeit besteht im Zugriff auf ein SOM-definiertes Objekt über das CICS-API. Darüber kann auf Distributed-SOM-Objekte plattformübergreifend zugegriffen werden.
Allerdings existieren im VW-Konzern, so Amthor, noch keine objektorientierten Anwendungen von Belang, wenn auch in Pilotprojekten fleißig "gebastelt" werde. Nur etwa ein Prozent der gesamten Audi-Software basiere auf der Objektorientierung und ebenfalls nur ein Prozent auf dem Internet. "Dagegen sind 70 Prozent unserer Programme zehn bis 20 Jahre alt und 20 bis 30 Prozent herkömmlich erstellte Anwendungen auf dezentralen Rechnern." Die verfügbaren und durchaus vielversprechenden Objekttechniken gehören für Amthor noch in die Probierphase. Beispielsweise mangele es noch gänzlich an käuflich zu erwerbenden fachspezifischen Objekten oder an einem dynamischen Object Request Broker (ORB).
Objektorientierte Gehversuche
Sollten sich jedoch die in der Theorie erkennbaren Vorteile der Objekttechnik für die Systementwicklung in der Praxis bestätigen und kann eine gesicherte Infrastruktur dafür aufgebaut werden, ließen sich die CICS-Applikationen kapseln und in die dann überwiegende Broker-Umgebung integrieren. Neue Anwendungen würden dann nur noch objektorientiert erstellt.
Ein Schritt in diese Richtung ist die Oberflächenentwicklung der Betriebssystem-unabhängigen Rahmensoftware "Dialog Plus" mit dem objektorientierten IBM-Tool "Visual Age". In Teilen seit Juli dieses Jahres im Einsatz, gewährleistet diese Konzerneigenentwicklung ein einheitliches, mehrsprachliches Dialogsystem auf allen Rechnerplattformen. Außerdem müssen nun die Benutzerrechte für alle Plattformen und Anwendungen nur noch einmal gepflegt werden.
Dialog Plus trägt, wie Amthor ausführt, wesentlich zur angestrebten Modularisierung der Anwendungen bei. Diese soll sich in drei Stufen vollziehen: Präsentations-, Logik- und Datenzugriffsprogramme werden getrennt, um eine Verteilung zu ermöglichen. Die Rahmensoftware bietet soviel Programmierunterstützung, daß bei einfachen Systemen nur noch die fachspezifischen Regeln codiert werden müssen. Diese sind so anzulegen, daß eine "Modulbörse" entstehen kann.
Ziel ist es, einen Geschäftsprozeß nicht in die Software zu "schnitzen", sondern ihn erst in einer dritten Stufe der Konfiguration durch Systemanalytiker abzubilden, um trotz Standardisierung eine gewisse Individualisierung zu ermöglichen.
Die bestehenden IMS-Anwendungen, die den Löwenanteil der Audi- Applikationen ausmachen, können jedoch nicht portioniert werden. Trotzdem lassen sie sich über Dialog Plus und CICS einbinden. Systeme, deren interner Ablauf nicht bekannt ist, können über Front-end-Verbindungen (FEPI = Front-end Programming Interface) oder IMS-Unterprogramme aus der CICS-Link-Library angeschlossen werden. Außerdem bieten APPC-Schnittstellen (Advanced Program to Program Communication, LU 6.2) die Möglichkeit einer Anwendung zu Anwendung-Kommunikation.
Eine Oberfläche - viele Plattformen
Auch Office-Programme lassen sich in Dialog Plus "verankern" - etwa über die Microsoft-Schnittstelle Dynamic Data Exchange (DDE), Cold oder Hot Links. Seit kurzem bieten einige CICS-Produkte außerdem Gateways für den Zugriff auf Internet-Applikationen zur Laufzeit an, so daß die VW-Strategie auch für Neuentwicklungen auf dieser Plattform offen ist.
Die Verwendung einheitlicher Oberflächen, wiederverwendbarer Bausteine und von CICS stößt nicht uneingeschränkt auf Gegenliebe. CICS gilt als "altbacken" und zu "Host-orientiert". Darüber hinaus fürchteten die Wartungsspezialisten um ihre unternehmensinterne Bedeutung und sehen die Gefahren einer Abhängigkeit von der IBM.
Tatsächlich ermöglicht laut Amthor die Softwarestrategie jedoch eine sinnvolle Aufgabenteilung unter den Mitarbeitern und eine Konzentration von Kapazitäten. Zwar blieben die Entwickler organisatorisch ihren bisherigen Wartungsaufgaben zugeordnet, könnten aber parallel in Entwicklungsaufgaben involviert werden.
Neue Kollegen sollten mindestens zwei Programmiersprachen beherrschen. Cobol ist, so Amthor, die weltweit häufigste Sprache. Sie sei ohne größere Modifikationen auf allen strategischen Betriebssystem-Plattformen verfügbar und komme zudem ohne weitschweifige Erklärungen aus. Bei C handle es sich um die am meisten verwendete Sprache auf Unix-Systemen.
Als Datenbanken läßt das Konzept generell nur noch solche zu, die die Standard-SQL-Schnittstelle bedienen. Nachdem die DB2-Familie innerhalb des Konzerns die am weitesten verbreitete relationale Datenbank-Engine ist, bleibt es bei diesem System. Alternativ setzt das Unternehmen auf Oracle, da diese relationale Datenbank am häufigsten genutzt wird und obwohl der Hersteller firmenspezifische Stored Procedures und abweichende SQL-APIs verwendet.
Kriterien
Jede Konzern-Anwendungssoftware soll
-sich den Anwendern in ihrer Sprache und auf jeder strategischen Betriebssystem-Plattform gleich darstellen,
-auf allen strategischen Plattformen ausführbar sein,
-preiswert sein, jedoch ohne den möglichen Einsatz fachlicher und DV-technischer Innovationen einzuschränken,
-sich veränderten Prozessen einfach anpassen lassen,
-die Integration andersartiger Umgebungen unterstützen,
-nur noch fachliche Regeln enthalten und
-den Rechnerbeschaffungsmarkt nicht einschränken.
Softwarekonzept
Eine konfigurierbare Applikationssoftware, wie sie die VW- Strategie vorsieht, geht von Kern- und Optionsmodulen aus. Der Kern entspricht einem Minimalsystem, dessen Funktionen für alle Konzernniederlassungen Geltung haben. Die Optionsmodule fügen die jeweiligen Spezifika hinzu. Damit bleibt eine Individualisierung für den jeweiligen Standort gewährleistet. Quelle: Audi AG 1996
Transaktionsverarbeitung
Das Customer Information Control System (CICS) gehört zu den Transaktionsmonitoren. Eine Transaktion entspricht einem Geschäftsvorgang und ist die kleinste logische Einheit innerhalb einer Applikation. Die Produkte arbeiten nach dem Alles-oder- nichts-Prinzip, das als Atomicity bezeichnet wird. Transaktionen liefern unter gleichen Bedingungen identische Ergebnisse (Consistency), sind gegeneinander abgeschirmt und beeinflussen sich nicht (Isolation). Die von einer Transaktion durchgeführten und bestätigten Datenveränderungen sind dauerhaft (Durability).
Transaktionsverarbeitung ist dann sinnvoll, wenn viele Anwender gleichzeitig zahlreiche und gleichartige Geschäftsvorfälle mit einem Online-System bearbeiten. Dabei soll nicht der Programmierer, sondern das System die Anwendungen und die Betriebsmittel überwachen. Eine Online-Eingabe erzeugt zumeist auch eine Ausgabe. Obwohl sich die Benutzer die Daten und Programme teilen, sieht es für sie aus, als stünde ihnen das System jeweils alleine zur Verfügung.
In einem verteilten Client-Server-Umfeld lassen sich drei Arten der Transaktionsverarbeitung unterscheiden: Das Online Transaction Processing (OLTP) ist die bekannteste Host-orientierte Form. Arbeiten in einer verteilten Umgebung nennt sich Distributed Transaction Processing (DTP), und der Einsatz in einem verteilten heterogenen Umfeld wird als Open Transaction Processing (OTP) bezeichnet.
IBM brachte CICS vor etwa 20 Jahren auf den Markt. Anfänglich unterstützte der Transaktionsmonitor die Betriebssysteme Virtual Storage Extent (VSE) und Multiple Virtual Storage (MVS). Heute steht die Middleware auch für Unix-Derivate wie IBM-AIX, HP-UX, Sun-OS, Digital-Unix, Sinix sowie für OS/2, Windows NT und das Internet zur Verfügung. Außerdem bieten zum Beispiel Tandem mit "Service for the RISC-API" und Sequent mit "Unikix" Schnittstellen-kompatible Produkte an.