Door: Harmen van der Veer
Ben je van plan nieuwe software aan te schaffen, dan kijk je natuurlijk als eerste naar hoe goed de software zijn doel bereikt. Een boekhoudpakket moet gemakkelijk en betrouwbaar zijn, een ERP-pakket moet al je bedrijfsprocessen ondersteunen en analytics-software moet privacyvriendelijk en inzichtelijk zijn. Veel organisaties vergeten één ander, zeer belangrijk, aspect: hoe goed is de data uit de applicatie te ontsluiten?
Veel moderne applicaties bieden tegenwoordig ingebouwde tooling aan om een mooi, overzichtelijk dashboard te maken. Dit juichen wij als Datalab enorm toe. Maar vaak is dit ook onvoldoende: inzicht komt vaak pas nadat databronnen gecombineerd worden. Zo kun je, door de voorraden uit je ERP-pakket te vergelijken met de boekhouding, een goede inschatting van de financiële situatie van je bedrijf schetsen. Zonder de boekhouding heb je alleen de voorraden en zonder het ERP-pakket heb je alleen de financiële situatie (zoals die in het verleden — boekhoudpakketten kijken immers vrijwel uitsluitend terug) was.
Met andere woorden: data combineren is essentieel. Daarvoor zijn twee zaken belangrijk:
- Het bij de data kunnen — van alle relevante bronsystemen
- Het uniformeren van die data in een goed datamodel
Over het tweede punt -uniformeren van data- volgt later een specifiek blog.
Data uit een bron ontsluiten: de mogelijkheden
Grofweg zijn er twee manieren waarop je bij de data uit een applicatie kunt:
- Via een API. Dit is een application programmable interface, een manier waarop je -volgens vaak ietwat onhandige- standaarden bij de data kunt. API’s kun je gebruiken om data te ontsluiten, maar ook om data toe te voegen.
- Via rechtstreekse toegang tot de database achter de applicatie. Dit is een fijne, maar storingsgevoelige manier van ontsluiten. De software is constant in ontwikkeling en daarbij zal een ontwikkelaar niet jouw belangen meewegen in hoe hij of zij de database vormgeeft en dus, naar gelang de functionaliteit of de versies van de onderliggende software dit vereisen, de databasestructuur veranderen.
Koop je een nieuwe applicatie en wil je data ontsluiten via de API, check dan een paar zaken goed. Natuurlijk of een API aanwezig is (dat is bijna altijd wel het geval), maar ook de volgende zaken:
- Is er een API beschikbaar? En zijn daar extra kosten aan verbonden?
- Hoe is de beveiliging (authenticatie) ingeregeld? Is er überhaupt degelijke beveiliging (we zijn weleens APIs tegengekomen die onbeveiligd klantgevens uitspuwden…) Kun je zelf access tokens aanmaken, of moet je hier contact met de ontwikkelaars voor opnemen? Worden moderne standaarden (bijvoorbeeld oAuth2.0) gebruikt?
- In welk formaat spuwt de API gegevens uit? Meestal is dit JSON, soms XML. Onze voorkeur gaat uit naar het eerste formaat.
- Zijn de gegevens compleet?
- Zijn alle records voorzien van een primary key (=een unieke sleutel die een record identificeert)? Helaas komen we maar al te vaak APIs tegen die geen unieke sleutel hebben of teruggeven. Gevolg is dat data zeer lastig, of helemaal niet, te koppelen is.
- Zijn records voorzien van foreign keys (= verwijzingen naar andere records, bijvoorbeeld een record van een product in een winkelshop dat verwijst naar de productcategorie). Ook al zo’n heikel punt dat vaak in de praktijk matig uitgewerkt is.
Als bovengenoemde zaken niet goed zijn geregeld, wordt het ontsluiten van data moeilijk of veel minder waardevol.
Data up-to-date houden, vaak vergeten
Data-ontsluiten is niet iets eenmaligs. We willen tenslotte data in het bronsysteem up-to-date houden met data in een analytics datawarehouse. Een API die matig in elkaar zit, biedt vaak alleen maar de mogelijkheid om álle data (of nog vervelender: alle records los) op te halen. Dit betekent dat je telkens alle data ophaalt, wat bijzonder kostbaar is. Bij grote systemen is je data hierdoor nooit volledig up-to-date, omdat het simpelweg te lang duurt voordat alle data binnen is.
Het is daarom handig als de API ondersteuning heeft voor incremental loads. Dit wordt vaak op één van twee manieren geïmplementeerd. De eerste, minder charmante, methode is het laden van data met behulp van een filter. Je filtert bijvoorbeeld op ‘alle records gewijzigd ná datum X’, waarbij X de datum is van het nieuwste record in je datawarehouse. Dit lijkt handig, maar is het niet helemaal: records die verwijderd zijn komen vaak niet terug en moet er dus alsnog een tijdrovende full load gedaan worden.
Beter is het als een API een sync– of batch-logica ondersteunt. In dit geval geeft een API óók terug wat er verwijderd is na een bepaalde datum. Dat maakt het een stuk eenvoudiger om je analytische data goed op orde te houden.
👉🏾 Een voorbeeld van een zeer degelijk opgezette API is die van boekhoudpakket Exact Online.
Onze voorkeur
Bij Datalab geven we, ondanks dat API’s stabiliteit geven, de voorkeur aan het ontsluiten door rechtstreeks met de database te ‘praten’. Ondanks dat dit soms wat extra werk inhoudt bij nieuwe softwareversies, is het sneller en makkelijker te implementeren. Helaas lukt dit zelden bij cloudsoftware, omdat de mogelijkheid hiertoe ontbreekt zodat je toch bent aangewezen op API’s.
Afbeelding gegeneerd door DALL-E, op basis van de fresco’s van ‘L’Allegoria ed Effetti del Buono e del Cattivo Governo’ (Lorenzetti; getoond in Siena, Italië), welke verwijzen naar een goede vorm van regeren en een slechte vorm van regeren. Maar dan dus toegepast op goede APIs versus slechte APIs.