Laatste update
5 juni 2026

Auteur

Tom Mathijssen

Leestijd
5 min

 

TL;DR – In het kort

De IBM i (AS/400) is een van de meest betrouwbare platformen ooit gebouwd. Maar de integratie-architectuur eromheen is in veel organisaties jarenlang niet meegegroeid. In dit artikel lees je vijf signalen die aangeven wanneer een moderne integratielaag de volgende stap is, niet als vervanging van je IBM i maar als de brug naar de systemen eromheen.

Maandagochtend. Een nieuwe klant wil een koppeling met zijn ordersysteem. Je IT-team opent het dossier, kijkt naar de IBM i (AS/400) en zucht — niet omdat het niet kan, maar omdat het weer weken gaat duren. Intussen draait de machine gewoon door, precies zoals hij al twintig jaar doet.

En dat is ook precies waarom dit gesprek zo lastig is.

De IBM i (ook bekend als AS400, iSeries of IBM Power Systems platform) is niet het probleem. Hij is een van de meest stabiele platforms die de IT-industrie heeft voortgebracht. De grootste uitdagingen die we bij logistieke en industriële bedrijven tegenkomen, liggen dan ook niet in het platform zelf, ze liggen in de integratie-architectuur eromheen die in de loop der jaren niet is meegegroeid.

In deze blog beschrijf ik vijf signalen die we keer op keer tegenkomen. Herken je er drie of meer? Dan is het tijd voor een eerlijk gesprek over de integratielaag rond jouw IBM i (AS400) niet over het platform zelf.

Wat is een IBM i integratie-architectuur probleem?

IBM i is technisch gezien een krachtig platform. Het ondersteunt real-time verwerking via journaling, data queues en triggers op DB2. Het kan worden ontsloten via REST, SQL services en moderne API-lagen. Het draait op IBM Power Systems hardware die dynamisch kan opschalen zonder downtime.
Het probleem zit zelden in het platform, het zit in de laag eromheen.

Een IBM i integratie-architectuur probleem ontstaat wanneer de verbindingen tussen de AS400 en andere applicaties zijn gebouwd op historische implementaties: bestandsoverdrachten, batch-processen, tight coupling van bedrijfslogica en koppelingen zonder servicelaag of canonical datamodel. Die architectuur was passend voor de tijd waarin hij werd gebouwd maar groeit niet automatisch mee met nieuwe ERP-systemen, cloudplatforms, klantportalen of WMS-oplossingen.

Dit onderscheidt een architectuurprobleem van een platformprobleem: de IBM i faalt niet, de integratie-architectuur eromheen past niet meer bij de manier waarop jouw organisatie vandaag opereert.

Signaal 1: Elke nieuwe koppeling is een project op zich

IBM i ondersteunt moderne integratiepatronen via REST, API-lagen, SQL services en event-driven verwerking. Maar in veel bestaande omgevingen is die laag nooit gebouwd. Data-uitwisseling verloopt via bestandsoverdrachten of batch-processen, de bedrijfslogica zit tight coupled in de applicatie en er is geen servicelaag of canonical datamodel waarop nieuwe koppelingen kunnen aansluiten.

Het gevolg: elke koppeling die je nodig hebt, met een nieuwe klant, een nieuw platform, een nieuwe retailer is een apart traject. Niet omdat IBM i dat vereist, maar omdat de architectuur eromheen geen snelle ontsluiting mogelijk maakt.

Een herkenbaar voorbeeld: een logistieke organisatie wil een nieuw klantportaal aansluiten op het bestaande WMS. Technisch gezien kan IBM i dit faciliteren. Maar omdat de bedrijfslogica ongedocumenteerd verweven zit in de applicatielaag en er geen API-ontsluiting beschikbaar is, kostte de koppeling meerdere weken terwijl hetzelfde traject op een modern platform met een bestaande servicelaag dagen had geduurd.

De vraag om jezelf te stellen: Hoe lang duurt het gemiddeld voordat een nieuwe koppeling operationeel is? Als het antwoord “maanden” is, zit de bottleneck in je integratie-architectuur – niet in het platform.

Signaal 2: De planner werkt met data van gisteren

IBM i (AS400) is geen batch-systeem. Het platform ondersteunt al decennia real-time verwerking: interactieve jobs, data queues, message queues en journaling voor near-real-time change tracking. DB2 for i is een van de snelste OLTP-engines beschikbaar.

Maar veel organisaties hebben hun IBM i historisch ingericht met batch-processen omdat dat destijds de standaard was, niet omdat het platform het vereist. Data wordt één of meerdere keren per dag gesynchroniseerd tussen systemen.

  • Voorraadniveaus in realtime?
  • Actuele orderstatus voor de planner?
  • Directe terugkoppeling vanuit het ERP naar het WMS?

Dat is in veel implementaties niet ingericht, terwijl het platform er technisch toe in staat is. Zeker in deze tijd waarin planners ’s ochtends vroeg beslissingen moeten nemen over voorraden, routes of capaciteit, is dat geen platformbeperking maar een architectuurkeuze die herzien kan worden.

De vraag om jezelf te stellen: Op welk moment van de dag beschikken je planners over betrouwbare, actuele data? En is dat vroeg genoeg?

Signaal 3: Één of twee mensen weten hoe het systeem is ingericht

RPG is geen verouderde hacktaal. Modern RPG is free-format, SQL-heavy, volledig API-based en geschikt voor servicegeoriënteerde architectuur. COBOL op IBM i is robuust en bewezen. De programmeertalen zelf zijn niet het probleem.

Wat wél een risico vormt: de kennis over hoe het systeem is geconfigureerd, welke SQL-queries de database bevragen, hoe koppelingen zijn opgezet en waar bedrijfslogica is vastgelegd, is in veel organisaties geconcentreerd bij één of twee beheerders. Dat is geen platformprobleem maar een kennisstrategieprobleem.

Het komt overigens ook voor bij SAP ABAP-omgevingen, maatwerkapplicaties en andere specialistische platforms.
Wat dit betekent in de praktijk: als die persoon vertrekt of niet beschikbaar is, liggen ontwikkeling en koppelingen stil. De oplossing zit niet in het vervangen van het platform maar in het documenteren van de architectuur en het opbouwen van een integratielaag die de afhankelijkheid van individuele systeemkennis verkleint.

De vraag om jezelf te stellen: Wat gebeurt er met de continuïteit van je bedrijfsprocessen als de persoon die “de IBM i kent” morgen niet meer beschikbaar is?

Signaal 4: Compliance vereist inzicht dat je omgeving niet automatisch levert

IBM i (AS400) heeft een uitgebreid en granulair beveiligingsmodel: object-level security, auditing via QAUDJRN, commitment control en journaling. Het platform is van zichzelf veilig en goed voorzien van logging-functionaliteit.
Maar NIS2 en de Nederlandse Cyberbeveiligingswet (die per 1 juli 2026 van kracht is) stellen eisen aan aantoonbaar inzicht voor auditors en toezichthouders: geëxporteerde rapportages, integratie met SIEM-systemen en toegangsbeheer dat zichtbaar is buiten het IBM i-platform. Die ontsluiting naar moderne compliance-tooling is in veel bestaande omgevingen niet ingericht niet omdat het platform het niet kan, maar omdat de koppeling naar buiten nooit is gebouwd.

De vraag om jezelf te stellen: Kun je de auditinformatie die in je IBM i-omgeving beschikbaar is, exporteren naar het format dat jouw SIEM of compliance-rapportage vereist?

Signaal 5: Je overweegt nieuwe software maar de integratiestrategie is nog niet beantwoord

Veel organisaties die nadenken over nieuwe ERP-systemen, WMS-platforms of cloud-software lopen tegen dezelfde muur: niemand weet precies hoe een nieuw systeem moet samenwerken met de bestaande IBM i-omgeving. Niet omdat de IBM i dat onmogelijk maakt maar omdat de integratie-architectuur niet is gedocumenteerd en er geen servicelaag of API-ontsluiting beschikbaar is om op aan te sluiten.

Het gevolg: de software-selectie loopt vertraging op, de scope groeit, en de projectkosten stijgen voordat er ook maar een regel code is geschreven.
IBM i hoeft niet te worden vervangen voordat je nieuwe software kiest. Maar de integratiestrategie — hoe ontsluiten we de bedrijfslogica en data die in de IBM i zit moet wél worden beantwoord als onderdeel van het selectieproces.

De vraag om jezelf te stellen: Is de integratiestrategie van je IBM i een vast onderdeel van je software-selectieproces?

Waarom dit probleem jarenlang onzichtbaar blijft

De AS400 draait bedrijfskritische applicaties op IBM Power Systems hardware zonder downtime. De schaalbaarheid van het platform stelt nooit teleur want resources kunnen dynamisch worden toegewezen via PowerVM zonder de operatie te verstoren. De database levert betrouwbare data en dat is precies waarom het probleem zo lang onzichtbaar blijft.

Pas wanneer een nieuw ERP-project, een klantportaal, een overname of een compliance-traject op tafel komt, wordt duidelijk hoeveel bedrijfsprocessen afhankelijk zijn van een integratie-architectuur die nooit is meegegroeid. De technische schuld zit niet in het platform maar in de verbindingen eromheen die jarenlang niet zijn herzien.

Integreren of moderniseren – niet hetzelfde

Een veelgehoord misverstand: wie integratieknelpunten herkent, denkt meteen aan het vervangen van de AS400 maar dat is zelden de juiste eerste stap. In veel gevallen is het slimmer om een moderne integratielaag of middleware toe te voegen die de IBM i ontsluit naar andere applicaties, zonder de stabiliteit en beschikbaarheid van het platform aan te tasten. Zo behoud je wat werkt, en verwijder je de architecturele beperking die groei blokkeert.

De vier modernisatieroutes: rehost, replatform, refactor en rebuild en wanneer welke route past bij jouw situatie, beschrijven we uitgebreid op onze AS/400 modernisatie-pagina.

Wat Axians anders maakt bij IBM i integratie-vraagstukken

Veel IT-partijen kennen moderne integratieplatforms en API-koppelingen. Minder partijen begrijpen ook de binnenkant van een IBM i-omgeving: de RPG-architectuur, de DB2-structuren, de SQL-queries, de configuratie en de bedrijfslogica die er al twintig jaar in zit.
Axians combineert beide. We werken vaak met een integratieplatform én met consultants die de IBM i kennen van binnenuit, de hardware, de software én de applicatielogica die erop draait. Die combinatie maakt het verschil: we begrijpen wat er is voordat we bepalen wat er moet veranderen.

Onze aanpak is altijd gefaseerd: eerst de integratie-architectuur in kaart brengen, dan bepalen welke koppelingen kunnen worden geoptimaliseerd, dan stap voor stap implementeren zonder de operationele continuïteit te verstoren.

Herken je deze signalen?

Als je drie of meer van deze signalen herkent, is het zinvol om de integratie-architectuur rond je IBM i opnieuw te beoordelen, niet als een technisch project maar als een strategische keuze voor de wendbaarheid van je organisatie.
Wij brengen bestaande systemen, afhankelijkheden en bedrijfsprocessen in kaart en werken van daaruit een gefaseerde, schaalbare oplossing uit. Geen standaard services, wel een aanpak die past bij jouw IT-landschap en continuïteitseisen.

Neem vrijblijvend contact op of lees meer over onze aanpak op de AS400 modernisatie-pagina.

Veelgestelde vragen

  • Kan een IBM i (AS400) real-time koppelen met moderne software en ERP-systemen?

    In de meeste gevallen wel. Een IBM i-omgeving kan via API’s, middleware of een integratieplatform zoals Boomi real-time worden gekoppeld aan moderne ERP-systemen en cloud-software. De complexiteit hangt af van de staat van de bestaande RPG- of COBOL-code en de beschikbaarheid van documentatie. Een grondige analyse van het bestaande IT-landschap vooraf voorkomt verrassingen tijdens de implementatie.

  • Wat is het verschil tussen batch-verwerking en real-time integratie op IBM i?

    Bij batch-verwerking worden gegevens op vaste momenten, bijvoorbeeld één of twee keer per dag, gesynchroniseerd tussen systemen. Bij real-time integratie worden gegevens direct doorgegeven zodra ze beschikbaar zijn. Voor bedrijfsprocessen die afhankelijk zijn van actuele voorraadniveaus, orderstatussen of planningsinformatie is real-time integratie steeds vaker een operationele noodzaak.

  • Wat is het verschil tussen IBM i integreren en IBM i moderniseren?

    Integreren betekent dat de IBM i blijft draaien als bedrijfskritisch platform, maar via een moderne integratielaag wordt verbonden met andere applicaties en systemen. Moderniseren is een bredere term die ook het herschrijven of vervangen van de RPG- of COBOL-softwareontwikkeling omvat. Integreren is minder risicovol en behoudt de beschikbaarheid en robuustheid van het bestaande AS/400-systeem. Moderniseren is beter als de legacy-code onvoldoende gedocumenteerd is of als het systeem functioneel niet meer aan de eisen voldoet.

  • Waarom worden IBM i integraties complexer bij groei?

    Bij groei — nieuwe vestigingen, overnames, extra klantkanalen of nieuwe cloud-software — neemt het aantal applicaties toe dat real-time met de IBM i moet communiceren. Elke nieuwe koppeling voegt complexiteit toe aan een omgeving die historisch is ingericht op batch-verwerking. Zonder een centrale integratielaag of middleware groeit de technische schuld mee met het bedrijf en worden toekomstige services steeds lastiger aan te sluiten.

  • Voldoet een IBM i automatisch aan NIS2 en de Cyberbeveiligingswet?

    Niet automatisch. IBM i is een robuust en betrouwbaar platform, maar NIS2 en de Cyberbeveiligingswet vragen om aantoonbaar inzicht: logging, toegangsbeheer en rapportages die exporteerbaar zijn voor audits. Veel bestaande omgevingen missen de koppelingen met SIEM-systemen of compliance-tools die daarvoor nodig zijn.

  • Hoe configureer je een IBM i voor moderne integratie?

    De basis is een integratielaag tussen het AS/400-platform en moderne applicaties — via API’s, middleware of een iPaaS-platform zoals Boomi. Daarnaast is het zaak om bestaande batch-processen in kaart te brengen en te bepalen welke daarvan kunnen worden geoptimaliseerd naar real-time datastromen. Axians begeleidt dit traject van inventarisatie tot implementatie.