L.S.,

Het grote Mexx project bestond uit een groot onderdeel en vele kleinere onderdeeltjes. Het grote onderdeel was een data warehouse volgens de data vault methodologie. Met wat externe hulp was een standaard manier van werken gecreëerd om het data warehouse te vullen van de vele verschillende bronnen. Een ontwikkelaar kon met behulp van een handleiding binnen korte tijd de vulling regelen. Nadat ik dit drie had gedaan verveelde me ik al kapot en vroeg of dat ik niet de kleinere onderdelen van het project op mocht pakken.
Het oude gedeelte van Mexx draaide op het rondsturen van bestanden. Duizenden bestanden per dag voor honderden systemen. Ook dit proces moest vervangen worden door iets nieuws. Gelukkig hadden we PowerCenter, in combinatie met B2B Data Transformation en VL-Trader, die dit allemaal voor ons kon regelen. Technisch was dit interessant genoeg, maar aangezien alles zo’n beetje werkte zoals het moest, wil ik het daar niet over hebben.
De uitdaging van dit project was niet de techniek, de uitdaging zat meer in de gebruiker. Deze gebruiker had namelijk iets te veel ervaring. Iets te veel negatieve ervaring. De gebruiker was bang dat dit project zijn leven moeilijker zou maken, in plaats van makkelijker. Om zijn zorgen te verminderen wilde hij ervan overtuigd zijn dat de ‘consultants’ weten wat hij nodig had. De enige manier waarop was door bij elke vraag en elk overleg van begin tot eind alles te vertellen. Alles wat hij weet over het systeem dat er nu draait, alles wat nagemaakt of vervangen moest worden. Ik zie mezelf niet als een erg sociaal persoon, maar ik realiseerde dat ik zijn vertrouwen moest winnen. Dus ik tolereerde zijn verhaal, keer op keer. Ik verzekerde hem er van dat ik begreep wat de bedoeling was. En ik liet hem zien wat ik aan het maken was. Op het einde is alles goed gekomen en hij was tevreden. En ik was trots op een elegant systeem dat de nodige duizenden bestanden in een uur kon verwerken en daar geen hele dag voor nodig had.

Mijn eerste contact met een klant die eigenlijk niet met je wil samenwerken, maar wel moet.

L.S.,

Een van mijn favoriete uitspraken in de ‘werk-wereld’ is: ‘goed werk wordt beloond met meer werk’. Het voordeel van mijn oplossing in het vorige verhaal was de positieve indruk die ik achterliet, en de tevredenheid van mijn werkgever dat zijn eerste aangenomen junior een resulterende investering was. Het nadeel is natuurlijk dat er steeds meer en hogere verwachtingen zijn.
Ik kreeg mijn eigen mini-projectje binnen het grote project dat Mexx was. Zoals je misschien kan verwachten bij een kledingbedrijf moeten zij kleding maken. Het maken van deze kleding gebeurd in de lage lonen landen van de wereld, zoals eigenlijk al het relatief simpele maak werk in de wereld. Het aansturen van dit fabriceren was een veel belangrijker, groter en complexer project waar een aantal collega’s aan werkten. Als deze kleding gemaakt is moet deze verstuurd worden naar de landen in de wereld waar Mexx haar waren probeerde te verkopen. Het versturen wordt geregistreerd in een ‘Electronic Freight Record (EFR)’. Hier staat in welke dozen, in welke containers, in welke schepen of vliegtuigen, waarheen gaan en wanneer deze daar verwacht worden of aangekomen zijn.
Deze bestanden met de EFRs erin werden regelmatig door fabrikanten naar Mexx toe gemaild, gecontroleerd door mijn proces, daarna de database geüpdatet waar nodig en klaargezet om ingezien te worden door de medewerkers van Mexx. Zij konden met behulp van deze informatie sturing toepassen richting de fabrikant of het transportbedrijf.
Om dit proces te kunnen bouwen was er een klein ontwerp gemaakt. Als een brave junior heb ik dit document van voor tot achter bestudeerd en er voor gezorgd dat elke letter geïmplementeerd is. Nadat ik er van overtuigd was dat alles goed ging is onze architect samen met de gebruiker er bij komen zitten om er doorheen te lopen. Hij was erg ontevreden, er ontbraken allerlei validaties! Met schrik in mijn hart zat ik daar, mijn eerste project en een ontevreden gebruiker! Gelukkig had de architect de tegenwoordigheid van geest om het originele ontwerp erbij te pakken. Het ontwerp geschreven door die gebruiker. Zoals ik al wist kon de klant niet aanwijzen in dit document waar die validaties moesten komen en hij gaf toe dat dit niet onderdeel was van de opdracht. Ik kon weer rustig ademhalen, in ieder geval totdat de klant het document had aangepast en de validaties had toegevoegd.

Mijn eerste les dat een klant soms wat begeleiding nodig heeft in vragen wat die wenst.

L.S.,

Daar zijn we dan, mijn eerste echte project, een project waar ik ‘in het diepe’ gegooid word. Het punt waar ik geïntroduceerd word is het ontsluiten van een webservice via PowerCenter. Voor de mensen die niet bekend zijn met webservices (en helemaal in 2012), deze communiceren vaak in XML. En voor de mensen die niet bekend zijn met PowerCenter (of bijna elke ETL tool), XML is een drama! Dus na mijn 3 dagen PowerCenter training, welke kort samengevat kan worden in: ‘Zo ziet PowerCenter eruit, deze knopjes staan hier. Veel plezier.’, mocht ik meteen aan de bak. Tot iedereens verrassing was het daadwerkelijk verbinding maken met de webservice relatief probleemloos. Het probleem begon pas nadat we de verbinding hadden gemaakt.
Het proces moest op basis van een lijst de webservice aflopen om per item op de lijst wat bijbehorende informatie op te halen. Voor de items die aanwezig waren aan de andere kant van de webservice ging dit vlekkeloos. Als dit item echter niet aanwezig was gebeurde hier wat onverwachts. Ieder normaal systeem zou in dit geval een leeg resultaat terugsturen, ter informatie dat hier geen informatie voor aanwezig is. De ontwikkelaar van dit systeem had het briljante idee om in plaats daar van een HTTP fout code te hergebruiken. PowerCenter is echter niet flexibel genoeg dat je hem kan vertellen foutcodes te negeren. Dus op het moment dat een item niet gevonden werd en de webservice zijn foutcode terugstuurde, deed PowerCenter het enige wat PowerCenter kan doen. Hij knalt eruit op een technische fout en weigert verder te gaan.
Een uitgebreide ‘high-level’ meeting verder zijn we tot de beslissing gekomen dat de uitbater van de webservice dom bezig is geweest. Zij kunnen met liefde een wijziging doorvoeren in de webservice om een daadwerkelijk nuttige boodschap terug te sturen als iets niet gevonden kan worden. Verwacht levertijd: 6 maanden. Gelukkig heeft PowerCenter een wanhoop functie: custom Java componenten. Ik heb dus een stuk code mogen schrijven in Java om de webservice uit te lezen en niet te steigeren op deze specifieke foutmelding. Die vervolgens in PowerCenter kunnen hangen om toch nog onze taken uit te kunnen voeren.
Later zou ik realiseren dat dit de essentie is van IT werk. Er gaat altijd iets gebeuren wat je niet verwacht of wenst en jouw werk is een oplossing vinden om het probleem heen. Gelukkig word het vinden van oplossingen voor onmogelijke problemen erg gewaardeerd door beide werkgevers en klanten.