• Skip to primary navigation
  • Skip to main content
  • Skip to footer

Codemotion Magazine

We code the future. Together

  • Discover
    • Events
    • Community
    • Partners
    • Become a partner
    • Hackathons
  • Magazine
    • Backend
    • Dev community
    • Carriere tech
    • Intelligenza artificiale
    • Interviste
    • Frontend
    • DevOps/Cloud
    • Linguaggi di programmazione
    • Soft Skill
  • Talent
    • Discover Talent
    • Jobs
    • Manifesto
  • Companies
  • For Business
    • EN
    • IT
    • ES
  • Sign in
ads

Arnaldo MorenaSettembre 3, 2026 9 min di lettura

L’IA rallenta le vendite dei mainframe. Ma il mondo può davvero fare a meno di loro?

Intelligenza artificiale
facebooktwitterlinkedinreddit

Qualche settimana fa IBM ha commentato il rallentamento delle vendite dei propri mainframe spiegando agli investitori che si tratta di un fenomeno temporaneo. La notizia è passata quasi inosservata al di fuori degli ambienti finanziari, ma ha suscitato un certo interesse tra gli addetti ai lavori. https://newsroom.ibm.com/2026-07-14-Arvind-Krishnas-Letter-to-IBM-Investors

Del resto viviamo in un momento storico in cui l’attenzione dell’industria sembra concentrata esclusivamente sull’intelligenza artificiale, le aziende investono miliardi di dollari in data center popolati da GPU, i produttori di hardware competono per realizzare acceleratori sempre più potenti e il cloud continua a espandere la propria presenza.
In questo scenario è naturale chiedersi quale spazio possa ancora avere una tecnologia nata oltre sessant’anni fa.

Recommended article
Agosto 26, 2026

I prompt hanno rotto: viva le specifiche

Matteo Baccan

Matteo Baccan

Intelligenza artificiale

Il mantra di questi mesi però è che a dare risposte sono capaci tutti, la cosa difficile di questi tempi è fare le domande giuste. Non dovremmo chiederci perché esistano ancora i mainframe, ma perché, nonostante sei decenni di evoluzione dell’informatica, continuino a essere il cuore operativo di banche, assicurazioni, compagnie aeree, amministrazioni pubbliche e grandi aziende. E, come è comprensibile, la loro sopravvivenza non è il risultato dell’inerzia o della resistenza al cambiamento ma piuttosto la conseguenza del fatto che risolvono un problema estremamente specifico meglio di qualsiasi altra ‘piattaforma’.

Per inquadrare il ruolo del mainframe bisogna dimenticare, almeno per un momento, il modo in cui siamo abituati a guardare un computer. Negli ultimi vent’anni abbiamo imparato a confrontare le macchine in base alla velocità del processore, al numero di core, alla quantità di memoria installata o alla capacità di addestrare un modello di intelligenza artificiale idolatrandone le schede grafiche. È una prospettiva comprensibile, ma descrive soltanto una parte dell’informatica moderna. Esistono infatti sistemi progettati con un obiettivo completamente diverso: non ottenere le massime prestazioni in un benchmark, ma garantire che milioni di operazioni vengano eseguite correttamente, senza interruzioni e senza perdita di dati.

È proprio in questo contesto che il mainframe mostra la propria ragion d’essere. Fin dagli anni Sessanta è stato progettato per elaborare enormi quantità di transazioni garantendo continuità operativa, affidabilità e integrità del dato. Nella storia dell’informatica sono nate e scomparse innumerevoli architetture hardware, sistemi operativi e linguaggi di programmazione, ma il problema di registrare correttamente una transazione bancaria è rimasto sostanzialmente immutato. Se un bonifico viene addebitato sul conto del mittente, il denaro deve comparire anche sul conto del destinatario. Se qualcosa impedisce il completamento dell’operazione, il sistema deve annullare tutto e riportare la situazione allo stato iniziale.
È il principio delle transazioni ACID, un concetto noto a qualsiasi studente di informatica, ma che, nella pratica, nessuno ricorda mai bene. È un acronimo che indica le quattro proprietà fondamentali che garantiscono la sicurezza e l’affidabilità dei dati in un database quando si eseguono delle transazioni ovvero un gruppo di operazioni che deve essere trattato come un unico blocco .
I 4 Pilastri di ACID :
A – Atomicità (Atomicity): L’intera transazione viene eseguita con successo, oppure non viene eseguito nulla.Esempio: Se trasferisci 50€ dal conto A al conto B, il sistema deve sia scalare i soldi da A sia accreditarli su B. Se il sistema si blocca a metà, l’intera operazione viene annullata e nessuno perde denaro.
C – Consistenza (Consistency): Il database deve passare da uno stato valido a un altro stato valido, rispettando tutte le regole e i vincoli.Esempio: Se il saldo di un conto corrente non può legalmente scendere sotto lo zero, una transazione che prova a prelevare più del dovuto viene bloccata per non violare questa regola.
I – Isolamento (Isolation): Ogni transazione viene eseguita in modo isolato, come se fosse l’unica nel sistema. Le transazioni simultanee non si disturbano a vicenda.Esempio: Se due persone prelevano contemporaneamente dallo stesso conto cointestato, il database elabora le richieste una alla volta per evitare che il saldo venga calcolato in modo errato.
D – Durabilità (Durability): Una volta che la transazione è completata con successo, le modifiche sono permanenti e non verranno perse, nemmeno in caso di blackout o guasto del server. Esempio: Appena ricevi la conferma del bonifico, il dato viene salvato sul disco fisso (o log di sistema) in modo sicuro e definitivo.

Ok tutti i database relazionali e anche qualche Nosql però rispettano i criteri acid, perchè non affidarsi ad Oracle o al prodotto superfantastico appena uscito?
Indossiamo un camice bianco come fossimo un Marvin Candle qualsiasi e immaginiamo di proiettare un bel filmato in bianco e nero della DHARMA Initiative.


Per prima cosa la gestione dell’I/O (Input/Output) hardware, i PC e i normali server x86 usano la CPU centrale per fare quasi tutto : calcoli, logica software e gestione del traffico dati verso i dischi. I mainframe dispongono di co-processori dedicati solo all’I/O. La CPU principale calcola, mentre centinaia di chip secondari muovono i dati. Questo permette di gestire decine di migliaia di transazioni finanziarie al secondo senza alcun rallentamento o collo di bottiglia, prestazioni difficili da replicare per il vostro database preferito su server standard con carichi massivi globali. Poi abbiamo la tolleranza ai guasti o se preferite la fmigerata “fault tollerance”.
I mainframe sono progettati per avere una disponibilità del 99,999% (i famosi “cinque nove”), significa pochissimi minuti di disservizio all’anno grazie al fatto che ogni singolo componente hardware all’interno di un mainframe (schede madri, RAM, alimentatori, CPU) è duplicato o triplicato. Se un pezzo si rompe mentre la banca sta elaborando i bonifici, il sistema lo sostituisce a caldo senza spegnersi e senza perdere un singolo bit. Potete metterci Kafka, Rabbitmq e le tavolette di argilla ma per quanto un sistema possa essere robusto, dipende dall’infrastruttura server o cloud sottostante, richiedendo configurazioni di clustering molto complesse per avvicinarsi a questi livelli.

Poi c’è l’applicazione della legge universale “se funziona non toccarlo”. I sistemi centrali delle banche si sono stratificati nel corso di 40-50 anni e scritti in linguaggi storici come il COBOL, milioni di righe di codice intrecciate con regole fiscali e logiche bancarie stratificate nel tempo, spesso non documentate. Spegnere il mainframe per passare a un infrastruttura moderna viene visto dai manager come un rischio colossale: un solo bug durante il passaggio potrebbe bloccare i bancomat di una nazione o alterare i saldi di milioni di clienti con scenari alla Mr Robot. Infine la velocità nell’elaborazione Batch massiva visto che le banche lavorano in due modi: le transazioni in tempo reale (es. quando paghi con la carta) e i processi batch (es. il calcolo degli interessi di milioni di conti che avviene di notte). I mainframe sono nati per macinare volumi spaventosi di dati sequenziali in pochissimi minuti. Un’operazione batch notturna che sul mainframe richiede 20 minuti, su un database relazionale standard non ottimizzato per quel tipo di hardware specifico potrebbe richiedere ore, sforando l’inizio della giornata lavorativa successiva.

Questa attenzione alla continuità rappresenta ancora oggi uno degli aspetti più affascinanti del mondo mainframe, la cui origine coincide con uno dei momenti più importanti della storia dell’informatica. Nel 1964 IBM presentò il System/360, una famiglia di computer che cambiò radicalmente il modo di progettare i sistemi aziendali. Fino a quel momento ogni nuova macchina richiedeva spesso la riscrittura del software sviluppato per la generazione precedente. Il System/360 introdusse invece una piattaforma compatibile, capace di crescere mantenendo lo stesso patrimonio applicativo. Fu una scelta rivoluzionaria, perché consentì alle aziende di investire nello sviluppo del software senza il timore di dover ricominciare da zero a ogni evoluzione dell’hardware.

Katherine Johnson, una delle prime scienziate afroamericane della NASA, la sua storia ne “il diritto di contare” commuove qualsiasi programmatore, specialmente quando fa l’ “hello world” su un bestione da 5 milioni di dollari dell’epoca

Abbiamo visto come molti programmi scritti decenni fa continuano a essere utilizzati, non perché siano vecchi, ma perché svolgono il proprio compito in modo impeccabile. In un settore come quello bancario, un’applicazione che gestisce milioni di conti correnti costituisce un patrimonio enorme. Riscriverla integralmente non significa soltanto sostenere un costo elevato; significa affrontare anni di analisi, test e certificazioni con il rischio concreto di introdurre errori in procedure che funzionano da decenni. Per questo motivo il software viene evoluto progressivamente, adattato alle nuove esigenze e integrato con tecnologie moderne, piuttosto che sostituito completamente.

È in questo contesto che domina COBOL, probabilmente il linguaggio di programmazione più discusso e, allo stesso tempo, più frainteso dell’informatica moderna. Nato nel 1959 con l’obiettivo di descrivere in modo chiaro le procedure amministrative e gestionali, COBOL venne progettato affinché il codice fosse leggibile anche da chi non fosse uno specialista di informatica. A differenza dei linguaggi orientati al calcolo scientifico, privilegiava la descrizione di record, archivi, movimenti contabili e procedure aziendali. Ancora oggi milioni di righe di codice COBOL vengono eseguite quotidianamente, non per nostalgia, ma perché rappresentano la formalizzazione di regole di business affinate nel corso di decenni.

Questo non significa che un moderno mainframe esegua soltanto software scritto negli anni Sessanta. Al contrario, l’evoluzione di queste piattaforme è stata continua. Oggi un sistema IBM Z può ospitare applicazioni Java, servizi scritti in C e C++, distribuzioni Linux complete, macchine virtuali, container e API che dialogano con applicazioni sviluppate nel cloud. Nella realtà attuale il mainframe è spesso uno dei nodi di un’architettura distribuita molto più ampia, nella quale convivono microservizi, database relazionali, sistemi di messaggistica e applicazioni mobili. Un nodo però che quasi sempre rappresenta il punto più stabile dell’intera infrastruttura , quello sul quale convergono le operazioni più delicate mentre tutto il resto evolve con ritmi decisamente più rapidi.

A questo punto torniamo alla domanda iniziale. Se i mainframe sono ancora così importanti, perché il mercato sembra interessarsi quasi totalmente alla corsa ai sistemi dedicati all’intelligenza artificiale?

Il fatto è che anche il mondo dei mainframe non è rimasto estraneo all’intelligenza artificiale. Negli ultimi anni IBM ha introdotto acceleratori dedicati all’inferenza direttamente all’interno dei propri sistemi, consentendo di eseguire modelli addestrati per il rilevamento delle frodi, l’analisi del rischio o l’individuazione di comportamenti anomali senza spostare i dati verso piattaforme esterne. È una differenza importante. In questi casi il valore non consiste nell’addestrare un nuovo modello, ma nel prendere una decisione in pochi millisecondi nel momento esatto in cui una transazione viene autorizzata. Bloccare una carta di credito utilizzata in modo sospetto o segnalare un bonifico anomalo rappresenta un esempio concreto di come l’intelligenza artificiale possa affiancare il mainframe senza sostituirne il ruolo.

Il rallentamento delle vendite osservato da IBM va quindi interpretato all’interno di questo contesto. Le grandi piattaforme enterprise seguono cicli di rinnovo molto lunghi e gli investimenti vengono pianificati su orizzonti temporali che poco hanno a che vedere con il ritmo frenetico del mercato consumer ed è inevitabile che, in una fase storica dominata dagli investimenti nell’intelligenza artificiale, parte dei budget venga destinata alla costruzione di nuove infrastrutture dedicate al calcolo accelerato. Sarebbe però un errore interpretare questo fenomeno come il segnale della scomparsa del mainframe. Più probabilmente stiamo osservando una fase di riequilibrio degli investimenti, nella quale tecnologie differenti convivono e rispondono a esigenze differenti.

Forse il motivo per cui continuiamo a parlare poco di mainframe è che fanno esattamente ciò che dovrebbero fare: funzionano. Non generano immagini spettacolari, non scrivono testi, non partecipano alle conversazioni sui social network e raramente conquistano le prime pagine dei siti di tecnologia. Eppure ogni giorno elaborano una parte significativa delle transazioni economiche che sostengono il funzionamento della nostra società. Sono una presenza discreta, quasi invisibile, ma proprio questa invisibilità racconta il loro successo. In un settore in cui l’innovazione viene spesso misurata dalla capacità di sorprendere, il mainframe ricorda che esiste anche un altro modo di fare tecnologia: costruire sistemi così affidabili da diventare, con il tempo, parte integrante del paesaggio.
Se a questo punto vi risuona in testa il dialogo tra Neo e il Consigliere Hamman in Matrix Reloaded siete pronti per un supplemento di vacanza:
“Quasi nessuno viene qua sotto. A meno che, ovvio, non ci sia un problema. La gente
ragiona così. A nessuno interessa come funziona una cosa, finché funziona. A me questo posto
piace. E mi piace ricordare che la città riesce a sopravvivere grazie a queste macchine. Queste
macchine ci tengono tutti in vita, mentre altre macchine vengono a distruggerci. È singolare,
non trovi? Il potere di dare la vita e il potere di toglierla.”


Codemotion Collection Background
Il meglio della settimana
Selezionati per te

Vuoi scoprire più articoli come questo? Dai un’occhiata alla collection Il meglio della settimana dove troverai sempre nuovi contenuti selezionati dal nostro team.

Share on:facebooktwitterlinkedinreddit

Tagged as:ACID Transactions AI Inference Artificial Intelligence Banking Technology COBOL Data Centers Enterprise AI Enterprise Computing Enterprise Infrastructure Fault Tolerance Financial Systems High Availability IBM IBM System/360 IBM Z mainframe Mainframe Modernization Mission Critical Systems Transaction Processing

Arnaldo Morena
Passa gran parte dell’infanzia con il suo zx spectrum, coltivando un carattere mite che sfocia in improvvisi scatti di collera quando qualcuno afferma che il commodore sia superiore. Al liceo comincia a preferire gli amici all’amiga e questo gli comporta un tale disorientamento che finisce per iscriversi a economia e commercio. Quando si tratta di partire militare obietta e lo mandano a Viareggio a portare l'ambulanza, qui un losco gruppo di ingegneri pisani lo inizia alla programmazione con un linguaggio misterioso: visto che i toscani aspirano quasi tutte le consonanti, capisce che si tratta di c++ solo quando gli lasciano…
Cosa ti porti a casa: una guida alle track di Codemotion AI& Tech Conference 2026
Previous Post

Footer

Discover

  • Events
  • Community
  • Partners
  • Become a partner
  • Hackathons

Magazine

  • Tech articles

Talent

  • Discover talent
  • Jobs

Companies

  • Discover companies

For Business

  • Codemotion for companies

About

  • About us
  • Become a contributor
  • Work with us
  • Contact us

Follow Us

© Copyright Codemotion srl Via Marsala, 29/H, 00185 Roma P.IVA 12392791005 | Privacy policy | Terms and conditions