ORDINA BLOGT

Datamigratie: van datamapping naar dataflow

  • Henk Zwaan
  • 12 april 2018

Datamigratie, dat is toch vooral het uitwerken van de datamapping: voor ieder veld van het bronsysteem bepalen wat het corresponderende veld in het doelsysteem is. Dit is een veelgehoord misverstand over datamigraties. Slechts weinig migraties kunnen op deze wijze worden aangepakt. Bij de meeste migraties loopt een dergelijke aanpak vast omdat er geen sprake is van een-op-een mapping. Er zijn verschillen per product- of klantsoort of de mapping is afhankelijk van bepaalde statussen. Met andere woorden, de mapping en conversieregels gelden voor een bepaalde selectie.

In dit artikel laten we zien hoe een complexe datamigratie wordt opgezet. We laten zien dat selecties de kern vormen van een datamigratie. De volgorde van de selecties zorgt ervoor dat de te migreren data van bron naar doel stroomt. We verleggen de focus van datamapping naar dataflow.

Productmapping
We starten met productmapping. We analyseren hoe producten in de bron en het doel worden vastgelegd. Met producten bedoelen we functionele gegevensgroepen behorende bij producten als abonnementen, financiële producten of bepaalde diensten, dossiers of cases. Deze gegevensgroepen vormen de hoofdselecties voor de dataflow. Een fit-gap analyse geeft aan of de huidige producten in het doelsysteem passen. Als dit niet het geval is, moeten we keuzes maken: producten aanpassen, doelsysteem aanpassen, of producten buiten scope plaatsen.

Dit soort keuzes hebben grote impact op business en IT. Productwijzigingen zijn niet zomaar door te voeren. Vaak kan dit alleen in overleg met klanten. Een systeemaanpassing kan ook complex zijn. Daarnaast krijgt het migratieproject te maken met een bewegend doel.

Het is dus belangrijk om in een zo vroeg mogelijk stadium keuzes te maken en de scope vast te stellen. Het gaat daarbij niet alleen om de producten, maar bijvoorbeeld ook om historie. Welke oude transacties moeten worden meegenomen? En als dat oude producten betreft, passen die in het doelsysteem? Wat gebeurt met historie die achterblijft? Wordt deze gemigreerd naar een apart systeem voor historisch databeheer; historie moet immers conform de AVG/GDPR worden beheerd.

Tunnel, trechter of kegel
Als de productmapping duidelijk is en de scopebepalende keuzes gemaakt zijn, is duidelijk wat de hoofdselecties zijn waarmee de datamigratie wordt gerealiseerd. Hoe stroomt nu de data vanuit het bronsysteem naar het doelsysteem? De dataflow gaat soms via een tunnel, soms door een trechter, of via een kegel.

We spreken van een tunnel in eenvoudige situaties waarbij de te converteren producten passen op het doelsysteem. De structuur van de producten wijzigt niet noemenswaardig. De datamapping is veelal één op één. Deze situatie is vaak snel herkenbaar doordat het aantal entiteiten en attributen in bron en doel niet veel van elkaar afwijken.

We spreken van een trechter als verschillende entiteiten uit de bron moeten worden samengevoegd in één entiteit van het doel. Of verschillende relatiegroepen die samengevoegd worden. Er ontstaat ook een trechter als er meerdere bronsystemen zijn waaruit data samengevoegd wordt in één doel. Bij een trechter is de datamapping afhankelijk van de bron of bronentiteit.

We spreken van een kegel als een entiteit uit de bron moet worden uitgesplitst naar verschillende entiteiten in het doel. De uitsplitsing is vaak afhankelijk van een status of type. Ook bij een kegel is de datamapping niet eenvoudig een-op-een.

Validatie en conversie
Zodra we per hoofdselectie weten hoe de data moet gaan stromen, kunnen we dit verder uitwerken. Hoofdselecties worden opgesplitst in deelselecties en alle selecties bij elkaar zorgen voor de datamigratie. Selecties zorgen voor de juiste scope, samenvoegingen en splitsingen. Op selecties kunnen bewerkingen worden uitgevoerd voor validatie en conversie.

Validatie gaat over datakwaliteit, voldoet de data binnen een selectie aan de eisen van het doelsysteem, of aan additionele business-eisen. Data die niet voldoet wordt gesignaleerd. We maken daarbij onderscheid tussen uitval en labelen. Data die echt niet naar het doelsysteem mag wordt eruit gefilterd, dit is dus uitval. Data waarvan we weten of denken dat deze incorrect is, maar welke we toch willen overzetten wordt van een label voorzien. Soms is het handig om bij een eerste proefmigratie weinig te filteren en veel te labelen, zodat er voldoende data wordt gemigreerd voor testdoeleinden. Bij de productiemigratie zullen de meeste validaties als filter zijn ingesteld. We willen immers het doelsysteem met correcte data vullen.

Op selecties worden ook conversieregels toegepast. Hierbij gaat het om veldbewerkingen die ervoor zorgen dat de data voldoet aan de veldeisen van het doelsysteem. Soms gaat het om splitsen of samenvoegen van velden, bijvoorbeeld een adresregel splitsen naar straatnaam en huisnummer. Soms gaat het om vertalingen van codes. Ieder systeem kent eigen coderingen en op basis van vertaaltabellen worden deze omgezet.

Geconverteerde data
Het totaal aan selecties, validaties en conversies zorgt voor de overall dataconversie, het omzetten van de brondata naar de doeldata. We hanteren een geautomatiseerd proces om alle selecties en bewerkingen in de juiste volgorde te zetten. Met een dataflowdiagram maken we vervolgens de gehele dataconversie visueel op een wijze die voor businessspecialisten helder is en ontstaat inzicht hoe de conversieflow verloopt.

Het resultaat van alle selecties, validaties en conversies is de geconverteerde data die vervolgens in het doelsysteem wordt ingelezen. Door niet de datamapping maar selecties en dataflow centraal te stellen, kunnen we een zeer complexe migratie eenvoudig maken en via een agile methodiek uitvoeren. Een olifant eet je in stukjes. Dat geldt ook voor een complexe datamigratie.

Dit artikel is de derde in een serie artikelen over datamigraties. Eerder zijn we ingegaan op de principes van datamigratie en op de migratiestrategie. In ons volgende artikel gaan we in op datakwaliteit. Voor meer informatie over de Ordina-aanpak van datamigraties neem vrijblijvend contact op met Henk Zwaan, management consultant bij Ordina Data & Finance Solutions.

Ordina Data & Finance Solutions biedt oplossingen voor onder meer datamigraties en datakwaliteit, voor het GDPR-compliant maken van datasets en voor historisch databeheer. Henk Zwaan is bereikbaar via henk.zwaan@ordina.nl.