De weg naar een nieuwe straat

Colosseus ondersteunt inmiddels al bijna 10 jaar verzekeraars en pensioenuitvoerders bij migratietrajecten. Daarbij zijn miljoenen polissen en deelnemers gemigreerd. Er is één grote gemene deler voor alle migraties: dit soort trajecten is complex. Het bevat veel facetten; van controle op data(kwaliteit) tot transformatie en van businessanalyse tot verrijking via business rules. Groot of klein, elke portefeuille kent z’n eigen eigenaardigheden en mogelijke struikelblokken.

Voor het proces om te komen van bron- tot doelsysteem gebruiken wij onze in-house ontwikkelde applicatie, Colosseus Data Platform (CDP). Een belangrijk onderdeel van CDP is de geautomatiseerde migratiestraat, waarmee de dataconversie en -validatie bij technische migraties automatisch kan worden doorgevoerd, waarbij elke stap wordt vastgelegd.

Dat gaat echter niet zomaar, omdat de datastructuur van elk systeem anders is. De eisen die aan de data worden gesteld, de controles, de beslissingen die gemaakt worden bij productrationalisatie en vele andere aspecten zorgen ervoor dat elk migratietraject nieuwe uitdagingen met zich meebrengt. En bij elk traject betekent dit concreet: nieuwe code schrijven voor de datatransformaties, business rules en validaties.

Initieel levert dit nog weinig problemen op. De business analyse gaat voort, de business rules worden vastgesteld, de ontwikkelaar gaat deze coderen en de proefmigraties kunnen beginnen.

Echter, daarmee is het einde nog lang niet in zicht. We migreren veelal naar een ‘moving target’. In de loop van het project volgen vaak nieuwe of gewijzigde producten die ingeregeld moeten worden. Dan blijkt er blijkt toch essentiële data te ontbreken of de structuur van de doelproducten wijzigt. Het doelsysteem krijgt als gevolg hiervan nieuwe functionaliteiten waar de migratiebestanden op moeten aansluiten. In de praktijk zijn de business rules altijd onderhevig aan veranderingen, tot de definitieve migratie aan toe.

Dus hoe verder in de tijd we komen, hoe uitgebreider de coding voor transformatie wordt. Aanpassingen worden daarmee ook complexer; kosten meer tijd en zijn foutgevoeliger. De tijdsdruk neemt daarentegen toe, waardoor aanpassingen voor vertraging kunnen zorgen.

Kortom: Hoe verder het project vordert, des te meer complexiteit en des te minder tijd.

Kunnen we dit proces verbeteren/optimaliseren?

Kunnen we onze efficiënte en geïntegreerde oplossing behouden, terwijl we de transformatie en datacontrole minder afhankelijk maken van complexe code? Met die vraag hebben we onze migratiestraat teruggelegd op de tekentafel.

Yes we can!

Een van de belangrijkste uitgangspunten van ons nieuwe ontwerp is dat we ernaar streven om alle codering volledig klantonafhankelijk op te zetten. Alle business rules, ook de meest complexe, worden in de configuratie vastgelegd en niet in code. Daardoor is het eenvoudiger om, ook in een later stadium van een traject, de wijzigingen die zich voordoen snel te implementeren. Daarnaast kunnen de businessanalisten veel slagvaardiger te werk gaan. Ze hebben immers een grotere invloed op de transformatie omdat ze daar zelf meer voor instellen, in plaats van het schrijven van specificaties die door een ontwikkelaar gebouwd moeten worden.

Hoe maatwerk toch mogelijk is

De sleutel tot deze methode is het opknippen van de codering in kleine stukjes (“ingrediënten”). De klantafhankelijke elementen zoals tabelnamen, veldnamen en business rules worden door programmatuur opgepikt uit de configuratie en omgevormd tot kleine en zeer efficiënt georganiseerde stukjes coding. Afhankelijk van business rules en database structuur, wederom vastgelegd in de configuratie, composeert de programmatuur van al deze kleine stukjes, efficiënte procedures die de data transformeren en valideren.

Voortdurend verbeteren van onze software

Heb je niet miljoenen van die kleine stukjes coding nodig? Niet als het opknippen slim gebeurt. Onze analisten en ontwikkelaars zijn tijdens het redesign voortdurend bezig om aan de hand van onze ervaring en klantspecifieke voorbeelden, te definiëren met welke ingrediënten de meest complexe business rules op te bouwen zijn. Als een migratietraject een functionaliteit vereist die nog niet voorzien is in de huidige migratiestraat, wordt deze bijgebouwd door ook hiervoor de losse ingrediënten te definiëren. Daardoor houden we de volledige migratiestraat klantonafhankelijk en flexibel.

Transformeren is coderen?

De afzonderlijke ingrediënten kunnen bij nieuwe klanten hergebruikt worden, zelfs als deze klant een volledig andere database structuur hanteert. Met meel, suiker, boter, ei en appels kun je ook heel veel verschillende appeltaarten bakken. Datzelfde principe geldt ook voor de migratiestraat.

Het is jarenlang gezegd: “transformeren is coderen”. Tot we besloten dat dat niet zo is.