(Fast) Alles Wissen der Fachbereiche (Regelwerke, Formelwerke, Produktstrukturen, Prozessabläufe etc.) ist heute in unseren (weitestgehend hostbasierten) Anwendungssystemen „versteckt“. Dies birgt zum einen das Risiko der Intransparenz der fachlichen Inhalte in der Zukunft (immer mehr der „alten Hasen“ im Fachbereich gehen in Rente) und zum anderen ein hohes Investitionsrisiko mit der zunehmenden Alterung der Systeme. An dieser Stelle setzt SOA an. SOA basiert auf dem Prinzip der Kapselung von Funktionen und Daten und deren Nutzung über öffentlich zur Verfügung gestellte Services.
Innerhalb der Versicherungen gibt es heute i.d.R. Anwendungslandschaften, die zwar weitestgehend hostbasiert sind, zum anderen aber schon SOA-Prinzipien (Kapselung, Angebot von Services, Komponenten) folgen (3 Schichten-Architektur).
Zur nutzbringenden Erstellung von SOA-Objekten (Service-Clustern) müssen Prinzipien zur Bildung von Service-Clustern aus fachlicher Sicht definiert werden. Zum einen muss für jedes fachliche Cluster eine genaue Beschreibung der fachlichen Funktionen und der Daten inkl. der Services, die das Cluster anderen Clustern zur Verfügung stellt und welche Sie von anderen Clustern nutzen will erstellt werden. Diese Beschreibung muss für jedes Cluster angefertigt werden. Die ⾬harchitektur“ eines Unternehmens ist dann die Grundlage von Systemplanungen und Realisierungen.
Zur Beschreibung dieser Facharchitektur und der entsprechenden SOA-Cluster stellt sich eine Aufgabenverteilung wie folgt dar:
D.h. die Rolle der IT wird reduziert auf die Lieferung von SOA-Clustern, die dann in Workflows durch den Fachbereich eingebunden werden. Damit erhält der Fachbereich seine Kernkompetenzen, Definition von fachlichen Regeln, Produkten und Oberflächen, zurück. Bei zukünftigen Änderungen an diesen Kernkompetenzen ist der Fachbereich nicht mehr auf die IT angewiesen. Dies erhöht wesentlich die Reaktionsgeschwindigkeit und positioniert damit die jeweilige Versicherung besser im zunehmenden Wettbewerb.
SOA – Service Orientierte Architekturen wird auch in Versicherungen als ein Mittel zum Aufbrechen der alten Host-basierten Systemlandschaft gesehen.
Was ist das Neue an SOA?
Klassisch hat man neue Systeme bzw. Anwendungen in Projekten organisiert, die i.d.R. 1 – 3 oder mehr Jahre gedauert haben. Allein die Aufnahme der Anforderungen im Fachbereich, das Schreiben eines Fachkonzeptes und der Entwurf eines Architekturmodelles (Daten- und Funktionen oder Prozessmodell) hat i.d.R. 1 Jahr oder länger gedauert. Anschließend hat man das technische Designmodell erstellt, die Umsetzung realisiert und einen umfangreichen Test organisiert, der mit der endgültigen Abnahme des neuen Systems durch den Fachbereich endete und damit das neue System in Produktion gehen konnte.
(Fast) Alles Wissen der Fachbereiche (Regelwerke, Formelwerke, Produktstrukturen, Prozessabläufe etc.) sind heute in unseren (weitestgehend hostbasierten) Anwendungssystemen „versteckt“. Dies birgt zum einen das Risiko der Intransparenz der fachlichen Inhalte in der Zukunft (immer mehr der „alten Hasen“ im Fachbereich gehen in Rente) und zum anderen ein hohes Investitionsrisiko mit der zunehmenden Alterung der Systeme.
An dieser Stelle setzt SOA an. SOA basiert auf dem Prinzip der Kapselung von Funktionen und Daten und deren Nutzung über öffentlich zur Verfügung gestellte Services.
Ein Beispiel:
Ein Anwendungssytem in der Versicherungswirtschaft, z.B. Leben-Bestandsverwaltung, ist im günstigsten Fall auf der Basis einer 3-Schicht-Architektur gebaut (Dialog, Fachfunktionen, Datenschicht). Dies hat zumindest den Vorteil, dass relativ einfach der Dialogmonitor und/oder die genutzte Datenbank ausgetauscht werden kann ohne dass aufwendige Änderungen in den eigentlichen Anwendungsprogrammen durchgeführt werden müssen. Wurde ein hostbasiertes Anwendungssystem als 3-Schicht-System gebaut, hat man i.d.R. auch jeglichen direkten Zugriff auf die Daten von Außen (andere Anwendungssysteme wie z.B. Leben-Leistung benötigt Informationen von Leben-Vertrag) verboten. Jegliche Anforderung einer anderen Anwendung (lesend oder schreibend) wird dann über den Aufruf einer Programmschnittstelle bereitgestellt. Dies war im Prinzip in der hostbasierten Welt der erste Schritt in Richtung einer Service-Orientierung. D.h. jede Anwendung stellt für andere Anwendungen eine oder mehrere Programmschnittstellen mit bestimmten Funktionalitäten (Services) zur Verfügung. Ein gutes Beispiel hierfür findet sich sogar innerhalb einer Leben-Anwendung: i.d.R. hat man bereits in den 80er-Jahren die mathematischen Funktionen in einer Sub-Anwendung (Versicherungstechnik) gekapselt. D.h. die Bestandsverwaltung bietet dem Sachbearbeiter die Möglichkeit den Kundenwunsch und die dafür notwendigen Daten aufzunehmen, die mathematische Ermittlung der finanziellen Auswirkungen dieses Kundenwunsches wird dann aber über den Aufruf einer Programmschnittstelle des Subsystems Versicherungstechnik weitergegeben und erledigt. Diese Kapselung von bestimmten Funktionalitäten, in unserem Fall der mathematischen Berechnungen, hat zum einen den Vorteil, dass spezialisierte Mitarbeiter diese Anwendung erstellen können und zum anderen dieses Subsystem bei einer entsprechenden Gestaltung der Schnittstelle austauschbar wird (im Prinzip).
Ein weitergehendes Beispiel ist die Nutzung von Kundendaten in einer Bestandsverwaltung. In den 70er Jahren wurden die Kundendaten an jedem Vertrag geführt. D.h. die Kundendaten wurden in jedem Vertragsdatensatz redundant abgelegt und die notwendigen Dialoge zur Erfassung Änderung dieser Daten waren Bestandteil des Vertragssystems. Diese Kundendaten wurden i.d.R. in den 80er und 90er Jahren aus den Vertragssystemen herausgelöst und in zentralen Kundensystemen (Kundendatenbank) abgelegt. Die notwendigen Funktionalitäten inkl. der Dialoge wurden ebenfalls zentral zur Verfügung gestellt. Dies bedeutete jetzt für ein Vertragssystem, dass es z.B. in einem Prozess der Antragserfassung, der ja i.d.R. vom Vertragssystem gesteuert wird, zunächst einen Dialog des Kundensystems aufruft, dort die notwendigen Daten durch den Sachberarbeiter erfasst oder ergänzt werden und anschließend im Vertragssystem die Erfassung der notwendigen versicherungstechnischen Daten des Antrages erfolgt. Auch hier hat eine Kapselung bestimmter Daten und Funktionen stattgefunden und die Nutzung findet über eine Programmschnittstelle (Service) statt.
D.h. innerhalb der Versicherungen gibt es heute i.d.R. Anwendungslandschaften, die zwar weitestgehend hostbasiert sind, zum anderen aber schon SOA-Prinzipien (Kapselung, Angebot von Services) folgen. Warum dann diese Euphorie von SOA?
Zum einen gab es die Entwicklung des Internets, die auch in Versicherungen nicht Halt gemacht hat. Heute gibt es Internetanwendungen von Versicherungen, die auch Funktionen aus klassischen Bestandssytemen (Host) anbieten. Damit hier nicht doppelte Realisierungen mit all den Problemen von Redundanz erfolgen, will man in diesen Anwendungen möglichst auf die Funktionalitäten (Services) dieser Host-Systeme zugreifen. Dies erfordert natürlich eine erweiterte Technologie wie z.B. Webservices, die Bestandteil von SOA ist. Darüber hinaus wandelt sich auch in der Versicherungswirtschaft der Markt, so dass Unternehmen nicht mehr wie früher üblich alles selbst mach sondern z.B. bestimmte Produkte zwar anbieten und verkaufen, diese jedoch von anderen Unternehmen erstellen und die Verträge verwalten lassen. D.h. hier will natürlich dann das Unternehmen, dass die Verträge verkauft hat (dies kann auch ein Makler sein) auf die Vertragsinformationen (die im liefernden Unternehmen vorhanden sind) zugreifen.
Leider ist es in der Informatik so, dass neue Technologien, wie z.B. SOA, gerne aus rein technischer Sicht verwendet werden. Es ist interessant und macht Spaß neue Technolgien einzusetzen. Dies führt i.d.R. zwar technisch modern gestalteten Anwendung, es stellt sich aber die Frage wie man den Einsatz dieser neuen Technologien nutzbringend für den eigentlichen Kunden, die Fachbereiche, einsetzen kann.
Konkret heißt dies, wie kann man fachliche Cluster (Kapseln) und deren notwendigen Services identifizieren?
Der Ausgangspunkt einer fachlichen Analyse zur Beantwortung dieser Frage können nur die fachlichen Prozesse sein. Im nachfolgenden Beispiel wird dies kurz dargestellt:
In diesem Beispiel sind die fachlichen Cluster eingerahmt:
Dies ist natürlich nur eine grobe Darstellung auf oberster Ebene, die jetzt innerhalb der einzelnen Cluster weiter nach unten gebrochen werden kann. Die folgende Grafik zeigt das Prinzip:
Aus Geschäftsprozessen werden „Geschäftssysteme“ (fachliche Cluster) erzeugt. Aus den Geschäftssystemen werden Geschäftskomponenten aus fachlicher Sicht abgeleitet, die jedoch dem Prinzip der Wiederverwendung folgen.
Ein Beispiel hierzu:
Vergleicht man die aus fachlicher Sicht gebildeten Geschäftskomponenten der einzelnen Geschäftssysteme, erkennt man, dass es hier Geschäftskomponenten gibt, die in mehreren Geschäftssystemen vorkommen.
Ein Geschäftskomponente KONTO(FÜHRUNG) stellt die grundsätzlichen Mechanismen einer Kontoführung dar. Diese Mechanismen können jetzt aus einer spezifischen fachlichen Sicht, wie z.B. Führung eines Rückversicherungsvertrages und Führung eines Einzel-Versicherungsvertrages, in einem Geschäftssystem RÜCKVERSICHERUNG und in einem Geschäftssystem VERSICHERUNG genutzt werden.
Bis jetzt wurden die Prinzipien gezeigt zur Bildung von Service-Clustern aus fachlicher Sicht. Es fehlt natürlich für jedes fachliche Cluster eine genaue Beschreibung der fachlichen Funktionen und die Daten inkl. der Services, die das Cluster anderen Clustern zur Verfügung stellt und welche Sie von anderen Clustern nutzen will. Diese Beschreibung muss für jedes Cluster angefertigt werden. Diese Beschreibungen der Facharchitektur eines Unternehmens ist dann die Grundlage von Systemplanungen und Realisierungen.
Diese Art der Dokumentation einer Facharchitektur sollte toolgestützt erfolgen. Es gibt jedoch nicht das Tool, das die gesamten Möglichkeiten bietet.
Wir schlagen folgende Tool-Welt und Rollen-Verteilung vor: