Omvangrijke systeemintegratie na de grootste Nederlandse overname in de verzekeringsmarkt succesvol afgerond

In 2017 lieten twee grote Nederlandse verzekeringsmaatschappijen gezamenlijk weten dat de overname van de een door de ander was voltooid. De moedermaatschappij is een beursgenoteerde financiële dienstverlener die producten en diensten aanbiedt op het gebied van verzekeringen, pensioenen en bankactiviteiten. Ruim 6 miljoen particuliere en zakelijke klanten in Nederland maken hier gebruik van. Juridisch mocht de overname in kannen en kruiken zijn, maar op het gebied van systeemintegratie begon het avontuur toen pas. Jeroen Jansen van Rosendaal, vanuit WeAreFrank! nauw betrokken bij de systeemintegratie, neemt ons mee in dit omvangrijke project. 

Doel van het integratieproject 

Ik werkte samen met de interne organisatie van de overnemende partij en de leadarchitect die verantwoordelijk was voor het neerzetten van een nieuwe enterprise-architectuur op het gebied van documentmanagement en het uitvoeren van de bijbehorende systeemintegratie. Hij zette de grote lijnen uit richting de toekomst en ik vertaalde dit naar oplossingen in het heden. Het uiteindelijke doel was de naadloze integratie tussen de digitale archieven van beide verzekeringsmaatschappijen. Je kunt hier niet in één grote stap naartoe. Dat is voor zo’n groot integratieproject niet alleen onhaalbaar, maar ook onbetaalbaar. Daarom hebben we de systeemintegratie opgedeeld in verschillende fasen en tussenoplossingen om zo het doel te bereiken.

Verschillen tussen de twee corporate organisaties 

Beide verzekeringsmaatschappijen zijn corporate organisaties met elk een eigen IT-organisatie en een eigen manier van werken. Waar de overnemende partij vrij gestructureerd werkte, voornamelijk met ingekochte applicaties, bouwde de overgenomen verzekeringsmaatschappij zelf hun oplossingen met behulp van verschillende ontwikkelaars. Ook was er een duidelijk cultuurverschil te zien: bij de overgenomen organisatie stuurde de business sterk op de ontwikkeling en koppeling van applicaties. Dat is aan de ene kant prima, maar aan de andere kant ook lastig bij het opzetten van een goede IT-architectuur. Vraaggestuurd ontwikkelen leidt namelijk tot veel maatwerk. Zo ontstond een divers IT-landschap met weinig structuur, waar we bij de overnemende verzekeringsmaatschappij misschien weer te veel structuur en te weinig vrijheid zagen.

Systeemintegratie: de genomen stappen

De integratie tussen de twee bedrijfssystemen kon op twee manieren plaatsvinden:

1. We bouwen een heel nieuw archief. Dat betekent dat alle systemen opnieuw aangesloten moeten worden op dit nieuwe archief.
2. We werken met een flexibele tussenlaag om beide archieven met elkaar en andere systemen te integreren.

Optie 1 zou erg tijdrovend en kostbaar zijn. Bovendien werkten beide verzekeringsmaatschappijen met standaardpakketten die niet aangepast konden worden aan een nieuw archief. Daarom zijn we met optie 2 aan de slag gegaan: de implementatie van het Frank!Framework als integratietool.” Dit framework vormde de basis voor de systeemintegratie en is een Open Source framework op basis van Java. Hiermee ben je in staat om relatief eenvoudig maatwerkkoppelingen op basis van lowcode(configuratie) te maken. Een ander voordeel is de bijbehorende beheermodule, waardoor beheerders inzicht krijgen in de status van de koppelingen en data.

Wat is het Frank!Framework?

De eerste stap in ons integratieplan was het migreren van de archieven van de overgenomen verzekeringsmaatschappij naar de nieuwe oplossing. Uiteraard na het maken van analyses hoe we het slimst zouden komen tot ons einddoel. Eigenlijk wilden we het archief helemaal uitfaseren, maar bepaalde gegevens, gekoppeld aan bijvoorbeeld pensioenverzekeringen, moet je wel 30 jaar bewaren volgens de weten regelgeving. Daarom waren we genoodzaakt het oude archief aan te sluiten op de nieuwe omgeving om die informatie te behouden.

De services die op het oude archief draaiden, hebben we weer opgebouwd in het Frank!Framework dat in het landschap van de overnemende verzekeringsmaatschappij draait. Met een replicatiemechanisme werden oude documenten overgezet, zodat er een kopie van het oude archief in het nieuwe archief kwam te staan. Op die manier hoefden we weinig te veranderen aan de systemen zelf, maar voornamelijk aan de communicatie tussen de systemen.

We hebben een tijdje de ‘afnemers’ (bedrijfsapplicaties) op beide archieven laten werken, het is namelijk onmogelijk om alle afnemers in een keer over te laten gaan. Daarom gebruikten we beide archieflocaties voor de services. Dit geeft ook ruimte om het een en ander aan de achterkant op te schonen. Uiteindelijk zijn sommige afnemers overgenomen door de overnemende verzekeringsmaatschappij en zijn andere uitgefaseerd. Zo zijn we stap voor stap gevorderd met de integratie.

Het resultaat

Voor de eindgebruikers ziet het systeem er nu hetzelfde uit als voorheen, alleen aan de achterkant worden wat extra stappen gezet om de juiste informatie naar boven te halen. Daar werkt ons framework als tussenlaag, waarop alle verschillende afnemers zijn aangesloten. Op die manier krijg je met goed gedefinieerde services alsnog de juiste informatie naar boven. Via het Frank!Framework als tussenlaag, komen afnemers van de overgenomen verzekeringsmaatschappij nu automatisch in het nieuwe archief terecht. Het oude archief is alleen nog beschikbaar om in te zoeken.

Navigator project

Een ander mooi en noodzakelijk deelproject dat we hebben voltooid, is het bouwen van de Navigator. Binnen de overgenomen partij werkten eindgebruikers met een oplossing waarbij ze bijvoorbeeld een e-mail konden slepen naar een vergelijkbare applicatie. Daar voegden ze dan handmatige gegevens aan toe en deze informatie werd vervolgens opgeslagen in het archief. Bij de overnemende verzekeringsmaatschappij waren deze processen veel verder geautomatiseerd met OCR-software (Optical Character Recognition) en scanning. Dit verschil in bedrijfsprocessen moest worden opgelost, voordat we de nieuwe archiefoplossing in gebruik zouden nemen.

We hebben de Navigator binnen 9 sprints van 2 weken en binnen tijd en budget gerealiseerd.

Na afweging van verschillende alternatieven en partijen kreeg WeAreFrank! het vertrouwen om dit project te mogen realiseren. We hebben de Navigator binnen 9 sprints van 2 weken en binnen tijd en budget gerealiseerd. Hierbij boden we dusdanige flexibiliteit dat we het product hebben gerealiseerd dat nodig was en niet het product dat in eerste instantie was gespecificeerd.

De Navigator is de integratiecomponent voor inkomende poststromen, e-mails, webformulieren en gescande post. Het is de user-interface voor eindgebruikers, zodat zij eenvoudig documenten kunnen beheren: data toevoegen, rubrieken toewijzen, controles uitvoeren en informatie valideren. Het was essentieel dat deze oplossing werd gebouwd, anders kon de overnemende verzekeringsmaatschappij niet live met het nieuwe archief.

Voordelen van flexibele integratielaag

In de omgeving van de overgenomen organisatie was er sprake van een sterke afhankelijkheid van techneuten en programmeurs. Je hebt dan vaak niet inzichtelijk hoe datastromen en koppelingen lopen en dan kan het lang duren, voordat een probleem is opgelost. Bovendien betekent die afhankelijkheid dat wanneer je een nieuwe oplossing neerzet en de standaarden veranderen, je de aanpassing moet doorvoeren bij alle componenten die worden beïnvloed.” “Met het Frank!Framework dat we nu hebben neergezet, is die functionele laag losgekoppeld van de technische laag. Het grote voordeel voor beheerders is dat bij een upgrade of andere veranderingen, alle componenten automatisch worden meegenomen. Je hoeft dan niet meer alles apart in te kloppen en te testen, wat je veel werk en tijd bespaart. Als beheerder heb je met het framework veel meer zelf de touwtjes in handen. Andere voordelen:

1. Voor de bouw van de nieuwe oplossing konden we veel sneller werken met deze standaardcomponenten. We hoefden niet na te denken over de technische configuratie: tijdens de implementatie konden we bijvoorbeeld code-snippets hergebruiken. Verder konden we geautomatiseerd en op een uniforme wijze testen en debuggen.
2. Beheerders hebben met het Frank!Framework toegang tot alle resources die worden gebruikt. Je hebt per applicatie inzicht in logs, instellingen en kunt de configuratie controleren. Maar je hebt ook een overzicht van alle adapters, performances en datastromen. In één oogopslag is voor een beheerder duidelijk waar het probleem ligt, bij bijvoorbeeld een trage applicatie, zodat hij of zij dit zelf kan oplossen en maar sporadisch de hulp van een ontwikkelaar hoeft in te roepen.

Omvangrijke systeemintegratie afgerond

De hele omgeving is nu live, de systeemintegratie is afgerond en alle applicaties zijn nu helemaal over. Er staat geen infrastructuur meer van de overgenomen verzekeringsmaatschappij, alle systemen draaien nu binnen de infrastructuur van de overnemende organisatie. We hebben het integratieproject nog een korte periode beheerd na oplevering, maar nu overgedragen. Ik denk dat dat WeAreFrank! wel typeert: ook na het voltooien van een project voelen we ons nog verantwoordelijk en zijn we er voor je als je ergens tegenaan loopt. Al met al was het een erg succesvolle, intensieve en leerzame samenwerking, waarbij we een mooi resultaat hebben neergezet.

Ook na het voltooien van een project voelen we ons nog verantwoordelijk en zijn we er voor je als je ergens tegenaan loopt.