Near-Realtime-Datenhaushalt mit Kafka?
In der Bereitstellung von Kundendaten für Vermittler setzen Versicherer in Abhängigkeit von ihrem in die Jahre gekommenen Host-System auf eine zeitversetzte Bereitstellung der Daten: Aktualisierte Kundendaten stehen um einen Tag verzögert im Maklerportal zur Verfügung. Ruft der Kunde also direkt nach Online-Übermittlung eines Antrags im Service-Center an, so ist der Antrag für den Service-Agent noch nicht sichtbar. In Zeiten in denen Pakete innerhalb von 24 Stunden ihr Ziel finden und dies positiv bewertet wird, ist es für einen Makler durchaus negativ, wenn die Datenverarbeitung zeitversetzt und Daten teilweise nur tagesaktuell und nicht synchron zur Verfügung stehen.
Der Aufbau zentraler Vertriebsplattformen für Makler, Service-Center und Kunden, in denen sich CRM-Lösungen, Beratungsangebote und Portale wiederfinden, erfordert einen Datenhaushalt in Echtzeit. Gerade im Kontakt mit dem Endkunden ist eine Stringenz der Daten erforderlich, um kurzfristige Änderungen live mit dem Endkunden besprechen zu können.
Der Einsatz von Apache Kafka als Open-Source-Software-Projekt bietet auf den ersten Blick viele Vorteile, wenn es um die Bereitstellung eines aktuellen Datenhaushalts in Near-Realtime und die Entkopplung des Host-Systems geht. Aber welche Mehrwerte ergeben sich daraus und welche Herausforderungen gilt es zu meistern? Welche Erfahrungen gibt es aus der Praxis und welche Handlungsempfehlungen leiten sich dadurch ab? Ziel des Artikels ist eine pragmatische Herangehensweise an die Sicherstellung der Aktualität des Datenhaushalts einer heterogenen IT-Landschaft in Near-Realtime mittels Apache Kafka.
Willkommen in der Krise
Noch vor einigen Wochen konnte niemand ahnen, wie disruptiv sich die Situation in der Versicherungsbranche innerhalb kurzer Zeit ändern würde. Dort wo vorher Projekte zur Automatisierung von Prozessen die Unternehmensstrategie beherrschten, wurde und wird durch Corona der Fokus in den IT-Betrieb verlegt. Mitarbeiter wurden von heute auf morgen ins Homeoffice geschickt und stellen nun die VPN-Verbindung zum eigenen Unternehmen auf die Probe.
Vermittlern und Maklern brach plötzlich der persönliche Kontakt zum Kunden weg. Ausgerechnet in einer Phase, in der Kunden vor finanziellen Herausforderungen stehen oder in vielen Fällen die Zeit haben, den eigenen Versicherungsschutz zu prüfen und anzupassen.
Generell ist aktuell spürbar, dass sich die Menschen vermehrt für digitale Lösungen öffnen, sei es um den eigenen Job von zu Hause ausführen zu können oder für diverse Erledigungen. Angebote, die bisher eher offline wahrgenommen werden konnten, gibt es nun auch online. Die Menschen verstehen, was digital möglich ist. Die Erwartungshaltung an den medienbruchfreien digitalen Prozess steigt.
Die neue Realität
Versicherer haben in den letzten Jahren viel Geld und Zeit in die Automatisierung von Prozessen im digitalen Dreieck zwischen Versicherer, Vermittler und Endkunde investiert, unter anderem um folgenden Faktoren entgegenzutreten:
Heranwachsende Zielgruppen
Das Verhältnis und der Umgang mit digitalen Medien werden intensiver. Die Generation Z, die nun studiert oder in das Berufsleben einsteigt, ist mit Laptop, Smartphone und modernen Spielekonsolen aufgewachsen und hat ein natürliches Verhältnis zu diesen Medien entwickelt. Das digitale Angebot bietet eine hohe Individualisierung für jeden Anwender. Die Erwartungshaltung, die aus dieser Erfahrung resultiert, stellt diese Zielgruppe nun auch an den Versicherungsmarkt. Die Versicherer haben darauf in den letzten Jahren reagiert. Neue modulare Produkte ("Ich versichere meinen Laptop"), optimierte Kündigungsfristen (täglich kündbar) und digitale Angebote begegnen der gestiegenen Erwartungshaltung mit individuell zugeschnittenen Lösungen, von denen auch andere Zielgruppen profitieren. Auf diese Mehrwerte möchte niemand mehr verzichten.
Digital aufgestellte Vermittler
Auch die Vermittler haben diesen Trend schon längst erkannt. Einfaches Beratungsgeschäft wie beispielsweise der Verkauf einer Privathaftpflichtversicherung wird online mit dem Kunden abgewickelt. Die persönliche Beratung im Privatkundengeschäft bezieht sich schwerpunktmäßig auf Leben- und Kranken-Produkte, die heute noch weit erklärungsbedürftiger sind und eine höhere Provision erbringen und somit den persönlichen Einsatz finanziell gut ausgleichen. Der persönliche Kontakt zwischen Vermittler und Kunde erfordert, gerade zu Zeiten von COVID-19, ebenso den Einsatz moderner Kommunikationsformen (wie z. B. Videoberatung), Bereitstellung von aktuellen Daten, und eine hohe Flexibilität, um im Gespräch direkt auf die Wünsche und Anfragen des Kunden reagieren zu können. Der Digitalisierungsdruck wird vom Makler an den Versicherer weitergegeben, der somit eine weitere Zielgruppe unterstützen muss.
Das stetige Sinken der Vermittlerzahl in den letzten Jahren macht die Situation nicht einfacher. Neben der Herausforderung, sich technisch weiter zu entwickeln, müssen die Versicherer ihre Produkte zielgruppenübergreifend einfacher aufbereiten. Der Kunde muss in die Lage versetzt werden, online – mit oder ohne Vermittler – zurechtzukommen.
Neue Player im Markt
Online-Vergleichsportale, digitale Makler oder digitale Versicherer erhöhen den Druck auf die etablierten Versicherer hinsichtlich der Effektivität ihrer digitalen Prozesse. Auch fördern gesetzliche Veränderungen wie PSD2 (Payment Services Directive2) neue Angebote im Markt, denen auch die Versicherer nachkommen müssen. Dabei muss man verstehen, dass es sich hier nicht immer um Konkurrenzsituationen handelt. Die etablierten Unternehmen und die neuen Player arbeiten eng zusammen.
Die Versicherer haben längst verstanden, dass sie in der Zusammenarbeit mit den neuen Playern viel lernen können und auch die neuen Player im Markt profitieren von der Zusammenarbeit mit den Versicherungen.
Wie in allen Branchen nimmt der Veränderungsdruck auf die Marktteilnehmer zu, auch wenn man in der Versicherungsbranche den Eindruck hat, bewusst anderen Industrien mit gewissem Abstand zu folgen.
Was sind die aktuellen Handlungsfelder der Versicherer in der Schnittstelle zum Kunden, die auch Vermittler und neue Player im Markt berücksichtigen müssen?
Daten als kritischer Pfad
Die Rohdiamanten der Versicherer sind die in den vergangenen Jahrzehnten gesammelten Daten. Sie geben Informationen über (familiäre) Beziehungen, anstehende Lebensereignisse, Verhaltensweisen, Schadenquotienten und am Ende auch über die Bonität der Kunden. Durch den Zusammenschluss oder die Übernahme von Versicherern, aber auch durch interne Entscheidungen in den Versicherungshäusern, verfügen die etablierten Versicherer über keine zentrale Datenhaltung. Vertragsdaten werden nach Sparten (Leben/Sach/Kranken) oder gegebenenfalls als Relikt der Vergangenheit in den verschiedenen Bestandslösungen zusammengeführter Versicherer gelistet. Vorteile aus den vorhandenen Daten können nicht ausreichend gezogen werden, die Rohdiamanten werden nicht geschliffen. Dass diese Daten aber nicht nur für das Angebot von (neuen) Produkten genutzt, sondern auch die Kommunikation in Richtung Kunden und Vermittler verbessern könnte, haben die Versicherer erkannt.
Die Versicherer gehen die "Diamantenförderung" unterschiedlich an. Zwei Optionen werden hier beleuchtet. Option 1 ist die Migration von Daten in ein vorhandenes zentrales Bestandssystem, Option 2 der Kauf und die Individualisierung (das Customizing) von technisch neuen Bestandslösungen und die Migration der bestehenden Daten in diese. Beide Vorhaben sind auf Jahre angelegt und bieten erst "Step by Step" einen Mehrwert. Eine ergänzende und vermutlich schnellere Alternative ist die Bereitstellung einer zentralen Vertriebsplattform als Frontend. Ziel ist hier, die Daten aus den verschiedenen Datentöpfen zu ziehen und zentral an einer Stelle anzubieten. Welche wichtige Rolle Kafka in diesem Zusammenhang spielen kann, erläutern wir an späterer Stelle.
Zentrale Vertriebsplattformen rücken in den Fokus
Warum ist die zentrale Bereitstellung der Daten so wichtig? Der Fokus richtet sich auf die Kontrolle der Daten, eine 360°-Kundensicht für den Versicherer, für den Vermittler und erst recht für den Kunden. Das Ganze wird verkompliziert, wenn es übergreifend darum geht, diesem Anspruch auch für einen Makler, der mit mehreren Versicherungen zusammenarbeitet, oder einen Kunden, der seine Versicherungen bei verschiedenen Versicherungen hat, gerecht zu werden.
Diese zentralen Vertriebsplattformen haben aber nicht nur das Ziel, Daten zentral anzubieten, sondern sollen die zentrale Schaltstelle werden, um Daten einzugeben – und dabei von verschiedenen Anwendergruppen (Innen- und Außendienst, Partner, Kunden) genutzt werden. Damit dies gelingt, müssen die einzelnen Zielgruppen pragmatisch eingebunden werden. Für die Zielerreichung ist zu Beginn ein Zielbild zu erstellen, um anschließend Schritt für Schritt das Bild umzusetzen. Aber was macht eine gute Vertriebsplattform aus?
Vertriebsplattformen als Datawarehouse
Mit dem Blick auf eine koordinierte Ansprache des Kunden über die verschiedenen Kommunikationskanäle im Innen- und Außendienst, bieten zentrale Daten die Chance den Kunden über verschiedene Kontaktwege mit einheitlichen Informationen zu versorgen. Schließt der Kunde beispielsweise online einen Vertrag ab und findet im Nachhinein einen Fehler im Vertrag, möchte er im Zweifel direkt mit dem Vermittler oder dem Service-Center des Versicherers die Änderung besprechen. Es scheitert schon oft daran, dass Daten erst über Nacht eingespielt werden und somit frühestens am Folgetag bei den verschiedenen Ansprechpartnergruppen aufschlagen.
Die Integration einer Beratungskomponente ist sinnvoll. Die Akzeptanz der Anwender steigt, wenn sie durch die bereitgestellten aktuellen Daten einfach und flexibel auf die Bedürfnisse des Kunden im persönlichen Gespräch oder am Telefon eingehen können. Als Ergebnis aus dem Beratungsgespräch muss die Option bestehen, den Vertrag mit dem Kunden abschließen zu können. Viele Versicherer sind mittlerweile so aufgestellt, dass die Online-Anträge auch direkt eingespielt werden können. Die Herausforderung liegt aktuell darin, dass auch hier die Daten direkt über die verschiedenen Kanäle sichtbar werden. Selbst wenn die Verarbeitung nicht direkt erfolgen kann, so ist zumindest ein Status-update als Information erforderlich.
Eine moderne Plattform bietet die Option, für die verschiedenen Anwendergruppen (auf Basis verschiedener Rollen und Rechte) Kampagnen zu erstellen oder zu verteilen. Ziel ist auch hier, den Vorteil zu nutzen, die Kunden anhand ihrer gebündelten Daten besser zu kennen. Diese Kampagnen können den Kunden über verschiedene Wege erreichen (Post, Endkundenportal, Homepage). Hierfür sind insbesondere auch Daten wie Hobbies oder Interessen relevant, die der Vermittler kennt und gegebenenfalls nicht mit dem Versicherer teilen möchte. Ein entsprechendes Rechte-/Rollenkonzept muss auch deswegen dem Vermittler zugesichert werden.
Um das Angebot auch für den Kunden attraktiv zu machen, muss der Kunde die Möglichkeit haben, aufgrund der vorhandenen Daten einfache Veränderungen abschließend durchzuführen oder zumindest anstoßen zu können – Stichwort "Self-Services". Der Kunde ist hierfür nicht zwingend als Anwender eines Portals zu registrieren. Vielmehr muss er die Chance haben, seine Informationen oder Änderungen einfach, aber datenschutzgerecht, zu teilen.
Digitale Daten-Dynamik
Die Unternehmen der Versicherungsbranche verfügen über ein riesiges Datenvolumen, das zusammengeführt und im Unternehmen verfügbar gemacht werden muss. Alte, schwerfällige Systemlandschaften stehen digitalen Chancen mit leichtgewichtigen Prozessen gegenüber. Die Sanierung der eigenen Systemwelt ist aufwändig, muss aber angegangen werden, da die rein digitalen Mitbewerber nicht warten. Um in der Zwischenzeit den Anschluss nicht zu verlieren, müssen technologische Trends kontinuierlich bewertet, in Betracht gezogen und etabliert werden.
StatusQuo: Peer-2-Peer-Verbindungen
Um den aktuellen Herausforderungen der Versicherungen gerecht zu werden und diese Datenflut zu bewältigen ist eine leistungsfähige Integrations-Architektur zwingend erforderlich. Ohne sie kann eine Omni-Channel-Vertriebsstrategie nicht umgesetzt werden. Des Weiteren ist die Befüllung eines Datawarehouse, sowie der Aufbau einer 360°-Kundenauskunft sehr aufwändig und gestützt durch tausende Zeilen Quellcode, die gewartet und weiterentwickelt werden müssen. Durch die Integrations-Architektur können die riesigen Datenmengen effizient im Unternehmen verfügbar gemacht und genutzt werden, um den digitalen Herausforderern nicht das Feld zu überlassen.
Oftmals basiert die derzeitige Architektur auf unzähligen historisch gewachsenen Punkt-zu-Punkt-Verbindungen (s. Abb. 3), die nicht genau dokumentiert sind. In großen, gewachsenen Organisationen steigt die Komplexität des Gesamtsystems dadurch stark an und die Stabilität leidet. Die Relevanz einzelner Verbindungen wird erst dann sichtbar, wenn zum Beispiel ein FTP-Server abgeschaltet wird. Die daraus resultierende Hektik beschäftigt viele IT-Abteilungen das ganze Jahr über.
Um dem Komplexität-Overkill Herr zu werden, gibt es unzählige Projekte, die das Ziel haben, zentrale Backend-Systeme (z. B. ESB) zu etablieren, über die alle Peer-2-Peer-Verbindungen geleitet werden sollen. Die Versprechen sind an dieser Stelle die Wiederverwendbarkeit der Schnittstellen zu sichern, eine Transparenz des Gesamtsystems zu erreichen, die Stabilität zu erhöhen und die Kontrolle zurückzugewinnen. Der Traum der Enterprise-Architekten scheint wahr geworden zu sein.
Der Aufwand für diese Integrationsprojekte läuft nicht selten aus dem Ruder und entwickelt sich zu einer unendlichen Geschichte. Die Idee, dass Geschäftsentitäten für jeden Anwendungsfall gleich dargestellt werden, hat sich spätestens mit Domain-driven Design als unzutreffend herausgestellt. Dazu kommt, dass gerade im Rahmen von modernen Architekturen (z. B. Microservices) die Realität gezeigt hat, dass zentrale Integrations-Architekturen (z. B. ESB-Systeme) zu schwerfällig sind und der Aufwand für die Wartung und Pflege exponentiell mit den Anforderungen wächst. Die gewünschte Time-to-Market, um die die digitalen Herausforderer beneidet werden, ist damit kaum realisierbar.
Wenn 24 Stunden nicht mehr reichen
In den Bestandsführungssystemen der Versicherungsunternehmen werden Verträge aus mehreren Dekaden verwaltet. Der Zeithorizont für diese Art von Systemen ist daher entsprechend lang und die eingesetzte Technologie eher elaboriert. Im konkreten Fall kommen häufig hostbasierte Systeme zum Einsatz. Jahrelang war es ausreichend, Daten tagesaktuell bereitzustellen. Die Erwartungshaltung an den modernen Kundenkontakt hat sich jedoch weiterentwickelt. Die Aktualisierung der Daten auf allen Kanälen muss in Zukunft nahezu in Echtzeit erfolgen. Polling von definierten Endpoints ist in diesem Rahmen nicht zukunftsfähig. Die Zeitintervalle können nicht klein genug gewählt werden und der Hardwarebedarf wäre unbezahlbar.
Um den gestiegenen Anforderungen, wie Antwortzeit und Datenaktualität im Omni-Channel-Vertrieb, gerecht zu werden, ist ein Umdenken erforderlich, wie Anwendungssysteme gebaut und miteinander integriert werden. Die Zukunft großer Anwendungssysteme liegt in reaktiven eventbasierten Architekturen. Durch den Einsatz steigt die lose Kopplung. Dies dient der Ausfallsicherheit und senkt die Kosten für den Betrieb, da weniger Hardware vorgehalten werden muss. Des Weiteren wird sich den großen Cloud-Native-Architekturen angenähert.
Was ist eigentlich Kafka?
Eventbasierte Architekturen basieren, wie der Name schon sagt, auf Events. Ein Event ist ein atomares Ereignis, das in der Systemlandschaft auftritt (z. B. die Änderung der Adresse oder ein Klick auf einen Button in der UI). Wichtig ist dabei zu beachten, dass Events nicht mit Commands verwechselt werden. Ein Event liegt in der Vergangenheit (die Adresse hat sich geändert) wohingegen ein Command zur Steuerung verwendet wird (ändere die Adresse). Es fallen jeden Tag unzählige Events an, wobei nicht alle für uns relevant sind. Wir beschäftigen uns in diesem Artikel nur mit den Geschäftsvorfällen (Business Events).
Um der Vielzahl von Events gerecht zu werden und sie nahezu in Echtzeit (Near-Realtime) durch unser System zu propagieren und zu verarbeiten, kommt immer häufiger Apache Kafka zum Einsatz. Bekannte Alternativen für die Eventverarbeitung im Unternehmen sind ActiveMQ und RabbitMQ. Im Folgenden wird ein Blick auf Kafka geworfen und untersucht, wie es bei Versicherern eingesetzt wird.
Kafka ist eine verteilte Streaming-Plattform, bei der sehr viel Wert auf Skalierbarkeit und Performance gelegt wird. Die Plattform implementiert das Publish/Subscribe-Pattern um die Events nahezu in Echtzeit zu verteilen, wodurch unsere reaktive Architektur sinnvoll unterstützt wird.
Die Daten werden innerhalb von Kafka in Topics organisiert (s. Abb. 4) und in Form von Logs abgelegt. Ein wahlfreier Zugriff auf die Events ist durch Standard-Tools nicht möglich, allerdings kann der Zeiger jederzeit auf einen beliebigen Punkt im Log gesetzt werden. Die Verarbeitung der Events kann ab einem bestimmten Zeitpunkt erneut durchgeführt werden, was zum Beispiel den Einsatz des Event Sourcing Pattern ermöglicht. Die Events werden von Producern an die Topics gesendet und von Consumern empfangen. Eine Besonderheit gegenüber JMS ist, dass mehrere Consumer auf einem Topic registriert sein können und jeder Consumer seinen eigenen Pointer auf das Log hat.
Consumer und Producer können in nahezu jeder beliebigen aktuellen Programmiersprache erstellt werden. Es gibt Client-Bibliotheken für Java, .Net, Go, Python und viele mehr. Durch die IBM Event Streams sollte sogar die Integration in Cobol möglich sein. Mit dem Connector API stellt Kafka zusätzlich eine Möglichkeit bereit, um Umsysteme auf einfache Weise zu integrieren. Ein Connector ist eine Softwarekomponente, die sich beispielsweise zu einer Datenbank verbindet und daraus Events generiert. Damit ist es möglich, aus nahezu jedem beliebigen System Events zu generieren und in Topics zu laden. Neben dem lesenden Zugriff können eingehende Events auch zugestellt werden. Stellt ein Host-System bereits fachliche Events an eine ActiveMQ-Instanz zu, ist Kafka in der Lage, die Events über einen ActiveMQ-Connector zu lesen und weiterzuverarbeiten.
Event Mining vs. Business Events
Um Topics mit Daten zu befüllen, müssen Events erzeugt werden. Im Idealfall ist es möglich, die gesamte Anwendungslandschaft zu beeinflussen und fachliche Events, die über Vertragsänderungen informieren (z. B. vom Bestandsführungssystem), sind frei wählbar. Danach müssen diese Events nur noch konsumiert werden und die Integration ist abgeschlossen.
In der Realität handelt es sich meist um eine sehr heterogene Anwendungslandschaft, die historisch gewachsen ist. Dies sind Systeme, die regelmäßig einmal im Jahr released werden, wodurch das Ziel der schnellen Time-to-Market in den Wind geschrieben werden kann. Bei einigen Systemen kommt die Abhängigkeit zum Hersteller hinzu, der vielleicht nicht bereit ist, ein besonderes Feature für den Versicherer zu integrieren. Aber wie können die Events dann erzeugt werden?
Die Antwort heißt Change Data Capture. Damit können die Daten mittels Connectoren aus unterschiedlichen Quellen verarbeitet und in ein Topic geladen werden (s. Abb. 5). Um das Verfahren sinnvoll einsetzen zu können, muss es möglich sein, die Änderungen zu ermitteln. Exportierte Dateien können im Batch eingelesen und zeilenweise auf ein Topic gesendet werden. Dabei gilt es zu beachten, dass nur Deltas exportiert werden oder über einen Timestamp ersichtlich ist, welche Datensätze neu sind.
Über den JDBC Connector wird direkt auf die DB zugegriffen. Mit einfachen SQL-Mitteln werden die Daten so eingeschränkt, zum Beispiel über Timestamps, dass nur die Deltas extrahiert werden. Dadurch wird allerdings eine direkte Kopplung zwischen den Topics und dem konsumierten DB-Schema geschaffen. Trotzdem kann dieser Schritt erforderlich sein.
Das minimal-invasivste Verfahren ist die Verwendung des DB Transaction Logs. Für die meisten DB-Systeme gibt es von verschiedenen Herstellern Softwarekomponenten, um die Daten auszulesen und weiter zu verarbeiten. Das Verfahren ist insbesondere in Szenarien, bei denen es auf die Unversehrtheit (Performance, Quellcode, DB-Schema) des Anwendungssystems ankommt, geeignet. Aus dem Transaction Log fachliche Events abzuleiten ist jedoch keine triviale Arbeit.
Der Wilde Westen für Events
Um nicht wieder in der Komplexitätshölle der Integration zu landen, muss genau beobachtet werden, welche Events im System unterwegs sind und wie mit Änderungen umgegangen wird. Bei mehreren Consumern auf einem Topic sind abwärtskompatible Änderungen zwingend erforderlich. Eine Möglichkeit ist die Verwendung der Avro Schema Registry, die von Confluent als Open-Source-Komponente bereitgestellt wird. Alternative Implementierungen sind Apache Thrift oder Protobuf. Bei der Entscheidung für eine Bibliothek zur Schemaevaluation muss insbesondere auf die verwendeten Programmiersprachen geachtet werden, denn es werden nicht alle Programmiersprachen unterstützt. Der Einsatz von Avro findet häufig Verwendung, da die Integration in das Gesamtsystem relativ einfach erfolgt und alle notwendigen Features abgedeckt werden.
In der Schema Registry registriert der Producer ein Schema, nach dem er die Events konstruiert und serialisiert (s. Abb. 6). Per Default sind alle Felder in einem Avro-Schema Pflichtfelder. Wird ein optionales Feld benötigt, muss es als nullable gekennzeichnet werden. Ein einmal registriertes Schema kann nur abwärtskompatibel weiterentwickelt werden, was bedeutet, dass nur optionale Felder hinzugefügt werden können. Hält sich der Entwickler nicht daran, kann das Schema nicht registriert werden und es wird von der Registry zurückgewiesen. Somit ist sichergestellt, dass die Deserialisierung der Events durch mehrere Consumer jederzeit gewährleistet wird und neue Events ebenfalls in alten Schemata serialisiert werden können.
IT der zwei Geschwindigkeiten
Bei den Überlegungen zur eventbasierten Architektur muss irgendwann die Frage gestellt werden, wie das Ganze betrieben wird. Der Betrieb von Kafka darf nicht unterschätzt werden. Damit die Streaming-Plattform sauber skaliert und hochverfügbar ausgelegt ist, bedarf es einiger Vorkehrungen. Für ein kleines Setup sind schnell mehr als 10 Prozesse erforderlich, die betrieben und überwacht werden müssen.
In vielen Unternehmen stützt sich der Betrieb zumindest teilweise auf der Cloud ab. Für Kafka gibt es in der Cloud verschiedene Managed-Service-Angebote, die verwendet werden können. Je nachdem wie weit die Betriebsmannschaft in der Bereitstellung von flexiblen Infrastrukturen ist, kann Kafka natürlich auch On-Premise verwendet werden. Wird ein Kubernetes Cluster betrieben und sicher beherrscht, spricht nichts dagegen, Kafka im eigenen Rechenzentrum oder in einer Private-Cloud zu betreiben. Ist das nicht der Fall, ist davon abzuraten und sollte eher der Start-Service von Confluent, AWS, Azure oder Google verwendet werden. Nach der erfolgreichen Einführung kann der Wechsel aus der Cloud zu On-Premise immer noch erfolgen, sofern er erforderlich ist.
Als Argument gegen den Cloudbetrieb wird an dieser Stelle häufig der Datenschutz vorgeschickt. Den kompletten Vertragsbestand einer Versicherung in ein Kafka-Cluster in der Cloud zu schieben, ist sicherlich eine Aufgabe, bei der die Sicherheit und der Datenschutz höchste Priorität haben. In solchen Fällen macht es immer Sinn, sich rechtzeitig mit dem Datenschützer zu unterhalten. Oftmals reicht es, an neuralgischen Punkten eine Verschlüsselung vorzusehen.
In einem konkreten Fall reichte die Verschlüsselung at-rest durch die Festplattenverschlüsselung und in-transit durch SSL nicht aus. Um das Problem zu lösen, haben wir in diesem konkreten Fall Wrapper für die Avro Serializer und Deserializer erstellt (s. Abb. 7). Die existierenden Implementierungen in unterschiedlichen Bibliotheken sind leider nicht ausreichend oder veraltet. Durch den Wrapper wird nach der Serialisierung des Events durch Avro der Output durch einen synchronen AES256-GCM-Algorithmus verschlüsselt. Bei der Deserialisierung wird das ankommende Event zuerst entschlüsselt, bevor die Daten mit dem Avro-Schema deserialisiert und weiterverarbeitet werden.
Ausblick
In diesem Beitrag wurde gezeigt, welchen enormen Herausforderungen der moderne Versicherungsvertrieb gegenüber steht und wie Versicherungsunternehmen den vorhandenen Datenschatz im Unternehmen verteilen können. Mit Apache Kafka haben wir eine sehr flexible, skalierbare und hoch verfügbare Integrations-Architektur skizziert, die auf unseren Erfahrungen aus der Praxis beruht. Unser Vorschlag basiert auf einer pragmatischen Herangehensweise, um die Aktualität des Datenhaushalts in einer heterogenen IT-Landschaft in Near-Realtime sicherzustellen. Bei den Ausführungen wurde auf die Mehrwerte eingegangen und konkrete Handlungsempfehlungen für den Betrieb gegeben. Jetzt heißt es loslegen. Stream On!
