Mehrere Jahre habe ich für den größten Versicherungskonzern Europas gearbeitet und dort in der Kernsoftware neue Features entwickelt sowie bestehende Systeme gewartet. Die Landschaft, die sich einem in einem solchen Konzern offenbart, ist kaum zu überblicken, denn es gibt unzählige Schnittstellen zu eigenen Systemen, zu Drittsystemen, zu Modulen anderer Teams und zu Fremdsystemen, die wiederum ihre eigenen Eigenheiten mitbringen. Damals war ich als Berater für ein Beratungshaus tätig und habe die Arbeitsweise großer Versicherungskonzerne von innen kennengelernt, mit all ihren Prozessen, Abstimmungsschleifen und technischen Altlasten.
Heute bin ich selbständig und habe die Seiten gewechselt. Statt innerhalb eines Konzerns Systeme zu warten, baue ich Software, die das Leben im Umgang mit Versicherungen erleichtert oder an bestehende Schnittstellen der Versicherungswelt andocken soll. Und zum ersten Mal arbeite ich dabei direkt mit einer österreichischen Versicherung zusammen, was mich auf eine Besonderheit geführt hat, die es in dieser Form nur in Österreich gibt.
Der VVO und sein Standard
Der Versicherungsverband Österreich, kurz VVO, ist die Interessenvertretung der privaten Versicherungsunternehmen in Österreich und wurde bereits im Jahr 1899 gegründet. ¹ Mit 116 Mitgliedsunternehmen vertritt er nahezu die gesamte österreichische Versicherungswirtschaft und fungiert als zentrale Anlaufstelle für versicherungsrelevante Fragen gegenüber Politik, Wirtschaft und internationalen Institutionen.
Eine bemerkenswerte Eigenheit des VVO ist die Entwicklung einer eigenen Schnittstellendefinition namens OMDS 3.0, dem Österreichischen MaklerDatenSatz. ² Dieser Standard normiert den Datenaustausch zwischen Versicherungsunternehmen und ihren Vertriebspartnern, also Maklern, Mehrfachagenten und Softwareanbietern, die in ihrem täglichen Geschäft Polizzendaten, Vertragsinformationen und Prämienberechnungen austauschen müssen. Die Idee dahinter ist nachvollziehbar und im Grunde sinnvoll, denn ein einheitlicher Standard reduziert den Integrationsaufwand für alle Beteiligten und schafft eine gemeinsame Sprache in einer Branche, die traditionell von Insellösungen geprägt ist.
Was OMDS allerdings besonders macht, ist die technologische Basis, auf die der Standard setzt. Während die gesamte moderne Webentwicklung aus gutem Grund auf REST als Architekturstil für Schnittstellen baut, verwendet OMDS 3.0 das SOAP-Protokoll, und genau hier beginnt die Geschichte interessant zu werden.
SOAP in einer REST-Welt
SOAP, das Simple Object Access Protocol, ist ein XML-basiertes Nachrichtenprotokoll, das seine Wurzeln in den späten Neunzigerjahren hat und im Jahr 2003 als W3C-Empfehlung veröffentlicht wurde. ³ Es stammt aus der Java-Welt und war in den Nullerjahren die dominierende Technologie für Webservices in großen Unternehmen. Die Grundidee ist durchaus elegant, denn über sogenannte WSDL-Dateien lassen sich Schnittstellendefinitionen maschinenlesbar beschreiben, sodass Clients theoretisch automatisch generiert werden können.
Die Praxis sieht allerdings anders aus. SOAP ist verbose, die XML-Nachrichten sind aufgebläht, das Tooling außerhalb der Java-Welt ist lückenhaft und die Fehlersuche in verschachtelten XML-Strukturen gehört zu den weniger erfreulichen Tätigkeiten in der Softwareentwicklung. REST hingegen setzt auf einfache HTTP-Methoden, leichtgewichtiges JSON und eine Architektur, die intuitiv verständlich ist und sich mit praktisch jeder Programmiersprache bequem nutzen lässt. Dass die Welt sich aus guten Gründen in Richtung REST bewegt hat, ist kein Zufall, sondern das Ergebnis jahrelanger praktischer Erfahrung.
Und doch lebt SOAP in der Versicherungswelt weiter. Der VVO stellt auf Bitbucket ein Repository mit den OMDS-Servicedefinitionen bereit ⁴, und bis vor kurzem gab es dort auch einen Sampleserver, gegen den man Testanfragen schicken konnte. Dieser Sampleserver ist mittlerweile verschwunden, was vermutlich auch nicht weiter tragisch ist, denn er hat mich drei Tage Lebenszeit gekostet, in denen ich vergeblich versucht habe, ihn zum Laufen zu bringen. Gescheitert bin ich trotzdem. Man könnte OMDS als technologischen Dinosaurier bezeichnen, wobei das weniger abwertend gemeint ist als vielmehr als Feststellung, dass hier eine Technologie am Leben erhalten wird, die in den meisten anderen Branchen längst durch modernere Ansätze ersetzt wurde.
Die Konzernwelt von der anderen Seite
In den letzten Jahren war ich leichtgewichtig unterwegs. Bequeme REST-Schnittstellen, kleine agile Teams und die Zusammenarbeit mit hochqualifizierten Partnern, bei denen man sich darauf verlassen konnte, dass Entscheidungen schnell und kompetent getroffen werden. Und plötzlich befindet man sich wieder in der gut bekannten, etwas behäbigen und großen Konzernwelt, die einem als ehemaliger Berater so vertraut ist, dass sich ein fast nostalgisches Gefühl einstellt.
Gleich vorweg sei gesagt, dass die Zusammenarbeit unkompliziert und schnell funktioniert und die kompetenten Mitarbeiterinnen und Mitarbeiter auf der Versicherungsseite die Meetings kurzweilig gestalten. Auch der Respekt, den wir, als kleiner Fisch im großen Teich, bekommen ist erfrischend positiv. Der Perspektivwechsel ist dennoch bemerkenswert, denn als Berater im Konzern hatte ich ein System von innen gewartet und verbessert, während ich als Selbständiger von außen andocke und dabei auf Strukturen treffe, die ich zwar kenne, aber aus einer völlig neuen Richtung betrachte. Was früher die eigene Infrastruktur war, in der man sich frei bewegen konnte, ist jetzt eine fremde Schnittstelle, deren Eigenheiten man akzeptieren und in die eigene Architektur integrieren muss.
Wo KI den Unterschied macht
Vor zwei Jahren hätte mich die Integration der OMDS-Schnittstelle in krankenprofi.at vermutlich einen Monat Arbeit gekostet. Man hätte die Servicedefinitionen studieren, die XML-Strukturen verstehen, eine belastbare Architektur in PHP entwickeln und dann irgendwann feststellen müssen, dass die angebundene Versicherung nicht exakt auf den Standard setzt, woraufhin man die mühsam aufgebaute Architektur wieder hätte umwerfen müssen. SOAP und PHP sind keine natürliche Kombination, und wer schon einmal versucht hat, aus einer WSDL-Datei einen funktionierenden PHP-Client zu generieren, der weiß, dass die Theorie und die Praxis hier besonders weit auseinanderliegen.
In Zeiten von KI wird einem vieles davon abgenommen. Ein Large Language Model versteht die strukturierten Daten einer SOAP-API ohne Probleme und kann sie gezielt, ohne Kopfschmerzen und Kaffee-Überdosis, in einer SOAP-fremden Programmiersprache reproduzieren. Die Fehlerquote reduziert sich dabei auf ein Minimum, weil das Modell die repetitiven und fehleranfälligen Teile der Arbeit übernimmt, während ich mich auf die Architekturentscheidungen und die Geschäftslogik konzentrieren kann.
In meinem ersten Blog-Beitrag habe ich geschrieben, dass KI keine Erfahrung ersetzt, sondern sie skaliert. Genau das erlebe ich hier in der Praxis. Ohne meine Jahre in der Versicherungswelt, ohne das Verständnis für die Datenstrukturen und Geschäftsprozesse, die hinter einer Polizze, einer Prämienberechnung oder einem Vertragswechsel stehen, wäre auch die beste KI nur ein Werkzeug, das elegant aussehenden Code produziert, der am Ende an der Realität scheitert. Die Kombination aus Domänenwissen und KI-gestützter Implementierung ist es, die den eigentlichen Mehrwert schafft, und genau das habe ich in meinem Beitrag über Expertise gemeint, als ich argumentiert habe, dass echte Experten nicht durch Abkürzungen entstehen.
Die Bugs, die bleiben
Selbstverständlich gibt es auch bei KI-gestützter Entwicklung Bugs, die bei so komplexen Vorhaben unvermeidlich sind und einen manchmal viele Stunden beschäftigen, nur um am Ende festzustellen, dass die Lösung in wenigen Buchstaben bestand. Ein falscher Namespace, ein fehlendes Attribut in der XML-Struktur oder eine Versicherung, die den Standard an einer Stelle anders interpretiert als dokumentiert. Solche Fehler gehören dazu und werden sich auch durch noch so leistungsfähige Modelle nicht vollständig eliminieren lassen.
Aber der Spaß und die Freude, ein funktionierendes System zu entwickeln, das strukturierte Daten zuverlässig zwischen zwei Welten hin und her transportiert, ist hier sehr gut spürbar. Es fühlt sich an wie früher, als man nach wochenlanger Arbeit endlich das erste erfolgreiche Testergebnis gesehen hat, nur ohne die vielen Nebenwirkungen. Ohne die Kaffee-Überdosen, ohne die vielen schlaflosen Nächte vor dem XML-Parser und ohne das Gefühl, gegen Windmühlen zu kämpfen.
KI hat die Softwareentwicklung nicht einfacher gemacht. Sie hat die Reibung dorthin verlagert, wo sie produktiv ist, nämlich in die Architekturentscheidungen, in die Geschäftslogik und in die Frage, was wirklich gebaut werden muss. Die mechanische Übersetzungsarbeit, das stumpfe Abtippen von XML-Strukturen in PHP-Klassen, das Debuggen von SOAP-Envelopes, all das hat an Gewicht verloren. Was bleibt, ist die eigentliche Ingenieursarbeit. Und die macht nach wie vor Freude.
Erfahrung lässt sich nicht prompten. Aber mit Erfahrung lässt sich ein Prompt schreiben, der den Unterschied macht.
Die Schnittstellen werden nicht moderner. Aber die Werkzeuge, mit denen wir sie anbinden, schon. Und das verändert alles.