{"id":5071,"date":"2025-07-10T10:04:50","date_gmt":"2025-07-10T08:04:50","guid":{"rendered":"https:\/\/www.skillup.cloud\/?p=5071"},"modified":"2025-07-14T11:37:10","modified_gmt":"2025-07-14T09:37:10","slug":"ha-ancora-senso-investire-nella-modernizzazione-dellas-400-una-riflessione-sullentropia-dei-sistemi-legacy","status":"publish","type":"post","link":"https:\/\/www.skillup.cloud\/en\/ha-ancora-senso-investire-nella-modernizzazione-dellas-400-una-riflessione-sullentropia-dei-sistemi-legacy\/","title":{"rendered":"Ha ancora senso investire nella modernizzazione dell’AS\/400? Una riflessione sull’entropia dei sistemi legacy"},"content":{"rendered":"\n

Marco Del Corto – Founder \/ CEO Genesi srl<\/em>
3 luglio 2025<\/em>
Aggiornamento sezione “Commenti e Reazioni dalla Community” al 14 luglio 2025
(Articolo su Linkedin https:\/\/www.linkedin.com\/pulse\/ha-ancora-senso-investire-nella-modernizzazione-una-dei-del-corto-zoy0f<\/a>)<\/p>\n\n\n\n

L’AS\/400, oggi IBM i, rappresenta uno dei casi pi\u00f9 emblematici di longevit\u00e0 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 \u00e8 arrivato il momento di considerare alternative pi\u00f9 radicali?<\/p>\n\n\n\n

L’entropia inevitabile dei sistemi legacy<\/strong><\/p>\n\n\n\n

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\u00f9 toccare. Nei sistemi AS\/400, questa entropia assume caratteristiche peculiari.<\/p>\n\n\n\n

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

Il costo dell’inerzia<\/strong><\/p>\n\n\n\n

L’inerzia tecnologica ha un prezzo che va oltre i semplici costi di manutenzione. I sistemi AS\/400 non modernizzati presentano diverse criticit\u00e0:<\/p>\n\n\n\n

Competenze in via di estinzione<\/strong>: Il pool di sviluppatori RPG e COBOL esperti si riduce costantemente, con conseguente aumento dei costi di manutenzione e rischi operativi crescenti.<\/p>\n\n\n\n

Isolamento architetturale<\/strong>: L’integrazione con tecnologie moderne diventa sempre pi\u00f9 complessa, limitando la capacit\u00e0 dell’organizzazione di innovare e competere.<\/p>\n\n\n\n

Vincoli normativi<\/strong>: Le crescenti richieste di compliance, sicurezza e auditing diventano difficili da soddisfare con sistemi non adeguatamente documentati e strutturati.<\/p>\n\n\n\n

Il costo nascosto dell’entropia: un caso emblematico<\/strong><\/p>\n\n\n\n

Per comprendere appieno i rischi del mancato controllo dell’entropia nei sistemi legacy, \u00e8 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”.<\/p>\n\n\n\n

In una grande societ\u00e0 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\u00f9 rilevanti: dalle politiche di sviluppo agli investimenti, dalla definizione delle strategie alla pianificazione dei budget e delle priorit\u00e0 progettuali dei vari settori aziendali.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Un problema sistemico nell’ecosistema AS\/400<\/strong><\/p>\n\n\n\n

Questo caso, pur rappresentando una situazione estrema, non \u00e8 isolato. Nell’ecosistema AS\/400 e IBM i sono frequenti scenari simili, seppur di minore gravit\u00e0, 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\u00e0 di mantenere in esecuzione codice sviluppato decenni fa, pu\u00f2 mascherare questi problemi fino a quando non emergono in modo critico.<\/p>\n\n\n\n

Le dinamiche che portano a queste situazioni sono molteplici: la pressione operativa che spinge a soluzioni rapide anzich\u00e9 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.<\/p>\n\n\n\n

L’importanza vitale del controllo dell’entropia<\/strong><\/p>\n\n\n\n

Questa situazione evidenzia la criticit\u00e0 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\u00f2 compromettere la qualit\u00e0 delle decisioni strategiche e, in ultima analisi, la competitivit\u00e0 dell’organizzazione.<\/p>\n\n\n\n

Il caso descritto dimostra che l’entropia non controllata pu\u00f2 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.<\/p>\n\n\n\n

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\u00e0 dell’organizzazione. La capacit\u00e0 di sapere esattamente cosa fa il proprio sistema, come lo fa e chi ne \u00e8 responsabile, rappresenta un asset strategico fondamentale nell’economia digitale contemporanea.<\/p>\n\n\n\n

Il valore della modernizzazione mirata<\/strong><\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Mappatura delle dipendenze<\/strong>: Prima di qualsiasi intervento, \u00e8 essenziale creare una mappa dettagliata delle dipendenze applicative, identificando i moduli critici e le loro interconnessioni.<\/p>\n\n\n\n

Modernizzazione incrementale<\/strong>: Piuttosto che progetti “big bang”, sono preferibili approcci incrementali che permettano di ridurre progressivamente l’entropia senza compromettere la continuit\u00e0 operativa.<\/p>\n\n\n\n

Standardizzazione delle interfacce<\/strong>: Investire nella creazione di API standardizzate che permettano l’integrazione con sistemi moderni, mantenendo il core business logic esistente.<\/p>\n\n\n\n

Quando la modernizzazione non basta<\/strong><\/p>\n\n\n\n

Esistono scenari in cui la modernizzazione dell’AS\/400 potrebbe non essere la scelta ottimale:<\/p>\n\n\n\n