Exportieren (0) Drucken
Alle erweitern
Erweitern Minimieren

Interoperable Systeme im Versicherungswesen mit .NET 3.0

Veröffentlicht: 29. Jan 2007
Von Mike Walker

In diesem Whitepaper werden anhand eines Fallbeispiels aus der Versicherungsbranche die Interoperabilitätsmöglichkeiten der Microsoft-Plattform aufgezeigt. Protokollschichtenstandards zu verwenden genügt nicht: Damit die Interoperabilität Ihrem Unternehmen Vorteile bringt, müssen Sie die betriebliche Seite von Messaging-Transaktionen erfassen und sinnvoll einbeziehen. Dies trifft nicht nur auf die Versicherungsbranche, sondern auf alle Branchen zu.

Auf dieser Seite

 Einführung
 Antriebskräfte der Versicherungsbranche
 Wirtschaftsbegriffe in diesem Dokument
 Fallbeispiel einer Lebensversicherungspolice
 Architektur im Überblick
 Das System der Versicherungsvertreterpolicen
 Die Versicherungsträgersysteme
 Worin liegt der Wert?
 Schlussbemerkung
 Ressourcen

Einführung

Diese Whitepaper-Serie dient dem Zweck, Ihnen einen Leitfaden bereitzustellen, mit dessen Hilfe Sie die Hürden der Integration überwinden können.

In diesem Whitepaper werden anhand eines Fallbeispiels aus der Versicherungsbranche die Interoperabilitätsmöglichkeiten der Microsoft-Plattform aufgezeigt. Aufgrund der geschichtlichen Entwicklung zahlreicher Unternehmen leben wir in einer Welt, in der homogene Systeme nicht selbstverständlich sind. Die firmenintern vorhandenen Technologiemixe reichen von Großrechneranwendungen, die auf COBOL oder FORTRAN beruhen, bis zu den moderneren Lösungen, die auf .NET, Mobile Systems oder Java beruhen – und allem, was dazwischen liegt. Im Prozess des Durchlaufens ganz verschiedener Technologien und technologischer Trends wurden deshalb einzelne Technologien in Unternehmen des Öfteren mit improvisierten Patches lebens- und kommunikationsfähig erhalten.

Serie zur Versicherungsinteroperabilität

Dieses Whitepaper dient als Leitfaden für Architekten, die mit den Integrationsherausforderungen in der Versicherungsbranche konfrontiert werden. Wir werden Ihnen zeigen, wie Sie mithilfe der Integrationstechnologien von Microsoft verschiedenartige Systeme in Ihrem Unternehmen integrieren können. Zusätzlich stellt dieses Dokument pragmatische Designanleitungen zum Erstellen interoperabler Lösungen mit offenen Standards wie z. B. WS-* bereit. Zu dieser Serie gehören die folgenden weiteren Dokumente:

Architektonischer Überblick für den Aufbau interoperabler Versicherungssysteme

Sichern von Versicherungslösungen

Skalieren und betriebliche Verwaltung

Bereitstellen von Unternehmenslösungen

Entwickeln zusammengesetzter Anwendungen

Die folgenden Technologien werden abgedeckt:

  • BizTalk 2006. Die Integrationstechnologie für diese Lösung. Diese Lösung verwendet auch die BizTalk-Geschäftsregeln und Arbeitsablauforchestrierung.

  • Windows Communication Foundation (WCF). Das Programmierungsmodell zum Entwickeln von Webdienstnachrichten und zum Verwalten von Kommunikation auf Protokollstufe mithilfe der WS-*-Protokolle.

  • Windows Workflow Foundation (WF). Dient dem Erstellen leistungsfähiger Arbeitsabläufe mithilfe von Smart-Client-Technologien.

  • SQL Server 2006. Der Ablagebereich für alle Anwendungs- und Kundendaten.

  • Windows Server 2003. Die Serverplattform.

Dieses Fallbeispiel wird Einblick in branchentypische betriebliche Prozesse gewähren. Genau wie viele andere Unternehmen hat auch jede Versicherungsgesellschaft ihre eigenen Methoden, ihre Arbeitsprozesse abzuwickeln. Es gibt jedoch auch diverse Gemeinsamkeiten, die diese Unternehmen auf Plattformebene miteinander teilen. Wir wollen Ihnen zeigen, wie sich solche gemeinsamen Plattformdienste für das Erstellen dienstorientierter Architekturen (SOAs, „Service-Oriented Architectures“) nutzen lassen, um Unternehmen mehr Agilität für ihre spezifischen Prozesse zu ermöglichen.

Antriebskräfte der Versicherungsbranche

In der Versicherungsbranche sind von Großrechnern bis hin zu UNIX und Windows zahlreiche Technologien im Einsatz. Diese breite Palette von Plattformtechnologien macht es zunehmend schwierig, die Arbeitsprozesse zu verwalten und abzuwickeln und zugleich agil zu bleiben in einem Finanzmarkt, der ständig Änderungen unterworfen ist. Über Jahre hinweg haben Organisationen Technologien erstellt und gekauft, um diesen Anforderungen gerecht zu werden. Sobald eine Lösung erstellt bzw. implementiert wurde, ist Interoperabilität zu einem notwendigen Übel geworden. Dadurch sind Punkt-zu-Punkt-Integrationen entstanden, die zur Behebung sehr spezieller Probleme entwickelt wurden, aber nicht auf der Ebene der Unternehmensfunktion, sondern lediglich auf der Anwendungs- oder Systemebene ansetzen.

Abbildung 1: Das Ergebnis von Punkt-zu-Punkt-Integrationen
Abbildung 1: Das Ergebnis von Punkt-zu-Punkt-Integrationen

Wenn keine Vorsorgemaßnahmen ergriffen werden, führen Punkt-zu-Punkt-Integrationen nach vielen Jahren zu Folgendem:

  • Die IT-Portfolio-Verwaltung wird aufgrund der Duplizierung von Systemen, mehrerer Integrationsvarianten, der Verwaltung von Anwendungsabhängigkeiten usw. unhandlich.

  • Vermehrte Kosten von IT-Systemen, die aufgrund der Anzahl angepasster Integrationen dramatisch in die Höhe schießen.

  • Verlust der Agilität, weil die Entwicklung von Systemen infolge einer erhöhten Codekomplexität, einer beschränkten Wiederverwendbarkeit und eines Standardisierungsmangels im Unternehmen beträchtlich verlangsamt wird.

Was hat dies für zahlreiche Versicherungsträger zu bedeuten? Es bedeutet, dass Interoperabilität eine entscheidende Rolle spielt, und zwar nicht nur hinsichtlich der Effizienz, sondern auch als wichtiger Faktor für die Wettbewerbsfähigkeit. Bei dem heutzutage herrschenden Wettbewerb müssen die Unternehmen die Anlagenrendite („Return Of Investment“, ROI) ihrer IT-Systeme erhöhen, indem sie die Prozesse rationalisieren und agiler werden, um konkurrenzfähig zu bleiben.

Unser Ziel besteht darin, die branchenspezifischen Herausforderungen durch einen Satz unternehmensfertiger Technologien in Angriff zu nehmen, die auf der Microsoft-Plattform beruhen. Wir verwenden in den Beispielen die folgenden Prinzipien:

  • Lösung der Unternehmensklasse

  • Standardkommunikationen:

    • Einsatz von WS-*-Standards

    • ACORD-Nachrichten

  • Sicherstellen von Interoperabilität mit vorhandenen Lösungen

Wirtschaftsbegriffe in diesem Dokument

ACORD: ACORD (www.acord.org) ist ein gemeinnütziger Verband mit dem Ziel, die Entwicklung und Verwendung von Standards für die Versicherungs- und die Rückversicherungsbranche sowie die zugehörigen Finanzdienstleistungsbranchen zu fördern.

Auftragssystem: erstellt Anfragen nach externen Daten, überträgt sie zum geeigneten Drittanbieter-Datenprovider, verwaltet die eingehenden Antworten und ordnet die Antworten den entsprechenden ursprünglichen Anfragestellern zu.

Drittanbieterdienstprovider: externes System zum Beantworten einer Risikoschätzungsanfrage (z. B. Kreditauskunft).

Risikoeinschätzungsprozess: Implementierung des Betriebsprozesses zur Beurteilung und Verarbeitung eines neuen Geschäfts.

Vermittlungssystem: ein von einem Versicherungsmakler verwendetes mögliches Smart-Client-Front-End-System zur Auftragseingabe und Fortschrittsüberwachung. Andere Front-End-Systeme sind ebenfalls denkbar, z. B. ein System in Form eines Internetportals für Makler oder eine Internetbenutzeroberfläche für die Selbstbedienungseingabe von Aufträgen durch den Kunden selbst.

Fallbeispiel einer Lebensversicherungspolice

Der Kunde Robert will eine Lebenversicherungspolice der Platinstufe in Höhe von 1 Million Dollar kaufen. Der Makler Thomas gibt den von Robert gestellten Antrag auf eine Police mit seiner Smart-Client-Anwendung ein. Die Policenanfrage wird zum Auftragssystem gesendet, wo sie verarbeitet und an die entsprechenden Systeme weitergeleitet wird, um den Risikoeinschätzungsprozess einzuleiten. Während die Anfrage sich im Auftragssystem befindet, werden Drittanbieterdienste gestartet. In diesem Fallbeispiel werden wir einen Drittanbieterdienst namens Paramed verwenden, der die Krankenversicherungsdaten und die medizinischen Daten der Versicherten überprüft.

Die integrierte Betriebslogik kann auch Anfragen für Dritte generieren, falls eine bestimmte Bedingung erfüllt wird. Dies könnte beispielsweise der Makler oder ein anderer Partner der Versicherungsgesellschaft sein.

Abbildung 2: Für unser Fallbeispiel verwendeter Betriebsprozess
Abbildung 2: Für unser Fallbeispiel verwendeter Betriebsprozess

Architektur im Überblick

In diesem Abschnitt wird die im Fallbeispiel verwendete Architektur auf höchster logischer Ebene behandelt. Die Details zu bestimmten Aspekten wie z. B. Sicherheit, Nachrichten, Entwicklung und Bereitstellung, werden in anderen Dokumenten dieser Serie behandelt.

Um den in der Realität vorkommenden Szenarien gerecht zu werden werden, haben wir die unverzichtbaren Anforderungen zusammen gestellt.

Anforderungen

Für eine Lösung der Unternehmensklasse müssen die folgenden Anforderungen erfüllt werden:

  • Sie muss mit bestehenden, kommerziellen Standardanwendungen interoperabel sein. Wie bereits erwähnt, wird von vielen Organisationen Software gekauft und angepasst. Dieser Aspekt muss unbedingt beachtet werden.

  • Die Integrationstechnologie muss aus Webdiensten bestehen. Viele Kommunikationsformulare, wie z. B. Formulare für binäre Kommunikation, sind firmeneigene Produkte. Vor der Entstehung von Webdiensten gab es keine standardisierten Verfahren, um Nachrichten zu übermitteln. Webdienste ermöglichen es, zwischen heterogenen Plattformen zu kommunizieren.

  • WS-*-Standards müssen verwendet werden. Webdienste, die SOAP und WSDL verwenden, gehören seit Jahren zum Branchenintegrationsstandard. Diesen traditionellen Webdiensten fehlt jedoch die für das Messaging erforderliche Stabilität. Die WS-*-Standards stellen diese erforderlichen Eigenschaften und Funktionen bereit, ohne zu binärer Kommunikation zu greifen.

  • Lange andauernder Arbeitsablauf. Die Verwaltung lange andauernder Orchestrierungen ist schwierig - insbesondere dann, wenn der betreffende Arbeitsablauf viele kleinere externe Arbeitsabläufe generiert und somit die Fallabstimmung und die Transaktionsverwaltung recht komplex werden können.

Für diese Lösung verwenden wir als Nachrichtenhub BizTalk, da BizTalk vielfältige Funktionen bietet und bei dieser Lösung für die Versicherungsbranche die zwingende Anforderung erfüllt, mehrere Systeme zu verbinden und mehreren externe Arbeitsabläufe zu verwalten.

Abbildung 3: Verwendung von Nachrichtenbustechnologie
Abbildung 3: Verwendung von Nachrichtenbustechnologie

In Abbildung 3 ist eine Unternehmensansicht von BizTalk als Unternehmensdienstbus (ESB) zu sehen. Denken Sie daran, dass es keine Notwendigkeit gibt, diese als ESB zu verwenden. In diesem Whitepaper wird diese Schicht lediglich als Nachrichtenschicht behandelt, damit Sie sie in jedem Fall in Ihre Lösung integrieren können.

Der Grund für die Wahl von BizTalk liegt darin, dass BizTalk eine zentralisierte Plattform für die folgenden Möglichkeiten bereitstellt:

  • Betriebsprozessverwaltung. Die Zentralisierung eines wiederverwendbaren Betriebsprozesses fördert nicht nur die Dienstorientierung. Sie stellt auch einen Mechanismus bereit, um bestehende oder erworbene Standardanwendungen (auf COTS-Basis beruhende Anwendungen) auszubauen, ohne die Komplexität von deren Modifizierung in Kauf nehmen zu müssen.

  • Arbeitsablauforchestrierung: Durch diese Plattform kann die Verwaltung mehrerer Abeitsabläufe vereinfacht werden. Statt jeden Arbeitsablauf zu kodieren oder abzustimmen, können Lösungen in der ihnen entsprechenden Art verwaltet werden. Dies bewerkstelligen wir, indem wir einen Arbeitsablauf zur Verwaltung des Betriebsprozesses vom Anfang bis zum Ende erstellen, der mehrere interne Systemarbeitsabläufe orchestrieren kann.

  • Vielfältige Adapterunterstützung: Für Organisationen ist es von entscheidender Bedeutung, sofort mit der Entwicklung beginnen zu können. BizTalk bietet eine große Auswahl an Adaptern, um Ihren Integrationsanforderungen gerecht zu werden. In der Versicherungsbranche gibt es einen ACORD-Adapter, der Ihre Integrationsoperationen sofort realisierbar machen kann. Zusätzlich zum ACORD-Adapter sind für BizTalk der Web Services Adapter sowie Adapter auf Dateibasis erhältlich.

  • Nachrichtenweiterleitung und -transformation: Die Weiterleitung von Nachrichten kann ein sehr komplizierter Vorgang sein, wenn die Nachrichten transformiert werden müssen, um für andere Systemen verständlich zu sein. BizTalk kann eine Plattform bereitstellen, die diese Komplexität reduziert und trotzdem die Ausrichtung an offene Standards bietet.

Das System der Versicherungsvertreterpolicen

Derzeit schwanken die technologischen Trends in der Versicherungsbranche zwischen Portalen, Thick Clients, 3270-Großrechnerterminal-Emulationsstationen und Smart Clients. Angesichts der großen Anzahl von Anwendungen und Anbietern in diesem Marktsektor wählen wir eine Smart Client-Benutzeroberfläche aus, die aus den folgenden Gründen für den Außendienstmitarbeiter am besten geeignet ist:

  • Offline- und Online-Modi

  • Keine Abhängigkeiten von Netzwerkkonnektivität

  • Reichhaltige Benutzerführung mit wesentlich umfangreicherer Funktionalität

Für Vertreter ist ein nicht verbundenes Modell in vielen Situationen sinnvoll, denn sie sind häufig viel unterwegs oder haben nur beschränkten Zugang zu Netzwerkressourcen. Da wir jedoch beim Entwerfen dieser Lösung als Kern unserer Messaging-Strategie Webdienste verwenden werden, sollte das Verfahren, mit dem der Makler im Außendienst seine Anträge übermittelt, möglichst einfach sein.

Für die Architektur auf der Client-Seite haben wir als Benutzeroberfläche Windows Forms verwendet, das die für die Vertreter erforderliche Benutzerschnittstelle bereitstellt. Hier werden mehrere Steuerelemente, wie z. B. Datenraster, Textfelder und Befehlsschaltflächen, verwendet. Ein Datenraster auf dem Windows-Formular wird dem Makler als Einstiegspunkt in die Policen-Pipeline dienen. Zum Aktualisieren dieses Datenrasters verwenden wir Webdienste, um eine Aktualisierung in Echtzeit zu gewährleisten.

Weil dies ein Smart Client ist, können die zurückgegebenen Daten im Zwischenspeicher abgelegt werden, um sie im Offline-Betrieb anzeigen und aktualisieren zu können. Dies bietet den Maklern beträchtliche Vorteile. Zusätzlich zu den Daten bleibt in der Client-Anwendung auch eine kleine Schicht von Betriebslogik erhalten. Der größte Teil der Anwendungslogik bleibt auf der Seite der Versicherungsgesellschaft. Dadurch können wir bei den Funktionen der Benutzeroberfläche mit einfachen Regeln arbeiten.

Abbildung 4: Architektur der Clientlogik
Abbildung 4: Architektur der Clientlogik

Um vom Client aus Anfragen an die Messaging-Schicht zu senden, werden wir Windows Communication Foundation (WCF) verwenden. WCF wird mithilfe der ACORD-Messaging-Schemata SOAP 1.2-Webdienstnachrichten senden. Die WCF-Schicht wird unseren Entwicklern für das Kodieren von Kommunikationsvorgängen ein vereinheitlichtes Entwicklungsmodell bereitstellen. Aus der Protokollperspektive werden wir eine Serie von WS-*-Standards verwenden. Dies reicht jedoch noch nicht aus, um Interoperabilität zu gewährleisten. Auch die Verwendung der ACORD-Branchenstandards ist von zentraler Bedeutung. Wir sollten in der Lage sein, nahtlos zwischen Anwendungen der Marke „Eigenbau“, COTS-Anwendungen und Drittanbieterdiensten interoperieren zu können.

Messaging-Architektur

Die Verwendung von Webdiensten ermöglicht dieser großen Vielfalt an Kanälen, einen gemeinsamen Webdienst zu nutzen. Dieser empfängt im Risikoeinschätzungsprozess neue Policenanträge in Form einer ACORD 103-Nachricht, die eine zugewiesene Policennummer beinhaltet. Die Policennummer werden wir während dieser Demonstration für Nachverfolgungs- und Korrelationszwecke verwenden. Diese „ACORD 103 New Business Submission“-Nachricht wird auf einer SOAP MTOM/XOP-Anlage (Message Transmission Optimization Mechanism/XML-binary Optimized Packaging) basieren, die die binäre Darstellung von Roberts Signatur enthält, um die Freigabe der erforderlichen medizinischen Daten zu genehmigen. Die ACORD-Standards müssen unbedingt in unser Messaging-System eingebunden werden: Dies wird die Übertragbarkeit der Architektur gewährleisten.

Ferner ist es wichtig, dass Kommunikationsvorgänge sicher und zuverlässig sind. Um dies zu erreichen, werden wir für persönliche Daten, die evtl. eine unbestimmte Anzahl an Zwischenstellen durchlaufen, WS-Secure Conversation (WS-SC) verwenden. Wir verwenden WS-SC auch für Massenanfragen und häufige Anfragen (z. B. Kreditauskünfte), die bei allen neuen Policenanträgen erforderlich sein werden. Für weniger häufige Anfragen, wie z. B. die Anforderung eines ärztlichen Attests (APS, „Attending Physician's Statement“), bei denen die Gemeinkosten des Sitzungsaufbaus nicht durch die Anfragenmenge gerechtfertigt wird, verwenden wir WS-Security. In seltenen Fällen, in denen Anfragen ohne Zwischenstellen von einem Dienst direkt verarbeitet werden, verwenden wir auch TLS/SSL (auch HTTPs genannt).

Für eine Nachrichtenübermittlung, bei der ein Empfang gewährleistet sein muss (z. B. zur Gewährleistung des Erhalts einer neuen Police, um Anspruch auf Provision erheben zu können), verwenden wir WS-Reliable Messaging (WS-RM). Wir verwenden WS-RM auch für Datenanfragen, die mit hohen Verarbeitungskosten verbunden sind und i. d. R. die Einbeziehung menschlicher Fachkräfte erfordern (z. B. Attestanfragen). Dadurch wird gewährleistet, dass diese Anfragen nur ein einziges Mal geliefert und teure Doppelanforderungen vermieden werden.

Für lange andauernde Nachrichten werden wir WS-Secure Conversation (WS-SC) verwenden (siehe Ressourcen).

Abbildung 5: Muster des Client-Nachrichtenaustauschs
Abbildung 5: Muster des Client-Nachrichtenaustauschs

Tabelle 1: Entscheidungsmatrix für das Design von Betriebsprozessen

Transaktion

Betriebsprozesse

WS-*-Protokolle

Architekturentscheidung

Einreichung neuer Richtlinie (103 Anforderung)

Maklerclient

Risikoeinschätzungsprozess

WS-Security (WS-S)

WS-Reliable Messaging (WS-RM)

WS-S zur Übermittlung persönlicher Daten, die evtl. eine unbestimmte Anzahl an Zwischenstellen durchlaufen.

WS-RM zur Verfolgung des Nachrichtenempfangs.

Aufgrund seltener Transaktionen besteht kein Bedarf an sitzungorientierten Sicherheitsmechanismen wie z. B. WS-Secure Conversation (WS-SC).

Statusabfragen (122 Anforderung/Antwort)

Maklerclient

Risikoeinschätzungsprozess

Erfüllungsprozess

WS-Secure Conversation (WS-SC)

Unwichtigere und einzelne Anfragen oder Antwortnachrichten, die leicht wiederholt werden können, aber trotzdem persönliche Daten enthalten.

Risikoeinschätzungsanforderung (121)

Risikoeinschätzungsanforderung (1122)

Risikoeinschätzungsprozess

Erfüllungsprozess

WS-Secure Conversation (WS-SC) oder WS-Security (WSS) oder Sicherheit auf Transportstufe (TLS/SSL)

WS-Reliable Messaging (WS-RM)

Diese Nachrichten enthalten persönliche Daten.

WS-SC wird für Massenanfragen und häufige Anfragen (z. B. Kreditauskünfte) verwendet.

Verwenden Sie WS-Security für weniger häufige Anfragen, bei denen die Gemeinkosten des Sitzungsaufbaus nicht durch die Anfragenmenge gerechtfertigt werden.

Verwenden Sie in Fällen, in denen Anfragen von einem Dienst direkt verarbeitet werden, ohne durch Zwischenstellen geleitet zu werden, TLS/SSL.

Verwenden Sie WS RM für Datenanforderungen, die teuer zu verarbeiten sind.

Sie könnten sich nach dem Vornehmen einer Einreichung evtl. folgende Frage stellen: Warum wird der Status in einer separaten Transaktion zurückgegeben? Nun, dies hat zweierlei Gründe. Erstens ist es wichtig, dass dies asynchron geschieht, und der ACORD-Standard ermöglicht keine Implementierung, ohne den Status von der Einreichung zu trennen. Zweitens wird der Makler im Verlauf des Anwendungsprozesses durch Abfragen des Statusdienstes regelmäßig Statusrückgabedaten erhalten.

Die Versicherungsträgersysteme

Beim Entwerfen der Server-Seite der Lösung waren besondere Aspekte und Annahmen zu berücksichtigen:

  • Diese Architektur arbeitet mit fragmentierten Systemen.

  • Funktionsbereiche sind eigenständig und müssen verwaltet werden.

  • Betriebssysteme und Entwicklungsumgebungen sind unterschiedlich beschaffen.

Dadurch entsteht eine beträchtliche Anzahl an Punkt-zu-Punkt-Integrationen mit sehr spezifischen Anwendungen, die firmeneigene Implementierungen notwendig machen. In dieser Lösung wird die äußere Schicht um diese bestehenden Anwendungen herum erstellt.

Abbildung 6: Versicherungsnachrichtenbus
Abbildung 6: Versicherungsnachrichtenbus

Hier können Sie sehen, wie wir den Unternehmensdienstbus (ESB) als Nachrichtenbus verwenden. Diese Schicht wird als zentralisierte Messaging-Schicht dienen, die unsere internen und externen Nachrichten verwalten wird. Hauptvorteile dieser Architektur sind Verwaltung und Orchestrierung.

Eine Infrastruktur wie diese kann Ordnung in das Chaos ungleichartiger Punkt-zu-Punkt-Integrationen bringen, indem sie intelligente, lange andauernde Orchestrierungen und Policen nicht in vielen Schichten, sondern in einer einzigen Schicht in Transaktionen umwandelt. Es kann häufig vorkommen, dass mehrere verschiedene COTS-basierte Anwendungen in mehr als fünf oder sechs Systemen verwendet werden, um eine End-to-End-Transaktion abzuwickeln. Wir reduzieren diese Systeme beträchtlich, wenn wir die redundanten Funktionen (z. B. Arbeitsabläufe und Messaging) zusammenfassen, die Funktionen der Infrastrukturebene dort belassen, wo sie hingehören, und die Betriebslogik in geeignete Anwendungen packen.

Es ist wichtig, daran zu denken, dass dieser Nachrichtenbus eine logische Darstellung ist. Die Implementierungsansicht kann sehr unterschiedlich aussehen. So könnte der Nachrichtenbus beispielsweise aus mehreren BizTalk-Servern bestehen, oder Server könnten in unterschiedlichen DMZ-Umgebungen vorliegen, um sowohl interne als auch externe Kommunikationen zu verwalten.

Abbildung 7: Workflowdesigner (klicken Sie auf das Bild, um es zu vergrößern)
Abbildung 7: Workflowdesigner (klicken Sie auf das Bild, um es zu vergrößern)

Die nächst tiefere Ebene, auf der spezielle Betriebsfunktionen ausgeführt werden, enthält zwei verschiedene firmeneigene Systeme mit ihrer Benutzeroberfläche: Auftragssystem und Erfüllungssystem. Wir behalten diese Systeme als separate Systeme bei, statt sie zusammenzufassen, weil es sich bei diesen Systemen in den meisten Fällen um zwei separate Systeme auf COTS-Basis handelt.

Aus den folgenden Gründen wurde ein Statussystem hinzugefügt:

  • Bereitstellung eines zentralisierten Pfades, um den Status an die Vertreter zu übermitteln

  • Reduzieren der Anzahl von Schnittstellen und der Steuerlogik, die zum Abfragen mehrerer Systeme erforderlich wären

  • Es passt hervorragend zu den Orchestrierungsfähigkeiten unseres ESB für unseren lange andauernden Arbeitsablauf.

Das Auftragssystem und das Erfüllungssystem wurden in grobkörnige Dienste konvertiert. Dadurch haben wir die Abhängigkeiten unabhängiger Implementierungen ausgemerzt. Jede Kommunikation mit diesen Systemen wird jetzt über unseren Nachrichtenhub abgewickelt. Die freiliegenden Webdienstendpunkte, die vom Nachrichtenbus verwaltet werden, können nun durch Orchestrierungstechnologien verwaltet werden, die in BizTalk integriert sind.

Abbildung 8: Muster des End-to-End-Nachrichtenaustauschs
Abbildung 8: Muster des End-to-End-Nachrichtenaustauschs

Jetzt, da diese Anwendungen als Webdienste freiliegen, kann jede Technologie, die XML von Webdiensten annehmen kann, mit diesen Anwendungen integrativ kombiniert werden. Dadurch entfällt das dichte Verkoppeln der Protokolle anderer Technologien, die eine Interoperabilität einschränken würden. Sie könnten beispielsweise genauso leicht vorhandene Java-basierende Systeme verwenden, wenn solche Systeme in Ihrer Firma betrieben werden.

Microsoft SQL Server wird hier dazu verwendet, Anwendungsdaten in der Datenbankschicht zu speichern. Da vor allem Integration und zusammengesetzte Anwendungen im Brennpunkt dieser Dokumentation stehen, wollen wir hier nicht weiter darauf eingehen.

Die erwähnten Drittanbieterdienste sind externe Dienste, die vom Erfüllungsdienst aufgerufen werden. Diese Dienste besitzen unterschiedliche Protokollanforderungen. In dieser Dokumentation wird jedoch demonstriert, wie Sie mithilfe von WS-*-Standards mehr Funktionalität für Ihre Dienste bereitstellen können. Achten Sie darauf, dass in der Realität viele der Drittanbieterdienste für Versicherungen nicht die fortschrittlicheren Webdienste auf SOAP-Basis sind, sondern nur eine auf XML beruhende Kommunikation unterstützen. In den folgenden Abschnitten über die Messaging-Architektur wird auf die Drittanbieterdienste näher eingegangen.

Messaging-Architektur für Versicherer

In diesem Abschnitt wird eine einfache Lebensversicherungspolice behandelt, die vom Versicherer verarbeitet wird. Basierend auf den vom Kunden Robert bereitgestellten Daten haben die Geschäftsregeln bzw. die heuristische Logik, die im Risikoeinschätzungsprozess definiert wurde, die Entscheidung gefällt, dass zusätzlich eine ärztliche Bescheinigung verlangt wird.

Da diese Anfrage von einem anderen Anbieter erfüllt werden muss, erstellt das Auftragssystem eine Transaktion des Typs „ACORD XML TransType 121 General Requirements Order Request“ (TXLifeRequest) und übermittelt diese für den Arzt von Robert an ein sekundäres externes Auftragssystem (das Attest-System). Diese Nachricht enthält auch die MTOM/XOP-Anlage mit der Unterschrift von Robert, die ursprünglich der „ACORD 103 New Business Submission“-Nachricht beigefügt war und seinem Arzt die Befugnis erteilt, die medizinischen Daten für die Versicherungsgesellschaft freizugeben.

Der Arzt wird bei der Bearbeitung der Attestanfrage damit beginnen, die in der Anlage enthaltene digitale Unterschrift des Patienten anhand der in seinen Unterlagen vorliegenden Entsprechung zu überprüfen. Danach überprüft er die medizinischen Unterlagen und trägt im ärztlichen Attest die nötigen Angaben ein.

Sobald der Arzt sein Attest fertig gestellt hat, wird eine „1122 General Requirements Status/Results Transmittal“-Nachricht generiert und zurück zum Endpunkt übermittelt, der unter „WS-Addressing ReplyTo“ in der vorherigen ACORD 121-Anfrage angegeben ist. Diese Nachricht wird ebenfalls über WS-Reliable Messaging zuverlässig zugestellt.

Nun wird der Rest des Betriebsprozesses ausgeführt, einschließlich eventueller automatisierter versicherungsmathematischer Entscheidungen. Da nun jedoch ein ärztliches Attest vorhanden ist und damit möglicherweise zusätzliche Informationen vorliegen, die nicht automatisch verarbeitet werden können, wird der Fall für die Notwendigkeit einer manuellen Prüfung und Genehmigung gekennzeichnet.

Abbildung 9: Nachrichtenaustauschmuster der Risikoeinschätzung
Abbildung 9: Nachrichtenaustauschmuster der Risikoeinschätzung

Erfüllungsdienst

In der Versicherungsbranche unterscheidet sich ein Erfüllungssystem oder -dienst beträchtlich vom Erfüllungsprozess:

  • Erfüllungssystem: System oder Dienst, das bzw. der eine Anfrage erhält und sie erfüllt. Stellen Sie sich einen Erfüllungsdienst als eine Integrationskomponente zum Sammeln von Daten vor. In diesem Fallbeispiel ist das Erfüllungssystem dafür zuständig, die verschiedenen Berichte von Drittanbietern einzuholen.

  • Erfüllungsprozess: Prozess, durch den eine Police vom Versicherungsträger ausgestellt wird.

Sie könnten jetzt fragen, weshalb wir den Erfüllungsdienst beibehalten haben. In diesem Fallbeispiel gehen wir davon aus, dass Systeme wie dieses als Kompaktlösungen verkauft werden. Dies soll nicht heißen, dass es unmöglich wäre, diese Schichten zu entfernen und stattdessen in einen Nachrichtenbus einzubinden.

Ein Messaging-Muster auszuwählen, ist nicht so einfach wie das Wählen der zu berücksichtigenden Standards. Beim Entwerfen dieses Teils der Lösung mussten wir die betrieblichen und rechtlichen Aspekte jeder einzelnen Transaktion untersuchen.

Bei einigen Transaktionen, wie z. B. dem Empfangen einer Kreditauskunft, fiel die Entscheidung leicht. Bei anderen Transaktionen, wie z. B. dem Einholen eines ärztlichen Attests, war es erforderlich, Anlagen beizufügen zu können.

Hier sind einige der Aspekte, die Sie beim Entwerfen Ihres Messaging-Systems berücksichtigen müssen:

  • Verständnis des Betriebsprozesses. Es ist wichtig, exakt zu verstehen, wie das Unternehmen die Nachrichten verarbeitet (denken Sie beispielsweise an die Datensicherheit). Wenn es sich bei den gesendeten Daten nicht um vertrauliche Daten handelt, brauchen Sie für die Nachricht normalerweise keine besonderen Sicherheitsvorkehrungen zu treffen.

  • Verarbeitung der Transaktionen von den Dienstanbietern. Dies kann sowohl intern als auch extern vor sich gehen. Wenn man sich auf Dienstanbieter einlässt, kann dies oft technische Einschränkungen zur Folge haben. Diese können etwa von der (fehlenden) Unterstützung von Standards bis hin zu eingeschränkten Betriebszeiten reichen.

  • Widmen Sie dem Aspekt der Sicherheit gebührende Aufmerksamkeit. Dies wird häufig übersehen. Sicherheit auf Protokollstufe, wie z. B. SSL/TLS, ist zwar oft ausreichend, aber eben nicht immer. Achten Sie darauf, den Vertraulichkeitsgrad der Daten zu beurteilen. Prüfen Sie die Nachrichtenwege, um zu ermitteln, wie viele Kommunikationsendpunkte die Nachricht passieren wird, bevor sie den endgültigen Empfänger erreicht.

  • Seien Sie realistisch und pragmatisch. Versuchen Sie beim Entwerfen dieser Dienste nicht mit Gewalt, jeden denkbaren Standard einzubeziehen. Zwingen Sie einer Nachricht keinen Standard auf, der dort nicht hingehört. Dies hätte nur eine überflüssige Komplexität zur Folge.

Abbildung 10: Nachrichtenaustauschmuster des Erfüllungssystems
Abbildung 10: Nachrichtenaustauschmuster des Erfüllungssystems

Worin liegt der Wert?

Bei der Vorstellung dieses Fallbeispiels wurden die Microsoft-Plattform und die Entwicklungstechnologien von Microsoft ausführlich erörtert. Zudem wurde auch auf Architekturentscheidungen eingegangen. Die Merkmale dieser Microsoft-Technologien wurden jedoch noch nicht behandelt.

Im Folgenden werden die Hauptvorteile aufgelistet, die eine Verwendung von Microsoft-Technologien in der Versicherungsbranche mit sich bringen:

  • Betriebsprozessautomatisierung: Betriebsprozesse sind kompliziert und bei jedem Betrieb anders beschaffen. Durch die von BizTalk bereitgestellten Orchestrierungsfunktionen können Wirtschaftsanalytiker Orchestrierungen entwickeln; dadurch wird der Systementwickler aus diesem Prozess herausgenommen und der betriebswirtschaftliche Aspekt in den Vordergrund gerückt.

  • Reduzierung des Integrationscodes: Durch die Adapter von BizTalk und das vereinheitlichte Programmierungsmodell von WCF wird für das Integrieren von Systemen wesentlich weniger Code benötigt.

  • Ausrichtung an Standards: WCF und BizTalk beruhen auf sofort einsatzbereiten Open XML-Standards. Nie wieder wird angepasster Code benötigt, um Webdienstestandards einzubinden.

  • Produktivität: Durch das Integrieren von Visual Studio IDE- und .NET 3.0-Technologien werden sowohl bei den Tools als auch bei der Entwicklungssprache beträchtliche Produktivitätssteigerungen gegenüber anderen Sprachen erzielt.

Schlussbemerkung

Wie dieses Whitepaper zeigt, genügt es nicht, Protokollstandards zu verwenden. Zur Nutzung der Vorteile der Interoperabilität müssen Sie die betriebliche Seite von Messaging-Transaktionen erfassen und sinnvoll einbeziehen. Dies trifft nicht nur auf die Versicherungsbranche, sondern auf alle Branchen zu.

Wir haben Webdienstestandards, aber das genügt noch nicht. Es bedarf zusätzlich einer angemessenen Sorgfalt, um die für Ihre Organisation optimalen Entscheidungen zu treffen. Anhand dieser speziellen Referenzimplementierung gehen wir ein realistisches Fallbeispiel durch und ermitteln das für die betrieblichen Faktoren optimal geeignete Messaging-System. Dies kann als Leitfaden herangezogen werden, um Ihnen in Ihrem eigenen Unternehmen beim Auswählen der richtigen Nachrichtenaustauschmuster zu helfen. Beim Auswählen spezieller Standards müssen bei allen Architekturen Kompromisse eingegangen werden. Es ist wichtig, diese Kompromisse zu verstehen und bereit zu sein, die sich daraus ergebenden Konsequenzen zu tragen.

Microsoft hat sich der Aufgabe verschrieben, Kunden das Entwerfen und Entwickeln dienstorientierter Lösungen zu erleichtern. Hier demonstrieren wir, dass Microsoft viele der ehemals abschreckenden branchenspezifischen Barrieren und Komplexitäten bereits aus dem Weg geräumt hat. Dies erstreckt sich über das Bereitstellen bahnbrechender Vordenkerleistungen im Bereich der Branchenstandards bis hin zur Automatisierung und zum Aufbau sofort einsatzbereiter Webdienst-Supportleistungen.

Ressourcen

Microsoft-Zentrum für Finanzdienstarchitektur

BizTalk

.NET 3.0 Framework

Entwicklungszentrum für Webdienste

MTOM 1.0

SOAP 1.2

WS-Addressing

WSS 1.1

Username Token Profile 1,1

X.509 Token Profile 1,1

WS-Secure Conversation

WS-Trust

WS-Reliable Messaging


Anzeigen:
© 2015 Microsoft