Abwärtskompatibilität

Nicht die ganze Norm lässt sich über die alten Services abbilden: Produktwissen liefern die alten Services nicht – das ist der Anlass dieses Projektes. Die Norm ist daher in zwei Profile gegliedert, das Basisprofil und das Profil Produktwissen; das Profil Produktwissen baut auf dem Basisprofil auf. Inhalt, Operationen und Nachweis der Profile beschreibt die Seite Profile der Norm. Das Basisprofil lässt sich vollständig über einen Wrapper erfüllen; das Profil Produktwissen verlangt eine echte Neuimplementierung oder einen Wrapper, der Produktwissen aus einem formalisierten Produktkatalog ergänzt, und ist optional.

Ein Wrapper kann beide Profile erfüllen:

Schon das Basisprofil bringt gegenüber OMDS 3 zwei Vorteile: die KI-fähige Syntax und das Prozesswissen, das es in OMDS 3 nicht gibt. Ein Client oder KI-Agent erfährt zur Laufzeit, welche Prozessvarianten eine Versicherung umsetzt, statt es aus Dokumentation oder bilateralen Absprachen zu entnehmen. Ein Wrapper, der nur die Syntax übersetzt, löst das Kernproblem aber nicht: Der Client muss das Produkt weiterhin kennen, und ein KI-Agent kann das Werkzeug „berechnen“ ohne Katalog nicht bedienen, weil es eine vollständige Produktinstanz verlangt.

Die Selbsttests weisen aus, welche Profile eine Versicherung erfüllt. Das Basisprofil ist eine Untergrenze, keine Obergrenze: Eine Versicherung, die ihr Produkt als Katalog formalisiert, erfüllt das Profil Produktwissen mit demselben Wrapper.

Der Wrapper ist die → Muster-Versicherung ohne eigenen Tarif. Alles, was sie hält und berechnet – den Entwurf, die Delta-Operationen, die Prüfung mit SHACL, das Produktwissen zur Instanz, die Folgeschritte –, bleibt im Wrapper; nur die Berechnung und das Aufbewahren der Geschäftsobjekte liegen hinter einer Adapter-Schnittstelle. Die Muster-Versicherung bindet dort ihren Beispieltarif an, der Wrapper einen SOAP-Adapter gegen die bestehenden OMDS-3-Services. Beide sind dieselbe Software.

Die Übergänge sind die Übergabepunkte an SOAP: „berechnen“ wird calculateKfz, „annehmen“ wird createOfferKfz, „einreichen“ wird submitApplicationKfz; die Tarifauskunft ruft calculateKfz, ohne etwas aufzubewahren; Zustandsänderungen, Dokumente und Nebenprozesse laufen über die entsprechenden OMDS-Operationen. Die Bearbeitung des Entwurfs bleibt im Wrapper und braucht den Versicherer nicht. Prämie je Baustein, Meldungen mit Elementbezug, Geschäftsfallnummer und Status der SOAP-Antwort werden auf Instanzknoten, Prüfbericht, Geschäftsfall und Zustände des Geschäftsobjekts abgebildet.

Daraus folgt: Der Wrapper hält den Entwurf. Bevor der erste SOAP-Aufruf erfolgt, kennt der Versicherer den Vorgang nicht; danach liegt das Geschäftsobjekt unter der Geschäftsfallnummer beim Versicherer. Der Wrapper deklariert daher „Entwurf am Server“ und braucht eine Datenhaltung mit Berechtigungen und Lebensdauer für Entwürfe. Für den KI-Agenten, den typischen Client ohne Vorwissen, ist der Entwurf am Server die Normalform, nicht die Ausnahme.

Für die Versicherung ist der Katalog keine Wegwerfinvestition: Stellt sie später nativ um, ersetzt sie nur den SOAP-Adapter durch einen Adapter an ihre Backendsysteme. Katalog, Entwurf, Prüfung und Produktwissen zur Instanz bleiben. Der Wrapper ist die erste Hälfte der nativen Umsetzung, nicht ihre Alternative.

Der Wrapper ist bei jeder Versicherung dieselbe Software, ein Baukasten aus den Server-Bausteinen der Norm, den die Versicherung selbst betreibt und bei Bedarf erweitert. Die Anpassung besteht aus drei Dingen, keines davon ist Code:

Die spartenspezifische Struktur ist nicht konfigurierbar und muss es nicht sein: Das Kfz-Schema von OMDS 3 ist kein generischer Baum, sondern typisierte Elemente mit festen Feldern. Diese Abbildung ist für alle Versicherungen gleich und gehört zur Norm; der Wrapper trägt sie als Code oder Daten. Die Abbildung der einzelnen Versicherung steht im Katalog, nicht im Wrapper.

Wird ein Wrapper auf die tatsächliche SOAP-Implementierung einer Versicherung hin konfiguriert, drohen alle Abweichungen vom heutigen Standard – bewusste und Implementierungsfehler – in ihn zu gelangen, und die Normseite wird je Versicherung ein wenig anders. Dann wäre die bilaterale Abstimmung nur verschoben. Der Wrapper ist deshalb in drei Schichten gebaut, und Abweichungen dürfen die mittlere Grenze nicht nach innen überschreiten:

Für eine Abweichung gibt es genau drei Orte:

Einen vierten Ort gibt es nicht: Die Nordseite antwortet nie „ein bisschen anders“, weil das Backend es so braucht. Der Baukasten prüft das in seiner eigenen Integration: Für jede Konfiguration läuft der Selbsttest gegen die Nordseite mit aufgezeichneten SOAP-Antworten.

Keine Abweichung sind produktspezifische Festlegungen, die OMDS 3 ausdrücklich erlaubt: verlangte optionale Elemente, eigene Bausteine über den generischen Produktbaustein, eigene Codes. Sie gehören in den Katalog und seine Abbildung, nicht in die Südseite. Das hält die Abweichungsschicht klein.

Das Register der Abweichungen ist mehr als eine Verlegenheitslösung. Es macht je Versicherung erstmals zählbar, wie weit die SOAP-Implementierung von der Norm entfernt ist, und es ist Rückmeldung an die OMDS-3-Arbeitsgruppe: Einträge, die auf mehrdeutige Prosa der Norm zurückgehen, sind Kandidaten für abschließend aufgezählte Varianten.

Katalog und Backend können auseinanderlaufen: Der Wrapper meldet eine Konfiguration als konform, der SOAP-Service antwortet mit einem Fehler. Das bricht das Modell nicht, weil die Versicherung ohnehin alle vier Prüfungen selbst ausführt und ihre Meldungen mit Elementbezug als Bericht am Instanzknoten durchgereicht werden. Es macht aber den Test des Katalogs gegen das Backend zur Pflicht: Die Beispielinstanzen des Katalogs laufen durch SOAP, und der Selbsttest vergleicht Deklaration und Verhalten. Der Wrapper macht die Qualität eines Katalogs damit messbar.

Das Produktwissen entsteht nicht aus beobachteten SOAP-Antworten. Die Attribut-Metadaten und Produktbaustein-Elemente, die OMDS 3 ad hoc in Antworten mitgeben kann, sind optional, unvollständig und an generische Bausteine gebunden; sie taugen als Prüfdaten, nicht als Quelle. Quelle ist der Katalog aus dem Autorierungswerkzeug (Werkzeuge) oder aus einem Export interner Systeme; das Spartengerüst lässt sich aus dem Kfz-Schema ableiten.

Damit das Basisprofil wrapperfähig bleibt, hält die Norm folgende Regeln ein:

Wrapperfähigkeit ist eine Nebenbedingung, die am Ende geprüft wird, keine Vorlage. Das Zielmodell entsteht aus den Use-Cases und den normierten Geschäftsprozessen, die eine parallele Arbeitsgruppe festlegt. Würde der Wrapper den Entwurf bestimmen, entstünde SOAP im JSON-Gewand, und die semantische Präzision, die KI-Agenten brauchen, ginge verloren. Ein reiner Protokollwrapper, der SOAP-Typen eins zu eins nach JSON abbildet, ist deshalb nicht konform.

Nicht Teil der Norm sind Wrapper bei Dritten: ein Wrapper beim Softwarehaus oder Vermittler über viele Versicherungen oder ein zentraler Wrapper beim Verband. Authentifizierung, Datenhoheit und Haftung wanderten zu einem Dritten, und Produktwissen lieferte er nicht. Eine SOAP-Fassade in Gegenrichtung – OMDS 3 vor einem nativen Server der neuen Norm, damit bestehende Vermittlerprogramme eine umgestellte Versicherung weiter erreichen – ist vorgesehen, sobald die erste Versicherung nativ umstellt, und wird dann ebenfalls als Baukasten gebaut.

Die Anforderung „ein Wrapper muss möglich sein“ ist für sich nicht prüfbar. Der Nachweis erfolgt daher über ein Artefakt: den Referenz-Wrapper, die Muster-Versicherung mit SOAP-Adapter, der jede normative Operation der beiden Profile über die bestehenden SOAP-Services demonstriert – das Basisprofil mit leerem Katalog, das Profil Produktwissen mit dem Katalog eines Beispielversicherers. Die Selbsttests für Versicherungen laufen gegen die Muster-Versicherung und gegen den Referenz-Wrapper.

Als erstes Ergebnis ist eine Gap-Analyse für die Sparte Kfz vorgesehen: je neuer Operation die zugehörigen SOAP-Operationen und die verbleibenden Lücken. Sie ist zugleich die Spartenabbildung der mittleren Schicht.