In eerste instantie lijkt dat prima beheersbaar. Totdat dat niet meer zo is.
Het probleem zit niet per se in het aantal systemen, maar in de manier waarop ze met elkaar verbonden zijn.
De valkuil van point-to-point-integraties
Een veelgebruikte aanpak voor integraties is om systemen rechtstreeks met elkaar te verbinden zodra er een nieuwe koppeling nodig is.
Systeem A communiceert met systeem B.
Systeem B communiceert met systeem C.
Systeem A heeft ook informatie uit systeem C nodig, dus wordt er nog een koppeling gemaakt.
Zolang het om een beperkt aantal systemen gaat, werkt dit prima. Maar naarmate het aantal applicaties groeit, neemt ook het aantal mogelijke verbindingen snel toe.
En met iedere nieuwe koppeling komt er weer een stukje logica bij dat onderhouden moet worden.
Zo ontstaat een herkenbaar probleem: integratie verandert in een verzameling individuele oplossingen in plaats van een samenhangende architectuur.
Een wijziging in één systeem kan plotseling gevolgen hebben voor meerdere andere systemen. Gegevens worden op verschillende plekken op een andere manier getransformeerd. Bedrijfsregels worden dubbel geïmplementeerd. Monitoring raakt versnipperd. En wanneer er iets misgaat, is het lastig te achterhalen waar het probleem precies is ontstaan.
Het resultaat is een IT-landschap dat steeds moeilijker aan te passen wordt.
Integratie moet een architectuur zijn, geen verzameling koppelingen
Het alternatief is om integratie te beschouwen als een afzonderlijke architectuurlaag. In plaats van ieder systeem rechtstreeks met alle andere systemen te laten communiceren, worden verantwoordelijkheden duidelijk gescheiden. Systemen blijven verantwoordelijk voor datgene waar ze goed in zijn.
Salesforce kan bijvoorbeeld het centrale platform blijven voor klant- en orderbeheer. Leveranciers blijven verantwoordelijk voor hun eigen product- en fulfilmentinformatie. Een specifieke integratielaag verzorgt de communicatie, datatransformatie, orkestratie en monitoring.
Dat zorgt voor een veel beter beheersbare structuur.
Bij Infodation hebben we deze aanpak toegepast bij het inkoopautomatiseringsplatform dat we voor Hallo Nederland hebben ontwikkeld.
De architectuur combineert Salesforce, op Azure gebaseerde middleware en OneTrail TPN om Hallo te verbinden met meerdere distributeurs.
Het doel was niet simpelweg om negen leveranciers te koppelen. Het doel was om een integratiearchitectuur te ontwikkelen die ook in de toekomst verder kan groeien.
Een canoniek datamodel als fundament
Een van de belangrijkste architectuurkeuzes is het vastleggen van een gemeenschappelijk datamodel. Iedere leverancier kan producten, prijzen, voorraadniveaus, orders, verzendingen en facturen op een andere manier weergeven.
Als Salesforce ieder leveranciersspecifiek formaat moet begrijpen, verplaatst de complexiteit zich al snel naar het centrale bedrijfsplatform. In plaats daarvan kan de integratielaag verschillende externe formaten vertalen naar één gemeenschappelijke, canonieke representatie.
Een distributeur kan bijvoorbeeld op een heel andere manier beschikbare voorraad weergeven dan een andere distributeur. De integratielaag normaliseert deze informatie, zodat de rest van de applicatie niet hoeft te weten welke leverancier de gegevens oorspronkelijk heeft aangeleverd.
Dit zorgt voor een belangrijke scheiding:
Externe systemen kunnen veranderen zonder dat daardoor de volledige architectuur aangepast hoeft te worden.
Dat is een krachtig uitgangspunt bij het ontwikkelen van software die moet kunnen meegroeien.
Standaardisatie vermindert complexiteit
Hetzelfde principe geldt voor communicatie. Binnen het Hallo-platform biedt OneTrail TPN een gestandaardiseerde, op XML gebaseerde communicatielaag voor berichten zoals orders, verzendbevestigingen, facturen en productinformatie.
Hierdoor heeft het platform niet voor iedere distributeur een volledig andere integratiemethode nodig. De complexiteit van externe systemen wordt opgevangen aan de integratiegrens.
De interne architectuur kan daardoor consistent blijven.
Dat is een van de belangrijkste voordelen van standaardisatie: het elimineert complexiteit niet, maar zorgt ervoor dat die op de juiste plek wordt ondergebracht.
Middleware als orkestratielaag
Een moderne integratiearchitectuur heeft meer nodig dan alleen datatransformatie.
Er is ook orkestratie nodig. Binnen de oplossing voor Hallo biedt de Azure-middleware verschillende componenten, waaronder een canonieke productdatabase, een servicebus, een fulfilmentengine en monitoringmogelijkheden.
Met deze componenten kan het platform een volledig bedrijfsproces coördineren, in plaats van alleen berichten tussen systemen door te sturen.
Neem bijvoorbeeld een klant die een bestelling plaatst.
Het platform moet bepalen welke leverancier de bestelling kan leveren. Daarbij moet rekening worden gehouden met factoren zoals prijs, beschikbare voorraad en historische leverbetrouwbaarheid.
Zodra een leverancier is geselecteerd, moet de inkooporder worden aangemaakt en verstuurd.
Vervolgens moet het systeem orderbevestigingen verwerken, wijzigingen en annuleringen afhandelen, verzendinformatie ophalen, leveringen volgen en uiteindelijk de factuur controleren en matchen.
Dat is niet langer alleen een integratie. Het is een proces. En de architectuur moet dat proces van begin tot eind ondersteunen.
Van integratie naar procesorkestratie
Dit onderscheid is belangrijk.
Een API-integratie beantwoordt een relatief eenvoudige vraag:
Hoe krijg ik gegevens van systeem A in systeem B?
Procesautomatisering stelt een veel bredere vraag:
Wat moet er in verschillende systemen gebeuren om een bedrijfsproces volledig af te ronden?
Dat zijn fundamenteel verschillende uitdagingen.
Binnen het Hallo-platform loopt het proces van:
Offerte → Klantorder → Slimme inkoop → Inkooporder → Orderbeheer → Verzending → Levering → Factuur
Iedere stap is afhankelijk van informatie uit voorgaande stappen en kan acties in andere systemen activeren.
Een robuuste integratiearchitectuur maakt deze afhankelijkheden inzichtelijk en beheersbaar.
Monitoring is onderdeel van de architectuur
Er is nog een aspect dat vaak over het hoofd wordt gezien: inzicht.
Wanneer een proces meerdere systemen doorkruist, zijn fouten onvermijdelijk.
Een leverancier reageert misschien niet. Een bericht wordt afgekeurd tijdens de validatie. Een order wordt geweigerd. Of een verzendbericht bevat onverwachte gegevens.
Zonder centrale monitoring wordt het oplossen van problemen een handmatig onderzoek in verschillende systemen.
Met goede monitoring kunnen teams zien wat er is gebeurd, waar het proces zich op dat moment bevindt en waar een eventuele fout is ontstaan.
Dat is vooral belangrijk wanneer automatisering bedrijfskritisch wordt.
Hoe meer processen een organisatie automatiseert, hoe minder acceptabel het wordt om erop te vertrouwen dat medewerkers problemen toevallig ontdekken.
Ontwerp voor de volgende leverancier, niet alleen voor de huidige
Een goede integratiearchitectuur moet ervoor zorgen dat de volgende integratie eenvoudiger wordt dan de vorige.
Dat was een van de belangrijke ontwerpprincipes achter de oplossing voor Hallo.
Het platform is opgebouwd uit herbruikbare componenten en een gestandaardiseerde integratielaag. Hierdoor kunnen nieuwe leveranciers worden toegevoegd zonder dat de volledige architectuur opnieuw ontworpen hoeft te worden.
Het voordeel is niet alleen technisch. Het heeft direct invloed op de snelheid waarmee een organisatie haar ecosysteem kan uitbreiden.
Een nieuwe leverancier toevoegen moet vooral een kwestie worden van configuratie en onboarding, in plaats van een compleet nieuw softwareontwikkeltraject.
Daarbij is wel een belangrijke nuance: de configuratie van een leverancier in Salesforce kan aanzienlijk worden teruggebracht, maar de volledige onboarding omvat nog steeds netwerkregistratie, validatie en het daadwerkelijk live brengen van de koppeling.
De genoemde tijd van één minuut heeft daarom specifiek betrekking op de configuratiestap in Salesforce, en niet op het volledige onboardingproces.
Architectuur creëert ruimte om te groeien
De resultaten van de implementatie bij Hallo laten zien waarom dit belangrijk is.
Het platform is gekoppeld aan 10 distributeurs en meer dan 300.000 producten. Voorraadinformatie wordt ieder uur bijgewerkt en in de eerste maand werden al meer dan 100 inkooporders van begin tot eind gevolgd.
Tegelijkertijd is de handmatige verwerkingstijd per orderregel teruggebracht van ongeveer 28 minuten naar slechts 2 à 3 minuten. Dat betekent ongeveer 90% minder handmatig werk.
Daarnaast is het aantal handmatige processtappen met ongeveer 80% verminderd en is de operationele capaciteit met een factor tien toegenomen.
Deze cijfers zijn niet simpelweg het resultaat van het koppelen van systemen. Ze zijn het resultaat van een integratiearchitectuur die is ontworpen rondom het bedrijfsproces.
De werkelijke waarde van integratiearchitectuur
Integratiearchitectuur wordt soms gezien als een puur technische aangelegenheid. Maar de impact ervan is in de kern een bedrijfskundige kwestie.
Een goed ontworpen integratielaag stelt organisaties in staat om:
- Nieuwe systemen toe te voegen zonder dat de complexiteit zich opstapelt.
- Gegevens uit verschillende bronnen te standaardiseren.
- Processen over organisatiegrenzen heen te automatiseren.
- Bedrijfsprocessen van begin tot eind te monitoren.
- Handmatig werk te verminderen.
- Wijzigingen door te voeren zonder het volledige IT-landschap te destabiliseren.
- De operationele capaciteit te vergroten zonder dat de hoeveelheid handmatig werk in hetzelfde tempo meegroeit.
Dat is het verschil tussen integraties hebben en beschikken over een integratiearchitectuur.
Het eerste verbindt systemen. Het tweede creëert een fundament waarop de organisatie verder kan bouwen.
Bouw de architectuur voordat de complexiteit zichzelf opbouwt
De meeste integratieproblemen ontstaan niet van de ene op de andere dag. Ze ontwikkelen zich geleidelijk.
Eén API hier. Een maatwerkscript daar. Een tijdelijke workaround die uiteindelijk permanent wordt.
Voor je het weet, zijn al die individuele oplossingen samen de architectuur geworden.
Een betere aanpak is om bewust voor een architectuur te kiezen voordat dat gebeurt.
Bepaal waar bedrijfslogica thuishoort. Leg een canoniek datamodel vast. Standaardiseer de communicatie. Scheid systemen van orkestratie. Centraliseer de monitoring. En bouw herbruikbare integratiecomponenten.
Zo ontstaat een IT-landschap dat niet alleen verbonden is, maar ook daadwerkelijk beheersbaar blijft.
En wanneer de organisatie groeit, kan de technologie met haar meegroeien.
