Ha ancora senso investire nella modernizzazione dell’AS/400? Una riflessione sull’entropia dei sistemi legacy

Marco Del Corto – Founder / CEO Genesi srl
3 luglio 2025
(Articolo su Linkedin https://www.linkedin.com/pulse/ha-ancora-senso-investire-nella-modernizzazione-una-dei-del-corto-zoy0f)

L’AS/400, oggi IBM i, rappresenta uno dei casi più emblematici di longevità tecnologica nel panorama enterprise. Dopo oltre tre decenni di evoluzione, molte organizzazioni si trovano di fronte a un dilemma cruciale: vale ancora la pena investire in progetti di modernizzazione per gestire l’entropia accumulata in questi sistemi, o è arrivato il momento di considerare alternative più radicali?

L’entropia inevitabile dei sistemi legacy

Ogni sistema informativo, nel corso della sua vita operativa, accumula quello che possiamo definire “entropia tecnica”: modifiche non documentate, personalizzazioni stratificate, integrazioni temporanee diventate permanenti, codice legacy che nessuno osa più toccare. Nei sistemi AS/400, questa entropia assume caratteristiche peculiari.

La piattaforma IBM i ha dimostrato una straordinaria capacità di mantenere la compatibilità retroattiva, permettendo l’esecuzione di applicazioni sviluppate decenni fa. Questa forza, tuttavia, si è trasformata nel tempo in una debolezza: la facilità nel mantenere il codice esistente ha spesso scoraggiato gli investimenti in modernizzazione, creando un accumulo progressivo di debito tecnico.

Il costo dell’inerzia

L’inerzia tecnologica ha un prezzo che va oltre i semplici costi di manutenzione. I sistemi AS/400 non modernizzati presentano diverse criticità:

Competenze in via di estinzione: Il pool di sviluppatori RPG e COBOL esperti si riduce costantemente, con conseguente aumento dei costi di manutenzione e rischi operativi crescenti.

Isolamento architetturale: L’integrazione con tecnologie moderne diventa sempre più complessa, limitando la capacità dell’organizzazione di innovare e competere.

Vincoli normativi: Le crescenti richieste di compliance, sicurezza e auditing diventano difficili da soddisfare con sistemi non adeguatamente documentati e strutturati.

Il costo nascosto dell’entropia: un caso emblematico

Per comprendere appieno i rischi del mancato controllo dell’entropia nei sistemi legacy, è illuminante analizzare un caso reale che, per ragioni di riservatezza, presentiamo senza identificare l’organizzazione coinvolta. Come recita il detto: “citiamo il peccato ma non il peccatore”.

In una grande società multinazionale, periodicamente veniva presentato al CFO (Chief Financial Officer) un report dettagliato sull’andamento finanziario globale dell’organizzazione. Questo documento rivestiva un’importanza strategica cruciale, in quanto guidava le decisioni aziendali più rilevanti: dalle politiche di sviluppo agli investimenti, dalla definizione delle strategie alla pianificazione dei budget e delle priorità progettuali dei vari settori aziendali.

La scoperta fu tanto inaspettata quanto allarmante: il report veniva generato attraverso l’esecuzione di programmi rimasti non aggiornati, residenti nelle librerie personali di sviluppatori che avevano lasciato l’azienda anni prima. Nessuno era a conoscenza dell’esistenza di questi programmi, tanto meno del loro utilizzo continuativo per produrre informazioni di tale rilevanza strategica. Il sistema aveva continuato a funzionare in modo apparentemente corretto, ma basandosi su logiche e parametri potenzialmente obsoleti, con implicazioni difficili da quantificare per l’accuratezza delle decisioni strategiche prese sulla base di quei dati.

Un problema sistemico nell’ecosistema AS/400

Questo caso, pur rappresentando una situazione estrema, non è isolato. Nell’ecosistema AS/400 e IBM i sono frequenti scenari simili, seppur di minore gravità, specialmente in contesti caratterizzati da alto turnover del personale tecnico e processi di knowledge transfer inadeguati. La natura stessa della piattaforma IBM i, con la sua capacità di mantenere in esecuzione codice sviluppato decenni fa, può mascherare questi problemi fino a quando non emergono in modo critico.

Le dinamiche che portano a queste situazioni sono molteplici: la pressione operativa che spinge a soluzioni rapide anziché strutturate, la mancanza di documentazione adeguata, l’assenza di procedure standardizzate per la gestione del codice in produzione, e soprattutto la perdita progressiva della conoscenza istituzionale quando le persone lasciano l’organizzazione senza un adeguato trasferimento delle competenze.

L’importanza vitale del controllo dell’entropia

Questa situazione evidenzia la criticità e l’importanza strategica di mantenere un controllo rigoroso sull’entropia dei sistemi informativi. Non si tratta solo di una questione tecnica, ma di governance aziendale: la perdita di controllo sui propri sistemi può compromettere la qualità delle decisioni strategiche e, in ultima analisi, la competitività dell’organizzazione.

Il caso descritto dimostra che l’entropia non controllata può trasformarsi in un rischio operativo e strategico di dimensioni significative. Quando i processi critici di business dipendono da componenti software “fantasma”, l’organizzazione opera sostanzialmente alla cieca, assumendo rischi che potrebbero materializzarsi in modi imprevisti e potenzialmente devastanti.

Per questo motivo, gli investimenti in progetti di mappatura, documentazione e modernizzazione selettiva dei sistemi AS/400 non dovrebbero essere considerati solo come costi di manutenzione, ma come investimenti essenziali nella resilienza e nella governabilità dell’organizzazione. La capacità di sapere esattamente cosa fa il proprio sistema, come lo fa e chi ne è responsabile, rappresenta un asset strategico fondamentale nell’economia digitale contemporanea.

Il valore della modernizzazione mirata

Investire in progetti di modernizzazione dell’AS/400 ha ancora senso, ma richiede un approccio strategico e selettivo. Non si tratta di rinnovare tutto, ma di identificare e intervenire sui punti critici dove l’entropia ha il maggiore impatto sul business.

Mappatura delle dipendenze: Prima di qualsiasi intervento, è essenziale creare una mappa dettagliata delle dipendenze applicative, identificando i moduli critici e le loro interconnessioni.

Modernizzazione incrementale: Piuttosto che progetti “big bang”, sono preferibili approcci incrementali che permettano di ridurre progressivamente l’entropia senza compromettere la continuità operativa.

Standardizzazione delle interfacce: Investire nella creazione di API standardizzate che permettano l’integrazione con sistemi moderni, mantenendo il core business logic esistente.

Quando la modernizzazione non basta

Esistono scenari in cui la modernizzazione dell’AS/400 potrebbe non essere la scelta ottimale:

• Quando l’entropia è così elevata che il costo della modernizzazione supera quello di una migrazione completa
• Quando i requisiti di business sono cambiati radicalmente rispetto alla progettazione originale del sistema
• Quando l’organizzazione ha bisogno di capacità tecnologiche (cloud native, microservizi, analytics in tempo reale) difficilmente implementabili su piattaforma legacy

Una decisione strategica

La scelta di investire nella modernizzazione dell’AS/400 non può essere puramente tecnica, ma deve considerare il contesto strategico dell’organizzazione. Fattori come il settore di appartenenza, la pressione competitiva, la disponibilità di risorse e la strategia digitale complessiva devono guidare la decisione.

Per molte organizzazioni, soprattutto quelle con processi mission-critical consolidati, un approccio ibrido potrebbe rappresentare la soluzione ottimale: modernizzare selettivamente i componenti dell’AS/400 che generano maggiore valore, mantenendo la stabilità del core system, e parallelamente sviluppare nuove capacità su piattaforme moderne.

Conclusioni

Investire nella modernizzazione dell’AS/400 ha ancora senso, ma solo se fatto con criterio e visione strategica. L’obiettivo non deve essere eliminare completamente l’entropia – un’utopia costosa e spesso controproducente – ma gestirla in modo intelligente, concentrando gli investimenti dove possono generare il maggiore impatto sul business.

Il futuro dell’AS/400 nelle organizzazioni moderne non è scritto: dipenderà dalla capacità di bilanciare saggezza tecnologica, vincoli economici e ambizioni strategiche. Chi saprà trovare questo equilibrio continuerà a trarre valore da una delle piattaforme più longeve e affidabili della storia dell’informatica enterprise.

Commenti e Reazioni dalla Community

L’articolo ha suscitato un ampio dibattito nella community IBM i, raccogliendo 22 commenti e 4 condivisioni su LinkedIn. Di seguito riportiamo i principali contributi che hanno arricchito la discussione, mantenendo la fedeltà delle conversazioni e dei thread di risposta:

Il Problema Culturale della Progettazione

Questa sezione esplora come la mancanza di cultura progettuale rappresenti una delle radici del problema dell’entropia nei sistemi IBM i

Vincenzo Turturro (IT consultant – Software engineer) ha commentato:

“Ottima analisi che condivido pienamente. Purtroppo il problema è prima di tutto ‘culturale’: nel mio piccolo, credo che sia dimostrato anche dal fatto che il nuovo corso proposto da Faq400 – ‘Progettazione di basi di dati’ – è andato deserto (una sola iscrizione). Italiani popolo di poeti, santi, navigatori e progettisti di basi di dati relazionali? Che però balbettano ed incespicano quasi tutti nel rispondere alla domanda ‘Qual è la definizione di chiave primaria’… O che, ancora peggio, pensano che basti aggiungere un id autoincrementante ad ogni tabella per avere la base di dati (e la coscienza?) a posto. Peccato, perchè una buona base di dati, progettata seguendo i dettami della teoria, fornisce già di per sè una ottima documentazione di svariate caratteristiche dell’applicativo che la gestisce.”

Marco Del Corto (Autore) ha risposto:

“Grazie Vincenzo per il commento e il contributo prezioso che condivido appieno. La tua osservazione – ‘una buona base di dati, progettata seguendo i dettami della teoria, fornisce già di per sé una ottima documentazione di svariate caratteristiche dell’applicativo che la gestisce’ – centra perfettamente un aspetto fondamentale. Aggiungerei che questo elemento è indicativo non solo della corretta applicazione delle potenzialità dell’approccio SQL nella gestione dei processi aziendali, ma anche di una comprensione profonda della natura degli oggetti di business e delle loro relazioni. Questa comprensione deve necessariamente essere la guida nello sviluppo delle applicazioni che governano i processi aziendali. Il fatto che un corso sulla progettazione di basi di dati sia andato deserto è effettivamente sintomatico di un approccio culturale che privilegia il ‘funziona subito’ rispetto alla solidità architetturale a lungo termine.”

Fretta e Qualità: Le Cause Strutturali

I commenti in questa sezione identificano le pressioni operative e organizzative che contribuiscono all’accumulo di entropia

Massimiliano Andreis (Analista funzionale & Analista Programmatore Senior AS400 RPG ILE – Freelance – INPS) ha scritto:

“A monte, direi che le cause principali sono due: la prima è la fretta, il voler ridurre a tutti i costi i tempi di consegna – spesso per compiacere il cliente che nella maggior parte vuole tutto spendendo poco- ma la qualità ha un costo; la seconda é che nulla si improvvisa e, saper analizzare, modellizzare, sviluppare, documentare, ecc, richiede tempo, strumenti, studio e, spesso in ambiente IT, ti senti dire: l’importante è che funzioni… il tutto senza fare formazione preventiva sui processi di business sottostanti.”

Marco Del Corto (Autore) ha risposto:

“Grazie Massimiliano per aver individuato con precisione alcune delle cause strutturali che noi professionisti del settore conosciamo fin troppo bene. La presa di coscienza condivisa di questi problemi – da parte di committenti, team tecnici e stakeholder – è effettivamente il punto di partenza per costruire strategie sostenibili. Solo quando tutto l’ecosistema progettuale comprende il reale impatto dell’entropia tecnologica possiamo sperare di invertire questa tendenza. Senza questa awareness condivisa, continueremo a rincorrere i problemi anziché prevenirli.”

L’Approccio Ibrido e la Gestione del Know-how

Questa discussione approfondisce le strategie pratiche per gestire l’evoluzione dei sistemi IBM i e il problema della perdita di conoscenza aziendale

Andrea Valerio (Responsabile IT presso ISA SETA S.p.a.) ha condiviso:

“Articolo interessante che condivido su tanti punti, grazie per la condivisione. Personalmente credo che IBMi sia un ottimo backend per le applicazioni e necessariamente non deve fare tutto es. il frontend e già questo può ridurre l’entropia ma introduci comunque altri sistemi da gestire. Un problema è che le applicazioni scritte in rpg3/rpg4 sono ostiche da mantenere e non vicine ai linguaggi moderni e la conversione non è come scrivere a nuovo il programma in rpg free. Un giovane non ci mette troppo a fare coding in rpg free ma come lo riscrivi il passato se fai fatica a leggere il codice? Spesso viene voglia di cambiare perché si pensa sia più semplice e ripensi ai processi con un rischio aziendale da valutare. Aggiungo però che una AI come chatgpt analizza abbastanza bene il codice è può essere un aiuto ulteriore. Insomma, scelte non semplici ma se conosci IBMi un pó bene, prima di abbandonarlo ci penserei 3/4 volte perché ci sono tanti punti ancora a favore…”

Marco Del Corto (Autore) ha risposto:

“Grazie Andrea Valerio per il contributo concreto e calato nelle realtà operative che molti di noi conoscono bene. Vorrei aggiungere una riflessione su un aspetto critico spesso sottovalutato: il patrimonio di conoscenza aziendale incorporato nei sistemi AS/400. Questi sistemi non contengono solo codice, ma racchiudono decenni di evoluzione dei processi di business, adattamenti organizzativi e logiche operative che rappresentano la ‘memoria storica’ dell’azienda. Il vero rischio strategico risiede nel fatto che questa conoscenza è custodita principalmente da una generazione di programmatori prossima al pensionamento, quando non già pensionata. Il know-how sui processi aziendali, sulle ragioni che hanno guidato specifiche scelte implementative e sulla correlazione tra logiche di business e soluzioni tecniche rischia di andare perduto definitivamente. Il trasferimento di queste competenze non è solo una questione tecnica, ma rappresenta una sfida di knowledge management di portata strategica. Senza un piano strutturato di conservazione e trasmissione di questo patrimonio intellettuale, le organizzazioni rischiano di perdere elementi fondamentali della propria identità operativa e capacità decisionale.”

Andrea Valerio ha replicato:

“Sposo appieno la tua riflessione e aggiungo un altro fattore perché nel tempo mi sono sempre più convinto che gli analisti funzionali siano delle figure sempre più importanti. La perdita del know how è il vero rischio aziendale e demandare per abitudine o per necessità di costo tutto alla figura del programmatore/analista lo reputo potenzialmente pericoloso nel tempo. Inoltre gli analisti funzionali con il rapporto diretto con gli utenti hanno una visione diversa rispetto ai programmatori. Aggiungo anche una riflessione dove nel codice spesso ci sono modifiche che per motivi diversi non hanno più senso perché nel tempo sono cambiati i processi e diventati obsoleti e a fronte di un’analisi potresti capire che una parte significativa del codice non va riportato ma senza know how e memoria storica concordo che sia difficile andare lontano.”

Marco Del Corto (Autore) ha concluso:

“Siamo sulla stessa lunghezza d’onda…”

La Modernizzazione degli Sviluppatori

I commenti in questa sezione affrontano il paradosso della retrocompatibilità di IBM i e la necessità di modernizzare prima di tutto le competenze

Massimo Duca (Senior IBMi Analyst/Developer presso Exprivia) ha osservato:

“Analisi molto corretta e condivisibile. Ho sempre pensato che la retrocompatibilità sia il miglior pregio di IBM i… ma allo stesso tempo sia il suo peggior difetto! Secondo me oggi quello che va veramente modernizzato, prima ancora delle applicazioni, sono gli sviluppatori IBM i! Vedo ancora troppi personaggi che si adagiano nelle proprie conoscenze (RPG old style, SEU, PDM tanto per dirne alcune…) e non si preoccupano minimamente di esplorare le enormi evoluzioni che IBM i ha avuto in questi anni. La vera sfida è riuscire ad attrarre giovani verso la piattaforma, e far si che loro diano sempre più slancio verso l’evoluzione delle applicazioni aziendali. Nella mia azienda recentemente sono entrati due giovani, con una conoscenza della piattaforma scarsa o nulla, e dopo adeguato addestramento ed affiancamento ora sono pienamente attivi e produttivi… Qualche speranza quindi ce la possiamo avere!”

Marco Del Corto (Autore) ha risposto:

“Grazie Massimo Duca per aver centrato in modo sintetico il cuore del problema: modernizzare gli sviluppatori IBM i. In effetti, gli sviluppatori IBM i sono il focus principale della modernizzazione. Molti di loro sono prossimi alla pensione. Al tempo stesso, sono anche quelli che fanno più fatica a modernizzarsi dopo tanti anni di abitudine a processi consolidati. Sono però anche quelli che detengono il know-how cruciale dell’azienda. Qui si entra in un circolo vizioso non facile da sciogliere. I ‘vecchi’ sviluppatori fanno molta fatica a cambiare modelli di riferimento. Tuttavia sono insostituibili per il know-how che rappresenta un patrimonio aziendale. I giovani developer, invece, sono abituati alle nuove metodologie. Fanno però fatica ad acquisire il patrimonio aziendale rappresentato da tutto il ‘vecchio’ codice esistente. La soluzione probabilmente richiede approcci ibridi: mentoring strutturato, documentazione sistematica del know-how implicito e graduale introduzione di nuove metodologie che non stravolgano completamente i processi esistenti.”

Vito Morea (Consulente Senior specializzato ERP aziende tessili e sistemi Ibm Power) ha aggiunto:

“Sacrosanta verità!! Ci conosciamo da quasi 30 anni e vedo ancora tanti ‘colleghi’ che non ne vogliono neanche sentir parlare di altri strumenti che non siano SEU, PDM, SDA, ecc… Per non parlare del fatto che si ‘ignorano’ le potezialità dell’SQL per migliorare i ns. vecchi e cari sorgenti RPG IV (quando va bene)… Purtroppo, quella di ‘modernizzare’ i colleghi sviluppatori con i capelli bianchi (come i nostri) non è per nulla facile! Un saluto, caro Massimo… :-)”

Prospettive Strategiche: Valore vs Abbandono

Questa sezione presenta il dibattito tra chi sostiene il valore continuativo della piattaforma IBM i e chi ne prevede l’inevitabile abbandono

Gherardo Maspero (Managing Partner Twingroup Global Solutions) ha argomentato:

“Per noi ha senso, eccome. Crediamo che IBM i sia tuttora una piattaforma perfettamente adatta al mondo del business moderno: stabile, sicura, resiliente, con performance elevate e una straordinaria capacità di integrazione. Proprio per questo proponiamo soluzioni ERP moderne come Infor XA, nativamente sviluppate per IBM i, in grado di coniugare la robustezza del sistema con funzionalità avanzate e un’interfaccia utente al passo con le aspettative contemporanee. La modernizzazione non significa abbandonare ciò che funziona, ma valorizzarlo. Lavorare su IBM i con strumenti moderni permette di gestire l’entropia mantenendo la governance, proteggendo gli investimenti pregressi e garantendo continuità operativa. In altre parole: crediamo che non sempre serva ‘cambiare piattaforma’, ma piuttosto evolvere con intelligenza. È questa la logica che guida le nostre proposte e i nostri progetti.”

Marco Del Corto (Autore) ha risposto:

“Grazie delle riflessioni. Capisco le considerazioni e le ritengo valide, tenendo conto anche del fatto che l’approccio più efficace dipende da diversi fattori specifici del contesto e gli obiettivi della trasformazione digitale. Credo anche che non si debba associare il termine trasformazione digitale o modernizzazione con ‘cambiare piattaforma’: la modernizzazione può essere fatta benissimo indipendentemente dal fatto se si cambia o meno piattaforma.”

Gherardo Maspero ha ribattuto:

“Condivido pienamente la tua visione: è importante distinguere tra trasformazione digitale e semplice cambio di piattaforma. Spesso si tende a sovrapporre i due concetti, ma la modernizzazione è prima di tutto un cambiamento culturale, di processi e approccio. Grazie per averlo sottolineato con chiarezza.”

Marco Del Corto (Autore) ha concluso:

“Grazie a te e della bella definizione ‘la modernizzazione è prima di tutto un cambiamento culturale, di processi e approccio’ (e aggiungerei ‘a prescindere dalla piattaforma, che può rimanere, svilupparsi o anche cambiare, in relazione al cambiamento, ma rimane un concetto separato e per niente sovrapposto’)”

Danilo Cussini (I.T. Demand Manager, I.T. Business Analyst, I.T. Systems Analyst, IBM i software developer) ha espresso una posizione più critica:

“Ma in Italia c’è qualcuno che investe o sta pensando di investire sulla modernizzazione delle applicazioni IBM i RPG? Per le aziende che possono acquistare un ERP esterno la scelta è facile: nuovo ERP. Le aziende con un ERP completamente sviluppato internamente e senza soluzioni acquistabili saranno in grossa difficoltà nei prossimi anni; queste aziende dovevano muoversi 10 anni fa e aprire i propri uffici ai programmatori Java, ma qualcuno l’ha fatto?”

Marco Del Corto (Autore) ha risposto:

“Il problema non è mai semplice e ogni azienda presenta sfide uniche, ma è una realtà che un numero crescente di organizzazioni deve affrontare, scegliendo tra approcci graduali, ibridi o big bang. L’approccio più efficace dipende da diversi fattori specifici del proprio contesto: la strategia aziendale, il livello di competizione nel settore, le risorse disponibili (budget, competenze, tempo) e gli obiettivi della trasformazione digitale. Prima di scegliere una soluzione, è fondamentale analizzare questi elementi per identificare l’approccio che meglio si adatta alla propria realtà organizzativa.”

Danilo Cussini ha replicato:

“Capisco il suo punto di vista professionale, ma il problema non è né semplice né complicato: semplicemente il problema non esiste, perché i CIO hanno già deciso di lasciare IBM i a qualunque costo e il più delle volte è una decisone dogmatica, cioè bisogna lasciare IBM i perché bisogna lasciare IBM i.”

Apprezzamenti e Riconoscimenti

Gli ultimi commenti evidenziano l’apprezzamento generale per l’analisi presentata

Nicola Triti (Head of Accounting – BW Converting S.p.A.) ha commentato:

“Bellissimo articolo che ha confermato quanto ho imparato in questi anni! Complimenti davvero!”

Marco Del Corto (Autore) ha risposto semplicemente: “Grazie per l’apprezzamento!”

Pier Luigi Ferrari (Direzione Network Agenzie Enterprise presso TeamSystem) ha aggiunto:

“Analisi molto interessante, puntuale ed oggettiva. Introduce elementi di valutazione non sempre presi in considerazione, ma per nulla scontati. Grazie”

Marco Del Corto (Autore) ha risposto: “Grazie a Lei per l’apprezzamento”

Riflessioni Conclusive

I commenti hanno confermato la complessità e l’attualità del tema, evidenziando come la modernizzazione dell’AS/400 sia prima di tutto una sfida culturale e organizzativa che tocca aspetti tecnici, strategici e di gestione del capitale umano. La discussione ha mostrato come la community IBM i sia divisa tra chi vede ancora grande valore nella piattaforma e chi ritiene inevitabile l’abbandono, ma tutti concordano sull’importanza di una gestione consapevole dell’entropia tecnologica.

Un elemento emerso chiaramente dal dibattito è l’importanza di distinguere tra trasformazione digitale e migrazione di piattaforma. Come sottolineato durante la discussione, la modernizzazione rappresenta essenzialmente un cambiamento culturale, di processi e di approccio che può essere realizzato efficacemente indipendentemente dalla scelta di mantenere, evolvere o sostituire la piattaforma tecnologica sottostante. Questa distinzione è fondamentale per evitare decisioni strategiche basate su false correlazioni tra innovazione e cambio di tecnologia.