Systemen koppelen met een API

Nieuwe software komt zelden in een leeg landschap terecht. Er staat al een boekhoudpakket, er is een CRM, er draait een voorraad- of planningssysteem. De nieuwe software heeft gegevens uit die systemen nodig en stuurt er gegevens naar terug. Blijft die uitwisseling uit, dan verplaatst u het overtypen alleen naar een ander scherm.

De waarde zit daarmee vaak niet in de nieuwe schermen maar in de koppeling. Toch wordt juist dat onderdeel in offertes het sterkst samengevat: één regel, koppeling met het boekhoudpakket, en de rest blijkt gaandeweg. Voor een bouwer is dat begrijpelijk, want hij kan pas inschatten wat het werk is als hij inzage heeft in het andere systeem. Het risico van die onbekende ligt daarmee bij u. Vraag om die regel uit te splitsen naar welke gegevens, in welke richting en hoe vaak, en zet die uitsplitsing in uw programma van eisen. Bij software op maat bepaalt het bestaande landschap de bouwtijd net zo sterk als de functionaliteit.

Twee systemen laten praten via een API is voor een ervaren ontwikkelaar zelden ingewikkeld werk. Waar projecten op vastlopen is de vraag die eraan voorafgaat: wat betekenen de gegevens die eroverheen gaan?

Neem het begrip klant. In een boekhoudpakket is dat een debiteur: die ontstaat pas als er iets te factureren valt, heeft verplicht een factuuradres, en mag vaak niet meer worden gewijzigd zodra er een geboekte factuur aan hangt. In een CRM is een klant een relatie: die bestaat al als prospect, heeft geen adres nodig en krijgt regelmatig een andere contactpersoon. Hetzelfde woord, andere verplichte velden, een ander idee van wanneer iets nog mag veranderen.

De randen komen boven water zodra u die twee koppelt. Eén bedrijf met drie vestigingen staat in het CRM als drie relaties en in de boekhouding als één debiteur met drie afleveradressen. Wat telt dan als de klant? En mag een adreswijziging uit het CRM de boekhouding overschrijven, ook als daar al facturen op het oude adres staan?

De vraag die dit oplost is niet welk systeem leidend is, maar welk systeem leidend is voor welk gegeven: per gegeven precies één plek waar het gewijzigd mag worden. Dat is geen technische keuze maar een keuze over hoe uw organisatie werkt, en een bouwer kan hem niet voor u maken. Maakt niemand hem, dan maakt de programmeur hem impliciet ergens in de code. U merkt dat pas als de cijfers uit beide systemen niet meer op elkaar aansluiten.

Voordat er iets gebouwd kan worden moet duidelijk zijn wat het bestaande systeem toelaat. Er zijn drie tegenvallers die vaker voorkomen dan verwacht.

De eerste: er is geen bruikbare koppelmogelijkheid. Bij oudere pakketten en bij systemen die op uw eigen locatie draaien is er soms alleen een export naar een bestand. Dan bouwt u om het systeem heen, met een export die op een vaste plek terechtkomt en op een vast moment wordt ingelezen. Dat werkt, maar het is broos: één kolom erbij in die export en de uitwisseling staat stil.

De tweede: de koppelmogelijkheid bestaat, maar er hangt een rekening aan. Sommige leveranciers bieden hem alleen in een zwaarder abonnement, of rekenen per aangesloten applicatie of per hoeveelheid bevragingen. Dat is een terugkerende post die pas zichtbaar wordt als de bouw al loopt. Zoek het uit voordat u kiest.

De derde, en de meest onderschatte: de koppeling werkt maar één kant op. Veel koppelingen zijn gemaakt om te lezen. U kunt orders ophalen, maar de status niet terugschrijven. Of wegschrijven kan alleen als nieuw record, niet als wijziging op wat er al staat. De vraag is dus niet of een pakket een API heeft, maar of u dit veld ook kunt wegschrijven en bijwerken.

Realtime klinkt als de betere keuze, en soms is het dat ook. Maar er zit een keerzijde aan: u maakt beide systemen afhankelijk van elkaars beschikbaarheid. Ligt het andere systeem eruit voor onderhoud, dan kan uw eigen proces niet verder, tenzij er een wachtrij achter zit die berichten vasthoudt. Bouwt u die wachtrij, dan heeft u alsnog een periodiek mechanisme, alleen minder zichtbaar.

Beslis dit per gegevensstroom, niet per koppeling. Hoe erg is het als dit gegeven even oud is? Bij een voorraadstand in een webshop is dat erg, want u verkoopt iets wat er niet meer ligt. Bij klantgegevens en boekingen is een uitwisseling per etmaal meestal voldoende.

De gevaarlijkste storing is de storing die niemand ziet. Een koppeling die luid faalt wordt dezelfde dag opgelost, want iemand krijgt een foutmelding op zijn scherm. Een koppeling die stilletjes stopt doet geen pijn: alle schermen blijven het doen en de twee systemen lopen alleen langzaam uit elkaar. Dat komt aan het licht bij een afsluiting, of als een klant belt over een order die aan uw kant allang is afgehandeld.

Twee vragen horen daarom vóór de bouw beantwoord te zijn. De eerste: wie ziet het als het misgaat? Een regel in een logbestand is geen signaal, want niemand leest logbestanden uit gewoonte. Er moet iets naar een persoon gaan, met de afspraak wie dan actie onderneemt. Reken er ook op dat stilvallen niet altijd een fout oplevert: een koppeling die al een etmaal niets heeft doorgegeven, ziet er van binnen precies zo uit als een rustige dag. Er moet dus iets zijn dat het uitblijven opmerkt, niet alleen de fout.

De tweede: wat gebeurt er met de gegevens die intussen niet zijn doorgekomen? Berichten die niet konden worden afgeleverd moeten bewaard en opnieuw aangeboden worden, niet weggegooid. En dat opnieuw aanbieden mag niets verdubbelen. Krijgt elk bericht een eigen kenmerk mee, dan herkent het ontvangende systeem dat het die order al kent.

Dit is precies het werk dat uit een scherpe offerte verdwijnt: bewaking en herstel zijn onzichtbaar in een demo en kosten bouwtijd die niets zichtbaars oplevert. Vraag expliciet of ze erin zitten en wie ze bewaakt zodra de software draait. Het komt structureel terug in de onderhoudskosten.

De partij die uw nieuwe software bouwt kan niet meer dan de leverancier van het bestaande systeem toestaat. Die antwoorden haalt u zelf op, het liefst op schrift en vóór de opdracht.

Let vooral op de laatste twee. Een leverancier die zijn koppeling zonder aankondiging kan wijzigen, kan uw software laten stilvallen, en het herstel daarvan komt op uw rekening.

• Een programma van eisen schrijven
• Software op maat per sector
• Waar onderhoudskosten van software uit bestaan