Integratie: een goede aanpak is net zo belangrijk als techniek
Een veel voorkomende klantvraag: ‘Welke vormen van integratie ondersteunt u? Met welke systemen kunt u koppelen?’ etc. We hebben een API en dan kan alles, toch? Maar hoe dan? En hoe pas je dat toe in een implementatie? Waarom lijkt het zo ingewikkeld als je vraagt; “ Zullen we de developers van beide kanten even met elkaar te laten praten?” En waarom is een periodieke database-dump niet de juiste weg om te kiezen?
Een snelle start van de VMS trein
Onze ervaring leert dat het beter is eerst live te zijn met het VMS en de integratie in fase 2 op te pakken. De onervarenheid met Nétive VMS is dan geen hindernis meer. De VMS trein rijdt al en deze rijdt door een geolied integratie-project alleen maar beter en sneller. Wie kan je aan tafel uitnodigen bij een eerste gesprek over integratie van het VMS met omliggende systemen? De functioneel beheerder van het VMS is dan natuurlijk de prime suspect.
Daarnaast is het heel fijn als de organisatie beschikt over een hoofd informatie-management of een applicatiebeheerder van het omliggende systeem. De developers hoeven daar nog niet direct bij aanwezig te zijn. Het is goed om eerst binnen de business context in heldere taal op te schrijven welke uitwisseling van gegevens benodigd is. Teken het landschap, welke data zit waarin? Welk knelpunt in het overdragen van data kost waarschijnlijk veel tijd? Of waar is de kans op fouten in de overdracht het grootst?
Gaat het om masterdata? Meestal (niet altijd!) zit de grootste winst in transactionele data, als bijvoorbeeld de inhuuropdrachten van het VMS uitgewisseld kunnen worden met het ERP-systeem (inkooporders) of als het HR-systeem de gegevens van de ingehuurde medewerker kan verwerken. En uiteraard zijn de urenstaten en factuurgegevens uit het VMS zeer welkom in het ERP-systeem. Masterdata moet wel heel dynamisch zijn om een betere business case met zich mee te brengen dan transactionele data.
Middleware of ESB?
Is er eenmaal goed omschreven welke gegevens vanuit welke statusovergang van het ene naar het andere systeem moeten bewegen dan wordt het tijd om te kijken wat de systemen kunnen. Dat is tevens een moment om eens te kijken hoe er binnen de ICT-afdeling op de term ‘middleware’ gereageerd wordt.
Waarom dan? In de wereld van standaard software is het fijn als de leverancier beschikt over een API, want dan kan vrijwel alles. Maar als 2 API’s niet op elkaar zijn gecertificeerd en dus niet 100% op elkaar zijn ingesteld om gegevens uit te kunnen wisselen, dan zal er geprogrammeerd moeten worden. Leveranciers van standaard software hebben de voorkeur om hun ontwikkelaars niet te laten werken aan dit soort klantspecifieke aanpassingen. Er kan in dat geval dus discussie ontstaan rondom het standpunt ‘dit is ons API-framework, daar moet het mee gebeuren’.
Het lijkt op zo’n moment misschien goed als 1 van beide leveranciers uiteindelijk een offerte opstelt om aanpassingen te gaan doen maar of dat ook echt een verbetering van het standaard-product met zich meebrengt, is onzeker. Het integratie traject kan echter wel door naar de volgende ronde ;-).
Voordat een dergelijke discussie met de leveranciers wordt gestart is het goed om met de ICT-afdeling te praten over middleware of een technisch relevantere naam, een ESB. Het woord middleware illustreert wel beter wat het is en doet; software in het midden tussen alle applicaties, met als belangrijke functie het uitwisselen van gegevens tussen die applicaties.
Vaak is een ESB een forse hobbel. Er wordt immers geld uitgegeven aan een systeem wat net zo veel of weinig uitstraling heeft als het leidingwerk van een CV installatie nl.; je ziet er niets van en je wilt het ook niet zien. Het heeft bovendien de bijwerking van maatwerk software, er moet regelmatig aan gesleuteld worden om weer een volgende stroom van gegevens-uitwisseling mogelijk te maken.
Lange termijn winst door een goed gelegde puzzel
De winst zit echter in de langere termijn, als alle standaard applicaties doen waar ze voor gebouwd zijn zoals standaard functies uitvoeren en alle API’s van de standaardapplicaties praten met de ESB en de ESB is er naadloos tussen geprogrammeerd, dan is er sprake van een robuuste architectuur. En leveranciers van standaard applicaties die zich niet bezighouden met specifieke klant-integraties hebben uiteindelijk meer tijd voor het verbeteren van hun standaard applicatie en het uitbreiden van hun API.
Is er al een ESB in bedrijf dan scheelt dat dus veel werk. Het is plezierig als de beheerder van de ESB ook gesprekspartner is, vraag er een consultant van het VMS en het andere systeem bij en leg het plan en de tekening op tafel.
Dan begint het ambachtelijke werk;
Van welk proces moeten op welk moment welke data worden verstuurd van systeem A naar B? Begint 1 systeem met pushen?
Is het andere systeem aan het pollen?
Hoe houd je de middleware zo ‘slank’ mogelijk?
Misschien is het toch goed om hier en daar een veldje aan een bestaande webservice van een API toe te voegen?
Stuur je de gegevens wel op het juiste moment en vanuit de juiste status?
En zo verder.
Al met al nog steeds een hele puzzel, alleen wel met grotere kans op succes als de juiste mensen met elkaar om de tafel zijn gegaan en hier over mee gedacht hebben!
