Het probleem was nooit het koppelen van systemen
Vraag het aan iedereen die een integratieproject heeft geleid en je krijgt dezelfde frustratie te horen. Aan de oppervlakte lijkt het technisch, maar daaronder is dat zelden het geval.
“Het was nooit de technologie,” zegt Caspar, CEO van Alumio. “Het waren altijd de mensen in de organisatie. De IT-manager die de poorten niet wilde openen, of die geen helder beeld had van hoe alles in elkaar greep.”
Het loodgieterswerk zelf was meestal alledaags. Oude systemen werden vaak verkocht als moeilijk te koppelen, maar de realiteit viel mee. “Oudere software werd verkocht alsof koppelen ongelooflijk ingewikkeld was,” zegt Caspar. “Het kwam bijna altijd op hetzelfde neer: een bestand op een server of een SOAP-verbinding. En dan dacht ik: iemand heeft dit veel ingewikkelder gemaakt dan nodig was.”
Als het technische werk beheersbaar was, lag de moeilijkheid ergens anders. Die zat in de organisatie en in wat er gebeurde nadat de integratie live ging.
Hoe integratie-afhankelijkheid er in de praktijk uitziet
Wanneer een bedrijf een maatwerk-integratie bouwt, krijgt het niet alleen een werkende koppeling. Het erft een reeks afhankelijkheden waar op dat moment zelden rekening mee wordt gehouden.
De eerste is de afhankelijkheid van de bouwer. De logica zit in het hoofd van één ontwikkelaar of in code die alleen zij begrijpen. Wanneer zij vertrekken, verdwijnt de kennis met hen. Dit wordt vaak het 'key man risk' genoemd: het gevaar dat cruciale kennis bij één persoon ligt. Caspar heeft dit vaker gezien bij middelgrote productiebedrijven. “Alles was door één persoon gebouwd, en die persoon vertrok.” De systemen bleven draaien, maar niemand binnen het bedrijf begreep ze nog.
De tweede is de afhankelijkheid tussen de systemen zelf. Point-to-point-verbindingen raken na verloop van tijd zo verstrengeld dat een systeem niet meer kan worden vervangen zonder de andere te breken. Het vervangen van een ERP is dan geen project meer, maar een risico dat niemand wil nemen.
De derde is de afhankelijkheid van het verleden. Omdat verandering riskant voelt, blijven bedrijven architectuur gebruiken die ze allang zijn ontgroeid. “Bedrijven vroegen zich niet af hoe ze een fundament konden leggen waarop ze jaar na jaar konden voortbouwen,” zegt Caspar. “Ze bouwden het gewoon opnieuw, en een paar jaar later weer.”
De rekening komt later, en het is niet alleen geld
De kosten van integratie-afhankelijkheid zijn makkelijk te negeren omdat ze niet als aparte post op de balans staan. Ze komen langzaam naar boven, op manieren die moeilijk te herleiden zijn naar de bron.
Caspar beschrijft koppelingen met magazijnbeheersystemen die om de paar weken uitvallen en dan een uur of langer platliggen. Hele teams kunnen niet werken totdat het weer werkt. Wat opvalt is niet de storing zelf, maar dat het bedrijf het als normaal is gaan beschouwen. De hosting staat op een vage cloud-factuur. De downtime zit in verloren uren. Geen van beide wordt gelabeld als “afhankelijkheid”, maar beide zijn reëel.
Dit is waarom het gesprek niet langer alleen bij IT plaatsvindt. Investeerders en kopers stellen andere vragen. Wie kan dit onderhouden als het huidige team vertrekt? Wat is er daadwerkelijk gedocumenteerd? Wat zou het een koper kosten om dit over te nemen? Integratie-architectuur is onderdeel geworden van due diligence, en ongedocumenteerd maatwerk is een van de zaken die direct opvalt. Het praktische gevolg is dat het professionaliseren van de integratielaag niet langer alleen een IT-verbetering is. Het is onderdeel van het verkoopbaar maken van een bedrijf, en het betrekt de eigenaar en de CFO bij een discussie die voorheen alleen bij IT lag. Dezelfde vragen komen aan de andere kant van de tafel naar voren tijdens post-merger integratie.
Maar de grootste kostenpost is tijd. “Er is voor elk bedrijf eigenlijk maar één vijand, en dat is tijd,” zegt Caspar. “Als geld niet de beperkende factor is, wordt het eigenlijk gevaarlijker, omdat mensen accepteren dat dingen onnodig lang duren.” Een bedrijf dat niet op de snelheid van de markt kan bewegen, heeft een serieus probleem, en afhankelijkheid is wat het vertraagt.
De afhankelijkheden wegnemen die maatwerk-integraties creëren
Het antwoord is niet om betere maatwerk-integraties te bouwen. Het is om de afhankelijkheden te vermijden die maatwerk-integraties in de eerste plaats creëren. Dat betekent veranderen waar de integratielogica zich bevindt, niet hoe goed deze is geschreven.
Dit is waar een integration platform-as-a-service (iPaaS) het verschil maakt. Het Alumio iPaaS is een cloud-native, config-first platform dat bedrijfssystemen verbindt via een centrale laag, in plaats van via eenmalige maatwerkkoppelingen tussen elk paar systemen. Elke verbinding wordt opgezet via gestructureerde instellingen in plaats van vanaf nul geschreven. Dat werkt met een kant-en-klare connector waar die beschikbaar is, en met de eigen API van het systeem waar dat niet zo is. Alumio biedt ook een Code Transformer voor ontwikkelaars die liever een edge case in code oplossen. Het punt is niet dat het platform dingen eleganter met elkaar verbindt. Het punt is wat het wegneemt.
Plaats die centrale integratielaag, en de logica van elke verbinding bevindt zich op één zichtbare, beheerde plek in plaats van in het hoofd van één ontwikkelaar. Wanneer er een bestelling wordt geplaatst in de webshop, wordt deze naar het ERP geleid, wordt de voorraad bijgewerkt en wordt de afhandeling geactiveerd. Het bedrijf kan die stroom zien en wijzigen zonder afhankelijk te zijn van degene die het oorspronkelijk heeft geschreven. Eén systeem kan worden vervangen zonder dat de andere instorten. De kennis blijft binnen de organisatie.
Er is een afweging die het benoemen waard is. Het adopteren van een platform betekent standaardiseren, en standaardiseren betekent het opgeven van een deel van de vrijheid die maatwerk biedt. Voor bedrijven die ervan overtuigd zijn dat hun processen volledig uniek zijn, kan dat voelen als een beperking. In de praktijk is het tegenovergestelde waar. Het is wat hen in staat stelt één systeem te veranderen zonder hun volledige architectuur opnieuw te hoeven onderhandelen.
Waarom afhankelijkheid nu een strategische vraag is
Niets hiervan is statisch. Hetzelfde patroon dat begon met het weghalen van logica uit de code, voltrekt zich nog steeds. Caspar heeft sinds de oprichting van Alumio gezien hoe de grond onder dit probleem is verschoven, en zijn analyse is dat het nog steeds in dezelfde richting beweegt.
“We zijn Alumio gestart om de technologie uit de code te halen,” zegt Caspar. “Nu zit de technologie niet meer in de code; het zit in een visuele laag. De volgende stap is dat de visuele laag steeds minder belangrijk wordt. Het wordt een zakelijke vraag.” Het leidingwerk verdwijnt steeds meer naar de achtergrond, en de strategische beslissing komt steeds meer op de voorgrond te staan.
AI is waar dat concreet wordt. De belofte is dat modellen en agents actie zullen ondernemen op basis van bedrijfsdata: een vraag over voorraad beantwoorden, een nabestelling triggeren, een factuur afstemmen, een rapport voorbereiden. Dat werkt alleen als de onderliggende data volledig, actueel en voorzien van de juiste rechten is, en als er een overzicht is van wat waarheen is verplaatst en waarom.
Een organisatie waarvan de integratielogica in het hoofd van één ontwikkelaar zit, kan een AI-systeem geen betrouwbare toegang geven tot de eigen operaties. Het kan achteraf ook niet controleren wat dat systeem daadwerkelijk heeft gedaan. AI neemt de integratieafhankelijkheid niet weg. Het verhoogt de prijs ervan. De bedrijven die echt waarde uit AI zullen halen, zijn de bedrijven die hun datastromen zichtbaar en beheerd hebben gemaakt voordat ze dat nodig hadden. Een beheerde integratielaag is nu een fundament in plaats van een gemak.
Bedrijven die dit vroeg inzien, krijgen bewegingsvrijheid. Ze kunnen nieuwe systemen adopteren, reageren op de markt en hun data aan het werk zetten zonder telkens het fundament opnieuw te hoeven opbouwen. Degenen die maatwerk-integraties blijven herbouwen, erven dezelfde integratieafhankelijkheid als hun voorgangers, en betalen daarvoor in de enige valuta die geen enkel bedrijf terugkrijgt. Het later ongedaan maken daarvan verloopt via een gefaseerde migratie van legacy-systemen.
Waar uw integratielogica vandaag de dag leeft
De verschuiving in de manier waarop bedrijven hun systemen koppelen, komt neer op één fundamentele verandering in wat ze proberen te kopen. Jarenlang was het doel een werkende verbinding. Het doel is nu de vrijheid om te veranderen zonder toestemming te hoeven vragen aan het verleden. Dat is niet hetzelfde. Het verschil zit in de afhankelijkheid zelf. Die ligt bij de bouwer die de kennis bezit, bij systemen die te nauw met elkaar verweven zijn om ze te scheiden, en bij beslissingen van jaren geleden die niemand meer durft te herzien.
Geen van die afhankelijkheden kondigt zichzelf aan. Ze zitten stilletjes in een landschap dat nog steeds functioneert. Dan vertrekt een sleutelfiguur, stelt een investeerder een lastige vraag, of dwingt een marktverschuiving tot een verandering die de architectuur niet kan opvangen. Tegen die tijd zijn de kosten niet langer theoretisch. Het verschil is op dat moment scherp. Een bedrijf dat zijn integratielogica zichtbaar en beheersbaar heeft gemaakt, kan bewegen. Een bedrijf dat dat niet heeft gedaan, kan alleen toekijken.
Het praktische startpunt is kleiner dan het klinkt. Breng in kaart waar uw integratielogica zich daadwerkelijk bevindt en vraag uzelf af wie deze morgen zou kunnen aanpassen als de persoon die het gebouwd heeft er niet meer is. Die ene vraag legt de afhankelijkheid bloot die de meeste bedrijven niet meer opmerken, en het verandert een onzichtbaar risico in iets waar u actie op kunt ondernemen. Het wegnemen ervan vereist niet dat u alles in één keer vervangt. Het vereist dat u bewust besluit dat de volgende verbinding die u bouwt, niet weer iets is dat slechts één persoon begrijpt.
Integratie was nooit het moeilijke deel. Wat u daarna overhoudt, is dat wel. De bedrijven die daar nu naar handelen, zijn de bedrijven die in staat zullen zijn om te bewegen wanneer het er echt op aankomt.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
