Veel bedrijven stellen me de vraag; ‘Kan mijn app samenwerken met systemen die ik al gebruik in mijn bedrijf?’.

Om het antwoord op deze vraag te weten te komen heb ik een app programmeur geïnterviewd. Bas van Kuijck is lead mobile developer bij E-sites en vertelt over hoe een app kan samenwerken met een bestaand systeem.

Lees het artikel of bekijk de video:

Wat doe je precies bij E-sites als app programmeur?

Bij E-sites werk ik als mobile app developer. Ik ben gespecialiseerd in iOS apps ontwikkelen. Ik mag daardoor aan mooie apps werken, zoals Beesafe, Happi en Trivoly. 
 

Hoe maak je een app die met bestaande systemen integreert?

Ik heb al vaker apps gemaakt die moesten integreren met bestaande systemen. Daar komt wel het een en ander bij kijken. Om gegevens zoals berichten, foto's en video's weer te geven, moet een app praten met een zogenaamde backend. Daarin zit een communicatie kanaal en een database. 99% van de apps krijgen hiermee te maken. Zie het zo; je hebt een app aan de ene kant en het systeem aan de andere kant. Dan moet er een brug worden geslagen tussen de twee.

De API (Application Programming Interface) is het kanaal tussen de app en de systemen. Daardoor kunnen er in de app gegevens worden weergegeven. De app praat dan tegen de API, en de API praat weer met achterliggende database met gegevens. De backend wordt in een bepaalde programmeertaal geschreven, meestal in PHP.

Als het bericht via de API is aangekomen is in de backend dan komt er in de meeste gevallen een reactie terug in de vorm van een JSON bestand. JSON is een standaard gegevensformaat. Dat is dus erg handig want dan kan het gelezen worden door allerlei technologieën. Het JSON bestand moet wel aankomen in de app natuurlijk, en dat gaat via de API.

"Als bedrijf kun je niet vaak afstappen van bestaande systemen."

Als je verschillende systemen hebt, moet je dan steeds een nieuwe API maken?

Nee, dat is het handige aan de gemaakte API. Als je diverse apps of systemen hebt, dan kunnen al die apps met de API communiceren. Als je je app bijvoorbeeld wilt laten samenwerken met Facebook dan maakt de API dat mogelijk, en dat geldt dan ook voor Twitter of Instagram. Er hoeft dus niet steeds een nieuwe API gemaakt te worden. Deze zijn bovendien programmeertaal onafhankelijk. Dat is handig voor app programmeurs, maar ook voor de klant: die betaalt voor minder uren.

Dit zijn veel moeilijke woorden, zou je een praktijkvoorbeeld kunnen geven?

We werken nu aan een hardloop-app van Atletiekunie; de Hardloper app. Deze app bestond al in de vorm van de Dutchrunner app en had al een systeem. Dit gebruikerssysteem gebruikte de Atletiekunie al voor gegevens zoals abonnementsvormen, facturatie en een ledenoverzicht. Atletiekunie wilde het hele systeem inclusief de app veranderen. Onze missie is om te zorgen dat de app veranderd wordt zonder dat het gebruikerssysteem verloren gaat. Daarom hebben we eerst een API gemaakt om de gebruikersgegevens op te halen.

Een backend developer heeft een laag bovenop het ‘oude’ gebruikerssysteem gebouwd dat synchroniseert met deze gebruikersgegevens. Door deze laag, hoeft de app niet meer te communiceren met het oude systeem. De API communiceert dan met die nieuwe laag en zal zo de gebruikersgegevens gebruiken in de vernieuwde hardloop-app. Het mooiste hieraan is, de app kan aangepast worden maar de gebruikers merken er niets van omdat dezelfde data wordt gebruikt.

De hardloop-app is een voorbeeld van wat er gebeurt als je met leden werkt, maar zo gaat het ook bij klantsystemen (CRM), voorraadsysteem of bedrijfssysteem (ERP). Als bedrijf is het vaak onmogelijk om van zo'n bestaand systeem af te stappen. Net als met de hardloop-app wordt er dan een extra laag gecreëerd zodat de API met de bestaande systemen communiceert. Zo worden belangrijke gegevens gebruikt zónder dat het systeem compleet geïntegreerd hoeft te worden in de app!  

"De kennis van de consultants is ontzettend waardevol want deze kennen het systeem al."

Hoe werkt integratie als je een nieuw app-idee hebt?

Dan is alles veel gemakkelijker. Als je een nieuw app-idee hebt, wordt alles meteen in de meest ideale situatie opgezet. Er is wel een belangrijk puntje waar nog wel bij stil gestaan moet worden. Of het nu gaat om een nieuw systeem of een bestaand, een API moet er wel toegang tot hebben. Wil de API van de hardloop-app bijvoorbeeld gebruikersgegevens ophalen? Of moet de Pokémon Go app bij kaartgegevens kunnen komen? Dan moet de API een spreekwoordelijk 'toegangspasje' hebben om het systeem binnen te komen. Daar moet de maker/beheerder van het systeem toestemming voor verlenen en een toegangspunt tot het systeem maken. Hou er dus al bedenker van een nieuwe idee rekening mee, dat je toestemming hebt voor het gebruik van de data; in feite dat je een toegangspasje krijgt tot de API.

Waar moet een bedrijf rekening mee houden als er een bestaand systeem gebruikt wordt in een app?

De meeste mensen hebben geen idee van webservers, back-office of systemen. Daarom moet een klant idealiter dan een consultant, app programmeur, of iemand met gevoel voor techniek betrekken. Vaak wordt een bestaand systeem door een andere partij ontwikkeld, dan de partij die de app maakt. De app programmeur moet met die partij samenwerken om die data uit het bestaande systeem te ontsluiten. Oftewel, het toegangspasje moet verleend en uitgelegd worden.

Het ‘Ik wil een app’ tijdperk is voorbij. Bedrijven willen een app met toegevoegde waarde en nut. Nu is er al veel automatisering in bedrijven en als die systemen samen komen in een app dan is dat natuurlijk winstgevend. Dit zorgt er wél voor dat er veel samengewerkt moet worden tussen verschillende leveranciers en partijen. Daarom is het zo ontzettend belangrijk dat er technische kennis aanwezig is als een je zo’n app wil gaan maken.

In de praktijk huren grote bedrijven daarom vaak consultants in, en daar wordt dan ook een budget voor gealloceerd. De kennis van de consultants is ontzettend waardevol want deze kennen het systeem al. Dat is essentieel voor een schatting van de kosten en of iets technisch haalbaar is. Het gaat hierbij over grote opdrachten die vaak boven de €100.000 kosten. Een app kost al veel tijd en geld, dan wil je werken met ervaren mensen om die investering terug te verdienen.

Middelgrote en kleine bedrijven hebben vaak kleinere app-projecten die minder kosten. Zij doen er dan goed aan om óf hun interne ICT persoon zo vroeg mogelijk aan tafel te hebben óf de backend developer en app programmeur mee te laten kijken met hun bestaande systemen. Daarbij is ook de samenwerking met een bestaande leverancier van groot belang om samenwerking met bestaande systemen mogelijk te maken.

"Zorg dat je niet in de problemen komt met je data!"

Heb je nog een tip voor mensen die zo’n app maken?

Zorg dat je niet in de problemen komt met je data! Als je een app wilt ontwikkelen dan gaat het 1^e gesprek meestal over de app zelf en niet de techniek. Maar daar moet zeker al dieper op ingegaan worden tijdens het 2^e gesprek.

Stel jezelf dan de vraag: is er wel een mogelijkheid voor die app om de gegevens te krijgen? Dat moet je écht in het begin van je app al weten. Niet pas in week 6 als de app moet gaan communiceren met de systemen. Daarom moet je zo snel mogelijk uitsluitsel over de gegevens hebben. Hoe eerder technische mensen zoals een app programmeur en software leverancier van bestaande systemen met elkaar in contact komen, hoe beter!

Kortom, hoe maak je een app die toegang heeft tot andere systemen? Zorg voor samenwerking met technische partijen en een API.

Samenwerken met een app programmeur

Hopelijk ben je dankzij Bas en dit artikel meer te weten over apps in samenwerking met systemen.

Het is goed om te weten hoe een samenwerking tussen de app-ontwikkelaar en jouw bedrijf in zijn werking gaat. Daarvoor gebruik je de PDF '20 tips voor zakendoen met app-ontwikkelaars'. Vul hieronder je gegevens in om deze PDF te ontvangen:

Ik geloof dat je app succesvol wordt, als je waarde creëert. Daarom stuur ik alleen waardevolle e-mails. Hoe? Dat lees je in de Privacy Statement.

Op het succes van jouw app-droom!