Datamigratie #2: Het opzetten van een migratiestraat

HOE ZIET DE DATA-EXPORT VAN DE BRONAPPLICATIE ERUIT?

Nadat je weet wat en hoe je wilt migreren is het tijd om details verder uit te werken. Deze vraag richt zich op de bronapplicatie. Kunnen we de gewenste data eruit halen en in welke vorm? Hebben we anderen (bijvoorbeeld leveranciers) nodig om data te ontsluiten?

De data in de bron heeft een bepaalde vorm en opbouw. Soms heb je hier invloed op, soms niet. Dit kan zijn doordat het een eigen applicatie is en er veel kennis is over de data. Of dat het een externe applicatie is en er alleen met bestaande functionaliteit data ontsloten kan worden.

Indien er sprake is van een vaste vorm van data-exports (bijvoorbeeld een bestand met alle leningen) dan heb je een beschrijving nodig met welke erin zitten (compleetheid van het bestand). Dit is belangrijk, want aan de hand hiervan kun je controleren of de scope mogelijk is met de standaard exports. Indien er geen data-exports zijn, dan moet hiervoor specifieke programmatuur gemaakt worden. Indien de bronapplicatie is ingekocht kan het zijn dat er ondersteuning vanuit de leverancier van de bronapplicatie nodig is om de data uit te lezen.

Indien alle kennis en expertise in huis is om uit de bron zelf data-exports te maken, dan kun je de extractie maken op de manier welke het meest praktisch is. Mogelijk kun je zelfs al meteen de data omzetten naar een interface welke direct geschikt is voor inlezen door de doelapplicatie. Je voegt dan eigenlijk de stap export en transformatie samen.

In alle gevallen is het goed om de beschrijving te maken van de export, ofwel de interface. Deze informatie heb je nodig om de mapping te maken naar de doelapplicatie verderop in het proces.

Deze vraag zorgt ervoor dat je inzicht krijgt in wie je nodig hebt voor het maken van de export, welke data geëxporteerd kan worden en welke vorm deze data aan neemt.

WAT WIL DE DOELAPPLICATIE WETEN?

De doelapplicatie heeft meestal wensen en eisen bij de bestanden/tabellen welke zij in kunnen lezen om data te importeren en interpreteren. Deze vraag richt zich met name op de doelapplicatie. Welke data is er nodig en hoe moet deze worden aangeleverd.

De doelapplicatie heeft meestal een import functionaliteit. Deze functionaliteit heeft bepaalde verwachtingen bij de tabellen/bestanden welke geleverd moeten worden. Denk daarbij aan het aantal kolommen, mogelijke waardes, volgorde van kolommen, samenhang van bestanden. Kortom, de interface of interfaces welke voor de doelapplicatie te gebruiken zijn.

Indien er geen vaste methode voor is, dan is het verstandig om met de developers/leverancier te gaan zitten om afspraken te maken over hoe data moet worden geleverd om het te importeren in het nieuwe systeem. Eventueel moet hier ook nog programmatuur voor worden gemaakt (indien deze nog niet bestond).

Het resultaat van deze stap geeft een overzicht van interfaces en afspraken over hoe data geleverd moet worden om deze data te kunnen importeren.

IS ER EEN TRANSFORMATIE VAN DE DATA NODIG?

Ondertussen weten we hoe data uit de bron komt en hoe de doelapplicatie deze data verwacht te krijgen. Als deze interfaces matchen dan is deze stap snel gedaan. Vaak komt er echter meer bij kijken.

Zowel de bron en de doelapplicatie hebben vaak een eigen interface. Bijvoorbeeld 1 bestand in de bron moet uitsplitsen naar 3 bestanden in het doel, of er zijn verplichte velden in de doelapplicatie die niet verplicht waren in de bron. Mogelijk moeten er voor een aantal velden een default worden afgesproken. Bijvoorbeeld dat bij gemigreerde posten altijd ‘A’ wordt gevuld bij een veld of juist een transformatie om te kijken wat de bron heeft en doelapplicatie wil hebben (bv 1, 2, 3 in bron wordt ‘a’, ‘b’, ‘c’ in doel). Met name deze ‘mapping’ maken is iets wat tijd en effort kost. De precieze mapping regels zijn niet altijd duidelijk.

Indien er een mapping nodig is, dan wordt hier een applicatie voor geschreven op basis van hetgeen afgesproken is en hetgeen nodig is. De meeste zaken kunnen met een simpele afleiding worden gedaan, maar soms zijn complexe afleidingen nodig waarbij meerdere input’s leiden tot het juiste antwoord. Deze (bekende) zaken kunnen in ieder geval vast beschreven worden en zouden het gros van de transformaties moeten dekken. Hetgeen niet gedekt is zal bij proefmigraties worden gezien. Het is echter ook bij migraties zo dat hoe eerder issues getackeld worden hoe beter.

Het resultaat van deze vraag geeft je antwoord of je moet transformeren en indien nodig een overzicht van de benodigde mapping om data van bron naar doel te transformeren (een eerste technische specificatie).

STARTEN VAN DEVELOPMENT

De vragen hebben geleid tot een design. Tijd om dat design te ontwikkelen en een werkende migratiestraat neer te zetten. Dit kan iteratief door te starten met de export, dan transformatie, dan laadprogramma. Maar het kan ook simultaan zijn, afhankelijk van hoe groot het project is en wie verantwoordelijk is voor welk deel.

Voorbeeld: als een bedrijf over gaat van een eigen applicatie naar een maatwerkpakket van een leverancier dan kan het zijn dat zij zelf verantwoordelijk zijn om data uit hun applicatie te ontsluiten, maar dat de transformatie en laden valt onder het contract wat met de externe partij is overeengekomen. Het eigen team bouwt de export zoals is overeengekomen en de externe leverancier bouwt de transformatie laag. De doelapplicatie heeft al een laadprogramma wat werkt nadat transformatie is gedaan. De 2 teams kunnen dankzij de afstemming en design hun eigen stuk ontwikkelen en tezamen tijdig klaar zijn.

Let wel op: zelfs als een deel van de migratie de verantwoordelijkheid is van een andere partij zullen  controles moeten worden uitgevoerd op de resultaten van de conversie. Ga er zeker niet van uit dat de kwaliteit goed genoeg is, maar bewijs dat de kwaliteit goed is!

Denk ook aan het controleplan wat is opgesteld in de voorbereiding. Vergeet niet om deze controles ook in te bakken in het proces en er eventueel een specifieke code voor te schrijven (of SQL-scripts) zodat ook die controle snel en eenvoudig uit te voeren is.

TOT SLOT

Er is een design gemaakt en applicaties zijn opgebouwd. Deze zijn ook op werking gecontroleerd uiteraard, want kwaliteit staat boven alles in een migratie. Hiermee is deze fase afgerond.

Wil je meer weten? Over 2 weken komt er een vervolg blog: testen migratiestraat en de finale migratie.