Een dag in het leven van Erwin

Sinds 1999 werk ik in de detachering bij Caesar Groep, als ‘nerd’ zeg ik altijd maar. Mijn vakgebied is heel wat verschoven over de jaren heen, van programmeur in C++ tot C#, tot Data Engineer in Azure, wat het beste omschrijft wat ik tegenwoordig doe. Iedere dag leer ik bij, want in de wereld van de gemiddelde ‘nerd’ veranderen de tools constant. Zo ook bij mijn huidige opdracht, bij één van de grootste verzekeraars van Nederland. Wie deze opdrachtgever is laat ik even in het midden, anders moet ik door een heel legal proces. 

Test, één, twee, drie

Vandaag neem ik je mee en kun je een blik werpen op mijn dag in het leven als Data Engineer. Vandaag staat in het teken van het testen van mijn migratie-oplossing voor het verhuizen van data van een groot mainframe naar Dynamics 365 (SAAS-product van Microsoft). Het wordt een spannende dag, want ik heb tot nu toe alleen getest binnen een ontwikkelomgeving zonder representatieve data. Daarom werk ik bij mijn klant op kantoor, zodat ik dichtbij de testers ben.

Om 06.00 uur gaat de wekker en om 06.30 uur vertrek ik vanuit huis. Ik rijd naar een carpoolplaats waar een collega al staat te wachten. We reizen vaak samen, beter voor het milieu, voor de portemonnee en het is ook nog gezellig. Mijn reistijd naar de klant is, van deur tot deur, in de spits, zo'n anderhalf uur. Ik ben de files inmiddels wel gewend en heb geleerd dat reizen in Nederland vaak gepaard gaat met files, hoe laat je ook vertrekt.

Werkdag opstarten

We komen aan om 08.15 uur. Eerst tijd voor koffie en bijkletsen met collega’s. We werken in een grote kantoortuin met mooie werkplekken. Mijn eigen laptop aansluiten op het netwerk van de klant duurt altijd even. Koppelen met de klant-wifi, VPN opstarten met het token van de klant en mijn klantlogin. Hierna start ik mijn (remote) werkstation en vanuit hier mijn speciale Azure ontwikkelmachine. Als techneut ontkom je vaak niet aan dit soort stappen. We gebruiken veel tools en moeten op een veilige manier toegang krijgen tot klantinformatie. Alles wordt hier, zoals het hoort, keurig gelogd.

Vervolgens starten we om 09.00 uur met onze daily scrum. Het team van 14 personen, met verschillende disciplines, komt bij elkaar om de dag door te spreken. Ik geef aan wat ik vandaag op mijn agenda heb staan, of ik nog ergens hulp bij kan gebruiken of als ik ergens tegenaan ben gelopen. Voor vandaag geen problemen: ik heb zin om aan de slag te gaan met het testen. Ik ken de oplossing tot in detail en heb het vertrouwen dat ik snel kan handelen wanneer er iets mis gaat. Probleemanalyse en -oplossing vind ik één van de leukste onderdelen van mijn werk. Om 09.30 uur start ik mijn dagelijkse tools op. Ik werk nu met Azure Portal voor PIM, ADF en Storage, SQL Server Management Studio en XRM toolbox. Ik zet alles klaar om onder de motorkap mee te kijken wat er precies getest wordt en wat de gevolgen daarvan zijn.

De kick-off

Het testteam komt om 10.00 uur bij elkaar voor de aftrap van het testen. Samen met twee mainframe superusers, één mainframe developer en één D365-consultant gaan we de klus klaren vandaag. Ik heb samen met de mainframe developer het voortouw genomen in dit traject. Dat is niet zo gek, want bij een data migratie traject als deze, zit het hart van de oplossing vaak onder de motorkap. Na een half uur zijn we allemaal klaar voor de start.

We starten om 10.30 uur met het leegtrekken van het mainframe, door een aantal grote databestanden. Deze plaats ik op een locatie waarbij ze later door het proces worden opgepakt en (hopelijk goed) verwerkt. Ik klik en ram nog een paar keer op mijn toetsenbord en het proces voor het inlezen is gestart. Ik heb veel logging ingebouwd, daardoor kan ik prima volgen waar we zitten in het proces. De tester start samen met mijn collega van het D365-team de nieuwe testomgeving op en zijn al lekker aan het klikken (nog zonder gemigreerde data). Ook krijgen zij nog wat meer uitleg.

Foutje van de zaak

We waren zo lekker bezig, voor zolang het duurde. Om 11.15 uur klapt het migratieproces aan mijn kant. Ik zie aan de foutmelding in mijn logging snel wat dit zou kunnen zijn. Een factor die altijd een belangrijk rol speelt en impact heeft op het succes is de kwaliteit van de data. De representatieve data uit het mainframe lijkt nog niet helemaal goed voorbereid te zijn. Iets met "Cannot insert duplicate key" voor mijn mede-nerds. ;-) Wel fijn dat ik de constraint er in ieder geval op had zitten om 'data-garbage in' te voorkomen.

Om 11.30 uur zoek ik samen met de mainframe developer de dubs op en kijken we waarom dit zo is. Het lijkt erop dat we de constraint iets te streng hebben geschreven. We gaan terug naar de tekentafel om te bedenken hoe we de constraint beter kunnen opzetten. Daarbij stellen we de vraag: wat maakt een leverancier uniek? We dachten dit te weten tijdens de define-fase een aantal weken terug. De data denkt daar anders over.

Tijd voor pauze, of niet?

Normaal gesproken is het om 12.00 uur lunchtijd. Ik besluit om toch nog even door te gaan met het vinden van een oplossing. Ik wil graag verder kunnen testen vanmiddag. Ik verricht wat technische handelingen om duplicates eruit te filteren, zodat we toch de testmigratie kunnen doen. Dit is geen oplossing voor de échte migratie, maar daar maak ik me later zorgen om. Ik start het proces opnieuw op en omdat ik weet dat het even duurt, kan ik ondertussen even lunchen.

Het bedrijfsrestaurant is gelukkig nog open om 13.15 uur. Twee collega’s uit het team gaan mee. Na de lunch wandel ik vaak even, als het weer het toe laat. Samen met een collega lopen we een rondje van 20 minuten. Even babbelen over zonnepanelen, zelfvoorzienend worden en de nieuwe ‘flexflitser’.

Poging twee

Back to work! Helaas is het proces weer geklapt als ik inlog op mijn ontwikkelmachine om 14.30 uur. Nu is het een "Invalid date format", wat ook weer een data kwaliteitsissue is. Dit had ik kunnen voorkomen door in de oplossing TRY_PARSE te zetten, de rijen uit te sluiten van de migratie en later weer te rapporteren. Dat deed ik wel voor andere velden, maar voor dit veld had ik het niet verwacht. Ik realiseer me dat dit dus bij veel meer datumvelden mis kan gaan. Hier heb ik nu geen quick-fix voor, dus even overleg met een collega. Er komt een bedrijfsregel bij het proces voor een aantal velden die ik echt moet implementeren. Samen met mijn collega loop ik alle velden door die mogelijk hetzelfde probleem gaan hebben. Dat heeft wel even geduurd helaas.

Om 16.30 uur is het team op de hoogte van de testresultaten en de problemen. Het is geen verloren dag, want hier is het testen natuurlijk voor bedoeld. Uiteraard had ik liever gehad dat mijn oplossing al 99% goed was, maar helaas is dat niet het geval. Ik besluit morgen de bedrijfsregels toe te passen, want ik vermoed dat dit een halve dag gaat kosten. Ik mail de projectleider met de uitkomsten van vandaag en doe een voorstel voor een volgende testdag.

Het is 17.00 uur en dat betekent dat de dag er alweer op zit. Ik spiek even snel op Google Maps om te kijken wat de schade is met betrekking tot de reistijd. We gaan toch maar rijden, ondanks de files, want wachten tot deze voorbij zijn is vandaag geen optie. Ik zet mijn collega om 18.15 weer af op de carpoolplaats en rij door naar huis. Om 18.30 uur wacht mijn vrouw mij op met het avondeten.

Was het een succesvolle dag? Persoonlijk niet, maar objectief gezien heb ik gedaan wat ik moest doen. De details van wat ik allemaal op het toetsenbord heb geramd, heb ik maar achterwege gelaten. Als ik de dag zou moeten verdelen in percentages van ontwikkelen en overleggen zou dat 60/40 zijn. Dat is toch ongeveer het gemiddelde over een hele week gezien. Ik kan het toch niet laten om nog iets met data en cijfers te doen, zie ik :-)