Wat een koppeling werkelijk kost
Twee systemen laten praten klinkt als een dagtaak. Waarom het meestal langer duurt, waar het geld in gaat zitten, en welke vragen je aan een aanbieder moet stellen om een raming te kunnen beoordelen.
- Het grootste deel van de tijd gaat naar afspraken over gegevens, niet naar code.
- Ongeveer de helft van het bouwwerk is foutafhandeling en herstel.
- Een eenvoudige koppeling staat in twee weken; twee richtingen of een verouderd systeem maakt het vier tot acht.
- De doorlooptijd hangt vaker af van de andere partij dan van de techniek.
01Het gesprek dat voor de code komt
Voordat er iets gebouwd kan worden, moeten er afspraken zijn. Welk systeem is leidend als twee bronnen het oneens zijn over een adres. Wat gebeurt er met een order die in het ene systeem bestaat en in het andere niet. Hoe vaak moet iets doorkomen om nuttig te zijn: direct, elk kwartier, of één keer per nacht.
Die vragen kosten een paar gesprekken en bepalen het grootste deel van de bouwtijd. Wie deze stap overslaat, bouwt een koppeling die technisch werkt maar in de praktijk verkeerde gegevens verspreidt, en dat is erger dan geen koppeling.
In de praktijk levert dit gesprek ook winst op los van de techniek. Het is vaak de eerste keer dat op papier staat hoe gegevens door de organisatie stromen.
- Welk systeem is leidend per soort gegeven
- Wat is de gewenste vertraging: realtime of periodiek
- Wat gebeurt er bij tegenstrijdige waarden
- Wie krijgt bericht als iets niet doorkomt
02De helft van het werk is foutafhandeling
Op een goede dag is een koppeling eenvoudig: gegevens ophalen, omzetten, wegschrijven. Het werk zit in alle andere dagen. Een API die traag is, een token dat verloopt, een verplicht veld dat leeg blijkt, een bericht dat twee keer aankomt, onderhoud aan de andere kant.
Elk van die gevallen vraagt een beslissing en een terugvalpad. Berichten moeten opnieuw te versturen zijn zonder dubbele orders op te leveren, fouten moeten zichtbaar worden met de betrokken gegevens erbij, en een storing bij de ander mag jouw systeem niet meesleuren.
Dit is ook de reden dat een koppeling die “even snel” is gebouwd na een half jaar onbetrouwbaar blijkt. Niet omdat de code fout is, maar omdat er nooit is nagedacht over wat er gebeurt als het misgaat.
03Wat je ervoor terugkrijgt
Een goede koppeling levert meer op dan tijdwinst. Fouten door overtypen verdwijnen, en de gegevens waarop je beslissingen baseert kloppen met de werkelijkheid in plaats van met de laatste export.
In de projecten die ik doe is dat vaak het echte resultaat: niet dat het sneller gaat, maar dat het klopt. Een magazijn dat geen pakbonnen meer krijgt voor uitverkochte artikelen scheelt meer dan een uur per dag aan telefoontjes en correcties.
Daar komt bij dat werk dat niemand leuk vindt verdwijnt. Dat is moeilijker in een getal te vatten, maar het merkbaar effect op een team is groot.
04Een reële bandbreedte
Een eenvoudige koppeling met één richting en een goed gedocumenteerde API staat vaak binnen twee weken. Zodra er twee richtingen, meerdere kanalen of een verouderd systeem zonder documentatie bij komen, praat je over vier tot acht weken.
Wat de doorlooptijd het meest beïnvloedt is zelden de techniek. Het is de beschikbaarheid van iemand die vragen over het proces kan beantwoorden, en of de andere partij een testomgeving heeft waarin je fouten mag maken.
Vraag bij een raming daarom niet alleen naar de bouwtijd. Vraag wat er gebeurt als een bericht niet aankomt, en hoe je dat als opdrachtgever zelf kunt zien. Dat antwoord zegt meer over de kwaliteit dan de prijs.
- Eén richting, gedocumenteerde API: één tot twee weken
- Twee richtingen met voorraad of prijzen: drie tot zes weken
- Verouderd systeem zonder API: vier tot acht weken
- Eigen API voor derden, inclusief documentatie: vanaf drie weken
Vraag bij een raming niet alleen naar de bouwtijd, maar naar wat er gebeurt als een bericht niet aankomt.