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!
Leren programmeren objectificerenVoordat ik dit blog ben gaan schrijven heb ik een aantal van mijn trouwe blog lezers toegezegd dat ik in mijn onophoudende missie om te laten zien dat programmeren geen magie is (voor de woordgrap is het belangrijk dat je ons wie-zijn-wij filmpje even kijkt) een blog zou schrijven over APIs. Terwijl ik daar mee bezig ben en aan het kijken wat ik daar voor uit wil leggen loop ik tegen JSON aan, wat staat voor JavaScript Object Notation. JavaScript is al wel een heel aantal keer voorbij gekomen, maar objects heb ik nog niet echt uitgelegd. In eerste instantie wilde ik een kleine paragraaf er aan wijden, maar dat voelde wat karig. Het alternatief was om het te noemen en dan later toe te lichten, maar ik moet ook ooit nog een keer 3-waarde logica uitleggen en het was eigenlijk logischer om dat eerst te doen. De APIs komen volgende keer (of de keer daarop) maar vandaag: object georiënteerd programmeren.
Misschien dat je de term object georiënteerd programmeren of de afkorting OO/OOP wel eens voorbij hebt zien komen. Object georiënteerd programmeren is een manier van programmeren, andere vormen zijn bijvoorbeeld functioneel, logisch of declaratief. De code die ik jullie tot nu toe heb laten zien is allemaal declaratief; het is een opsomming van constructies. Bij OOP ga je uit van objecten. Stel je maakt een spelletje zeg monopolie, dan is eigenlijk alles wat je vast kan houden een object: het bord, het geld, de pionnen, de kanskaarten, de straten etc. Als voorbeeld ga ik de dobbelstenen nemen, vooral omdat die vrij universeel in een heleboel andere spellen gebruikt worden.
Omdat ik geloof dat je moet blijven proberen om programmeren een beetje onder de knie te krijgen ga ik de objecten als een functie implementeren, dat is misschien niet de manier waarop de meeste tutorials het uitleggen, maar het zorgt er voor dat je de script snippets die ik straks laat zien zo in je browser console kunt plakken en uit proberen. Bovendien kan ik daarmee in een later blog heel makkelijk JSON uitleggen, maar dat is voor later. Laten we een object gaan maken.
Voor het maken van een object moeten we eerst bedenken wat de eigenschappen van dat object zijn. Voor een standaard dobbelsteen is dat een kubus met dus een 6 tal zijdes, met op die zijdes een aantal ogen oplopend van 1 t/m 6. Ook is het zo dat de som van het aantal ogen van de twee zijdes die het verst van elkaar afliggen 7 is, maar daar gaan we ons in het voorbeeld geen zorgen over maken. Eerst gaan we het aantal zijdes toevoegen.
var dobbelsteen = { aantalZijdes: 6 }
Dat was nog niet heel ingewikkeld toch? Laten we ook nog de ogen toevoegen, dat is een lijstje, dus dat zetten we tussen blokhaken.
var dobbelsteen = { aantalZijdes: 6, ogen: [1, 2, 3, 4, 5, 6] }
Als we dat in onze browser console gooien en we proberen vervolgens het 3de oog te laten zien ziet dat er zo uit:
var dobbelsteen = { aantalZijdes: 6, ogen: [1, 2, 3, 4, 5, 6] } dobbelsteen.ogen[2]; > 3
Dat komt een lijstje in JavaScript begint bij 0, dus als we het 3de element willen hebben moeten we het item uit het lijstje hebben met het nummertje 2. Nu hoor ik je denken, leuk, maar wat is hier nou het voordeel van boven:
var dobbelsteenZijdes = 6; var dobbelsteenOgen = [1,2,3,4,5,6];
Goede vraag, ik had hem zelf kunnen stellen. Een voordeel is dat je de variabelen mooi groepeert en die groepering vervolgens weer gemakkelijk ergens anders kunt gebruiken. Ook geeft het je code een gestructureerde logica, alles is een object en heeft eigenschappen. Maar een object kan meer dan alleen variabelen groeperen. Hij ondersteunt naast eigenschappen ook acties en in JavaScript zijn acties functies. Dobbelstenen moeten rollen, dus laten we een functie maken om dat te ondersteunen.
var dobbelsteen = { aantalZijdes: 6, ogen: [1, 2, 3, 4, 5, 6], dobbel: function () { return this.ogen[Math.floor(Math.random() * this.aantalZijdes)] } }
Nu kunnen we dobbelen door de functie aan te roepen als actie van de dobbelsteen:
dobbelsteen.dobbel(); > 4
Met monopolie heb je twee dobbelstenen en het aantal zetten dat je mag doen is het totaal van de twee dobbelstenen, dat is nu simpel te doen:
dobbelsteen.dobbel()+dobbelsteen.dobbel() > 7 dobbelsteen.dobbel()+dobbelsteen.dobbel() > 6
Bij de 7 gaat dit goed, bij 6 echter kan het zijn dat we dubbel hebben gegooid, namelijk 2x 3, als dat zo is mogen we nog een keer gooien, dus dat is wel belangrijk om te weten. Of een worp ‘dubbel’ is eigenlijk een eigenschap van beide dobbelstenen. Als beide dobbelstenen samen één eigenschap hebben, dan zijn ze eigenlijk samen voor ons ook een object dat bestaat uit 2 dobbelsteen objecten. Dat ziet er zo uit:
var dobbelstenen = { aantalDobbelstenen: 2, dobbelstenen: [dobbelsteen, dobbelsteen] }
Dat is wel heel vaak het woord dobbelsteen, en we mogen zelf de namen kiezen, dus laten we dit object worp noemen:
var worp = { aantalDobbelstenen: 2, dobbelstenen: [dobbelsteen, dobbelsteen] }
De worp heeft dan natuurlijk ook een actie dobbel, waar in beide dobbelstenen worden gedobbeld:
var worp = { aantalDobbelstenen: 2, dobbelstenen: [dobbelsteen, dobbelsteen], dobbel: function () { return this.dobbelstenen[0].dobbel() + this.dobbelstenen[1].dobbel() } }
Dit lost ons probleem nog niet op, maar we hebben nu de twee dobbelstenen samen, dus we kunnen nu kijken of er dubbel gegooid is, daarvoor voegen we een klein beetje extra logica toe:
var worp = { aantalDobbelstenen: 2, dobbelstenen: [dobbelsteen, dobbelsteen], dobbel: function () { let dobbel1 = this.dobbelstenen[0].dobbel(); let dobbel2 = this.dobbelstenen[1].dobbel(); let dubbelIndicator = "" if (dobbel1 == dobbel2) { dubbelIndicator = " dubbel!" } return dobbel1 + dobbel2 + dubbelIndicator } }
Dan nog even testen of het werkt.
worp.dobbel() > "6" worp.dobbel() > "11" worp.dobbel() > "8" worp.dobbel() > "4" worp.dobbel() > "12 dubbel!"
Aah ja daar is die, nou is het voor 12 natuurlijk altijd dubbel, maar we weten ook dat de 6 8 en 4 die we daarvoor hebben gedobbeld niet dubbel waren.
Nou zijn er ook dobbelstenen met een andere vorm en andere hoeveelheden ogen, in het spel D&D (Dungeons and Dragons) heb je verschillende dobbelstenen en daarmee bedoel ik dit soort dobbelstenen:
Een veelgebruikte is er één met 20 zijdes, die noem je d20 (dobbelsteen met 20 zijdes). We hebben nu het object dobbelsteen met 6 zijdes, maar we kunnen daar ook prima 20 zijdes van maken.
dobbelsteen.aantalZijdes = 20; dobbelsteen.ogen = [1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20];
Omdat we nu het bestaande object dobbelsteen hebben aangepast is dat ook meteen aangepast in het worp opject, dus als we nu de worp dobbelen kunnen we veel hogere getallen krijgen:
worp.dobbel() > "21" worp.dobbel() > "19"
Dat zijn objecten. Ergens in het begin zei ik dat dit waarschijnlijk niet de manier is waarop het in de meeste tutorials uitgelegd wordt. Wat ik nu heb laten zien is hoe je losse objecten aanmaakt door een variabele te vullen met JSON (JavaScript Object Notation.) Wat je meestal zult zien is dat er een model van een object wordt gemaakt, en dat je daar vervolgens versies van kan maken. Ik zal daar ook nog een voorbeeld van laten zien, maar daar ga ik iets sneller; ik heb het verzoek gekregen de blogs niet te lang te maken, en ik zit al weer op ruim 1000 woorden.
Wat we gaan doen is functie objecten maken, in plaats van JSON gebruiken we een functie om het object te defineren.
//standaard aantal zijdes is 6 function d(az = 6, o = []) { this.aantalZijdes = az; this.ogen = o; //als je alleen het aantal zijdes op geeft vullen we die met getallen if (o.length == 0) { for (let i = 1; i <= az; i++) o.push(i); } this.dobbel = function () { return this.ogen[Math.floor(Math.random() * this.aantalZijdes)] } }
Nu kunnen we simpel zeggen:
var d20 = new d(20);
En nu is d20 een dobbelsteen met 20 zijdes. Maar we kunnen ook een kleuren dobbelsteen maken met:
var dkleur = new d(6,["rood", "geel","groen","paars","oranje","blauw"] );
Als je dan dobbelt krijg je één van die kleuren terug.
dkleur.dobbel() > "blauw"
Dat kunnen we dan natuurlijk ook voor de worp doen:
function w(ds, aantal = 0) { //als er 1 dobbelsteen wordt meegegeven vul het lijstje met aantal stuks er van if (aantal > 0) { this.dobbelstenen = []; for (let i = 1; i <= aantal; i++) this.dobbelstenen.push(ds); } //anders gebruik de opgegeven dobbelstenen else this.dobbelstenen = ds; this.dobbel = function (show = false) { let totaal = 0; let resultaat = "" for (d of this.dobbelstenen) { let ogen = d.dobbel() totaal += ogen; resultaat += ogen + "+"; } resultaat = resultaat.substr(0, resultaat.length - 1); resultaat += "=" + totaal if (!show) resultaat = "" + totaal return resultaat; } this.dobbelShow = function () { return this.dobbel(true); } }
In D&D kan je een spreuk doen die 8d8 aan schade doet (Je moet dan 8 keer met een dobbelsteen met 8 zijdes rollen en het totaal optellen, Dungeons and Dragons ga ik verder niet uitleggen hoor, dat moet je maar een keer bingen), als we dat in onze object georiënteerde functies willen doen kans dat nu zo:
var d8 = new d(8); var w8x8 = new w(d8,8) w8x8.dobbelShow() > "3+1+8+8+7+3+7+6=43" w8x8.dobbel() > "30"
Dat zijn kort samengevat objecten. Ik heb het voorbeeld gegeven van dobbelstenen, maar deze techniek kan je voor vrijwel alles toepassen. Kleine tip: als je mensen of dieren objectificeert, zorg dan wel dat je dat alleen tijdens het programmeren doet, sommige dingen vertalen slecht naar de echte wereld.
Eventual consistencyIk ga snel weer eens een blog schrijven zou ik lang geleden wel eens gezegd kunnen hebben. Dat zou dan inconsistent zijn met wat er hier op de site te zien is geweest.
Inconsistent zien we als een vies woord, het is een soort onwaarheid. Het ene zegt dit en het andere dat, er is er een die liegt!
In dit specifieke geval zou het meer een onverstandige belofte zijn, maar het had ook een technische reden kunnen hebben. Deze blog zou ik misschien een paar maanden geleden al geschreven kunnen hebben en vanwege een defecte communicatie nooit doorgekomen zijn. Wat je ziet is dan niet in sync met wat er geschreven is. Zou dat gebeurd zijn en de communicatie was hersteld dan zou je ineens een nieuwe blogpost met een datum ver in het verleden kunnen zien. Ziet er niet heel betrouwbaar uit, maar is in dit geval ook niet ernstig.
Dit soort situaties komen steeds vaker voor in systemen. Niet in de tijd van maanden zoals in dit (overigens zuiver hypothetische) voorbeeld, maar eerder in seconden of minuten. Dit heeft te maken met de meer gedistribueerde systemen die tegenwoordig ontwikkeld worden. De achtergrond zit hem in het zogenaamde ‘twee generaals probleem‘.
Het probleem is dat de generaals geen aanval kunnen coördineren als ze niet zeker zijn dat hun communicatie snel en volledig is. De generaals zijn in ons vakgebied computers en de communicatie loopt over een netwerk. Wil je zorgen dat alle betrokken systemen op elk punt in tijd hetzelfde laten zien dan is de consequentie wachten. Binnen een fysieke machine kan dat en dat is ook wat we gewend zijn te doen. Over een netwerk kan er verlies zijn en met gedistribueerde systemen als microservices kun je wel eens niet weten hoe vaak een stuk software waar draait.
Het gevolg is inconsistentie. Bah, ondanks de uitleg toch nog steeds niet leuk.
Je bent bijvoorbeeld een huisje aan het boeken voor de vakantie en even later blijkt dat de periode toch niet beschikbaar was. Van een systeem vinden we dit al snel een defect, maar in de buitenwereld speelt hetzelfde en zien we het als normaal. In een restaurant bestel je de dagschotel tonijn en even later komt de ober terug met de mededeling dat zojuist het laatste stuk tonijn gebruikt is en dat het toch iets anders uitzoeken wordt.
De vroegere systemen hadden als nadeel dat als het uitviel je niets had of je moest hele dure oplossingen voor failover en disaster recovery inrichten. Ook werd het heel snel heel duur als je op wilde schalen. Gedistribueerde systemen garanderen betere availability, maar er kunnen zogenaamde partitions ontstaan als er een een onderdeel niet bereikbaar is. Deze partitions zijn dan onderling niet meer consistent. We leveren dus consistentie in voor beschikbaarheid en in het kielzog daarbij winnen we snelheid en schaalbaarheid.
Om het voordeel te pakken en zo min mogelijk last te hebben van de consequenties is het zaak om gedistribueerde systemen slim op te zetten. Enerzijds vanuit de functionele hoek. Hoe ga je om met de verschillende inconsistente situaties? Hier is het zaak om zoveel mogelijk naar de buitenwereld te ontwerpen en vergelijkbare afhandelingen voor het systeem te bedenken.
Daarnaast moet de inconsistentie tijdelijk blijven, uiteindelijk moet alles weer kloppen. De oplossing daarvoor is werken met een patroon als ‘event sourcing’. Als je alle handelingen in de tijd wegschrijft in een centrale log dan is daaruit altijd weer te bepalen hoe elke situatie uitpakt ook al komt er iets te laat door. Zo kunnen de systemen op de achtergrond zelfherstellend zijn.
Stel je bijvoorbeeld de situatie van een bibliotheek voor. Je kunt in een database bijhouden welk boek aan wie uitgeleend is, maar als het terugbrengen eens niet goed verwerkt is blijft het boek uitgeleend staan. Als je het dan opnieuw uitleent staat de nieuwe klant geregistreerd bij het boek. Komt daarna de actie van het terugbrengen door dan kun je niet meer goed zien of het te laat ingeleverd is. Werken met een log als basis geeft je dan de mogelijkheid om elk punt in de tijd te reconstrueren en af te handelen.
De eigenlijke persistentie (opslag) ligt bij event sourcing niet meer zoals gebruikelijk in een database, maar in deze log. Dit levert weer andere voordelen. Dat is wellicht iets voor een andere keer, maar het kan even duren voor dat doorkomt.
De eeuwige strijd: middleware versus applicatieIedereen die te maken heeft gehad met integratie vraagstukken herkent het volgende probleem: plaatsen we de logica van de vertalingen in de middleware of in de applicatie? Ik heb zelf talloze uren gespendeerd aan deze discussie. Hele whiteboards werden dan vol geschreven met de pro’s en con’s van beide keuzes. Wat mij altijd opvalt bij deze discussies is de verbetenheid waarmee deze worden gevoerd. Het mondt vaak uit in een stammenstrijd waarin voor- en tegenstanders hun kampen betrekken en elkaar bestrijden met principes.
De applicatie-aanhangers vinden dat alle business logica tot het applicatie domein behoort. De middleware dient ‘onwetend’ te zijn en alleen te worden gebruikt als (geavanceerde) transportlaag.
De middleware-aanhangers vinden dat alle mogelijkheden van hun tools moeten worden benut. Dat is nou juist de kracht van de middleware. En daar is al veel geld voor betaald. Dus dan moet je het ook goed gebruiken.
Een principe-strijd dus. Al spelen politieke en commerciële belangen natuurlijk ook een grote rol bij het innemen van een standpunt. Het probleem van een dergelijke principe-strijd is dat beide standpunten zeer goed te verdedigen zijn. En dat niemand dus het absolute gelijk aan zijn zijde heeft. Helaas zijn dat precies de omstandigheden waarin mensen niet van hun standpunt willen afwijken. De stellingen zijn betrokken en niemand geeft elkaar een duimbreed toe.
Het zou helpen als er op een andere manier naar dit probleem gekeken zou worden. Voor zowel middleware als applicaties geldt dat deze bestaan omdat ze organisaties moeten faciliteren bij het realiseren van hun IT-processen. Het zijn dus beiden middelen en geen doelen op zich. Principale discussies hierover zijn dus weinig zinvol. Dergelijke discussies zijn relevant als je het hebt over doelen. Maar niet als je het hebt over middelen.
Het is mijn overtuiging dat bij de keuze tussen middleware versus applicatie vooral moet worden gekeken naar waar de organisatie het best in is. Stel dat je allemaal Oracle maatwerk applicaties hebt draaien en je hebt een fantastisch ingerichte IT-organisatie die zeer bedreven is in het bouwen en beheren hiervan. Dan lijkt het mij voor de hand liggen dat je alle logica in de applicaties aanbrengt. Daar ligt immers jouw kracht. En als je juist een heel divers IT-landschap hebt met verschillende technologieën, dan loont het wellicht om de logica in de middleware te leggen. Dan leg je daar jouw focus neer en zorg je ervoor dat je een competente middleware beheer-organisatie inricht. Dan zit daar jouw kracht en organiseer je van daaruit de grip en controle op jouw IT-landschap.
Kiezen tussen middleware versus applicatie? Kijk naar waar je goed in bent. Bedenk vooral wat jij het best en het goedkoopst kan organiseren. Laat je vooral niet verblinden door te veel principes. En als je een keuze hebt gemaakt, houd je daar dan ook aan. Dat houdt het simpel en overzichtelijk. En dat is een groot goed!
EDI – de ultieme integratie
Ik ben inmiddels al ruim 13 jaar bezig met EDI. Dat is best lang. Zo lang dat ik bij veel collega’s zelfs bekend sta als “Mister EDI”.
En het is ook alweer zo’n 9 jaar geleden dat ik voor het eerst te maken kreeg met het vakgebied van Integration en Middleware. In mijn geval betreft dat voornamelijk het werken met webMethods.
In al die jaren is mij een aantal zaken opgevallen. Als ik in mijn werk betrokken ben als EDI Architect dan komt heel vaak het volgende voorbij:
In mijn werk als Integration Architect hoor ik vaak heel veel ambities voorbij komen:
Tja, dan denk ik soms wel eens: dat ouderwetse EDI, is dat eigenlijk al niet decennia lang de ultieme vorm van Integration?
Hier komt de sidebar