Wat integratiemonitoring moet detecteren
Op een normale dinsdag verwerkt een webshop 400 bestellingen. De systeemintegratie die deze naar het ERP verplaatst, levert er 380 af en wijst er 20 af, omdat een nieuwe kortingscode een veld genereerde dat het ERP niet accepteerde.
Er ging niets offline. Er ging geen alarm af. Het magazijn pakt wat het kan zien, de financiële afdeling rapporteert over wat het grootboek heeft bereikt, en 20 klanten wachten op bevestigingen die nooit zullen komen. Elk systeem was de hele tijd online, en dat is precies waarom uptime de verkeerde graadmeter is.
- Records die door de bestemming zijn geweigerd: een bestelling of product dat is geweigerd vanwege een validatiefout; dit is een zakelijke fout in plaats van een technische.
- Volumes die zijn gedaald zonder te stoppen: een stroom die normaal 400 bestellingen verwerkt, maar er nu 380 verwerkt; dit ziet er prima uit, maar is het niet.
- Data die is aangekomen, maar onjuist is: een veld dat na een wijziging aan een van beide kanten onjuist is gekoppeld, waardoor de bestemming een waarde accepteert die niet klopt.
- Stromen die nooit zijn uitgevoerd: een geplande taak die niet is gestart; dit levert geen foutmelding op omdat er simpelweg niets is gebeurd.
- Data die te laat is aangekomen: een voorraadcijfer dat de winkel bereikt nadat iemand het laatste exemplaar al heeft verkocht.
De vierde categorie is wat de meeste monitoringsystemen missen. Een taak die nooit draait, stuurt geen signaal uit, dus alleen een systeem dat let op het uitblijven van een actie zal dit opmerken.
Waarom blijven systeemintegratiefouten onzichtbaar?
De belangrijkste reden is dat er nergens is om toezicht te houden. Wanneer een systeemintegratie rechtstreeks tussen twee applicaties wordt gebouwd, kent deze alleen zijn eigen status en niets anders. Een bedrijf dat veertig van dergelijke koppelingen gebruikt, heeft veertig afzonderlijke plekken om te controleren en geen enkel overzicht dat ze allemaal omvat. Dat is een van de verborgen kosten van point-to-point-integratie, en die staan zelden in de kostenraming voor de bouw.
Bevestigingen zijn ook misleidend. Wanneer een ontvangend systeem reageert met een succesmelding, betekent dit meestal dat het bericht is geaccepteerd, niet dat het record correct is verwerkt. Een record kan dus als afgeleverd worden gemarkeerd terwijl het aan de andere kant in geen enkele bruikbare vorm bestaat.
De derde reden is eigenaarschap. Het team dat het ERP beheert, houdt het ERP in de gaten. Het e-commerce-team houdt de webshop in de gaten. De verbinding daartussen is van degene die hem heeft gebouwd, en die is misschien al vertrokken. Dat gat is de plek waar fouten het langst onopgemerkt blijven, omdat het niemands dashboard is.
Een stille fout wordt dus niet alleen niet opgemerkt. Hij wordt niet opgemerkt op de enige plek waar niemand kijkt.
Wat zwakke integratiemonitoring kost
De kosten hangen af van hoe lang een fout aanhoudt voordat iemand het merkt.
- Klanten als alarm: de eerste melding komt van iemand wiens bestelling niet is aangekomen, wat de duurste manier is om erachter te komen
- Achterstanden die niemand ziet groeien: een storing van drie dagen laat drie dagen aan records achter die opnieuw verwerkt moeten worden
- Beslissingen op basis van onvolledige gegevens: een rapport of een voorraadbestelling die wordt gedraaid op een dataset waarin alles ontbreekt wat via de defecte stroom had moeten binnenkomen
- Diagnose gemeten in dagen: zonder overzicht van wat wanneer is verplaatst, betekent het vinden van de foutieve stap dat elk systeem één voor één moet worden gecontroleerd
- Verloren vertrouwen binnen het bedrijf: na één stille fout verschijnen er handmatige controles naast de automatisering
Die laatste blijft na het incident bestaan. Alles wordt hersteld, maar de handmatige controle blijft.
Waarom integratiemonitoring iets anders is dan uptime
Infrastructuurmonitoring stelt de vraag of systemen beschikbaar zijn en reageren. Dat is een terechte vraag, en het brengt storingen aan het licht die anders ook wel opgemerkt zouden worden.
Integratiemonitoring stelt een andere vraag. Zijn de bestellingen van vandaag in het ERP-systeem aangekomen? Is elke prijswijziging doorgevoerd? Heeft elke verzendbevestiging de marktplaats op tijd bereikt? Dat zijn vragen over data in plaats van beschikbaarheid, en een landschap kan slagen voor de eerste test terwijl het voor alle drie de andere punten faalt.
Om deze vragen te beantwoorden moet je weten wat er had moeten gebeuren, niet alleen wat er daadwerkelijk is gebeurd. Een systeem dat fouten rapporteert, kan niemand vertellen over 20 bestellingen die hadden moeten aankomen maar dat niet deden, omdat er geen foutmelding was. Monitoring die het normale verloop van een proces kent, kan dit gat als eerste signaleren. Dat is een andere discipline dan monitoring en logging als beveiligings- en auditfunctie.
Er zijn drie veelgebruikte benaderingen, elk met een blinde vlek. Infrastructuurtools kijken naar beschikbaarheid en weten niets over de vraag of een record is geaccepteerd. Logging die in elke verbinding is geschreven, werkt alleen voor die specifieke verbinding. Wachten op klachten is de standaard, en dat is de reden waarom stille fouten dagenlang onopgemerkt blijven.
Hoe maakt een integratieplatform stromen inzichtelijk?
Een Integration Platform-as-a-Service (iPaaS) verbindt systemen via één centrale hub in plaats van elk paar direct aan elkaar te koppelen. Elk systeem maakt één keer verbinding met het integratieplatform. Het platform verplaatst vervolgens data tussen de systemen, past de vorm onderweg aan en levert elk doel de gewenste indeling.
Het centraliseren van verbindingen maakt monitoring mogelijk. Elke stroom passeert nu één plek, dus er is eindelijk een centraal punt om toezicht te houden. Het integratieplatform verwerkt elk bericht al, dus het vastleggen van de inhoud, de bestemming en of de ontvanger het heeft geaccepteerd, kost geen extra moeite.
Alumio is een integratieplatform dat op dat principe is gebouwd, waarbij zichtbaarheid in de laag zelf zit in plaats van dat het achteraf is toegevoegd. Binnen het Alumio-integratieplatform krijgt dit vier vormen.
- Zichtbaarheid op berichtniveau: de Inspection Tool binnen Alumio toont de inhoud van individuele berichten en waar elk bericht is gestopt, zodat de diagnose begint bij bewijs in plaats van bij een gok
- Fouten opnieuw proberen, daarna escaleren: korte fouten worden automatisch opnieuw geprobeerd en hardnekkige fouten genereren een melding, zodat een kortstondige storing zichzelf oplost en een echt probleem de juiste aandacht krijgt
- Vastgehouden in plaats van verloren: een ingebouwde opslagwachtrij bewaart records die de bestemming niet kon accepteren, zodat er niets verloren gaat terwijl het probleem wordt opgelost en gecorrigeerde records achteraf alsnog kunnen worden verzonden
- Eén overzicht voor alle stromen: dashboards, gedetailleerde logs en audittrails die alle integraties dekken in plaats van dat elke verbinding afzonderlijk rapporteert
Sommige bedrijven vragen hier vooraf om. Heusinkveld, een Nederlandse fabrikant van sim-racing hardware die verkoopt via wederverkopers en een eigen WooCommerce-webshop, stelde drie eisen toen het overstapte op Odoo als ERP-systeem. De webshop moest gekoppeld worden aan het nieuwe ERP, er was controle nodig over welke producten en voorraadniveaus werden gesynchroniseerd, en er moesten aangepaste monitoring-alerts komen. In samenwerking met Odoo- en iPaaS-specialist BlueZebra implementeerden zij het integratieplatform Alumio om aan al deze drie eisen te voldoen. Monitoring werd direct meegenomen in de scope, in plaats van als reparatie na de eerste storing.
Detectie is slechts het halve werk. Zodra er iets misgaat, toont de Inspection Tool de data bij elke stap van de flow. De stap die fout ging is direct zichtbaar, in plaats van dat deze uit logbestanden moet worden samengesteld. Gepland onderhoud kan worden ingepland zodat verwachte downtime geen meldingen genereert; dit voorkomt dat een team leert om meldingen te negeren.
Omdat die zichtbaarheid bij het integratieplatform zelf hoort, is een nieuwe integratie vanaf de dag dat deze live gaat volledig inzichtelijk.
Wat integratiemonitoring oplevert voor de business
Monitoring wordt vaak gezien als een bijzaak, waardoor het pas als laatste wordt gespecificeerd en gefinancierd nadat de integraties zijn gebouwd. Het heeft echter een directe invloed op de mate waarin een bedrijf bereid is om te automatiseren.
Drie rollen dragen de gevolgen. De IT-manager moet een storing uitleggen zonder dat er een overzicht is van wat er is verwerkt. De klantenservice-manager hoort het als eerste en heeft geen antwoord voor de klant. De operations-manager houdt een handmatige controle naast de automatisering aan, wat betekent dat het proces nooit echt geautomatiseerd is, maar slechts gedupliceerd.
Vertrouwen is wat die handmatige controle overbodig maakt. Storingen worden gevonden door een alert in plaats van door een klant, en de diagnose duurt slechts minuten omdat de berichtgeschiedenis al beschikbaar is. Een integratieplatform zorgt ervoor dat dit de standaardstatus is voor een nieuwe flow, in plaats van een project dat er achteraf aan wordt toegevoegd.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
