Hoe we bij September software met elkaar ‘laten praten’​.

Wat is ‘een koppeling’ eigenlijk?

Soms ben je bij ons en dan hebben we het over hoe we kunnen zorgen dat jouw nieuwe website of webapplicatie kan gaan ‘praten’ met een andere. We bedoelen dan dat het ene stuk software, data kan uitwisselen met een ander: bijvoorbeeld de software waarmee jij je klanten beheert, je voorraad kan bijhouden of je online betalingen mee faciliteert.

Soms heb je misschien niet eens echt door dat we dit doen. Even een e-mailadres naar Mailchimp versturen bijvoorbeeld. Of integreren met een ticketsysteem zodat mensen naar jouw event kunnen. Meestal gaat het dan om grotere bedrijven die al langer meedraaien en succesvol zijn, met een heldere en simpel uitgedachte functionaliteit.

Maar soms moeten we ook echt goed uitpluizen wat er moet gebeuren: er komt business logic en complexiteit om de hoek kijken.

We koppelen met andere specialistische software zoals marketing automation, bookings platforms of een warehouse oplossing, omdat deze jarenlange ervaring hebben in een niche: je zou er bijzonder lang over doen om deze kennis zelf op te doen — laat staan dat je het allemaal moet ontwikkelen.

Het is ook vaak niet je core business. Waarom zou je als NGO moeten nadenken over hoe je het beste geavanceerde e-mail campagnes zo goed mogelijk kan laten afleveren bij je donateurs: het zou gewoon moeten werken — toch?

Bij September hebben we al jaren ervaring met het koppelen van allerlei systemen die moeten omgaan met complexe situaties en erg veel data, terwijl we het voor jouw klanten juist zo simpel mogelijk maken. Je wil namelijk niet dat een consument lang moet zoeken naar informatie en daardoor afhaakt in een proces, dat gaat ten koste van je doelstellingen: van informeren tot en met verkopen.

Tegenwoordig gaat de meeste communicatie tussen software systemen via een API, wat staat voor Application Programming Interface. Deze bieden toegang tot afgesproken bronnen van data in een systeem, met daarbij een afspraak over hoe deze opgevraagd kan worden: een protocol. Dat gaat bijvoorbeeld over dat de aanvragen via HTTP gedaan kunnen worden, en in een XML of bijvoorbeeld JSON formaat gecommuniceerd worden.

Doordat die afspraken er zijn en documentatie bekend is over hoe het systeem is ingericht, kan een andere applicatie, soms een andere API, informatie uitwisselen: opvragen en insturen.

Of zoals wij zeggen: praten :)

Een voorbeeld dan, bij ons.

De opleidingssoftware Coachview is goed in deelnemersdossiers, beschikbare cursussen en docenten tonen, facturen groeperen op bedrijf, certificaten aan personen koppelen… En nog veel meer.

Ze ontsluiten een API waar wij allerlei data uit kunnen ophalen en insturen, welke wij gebruiken op een website. Zo synchroniseren we voor onze opdrachtgever https://acta-de.nl alle cursussen naar Wordpress, zodat deze goed doorzoekbaar en direct boekbaar zijn. Zodra er een aanvraag gedaan wordt sturen wij deze weer terug naar Coachview.

Coachview zelf biedt geen online betaalmogelijkheid, maar bijvoorbeeld Mollie weer wel; voor een andere opdrachtgever gaan wij binnenkort dan weer bezig om deze twee met elkaar te koppelen.

Dit heeft allerlei voordelen: wij zorgen voor conversie en customer journeys, Coachview bijvoorbeeld voor betrouwbare en bewezen opslag van persoonsgegevens. Iedereen wint :)

Hoe ontwikkelen wij een koppeling?

Als je me een beetje kent, weet je dat ik hier erg lang over zou kunnen praten, maar ik ga het proberen bondig te houden.

• ‘Most overlooked’ bij software development in het algemeen, maar ook zeker bij koppelingen, is documentatie & requirements. We stemmen eerst samen af wat de einddoelen zijn, welke data er heen en weer moet — en hoe deze bereikbaar moet zijn. Dit doen we samen: onze opdrachtgever, een UX-er, developer en strateeg. Samen brengen we alle kennis bij elkaar.
• Niet bang zijn en het simpel houden! We starten met een proof of concept van de koppeling, zorgen dat we alles kunnen uitwisselen en maken het daarna mooi. Een ander gevaar is om alles maar uit te wisselen en te ver vooruit te denken over wat er nog bij zou kunnen. Dit is overigens een prachtige fase om allerlei ICT-bingo termen in gedachten te houden, zoals KISS, YAGNI of DRY ;)
• We denken wel ver vooruit over onderhoudbaarheid en duurzaamheid van de koppeling. We willen een langdurige werkzame functionaliteit opleveren — die gegarandeerd de juiste data door blijft sturen. We schrijven daarom documentatie, draaien uitgebreide Quality Assurance rondes en werken met meerdere developers die elkaars werk controleren.

En nu?

Nou: ik hoop in ieder geval dat je ons wat minder vreemd aankijkt wanneer we over pratende software spreken. Mocht je meer willen weten over slimme integraties dan weet je ons te vinden!

Deze post is er één in een serie om meer te vertellen over hoe wij bij September werken aan het maken van digitale producten. Dat kan van alles zijn: van product-statement tot en met de keuze voor een bepaalde techniek. Ik schrijf dit op omdat onze opdrachtgevers vaak nieuwsgierig zijn: waarom stel ik sommige vragen en hoe helpt ons dat verder in samen de juiste keuzes maken? Zoals wel vaker bij September probeer ik dat lekker dicht bij de praktijk te houden.