Het is tegenwoordig duidelijk dat SOA de bedrijfswaarde verhoogt, vooral voor verzekeringsbedrijven die meerdere systemen en technologieën gebruiken die veel organisatie en communicatie vereisen (zie onderstaand diagram van Celent).
SOA Verzekering
De waarde van SOA is te danken aan het feit dat deze architectuur verschillende systemen dichter bij elkaar brengt en bestaande systemen toegankelijk maakt voor nieuw aangeschafte systemen en zelf ontwikkelde systemen. Verzekeringsbedrijven hebben te maken met complexe transacties met grote hoeveelheden gegevens en gegevensattributen die veel voorwaarden en regels omvatten voor het afsluiten van verzekeringen, premieberekeningen, commerciële overeenkomsten en andere doeleinden.
Source: Celent
De nieuwe generatie programma’s voor verzekeringsbedrijven moet de technologie en de kenmerken van het verzekeringsbedrijf op een nieuw productiviteitsniveau brengen. De activering van diensten vereist meestal de overdracht van gegevens tussen verschillende systemen. In veel gevallen is de hoeveelheid gegevens die uitgevoerd wordt, overgebracht wordt via de ESB (Enterprise Service Hub) en aan de andere kant ingevoerd wordt, enorm groot. Verzekeringsregels zijn in hoge mate afhankelijk van productversies/dekkingsversies en veel soorten verzekeringsregels hebben het formaat van coëfficiëntstabellen (een formaat dat vaak afgeleid is van de actuariële statistische analyse). Daardoor leidt een standaard SOA tot verminderde prestaties en duplicatie van gegevensmodellen. Standaard rule engines vereisen grote hoeveelheden gegevensoverdracht en productieversies moeten handmatig beheerd worden, omdat extra regels het model ingewikkelder maken.
Een mogelijke oplossing voor betere prestaties en hogere productiviteit, zoals in het IDIT™ software- verzekeringsprogramma, is het gebruik van een centrale gegevensbus die eenvoudig toegankelijk is via XML, om gegevens te plaatsen en op te halen. Een eenvoudige methode met behulp van OGNL (Object Graph Navigation Language) stelt niet-technische gebruikers in staat om regels uit te schrijven die de gegevens van de databus heel eenvoudig kunnen gebruiken (bijvoorbeeld. als Polis.totaalPremie > 500). De verzekeringsgeoriënteerde rule engine wordt zo genoemd omdat hij automatisch de versiecontext van alle regels en rulesets opslaat (terwijl hergebruik mogelijk is), gebaseerd op de koppeling met het verzekeringsproduct. Bovendien worden coëfficiëntstabellen op de databus geplaatst en zijn toegankelijk voor de rule engine in een regelformaat. Op deze manier kunnen voorwaarden, berekeningen en coëfficiëntsuitdrukkingen beheerd en onderhouden worden op één plaats en met één gegevensmodel.
SOA en dienstenbus
Als de infrastructuur gereed is, kan SOA gebruikt worden voor ‘het loodgieterswerk’ en uitgevoerd worden op standaard ESB-platforms, maar de architectuur kan ook de basis worden voor de geleidelijke evolutie van oudere systemen en applicatielogica naar de dienstenbus. Dit lijkt heel ingewikkeld. Hoe kan dit gedaan worden?
Steeds als een dienst een grote wijziging vereist of als er een nieuw dienst nodig is – wordt dit uitgevoerd op het gesuggereerde platform (rule engine & gegevensbus) tijdens ROI-controles. Op deze manier wordt een geleidelijke evolutie van oudere applicatielogica en oudere technologieën naar het platform vereenvoudigd (alleen voor oudere systemen). In het geval van IDIT™, bijvoorbeeld, omvat dit platform ook een grote bibliotheek met specifieke verzekerings-‘services’, zodat die evolutie nog efficiënter en dynamischer gemaakt kan worden. Dit vervangt de gebruikelijke manier die met SOA ingevoerd is – waardoor er meer geïnvesteerd kan worden in bestaande systemen, omdat ze nu in de architectuur ‘ingepast’ kunnen worden.
Dit zorgt voor een zeer rendabele en betaalbare, maar toch architecturaal solide roadmap, niet alleen om uw bestaande systemen en diensten onderling te verbinden, maar ook als een basis voor nieuwe ‘services’, die volledig aan de nieuwste technologieën en best practices aangepast is.
Een bijkomstige meerwaarde is te danken aan het feit dat het gegevensmodel weer geconcentreerd wordt in een model met een grotere cohesie, dat via de gegevensbus het unieke verzamelpunt kan worden voor alle metagegevens van het gegevensmodel, waardoor verdere integratie met andere organisaties of systemen eenvoudiger wordt.
= = =
