Een eenvoudige vraag die regelmatig gesteld wordt, zeker vanuit businesszijde. Toch is het antwoord hierop niet altijd even simpel. Zeker niet met het oog op kosten versus baten. Systemen, bedrijfsprocessen, toekomst en schaalbaarheid zijn namelijk van grote invloed op de complexiteit van de interface en dus op de kosten. In dit blog een aantal overwegingen die kunnen helpen om deze vraag toch verantwoord te kunnen beantwoorden.

Verschillende doelen, concepten en modellen

Ieder systeem is oorspronkelijk ontworpen met een bepaald doel in gedachten. Zo is een ‘warehouse managementsysteem’ ontwikkeld om de goederenstroom in het magazijn te ondersteunen. Optimaliseert een ‘advanced planning system’ het planningsproces. En automatiseert een ‘verkoopsysteem’ de taken die horen bij het verkoopproces. Dit heeft als gevolg dat al deze systemen volgens verschillende filosofieën en datamodellen zijn gebouwd. Bij het koppelen van deze systemen is het ontwikkelen van de interface zelf dan ook niet het grootste probleem; de uitdaging is het op een juiste manier samenbrengen van de verschillende concepten en modellen, ofwel het mappen van datamodellen. Vaak een tijdrovend en dus kostbaar karwei.

Common Data Model

Om de tijd die nodig is voor het mappen van de datamodellen te verkorten, kan gebruik gemaakt worden van een Common Data Model of Canonical Data. Dat houdt in dat wanneer applicatie A aan zowel applicatie B als C gekoppeld moet worden, er niet twee koppelvlakken gedefinieerd worden (A naar B en A naar C), maar één koppelvlak (A naar B, C, D, etc.) dat voor alle te koppelen applicaties gebruikt kan worden. Als uiteindelijk alle pakketten uitgerust zijn met een standaard koppelvlak, kunnen pakketten eenvoudig vervangen worden, zonder steeds opnieuw interfaces te ontwerpen. Zeker wanneer de koppelvlakken ook nog eens hergebruikt kunnen worden op andere locaties, zijn de kosten snel terugverdiend.

Bedrijfsproces en belangen

Of het vanuit financieel oogpunt de moeite waard is om voor één specifieke applicatie een standaard koppelvlak (Common Data Model) te ontwikkelen, is nog maar de vraag. Hoe lang blijft het pakket nog in gebruik? Gaan we dit pakket vaker en op andere locaties inzetten? Waar in het bedrijfsproces wordt de software ingezet en tussen welke applicaties zijn koppelingen dan handig? Juist het bedrijfsproces speelt in deze overwegingen een grote rol. Om de juiste systemen aan elkaar te koppelen en inconsistente en onbeheersbare data te voorkomen, dient de informatie namelijk daar te worden opgehaald waar deze primair is vastgelegd. Een interface van A naar B en vervolgens van B naar C kan zomaar leiden tot een enorme onoverzichtelijke brij van systemen en interfaces.

API in plaats van interfaces?

De term API (Application Programming Interface) wordt steeds populairder. Ook aan businesszijde. Geen dure interfaces meer ontwikkelen maar ‘gewoon’ gebruik maken van een API, dat is de wens. Uiteindelijk zal alles toebewegen naar API’s, maar voorlopig is de wereld nog niet zo ver. Naast software die samenwerkt met API’s bestaan er vandaag de dag namelijk nog altijd de zogenaamde legacysystemen en op webservices gebaseerde systemen. Zomaar alle huidige software vervangen in het kader van interfaces is geen reële optie. Er bij de selectie van nieuwe software al wel rekening mee houden des te meer.

Van legacy naar SOA…

Bij een legacysysteem (bijvoorbeeld veel ERP-systemen) kunnen de verschillende onderdelen uit de software niet worden losgekoppeld. Een interface ontwikkelen naar een ander systeem is dan ook per definitie complex en maatwerk. Als een gevolg hiervan, ontstonden eind jaren negentig van de vorige eeuw Service Oriented Architectures (SOA), die met webservices werken. Een service is dan bijvoorbeeld inkoop of verkoop. Een flinke stap vooruit in systeemintegratie, maar in grote organisaties met veel applicaties leverde ook dat nog altijd een heel ingewikkeld bouwwerk op.

…van SOA naar API

Daarom zijn vervolgens de API’s ontwikkeld. Kleine stukjes die zich richten op één object. Een object is bijvoorbeeld een inkoopfactuur, een leverancier, een verkoopfactuur of een klant, ook wel microservices genoemd. Zo’n microservice kent vier opties: create, read, update en delete. Zo kunnen ook in hele grote en complexe organisaties eenvoudig allerlei functionaliteiten aan elkaar gekoppeld worden en blijven systemen up-to-date, omdat wanneer informatie op één plek wordt gewijzigd, deze op alle andere plekken mee verandert.

Zolang we nog te maken hebben met deze drie generaties systemen, zal de vraag of we hier een interface voor kunnen ontwikkelen niet zomaar te beantwoorden zijn. De mogelijkheden zijn er. Maar om te kunnen bepalen welke optie in welke situatie het meest geschikt is, moeten bedrijfsprocessen inzichtelijk gemaakt worden en kosten en baten geanalyseerd. Een uitdaging, maar wel een die de moeite meer dan waard kan zijn.