De API bestaat. De koppeling nog niet.

Waarom “even twee systemen verbinden” zelden een kwestie is van één digitale stekker

“Goed nieuws: het pakket heeft een API.”

Die zin wordt vaak uitgesproken alsof het project daarmee zo goed als klaar is. Er staat een deur open, dus we hoeven alleen nog even naar binnen. Helaas vertelt een API vooral dát twee systemen met elkaar kunnen praten. Niet of ze elkaar begrijpen.

En precies daar begint het echte werk.

Dezelfde klant, drie verschillende waarheden

Stel: een groothandel gebruikt een CRM voor verkoop, een ERP voor voorraad en een boekhoudpakket voor facturen. In het CRM heet een klant “Van Dijk Bouw”. In het ERP staat “Van Dijk Bouw B.V.” en in de boekhouding bestaat dezelfde organisatie twee keer, omdat daar ooit een tweede vestiging is toegevoegd.

Technisch kunnen we de systemen prima verbinden. We sturen een klant record van A naar B en krijgen een keurige bevestiging terug. Groen vinkje. Missie geslaagd.

Alleen: welk klant record is de waarheid? Wat gebeurt er als het adres in het CRM verandert, maar finance bewust een ander factuuradres gebruikt? Wie mag een klant verwijderen? En wat doen we met een order als één systeem de klant wel kent en het andere niet?

Een API beantwoordt geen van die vragen. Dat moeten mensen doen.

Een goede koppeling verplaatst niet alleen data. Hij begrijpt wat die data binnen beide organisaties betekent.

De happy flow is het goedkope deel

De demonstratie van een koppeling is meestal prachtig. Een nieuwe order verschijnt in het andere systeem. Een medewerker klikt. Iedereen kijkt tevreden. Koffie erbij.

Maar software leeft niet in een demonstratie. Software leeft op maandagochtend, wanneer een leverancier traag reageert, een artikelnummer ontbreekt en iemand ondertussen drie keer op dezelfde knop drukt.

Dan komen de vragen die de koppeling betrouwbaar of gevaarlijk maken:

• Wat gebeurt er als systeem B tijdelijk niet bereikbaar is?
• Proberen we het later opnieuw, en hoe vaak?
• Hoe voorkomen we dat dezelfde order twee keer wordt aangemaakt?
• Wie krijgt een melding als data niet verwerkt kan worden?
• Kan een medewerker zien wat er misging zonder een developer te bellen?
• Kunnen we achteraf reconstrueren welke informatie wanneer is verstuurd?

De regel code die een order verstuurt, is vaak niet het moeilijke deel. De uitzonderingen eromheen zijn het product.

”Realtime” is ook een bedrijfskeuze

Niet alle informatie hoeft binnen milliseconden overal gelijk te zijn. Voor een voorraadreservering kan snelheid essentieel zijn. Voor het bijwerken van een marketingkenmerk misschien niet.

Toch wordt “realtime koppelen” regelmatig als vanzelfsprekend op een wensenlijst gezet. Dat klinkt modern, maar het maakt een oplossing ook complexer. Systemen worden sterker van elkaar afhankelijk en een storing verspreidt zich sneller door de keten.

Bij Byte Me vragen we daarom niet alleen óf data gekoppeld moet worden. We vragen waarom, voor wie en hoe snel. Soms is een directe koppeling nodig. Soms is iedere vijf minuten verstandiger. En soms is één gecontroleerde synchronisatie per nacht precies goed.

Sneller is geen doel op zichzelf. Betrouwbaar wel.

Een koppeling heeft een eigenaar nodig

Een integratie wordt vaak behandeld als leidingwerk: eenmaal aangelegd en daarna vergeten. Maar pakketten veranderen. Velden krijgen een andere betekenis. Leveranciers passen rechten of limieten aan. Processen binnen de organisatie bewegen mee.

Daarom moet duidelijk zijn:

• wie verantwoordelijk is voor de gegevens;
• wie meldingen beoordeelt;
• welke leverancier bij een storing als eerste kijkt;
• hoe wijzigingen worden getest;
• en welke afspraken gelden wanneer één systeem verandert.

Zonder eigenaar blijft een fout soms weken stil liggen. De koppeling draait technisch nog steeds, maar verwerkt intussen halve of verkeerde informatie. Dat is het vervelende soort storing: geen rood scherm, wel langzaam groeiende rommel.

Hoe Byte Me naar koppelingen kijkt

Wij beginnen niet bij de documentatie van de API. We beginnen bij de reis van de informatie.

Waar ontstaat een order? Wie mag hem aanpassen? Wanneer is hij definitief? Welke systemen moeten hem zien? Wat mag er gebeuren als één stap mislukt? Pas als dat helder is, wordt de technische route interessant.

Daarna bouwen we niet alleen de doorgang, maar ook de vangrails: validatie, logging, duidelijke foutmeldingen, monitoring en een veilige manier om mislukte acties opnieuw uit te voeren.

Dat is minder spectaculair dan twee blokjes met een pijl ertussen. Het is wel het verschil tussen een koppeling die tijdens een demo werkt en een koppeling waarop een bedrijf durft te vertrouwen.

De vraag die je vóór iedere koppeling moet stellen

Vraag een leverancier niet alleen: “Kunnen jullie deze systemen koppelen?”

Vraag: “Wat gebeurt er wanneer de koppeling niet werkt?”

Het antwoord vertelt je meestal alles wat je moet weten.