Informationstechnologie spielt in der Versicherungsbranche schon seit mehreren Jahrzehnten eine zentrale Rolle. Waren die ersten Systeme noch stark an der Devise "Erst Datenerfassung, dann Datenverarbeitung" orientiert, so entstanden im Lauf der Jahre immer mehr dialogorientierte Anwendungssysteme im Back-Office, die den Sachbearbeiter bei seinen Aufgaben mehr oder weniger durchgängig unterstützen. Diese Anwendungssysteme sind auch heute häufig noch die Arbeitspferde im täglichen Geschäft des Versicherers. Typischerweise sind sie als zentrale, monolithische Anwendungen auf dem Host mit Programmiersprachen der dritten Generation wie zum Beispiel Cobol realisiert.
Die wachsende Leistungsfähigkeit der PCs ermöglichte es, den Außendienst nach und nach mit eigenen dezentralen Anwendungen auszustatten. In vielen Fällen wurde dabei eine ähnliche Funktionalität, wie sie bereits zentral verfügbar war, dezentral in anderer Technologie neu implementiert. Man denke dabei nur an die Verwaltung von Angeboten, von Partnerdaten oder an die Rechenkerne. Die Anbindung an die zentralen Systeme erfolgte dabei häufig durch asynchronen Datenaustausch. Auch in der Zentrale entstanden nun neue Anwendungssysteme zum Teil auf NT- und Unix-Plattformen. Hauptmotivation waren hier die Schaffung größerer Produktflexibilität und die Unterstützung einer Rundumsachbearbeitung.
Ein wesentliches Konstruktionsprinzip, neuer IT-Landschaften, das heute verfolgt wird, ist es, Anwendungssysteme aus (vorgefertigten), prinzipiell voneinander unabhängigen Einheiten (Komponenten) im Sinne einer "Komponentenarchitektur" zusammenzusetzen.
"Komponente" ist ein viel benutzter Begriff, dessen definitorische Bandbreite vom kompletten Anwendungssystem, etwa einem Vertragsverwaltungs- oder Partnersystem bis zum klassischen Softwaremodul oder zum speziellen Pattern bei objektorientierter Bauweise, reicht. Gemeinsame Merkmale aller Begriffe sind der abgegrenzte Leistungsumfang, die wohl definierte Schnittstelle und dass erst das Zusammensetzen (lat. componere) von Komponenten eine vollständige Anwendung ergibt. Strittig ist häufig die Granularität von Komponenten (sind zum Beispiel Oberfläche und fachlicher Kern eines Anwendungssystems eigene Komponenten?) und inwieweit Komponenten eine bestimmte technische Bauweise, zum Beispiel Objektorientierung, voraussetzen.
Zu häufig wird der Komponentenbegriff nur technisch gesehen. Die Anwendungslandschaft eines Versicherungsunternehmens muss aber aus ihrer fachlichen Struktur heraus entwickelt werden. Neben der Definition der Geschäftsprozesse ist dabei von zentraler Bedeutung, geeignete fachliche Komponenten zu bilden, die später jeweils durch eine oder mehrere Softwarekomponenten realisiert werden. Dies soll am folgenden Beispiel einer Plattform für Customer-Relationship-Management (CRM) in Versicherungsunternehmen verdeutlicht werden:
Das Beispiel zeigt die zentralen (Back-Office) und dezentralen (Customer Relationship) fachlichen Komponenten unterschiedlicher Sparten, die zu einer unternehmensweiten CRM-Plattform des Versicherungsunternehmens verbunden werden. Aus fachlicher Sicht wird es bestimmte Komponenten, etwa Partner, in unterschiedlichen Ausprägungen sowohl zentral wie dezentral geben. Einerseits weil man dezentral - zum Beispiel mit dem Notebook beim Kunden - auch unabhängig von der Anbindung an die Zentrale arbeiten will; zum anderen weil bestimmte Daten nur in der Zentrale oder dezentral am Point of Service gehalten werden. Dabei werden Anwendungssysteme in der Regel durch das Zusammenspiel mehrerer fachlicher Komponenten gebildet. Eine fachliche Komponente wird dabei durchaus in mehreren Anwendungssystemen zum Einsatz kommen.
So wird in Lebensversicherungs-Anwendungen die Technische Bestandsführung (TBF) sowohl vom Angebotssystem als auch vom Bestandsführungssystem genutzt. Entscheidend ist, die zugehörigen Softwarekomponenten so zu schneiden, dass jede fachliche Funktionalität zwar softwaretechnisch nur einmal realisiert wird, sich aber flexibel zu fachlichen Komponenten zusammensetzen lässt.
Dazu müssen Softwarekomponenten folgende Eigenschaften haben:
-Sie sind eigenständige Softwareeinheiten aus Daten und Funktionen.
-Sie haben einen bestimmten, abgrenzbaren Leistungsumfang (fachlich/technisch).
-Sie werden erst in Kombination mit anderen Softwarekomponenten zu vollständigen Anwendungen.
-Sie haben eine wohl definierte Schnittstelle, über die sie ihre Dienste anbieten.
-Schnittstelle und Implementierung sind separiert. Damit sind unterschiedliche innere Architekturen möglich.
-Sie sind konfigurierbar.
-Sie sind "interoperabel" über Adressräume, Netzwerke, Programmiersprachen und Betriebssysteme hinweg, also in weitreichendem Sinne systemunabhängig. Dies bedingt ein standardisiertes Kommunikationsprotokoll zwischen Softwarekomponenten.
Damit ist grundsätzlich offen gelassen, ob Softwarekomponenten klassisch funktional oder objektorientiert gebaut werden. Die objektorientierte Konstruktion ist jedoch eine gute Voraussetzung, um zu Komponenten zu kommen, da man Komponenten in gewisser Hinsicht als Objekte im Großen betrachten kann. Die Forderung der Separierung der Schnittstelle, also der von einer Komponente zur Verfügung gestellten Dienste, von ihrer Implementierung, ermöglicht es zum Beispiel, ältere Systeme zunächst zu "wrappen", das heißt mit einer Komponenten-Schnittstelle zu versehen und gegebenfalls später durch eine neue Implementierung zu ersetzen.
Aus technischer Sicht sind die Interoperabilität und die Verteilbarkeit von Komponenten auf unterschiedliche Rechner entscheidende Merkmale. Erst damit lassen sich flexible Komponentenarchitekturen bilden. Voraussetzung ist ein übergreifender Standard zur einheitlichen Kommunikation von Komponenten. Mit Corba (Common Object Request Broker Architecture) von der Object Management Group (OMG), DCOM (Distributed Common Object Model) von Microsoft und den Enterprise Javabeans (EJB) stehen solche Standards mittlerweile zur Verfügung.
Nimmt man die heute anerkannten Konstruktionsprinzipien für Software- und Systemarchitekturen wie die Schichtenbildung und das Client-Server-Prinzip und ergänzt es um die oben genannten Überlegungen zu Softwarekomponenten, so kommt man zu dem folgendem Leitbild für die Bildung von Komponenten-Architekturen für Versicherungen aus softwaretechnischer Sicht.
Dieses Leitbild geht von einer horizontalen Schichtung der Software in eine Präsentationsschicht, einen Anwendungskern und eine Datenschicht aus. Die fachlichen Komponenten liegen vertikal dazu. Sie werden aus der jeweiligen fachlichen Anwendungsarchitektur des Versicherungsunternehmens abgeleitet.
Im Beispiel der dargestellten CRM-Plattform könnte zum Beispiel "Angebot/Antrag" die fachliche Komponente A sein, "TBF" (Technische Bestandsführung) die fachliche Komponente B und "Partner" die fachliche Komponente C. Aus Softwaresicht wird jede fachliche Komponente in zwei Softwarekomponenten unterteilt: in eine Client- (die Präsentationsschicht) und eine Server-Komponente (Anwendungskern und Datenzugriffsschicht). Die Client-Komponenten laufen auf einem Client, dem Arbeitsplatz des Sachbearbeiters. Client- und Server-Komponenten und die Server-Komponenten untereinander sind mit Kommunikations-Middleware wie Corba verbunden. Dies ermöglicht eine flexible Zusammenstellung der Softwarekomponenten auf einer oder mehreren Plattformen. Die Datenbasis, das heißt üblicherweise die Datenbanktabellen, der einzelnen fachlichen Komponenten kann auf einem oder mehreren Datenbank-Servern liegen. Der Zugriff erfolgt über die Middleware des jeweiligen Datenbanksystems.
Eine wesentliche Voraussetzung, um zu Komponenten-Architekturen zu kommen, ist eine unternehmensweite Sicht auf die Anwendungssysteme vom Point of Service bis zum Back-Office. Der erste Schritt sollte sein, die vorhandene Anwendungslandschaft zu "kartografieren" und an einer gemeinsamen fachlichen Anwendungsarchitektur, bestehend aus fachlichen Komponenten, auszurichten. Parallel dazu wird man die fachlichen Komponenten den Hauptgeschäftsprozessen des Unternehmens zuordnen. Dabei wird man Redundanzen, Lücken, Schnittstellen-Brüche etc. feststellen, die später bei der schrittweisen Umgestaltung der Anwendungslandschaft behoben werden.
Entscheidend für die Bildung von Komponenten-Architekturen ist die schrittweise Umsetzung des oben genannten Architekturleitbildes für die Bildung von Softwarekomponenten. Dies bedeutet einerseits, neue Anwendungen in dieser Architektur umzusetzen, andererseits vorhandene monolithische Anwendungen aufzubrechen, sodass diese Server-fähig werden. Dabei muss die vorhandene technische Vielfalt der Kommunikationsverbindungen zwischen den Anwendungssystemen systematisiert und anhand der genannten Basistechnologien vereinheitlicht werden.
Vorhandene Anwendungen können integriert werden
Im Zeitalter des World Wide Web benötigen die Versicherungsunternehmen eine durchgängige informationstechnische Unterstützung aller Geschäftsprozesse des Kerngeschäfts vom Front-Office bis zum Back-Office. Ein System aufeinander abgestimmter Komponenten, die sich flexibel und zielgruppenspezifisch zu einer integrierten Plattform verbinden lassen, trägt wesentlich dazu bei, diese Durchgängigkeit zu erreichen. Die im Beispiel dargestellte Insurance-CRM-Plattform basiert auf einem solchen Ansatz, bei dem Komponenten aus Front-Office, POS, E-Business und E-Commerce mit Komponenten aus dem Back-Office eines Versicherers zu einer flexiblen Plattform verbunden werden.
Aus softwaretechnischer Sicht gibt es heute die entsprechenden Basis-Technologien (Corba etc.), um Komponenten-Architekturen in Versicherungsunternehmen zu realisieren. Entscheidend sind jetzt die richtigen Architekturen sowie das richtige Schneiden (fachlich und DV-technisch) und Zusammenfügen der Komponenten, um eine vom Point of Service bis zum Back-Office durchgängige Anwendungslandschaft zu bekommen. Dabei können vorhandene Anwendungen durch geeignete Techniken integriert werden.
Angeklickt
Die große Herausforderung heute ist, die gewachsene IT-Landschaft an zentralen und dezentralen Anwendungssystemen in einen einheitlichen fachlichen und technischen Rahmen zu bringen, der die Wiederverwendung sowie die flexible Zusammenstellung und Verteilung einmal geleisteter Entwicklungsarbeiten ermöglicht. Damit rückt die Bedeutung der Architektur solcher Systeme und Systemlandschaften in den Vordergrund. Gefragt ist mehr und mehr eine Komponenten-Architektur.
*Michael Aschenbrenner ist Lehrbeauftragter für Informationsverarbeitung in Versicherungsunternehmen an der Ludwig-Maximilians-Universität, München, und Leiter des Competence Center Distributed Computing bei der Feilmeier & Junker Gruppe (FJA); Andreas Grotefeld ist Softwarearchitekt und Projektleiter ebenfalls bei JFA.