IBM i non è un sistema antiquato: le obiezioni una per una

Chi propone di sostituire un IBM i raramente porta un'analisi. Porta un'impressione: la schermata è verde, il linguaggio si chiama RPG, la macchina si chiamava AS/400 quando chi la propone era alle elementari. Da lì si conclude che il sistema è vecchio, e dal fatto che sia vecchio si conclude che vada sostituito.

Sono due salti logici, e nessuno dei due regge. Ma non reggono nemmeno le risposte che si sentono di solito da chi difende la piattaforma, perché sono affermazioni di fede: "è solidissimo", "non si ferma mai", "chi lo conosce non lo lascia". Un direttore finanziario ha ragione a non farsi convincere.

Questo articolo prende le obiezioni una per una, dice che cosa c'è di vero in ciascuna, e arriva alla domanda che conta: non se la piattaforma sia vecchia, ma per quali carichi di lavoro sia ancora la scelta migliore. E per quali non lo sia.

«È un sistema vecchio»

Vecchio è il nome. Il sistema no.

L'ultimo rilascio è del 2025 e richiede processori Power9 o superiori: chi lo installa sta mettendo in produzione un sistema operativo dell'anno scorso su hardware degli ultimi anni. Fra un rilascio maggiore e l'altro arrivano due aggiornamenti tecnologici l'anno, che aggiungono funzioni al sistema, al database e ai compilatori. Il linguaggio RPG che si scrive oggi ha una sintassi completamente libera, procedure, strutture qualificate e puntatori: non somiglia al codice a colonne del 1990 più di quanto il C# di oggi somigli al C di allora.

Quello che confonde è che l'interfaccia può essere ancora la stessa. Una sessione 5250 funziona uguale a trent'anni fa, e la si vede tutti i giorni, mentre l'architettura sotto non la vede nessuno. È come giudicare un'automobile dal cruscotto.

La domanda giusta non è "quanti anni ha", ma "riceve investimenti". La risposta è verificabile in dieci minuti, e sta in fondo a questo articolo.

«Nessuno lo usa più»

Questa è l'obiezione più debole, perché è controllabile. Un sistema che nessuno usa non riceve un rilascio nuovo che obbliga a cambiare hardware — è una decisione che si prende solo per una base installata che si aggiorna davvero. Non ha un catalogo di software gestionale ancora in vendita e in manutenzione. Non ha aziende che ci costruiscono sopra il proprio prodotto.

Vale però anche il contrario di quello che si sente dall'altra parte: non è vero che sia diffuso come un tempo. È una piattaforma di nicchia, concentrata in settori precisi — manifattura, distribuzione, assicurazioni, banche di piccola e media dimensione — e in aziende che hanno un nucleo gestionale stabile da decenni. Chi la sceglie oggi da zero è raro. Chi ce l'ha e la tiene, quasi sempre ha ragione, ed è il caso di cui parla il resto dell'articolo.

«Non si trova personale»

Questa obiezione è vera, ed è la più seria di tutte. Non serve girarci intorno: chi conosce questa piattaforma ha in media più di cinquant'anni, le università non la insegnano, e sostituire chi va in pensione è difficile.

Ma va confrontata con l'alternativa, non con un mondo ideale.

Sostituire l'applicativo significa un progetto pluriennale, con il rischio di fallimento che hanno tutti i progetti di rifacimento di un gestionale — che è alto, e documentato da una lunga serie di casi finiti male. Significa perdere le regole di dettaglio accumulate in vent'anni, quelle che nessuno ha scritto da nessuna parte e che si riscoprono in produzione una alla volta. E significa avere, alla fine, un sistema che ha bisogno di più persone di quello di prima, perché quasi tutte le alternative richiedono di gestire separatamente sistema operativo, database, middleware e piattaforma applicativa.

C'è poi un fatto che chi solleva l'obiezione non considera: la piattaforma si impara. Un programmatore Java competente diventa produttivo su RPG e SQL in qualche mese, perché la parte difficile non è il linguaggio ma il dominio applicativo — e quello lo dovrebbe imparare comunque, anche nel sistema nuovo. Il problema di personale è reale ed è di gestione del ricambio, non di tecnologia.

«È chiuso, proprietario, e ti lega»

Vero in parte, e conviene dire in quale.

L'hardware è di un fornitore solo, il sistema operativo è di un fornitore solo, e non esiste il piano B di spostare tutto altrove in un fine settimana. Questo è un vincolo reale e va messo nel conto.

Ma il confronto onesto non è con un mondo senza vincoli. Un'azienda che porta il gestionale sui servizi gestiti di un fornitore cloud ha un vincolo esattamente della stessa natura, con la differenza che nell'IBM i i dati stanno in un database standard interrogabile in SQL, e i programmi sono sorgenti che si possiedono. Il vincolo è sull'esecuzione, non sui dati.

E per il resto la piattaforma è molto meno chiusa di quanto si creda. Ci girano Python, Node.js, Git, Bash, i database si interrogano in SQL standard via JDBC e ODBC, i programmi si espongono come servizi REST con la configurazione. Un'applicazione moderna scritta altrove può usare la logica che sta qui senza sapere che è scritta in RPG.

«Non si integra con niente»

Questa era vera vent'anni fa. Oggi è semplicemente sbagliata, e chi la sostiene sta descrivendo un'installazione ferma, non la piattaforma.

Un IBM i attuale espone i propri programmi come servizi web, si fa interrogare in SQL da qualunque linguaggio, legge e scrive sull'IFS file che chiunque può prendere, manda posta, chiama servizi esterni. Le tecnologie sono quelle di tutti.

Va detto con altrettanta chiarezza che molte installazioni non lo fanno. Non perché non si possa, ma perché nessuno ha mai avuto il compito di farlo. Confondere i due piani — la piattaforma e l'uso che se ne fa in quell'azienda — è l'errore che rende sterile la discussione: il sistema che "non si integra" quasi sempre è un sistema che nessuno ha mai integrato.

«È insicuro perché è vecchio»

Qui l'obiezione è capovolta rispetto alla realtà architetturale, e va spiegato perché invece di limitarsi a smentirla.

Su questo sistema ogni cosa è un oggetto con un tipo dichiarato, e il sistema fa rispettare quel tipo. Un file di dati non può essere eseguito: non perché manchi un permesso, ma perché l'operazione non esiste per quel tipo di oggetto. Ai livelli di sicurezza 40 e 50 — quello predefinito sui sistemi nuovi è il 40 — il sistema impedisce anche ai programmi di usare interfacce non supportate per scavalcare i controlli.

La conseguenza pratica è che un'intera categoria di attacchi qui non funziona. Il malware scritto per Windows o per Linux non gira: non è compatibile con niente. Molte tecniche che altrove si basano sul far passare per codice qualcosa che è stato scritto come dato, qui non hanno un appiglio nell'architettura.

Ma non è invulnerabile, e sostenerlo fa danno. I rischi reali ci sono e sono tre, tutti di configurazione e non di piattaforma:

• profili con *ALLOBJ distribuiti a chi non serve, quasi sempre perché creati copiandone uno esistente;
• diritti pubblici a *CHANGE — l'impostazione di fabbrica — che non danno fastidio finché si usa solo l'applicativo a menu, e diventano un problema il giorno in cui qualcuno si collega in ODBC;
• le cartelle dell'IFS condivise in rete, che sono l'unico punto in cui un ransomware partito da un PC Windows può cifrare dati su questo sistema. Non attacca il sistema: attacca file condivisi, come farebbe con qualunque altro disco di rete.

Un IBM i configurato bene è più difficile da compromettere della media dei sistemi. Un IBM i lasciato com'è uscito dalla fabbrica, con dieci profili *ALLOBJ e le PTF di sicurezza ferme da tre anni, non lo è affatto.

«Costa troppo»

Il costo per processore è alto, e non ha senso negarlo. Hardware e licenze costano più di un server x86 con Linux, a parità di core.

Il confronto sensato però non è sul prezzo di listino, ma su che cosa serve per far girare lo stesso lavoro. Su questa piattaforma il sistema operativo, il database, il gestore delle transazioni, la sicurezza e lo strumento di salvataggio sono la stessa cosa: non ci sono un DBA e un sistemista e un amministratore del middleware, non c'è un database da tenere allineato al sistema operativo, non ci sono quattro contratti di manutenzione e quattro finestre di aggiornamento da sincronizzare.

Nella pratica un IBM i di media dimensione è amministrato da una persona, spesso a tempo parziale. È lì che il conto cambia, ed è la voce che non compare mai nella tabella di confronto perché non ha una fattura.

Va aggiunta l'onestà sul rovescio: se il carico di lavoro è piccolo, il conto non torna. Una macchina con questa architettura ha senso quando c'è un nucleo transazionale da servire, non per far girare tre applicazioni leggere.

Quando è davvero la scelta migliore

Tolte le obiezioni, resta la domanda utile. Ci sono profili in cui questa piattaforma non è "ancora accettabile": è tecnicamente superiore alle alternative, e sono questi.

Il nucleo transazionale di un'azienda che deve stare in piedi. Molte scritture, dati che devono essere coerenti sempre, e il costo di un'ora di fermo che si misura in fatturato non prodotto. Database dentro il sistema operativo, journaling nativo, controllo di commit integrato: la coerenza non è un livello aggiunto sopra, è il piano su cui la macchina è costruita.

Dove il personale IT è poco. Un'azienda manifatturiera con quattrocento dipendenti e due persone in IT non ha le competenze per gestire un cluster Kubernetes, un database replicato, una pipeline di aggiornamenti e la sicurezza di tutto questo — e non le avrà mai, perché non è il suo mestiere. Un sistema che chiede poca manutenzione e non si ferma è, per quell'azienda, la scelta razionale, non quella nostalgica.

Dove la logica di business vale più del codice. Vent'anni di regole accumulate sono un patrimonio, non un debito: contengono ogni caso particolare che si è presentato davvero. Riscriverle significa perderle e riscoprirle in produzione. Questo argomento vale finché quel codice è modificabile a costi ragionevoli — se nessuno riesce più a metterci mano, l'argomento decade, e allora la discussione è un'altra.

Dove il carico è prevedibile. L'elasticità del cloud si paga, e serve a chi ha picchi imprevedibili. Un gestionale con un carico che si conosce e cresce del cinque per cento l'anno non ha niente da guadagnare dall'elasticità e paga solo la complessità che porta con sé.

Dove la compatibilità nel tempo ha un valore economico. Un programma compilato negli anni Novanta gira su un Power di oggi. Nessun'altra piattaforma commerciale offre questa garanzia, e chi ci ha costruito sopra vent'anni di sviluppo sa quanto vale — è la ragione per cui gli aggiornamenti di sistema qui non diventano progetti applicativi.

Quando non lo è

Un articolo che si fermasse qui sarebbe una brochure. I casi in cui la piattaforma è la scelta sbagliata esistono e sono chiari.

Un prodotto nuovo, soprattutto se venduto come servizio a molti clienti. L'ecosistema, il modello di costo per processore e la disponibilità di persone giocano tutti dall'altra parte.

Carichi di analisi e di apprendimento automatico. Le librerie, gli acceleratori e le competenze stanno altrove, e non c'è motivo di forzare. La strada sensata è portare i dati dove si elaborano, non spostare l'elaborazione qui.

Dove serve crescere in orizzontale e in fretta. Questa architettura scala verticalmente molto bene e in orizzontale no. Un carico che deve passare da dieci a mille istanze in un'ora vuole un'altra piattaforma.

Dove l'azienda deve assumere in fretta e in quantità. Se il piano richiede venti sviluppatori entro un anno, la difficoltà di reperimento smette di essere un fastidio e diventa il vincolo che decide.

Dove l'applicativo è già morto. Se il codice non è più modificabile, se chi lo capiva se n'è andato e nessuno sa più perché faccia quello che fa, la piattaforma non c'entra: il problema è il software, e va rifatto. La domanda su dove rifarlo viene dopo, e la risposta può benissimo essere "altrove".

Come verificare da soli

Questo è un sito che parla di IBM i, quindi è parte in causa, e chi legge fa bene a non fidarsi. Quattro controlli, tutti a portata di chiunque:

1. Le date di supporto e i rilasci stanno sulla pagina ufficiale del ciclo di vita dei rilasci di IBM. Dice quali sono supportati oggi e fino a quando: è il modo più rapido per sapere se una piattaforma è viva o in manutenzione.
2. Gli aggiornamenti tecnologici. IBM pubblica il contenuto di ogni technology refresh. Leggerne uno recente dice, meglio di qualunque opinione, se il prodotto riceve investimenti o solo correzioni.
3. Il proprio sistema. WRKPTFGRP dice a che livello sono le PTF, DSPSYSVAL SYSVAL(QSECURITY) a che livello di sicurezza si gira. Se la risposta è "PTF ferme al 2021 e sicurezza a 30", il problema non è la piattaforma.
4. Il mercato del software. Cercare se esiste ancora software gestionale in vendita per questa piattaforma, e da quante aziende. È il segnale economico più difficile da falsare.

L'obiezione a cui questo articolo non risponde è l'unica seria: fra quindici anni chi ci lavorerà. È una domanda legittima, e la risposta non è tecnologica — è che le competenze si costruiscono se qualcuno decide di costruirle. Nel frattempo, sostituire un sistema che funziona per un problema che si presenterà fra quindici anni è un modo costoso di anticiparlo.