Eén van mijn jeugdhelden is Doctor Who. Deze sympathieke avonturier beleefde spannende avonturen in tijd en ruimte om de mensheid voor allerhande kwaad te behoeden. En nog steeds, want momenteel zendt de BBC alweer het 38ste seizoen uit van de oudste nog lopende TV serie ter wereld. Al heeft de Doctor wel wat veranderingen ondergaan en is hij inmiddels een tijdreizigster geworden.
Het fenomeen van tijdreizen is een populair onderwerp in fictie. Eén van de eerste boeken hierover was The Timemachine van H.G. Wells. Denk ook aan films als de Back to the Future reeks, 12 Monkeys, Groundhog Day en de verschillende iteraties van Star Trek. En wie is er niet groot geworden met de Teletijdmachine van professor Barabas?
Nu biedt het leven van een software ontwikkelaar vele uitdagingen, maar degene die de gemiddelde tijdreiziger het hoofd moet bieden ken ik dan weer niet. Alhoewel?
Ik houd mij vooral bezig met het ontwikkelen, en aanpassen van, bedrijfskritische business applicaties. De afgelopen tijd heb ik verschillende leuke opdrachten voor Ahold mogen uitvoeren op het gebied van Store Replenishment. De meest recente klus betreft het NGR project bij Albert Heijn. NGR staat voor Next Generation Replenishment. Eén van de slogans van dit project is “Bettering the Best” en daarmee is denk ik niets teveel gezegd.
De maatwerk Applicaties binnen het huidige Replenishment landschap hebben Albert Heijn namelijk al veel goeds gebracht op het terrein van beschikbaarheid, winkelbeeld en afboekingen. Om verdere voordelen op het gebied van onder andere transport te kunnen behalen, is besloten om een extra laag toe te voegen die winkelorders nog beter in hun onderlinge samenhang kan optimaliseren. Daarnaast is er de wens om meer gebruik van A.I. elementen te kunnen maken en verschillende functionaliteiten breder binnen het bedrijf beschikbaar te stellen. Mede daarom is er voor gekozen om het NGR project op het Azure cloud platform te ontwikkelen, waarbij functies middels API’s toegankelijk zijn voor andere applicaties.
Omdat NGR vooralsnog een extra laag “bovenop” de bestaande systemen vormt, moest er een integratie met de huidige applicaties worden gemaakt. Binnen Orcado hebben we een ruime ervaring met de ontwikkeling en het onderhoud van de Store Replenishment systemen van Albert Heijn en ook ik heb daar zeer veel jaren aan mogen bijdragen. Aan ons de schone taak om de DESO applicatie te laten integreren met NGR.
En onwillekeurig voel ik mij toch een beetje een tijdreiziger in dit project. Want ga maar na; de winkelorder wordt berekend in de huidige applicatie (DESO), maar stuurt zijn uitkomst naar de toekomstige wereld: NGR. De winkel order wordt daar geoptimaliseerd door deze te combineren met andere winkelorders en wordt weer teruggezonden naar DESO voor verdere verspreiding. Heden communiceert met toekomst en vice versa.
Maar zoals dat met tijdreizen gaat, dienen er wel een aantal regels in acht te worden genomen om tijdsparadoxen en ander ongemak te vermijden:
Het heden is onafhankelijk van de toekomst.
In verband met het volume en stringente afspraken voor doorlooptijden binnen de supply chain is het berekenen van winkelorders aan een strikt tijdschema gebonden. DESO is dan ook gevoelig voor performance invloeden. Het gebruik van API’s is in dit verband niet de meest ideale oplossing, omdat je de winkelorderberekening niet afhankelijk wil laten zijn van de performance van een externe applicatie; NGR in dit geval. Er is daarom gekozen voor een ontkoppelde interface met een request en reply structuur, gelinkt middels een requestid. Op deze manier is DESO nog steeds baas in eigen huis en kan het de verantwoordelijkheid blijven nemen over zijn eigen tijdspaden. Mocht de reply vanuit NGR onverhoopt te laat zijn, dan wordt deze niet verwerkt en geldt de door DESO berekende winkelorder, die dan dus niet geoptimaliseerd is, als output.
Wijzingen aangebracht in het verleden hebben effect op de toekomst.
DESO berekent niet enkel de actuele winkelorder, maar tevens een set van winkelorders voor de toekomst, om op die manier beter inzicht te verkrijgen in de supply chain keten (over tijdreizen gesproken). Men noemt dit de SDF (Store Demand Forecast). Omdat NGR meerdere winkelorders combineert, heeft elke wijziging in de berekende winkelorder dus een mogelijk effect op de optimalisatie van andere winkel orders. Elke wijziging in een berekende SDF dient dan ook met NGR te worden gecommuniceerd. Daarnaast brengt NGR ook zelf wijzigingen aan op de winkelorder in het kader van de optimalisatie. Deze worden als reply weer naar DESO verzonden. Om te voorkomen dat DESO deze weer als wijziging naar NGR moet versturen, die weer mogelijk opnieuw geoptimaliseerd zou worden en daarmee een oneindige loop start , slaat NGR zijn eigen wijzigingen ook onafhankelijk op.
Weet waar je bent; bepaal je positie in tijd en ruimte
Bijkomende uitdaging binnen dit project, en vaak binnen grote organisaties, is het feit dat er meerdere projecten tegelijkertijd actief zijn, die elk wijzingen aanbrengen op de applicatie. Het gevaar bestaat dus dat er simultane werkelijkheden ontstaan, helemaal als er gedeelde functionaliteit in het spel is. Continue afstemming tussen de (SCRUM-) teams is daarom van groot belang evenals een zorgvuldig versiebeheer. Weten op welke versie van de code je de wijzigingen aanbrengt, wanneer elk project een (deel)oplevering naar de productie omgeving doet en hoe je alle wijzingen correct administreert is daarbij essentieel. Een TARDIS zou handig zijn.
Waarmee we dan weer bij Doctor Who zijn aanbeland. De eerste twee afleveringen van het huidige seizoen gaan overigens voor een deel over Ada Lovelace en Charles Babbage, geen onbekenden voor degenen met interesse in de oorsprong van het vakgebied van IT en software ontwikkeling. En mochten deze namen je niets zeggen, zoek ze een keertje op. Een kleine reis door de tijd is zo op zijn tijd de moeite waard!
Hier komt de sidebar