Sistemi di prenotazione aerea: perché sono ancora basati su mainframe

Quando nel 2026 prenoti un volo tramite smartphone, la tua richiesta passa attraverso diversi livelli di tecnologia moderna: un'app mobile, un servizio web, un sistema di elaborazione dei pagamenti, prima di arrivare al sistema che effettivamente riserva il tuo posto. Questo sistema, nella maggior parte dei casi, è un software le cui origini risalgono agli anni '1960, che gira su un'infrastruttura che il settore dei viaggi ha cercato di sostituire per decenni senza riuscirci completamente. Sabre, Amadeus e Travelport gestiscono insieme praticamente tutte le prenotazioni aeree del mondo. Insieme elaborano miliardi di transazioni all'anno per centinaia di compagnie aeree, migliaia di agenzie di viaggio e un inventario in tempo reale che copre milioni di combinazioni di posti. Il più antico di questi sistemi risale a un mainframe IBM del 1964 che ha ridotto i tempi di prenotazione da 90 minuti a pochi secondi, cambiando per sempre l'aviazione commerciale.

La storia del perché questi sistemi rimangono dove sono non è una storia di inerzia organizzativa o di conservatorismo ingegneristico. È la storia di cosa succede quando un software si radica così profondamente in un processo operativo critico che il costo e il rischio della sua sostituzione non sono giustificabili in base a una tempistica realistica, e di come il settore ha reagito modernizzando il nucleo centrale anziché tentare di sostituirlo. Per chiunque lavori alla modernizzazione di sistemi legacy su larga scala, i sistemi di prenotazione delle compagnie aeree rappresentano il caso di studio più chiaro di cosa significhi in pratica il concetto di "troppo importante per fallire".

L'origine: perché i mainframe hanno vinto la sfida delle compagnie aeree

Il SABRE (Semi-Automated Business Research Environment) originale non era un prodotto, bensì una soluzione personalizzata per una specifica crisi operativa. Alla fine degli anni '1950, American Airlines stava crescendo più rapidamente di quanto il suo sistema di prenotazione manuale potesse gestire. Prenotare un posto richiedeva una telefonata, un controllo manuale su una scheda di inventario fisica, una prenotazione in sospeso, una richiamata e una registrazione cartacea: un processo che richiedeva in media 90 minuti per prenotazione e non era scalabile.

Quando SABRE divenne pienamente operativo nel 1964, basato su due mainframe IBM 7090 e collegato a 1,500 terminali negli Stati Uniti e in Canada, era in grado di elaborare 7,500 prenotazioni all'ora con tassi di errore prossimi allo zero. Per la prima volta, una compagnia aerea poteva mantenere la disponibilità dei posti in tempo reale, memorizzare i dati completi dei passeggeri e consentire prenotazioni istantanee su tutta la sua rete. I tempi di prenotazione si ridussero da 90 minuti a pochi secondi.

La scelta architetturale che rese possibile tutto ciò, ovvero l'elaborazione centralizzata delle transazioni su hardware mainframe, non fu dettata da ragioni filosofiche. Fu scelta perché nel 1964 era l'unica architettura disponibile in grado di soddisfare i requisiti di latenza, affidabilità e accesso simultaneo richiesti dalla gestione in tempo reale delle prenotazioni aeree. E funzionò così bene da diventare il modello architetturale su cui si basò ogni successivo sistema di prenotazione aerea.

Il Transaction Processing Facility (TPF) di IBM, originariamente progettato per SABRE, è diventato l'ambiente operativo per l'intera categoria. Secondo IBM, quasi tutte le principali banche, compagnie assicurative, rivenditori e compagnie aeree lo utilizzano ancora. Quando Amadeus fu fondata nel 1987, si basò su TPF. Quando Galileo (ora Travelport) lanciò il suo GDS, si basò su TPF. Tre generazioni di Passenger Service System coesistono oggi nell'aviazione commerciale e molti funzionano ancora su mainframe TPF, non perché la tecnologia non sia mai stata messa in discussione, ma perché la velocità di elaborazione delle transazioni, l'affidabilità e la tolleranza ai guasti che TPF offre su hardware mainframe si sono dimostrate davvero difficili da replicare su scala equivalente su architetture alternative.

Cosa fanno concretamente questi sistemi su larga scala

La portata su cui operano i sistemi di prenotazione aerea non è intuitivamente comprensibile dal punto di vista dell'ingegneria del software. Un sistema di distribuzione globale non gestisce solo la disponibilità dei posti, ma anche un problema di inventario combinatorio di una complessità sbalorditiva.

Un singolo volo transatlantico prevede centinaia di classi tariffarie. Ogni classe tariffaria ha regole specifiche: requisiti di acquisto anticipato, soggiorno minimo, periodi di esclusione, penali per il cambio, scali consentiti o meno, accordi di code-sharing con le compagnie aeree partner. Una prenotazione che coinvolge due compagnie aeree, uno scalo e un viaggio di andata e ritorno crea una matrice di potenzialmente migliaia di combinazioni tariffarie valide che devono essere verificate, prezzate e confrontate con la disponibilità in tempo reale prima che venga fornita una risposta, in genere in meno di un secondo.

Durante i periodi di punta delle prenotazioni, Sabre e Amadeus elaborano insieme decine di migliaia di transazioni al secondo. Non al minuto. Al secondo. Ogni transazione prevede la ricerca della disponibilità in tempo reale, la valutazione delle regole tariffarie, la creazione o la modifica del PNR (Passenger Name Record) e il coordinamento con i sistemi di controllo delle partenze, dei programmi frequent flyer e dei servizi ausiliari. Il tempo di risposta garantito si misura in millisecondi, perché un agente di viaggio o un motore di prenotazione che attende più di qualche secondo per la verifica della tariffa andrà in timeout e tenterà di nuovo o abbandonerà la transazione.

Il TPF su hardware mainframe offre questa velocità di elaborazione con un tasso di guasto che i professionisti IT di altri settori faticano a credere. La tolleranza ai guasti del mainframe, i processori ridondanti, i componenti sostituibili a caldo e decenni di codice del sistema operativo collaudato, garantiscono una disponibilità del 99,999% come parametro operativo standard, non come obiettivo auspicabile. Replicare tutto ciò a costi equivalenti su un'infrastruttura cloud è stata la principale sfida tecnica di ogni programma di modernizzazione IT delle compagnie aeree intrapreso dagli anni '90.

I tentativi di modernizzazione: cosa hanno realmente scoperto i programmi decennali

La storia della modernizzazione dei sistemi di prenotazione delle compagnie aeree è una storia di programmi che si sono prefissati l'obiettivo di sostituire il sistema centrale e che, anni dopo, sono giunti a una soluzione ibrida che, invece, lo integra.

Il progetto Jetstream di American Airlines, avviato negli anni 2000 con l'obiettivo esplicito di sostituire il mainframe Sabre PSS, si è concluso con l'adozione di un nuovo prodotto Sabre anziché con la costruzione di un'alternativa. L'ipotesi iniziale, secondo cui la realizzazione interna di un sistema sostitutivo avrebbe prodotto un sistema migliore in tempi più brevi, si è scontrata con la stessa realtà che si riscontra in quasi tutti i programmi di sostituzione di sistemi legacy su larga scala: il sistema esistente presentava requisiti di cui nessuno era a conoscenza finché il sistema sostitutivo non si è rivelato in grado di soddisfarli.

Dobbiamo addentrarci più a fondo nello stack e cambiare il motore principale, disaccoppiando le regole in modo da poterle modificare rapidamente. Questa affermazione, pronunciata dai vertici IT di American Airlines durante il programma Jetstream, descrive il problema con precisione. Le regole incorporate nel sistema legacy, la logica di calcolo delle tariffe, le implementazioni degli accordi di codeshare, i calcoli di conformità normativa, le integrazioni con la gestione delle entrate, si erano accumulate nel corso di decenni di cambiamenti aziendali e non erano documentate in alcun modo che ne consentisse l'estrazione senza dover eseguire il sistema esistente e osservarne il comportamento.

Il programma di modernizzazione di Sabre, avviato seriamente negli anni 2010, ha richiesto oltre un decennio e miliardi di dollari per spostare la maggior parte del codice dalle infrastrutture mainframe on-premise. Nel 2019, circa l'11% del codice di Sabre era ancora in esecuzione nei data center on-premise, mentre il resto era stato migrato. Nel febbraio 2026, Sabre ha rinnovato il suo accordo PSS a lungo termine con WestJet, a dimostrazione del fatto che, anche dopo un decennio di sforzi di modernizzazione e miliardi di dollari di investimenti, il PSS rimane il fondamento commerciale dell'attività.

Amadeus ha portato a termine una dismissione più completa dei mainframe, raggiungendo l'importante traguardo di mandare in pensione gli ultimi mainframe a favore di un'infrastruttura cloud. L'approccio di Amadeus, che prevedeva la sostituzione graduale dei componenti funzionali mantenendo inalterato il modello dati e l'architettura delle transazioni, ha preservato efficacemente le decisioni architetturali originarie del mainframe, anche con il cambiamento dell'hardware. La semantica delle transazioni, la struttura PNR, la logica di gestione dell'inventario: tutti questi elementi sono stati trasferiti su un'infrastruttura moderna, mantenendo la loro progettazione fondamentale.

Perché la sostituzione è più difficile di quanto sembri: la complessità nascosta

La spiegazione standard del perché i sistemi di prenotazione delle compagnie aeree continuino a funzionare su mainframe è legata ai costi e ai rischi. Entrambi sono reali. Ma sono sintomi di una realtà tecnica più profonda che vale la pena comprendere a fondo, perché si applica a ogni programma di modernizzazione di sistemi legacy critici.

Regole aziendali che esistono solo nel codice. La logica di calcolo delle tariffe in un sistema di distribuzione globale rappresenta decenni di requisiti normativi, accordi bilaterali tra compagnie aeree, revisioni degli standard IATA e modifiche alle regole aziendali, nessuno dei quali è documentato in una forma indipendente dal codice che li implementa. La specifica è l'implementazione. Sostituire l'implementazione senza la specifica significa osservare il comportamento del sistema esistente in modo esaustivo per ricostruire ciò che la specifica avrebbe detto, un processo che richiede anni e non è mai completo, perché la copertura dell'osservazione non può mai essere abbastanza completa da individuare ogni caso limite.

Semantica delle transazioni che le architetture moderne faticano a replicare. TPF fornisce un'elaborazione sincrona e atomica delle transazioni con coerenza garantita per l'intero PNR, la prenotazione del posto, l'aggiornamento dei dati del passeggero, l'autorizzazione al pagamento e la conferma, il tutto eseguito come un'unica unità atomica o non eseguito affatto. Replicare questo su architetture distribuite a microservizi richiede un'attenta orchestrazione, transazioni di compensazione e una gestione distribuita dei blocchi, che risulta complessa e potenzialmente più lenta rispetto all'equivalente sincrono su mainframe. L'esperienza del settore aereo dimostra che la "coerenza finale" non è una proprietà tollerabile per la gestione della disponibilità dei posti: un volo in overbooking rappresenta un guasto concreto e catastrofico a livello operativo, non una temporanea incoerenza da risolvere in seguito.

La superficie di integrazione. Un PSS (Processing System) maturo di una compagnia aerea è connesso a centinaia di sistemi esterni: controllo delle partenze, gestione delle entrate, programmi frequent flyer, sistemi aeroportuali, connessioni GDS di terze parti, partner di code-sharing, reporting normativo e altro ancora. Ogni connessione ha contratti di interfaccia specifici, formati di messaggio, requisiti di temporizzazione e comportamenti di gestione degli errori, che il sistema esistente ha implementato e attorno ai quali è stato costruito ogni sistema dipendente. La sostituzione del PSS richiede o il mantenimento simultaneo di tutti i contratti di interfaccia esistenti (il che limita l'architettura di sostituzione) o il coordinamento delle modifiche con ogni sistema dipendente (il che amplia l'ambito oltre ciò che un singolo programma può gestire).

Il problema dei dati in tempo reale. Le prenotazioni aeree sono dati in tempo reale, prenotazioni effettuate con mesi di anticipo che devono essere rispettate esattamente come prenotate. Non esiste un punto di transizione netto in cui i dati del vecchio sistema possano essere semplicemente abbandonati. La migrazione deve trasferire ogni PNR attivo dal vecchio al nuovo sistema, con tutte le regole, tariffe, restrizioni e servizi accessori associati intatti. La migrazione dei PNR su scala globale, con zero perdita di dati e garanzia di comportamento identico, si è dimostrata una delle sfide tecniche più complesse nella modernizzazione aziendale.

La risposta architettonica: modernizzare attorno al nucleo centrale.

L'approccio che ha effettivamente avuto successo, in Amadeus, in Sabre e nelle singole compagnie aeree, non è la sostituzione, bensì l'integrazione strategica e l'estrazione graduale.

L'incapsulamento delle API espone le funzioni di prenotazione principali come moderne API REST o SOAP, consentendo alle nuove applicazioni di interagire con il sistema legacy attraverso un'interfaccia moderna senza modificare la logica di transazione principale. Le compagnie aeree hanno sviluppato app per dispositivi mobili, motori di prenotazione web e strumenti di assistenza clienti basati su livelli API che traducono le richieste moderne in chiamate di transazione TPF e restituiscono risposte strutturate. Il terminale a schermo verde viene sostituito da una moderna interfaccia grafica; l'elaborazione sottostante delle transazioni rimane invariata.

Il metodo del "fico strangolatore" viene applicato alle funzioni non essenziali. Le funzioni adiacenti al nucleo centrale, come la gestione dei ricavi, la gestione dei programmi fedeltà, la reportistica e l'analisi, la pianificazione del personale, vengono estratte una alla volta e re-implementate su infrastrutture moderne. Ogni estrazione riduce l'ingombro del sistema legacy senza intaccare il nucleo transazionale, che presenta il rischio maggiore. Nel corso di oltre un decennio di estrazioni incrementali, il ruolo del sistema legacy si restringe, passando da una piattaforma applicativa onnicomprensiva a un motore transazionale mirato.

Infrastruttura cloud con architettura preservata. La dismissione dei mainframe di Amadeus ha spostato i carichi di lavoro sull'infrastruttura cloud, preservando al contempo l'architettura transazionale originaria del mainframe. L'hardware è cambiato; la progettazione del software, il modello dati, la semantica delle transazioni e la struttura PNR sono rimasti invariati, preservando le scelte architetturali che si erano dimostrate corrette nel corso dei decenni.

Nuova gestione di offerte e ordini in parallelo al sistema PNR tradizionale. Lo standard IATA ONE Order, che sostituisce i record basati su PNR con un moderno modello di gestione degli ordini, viene implementato dalle compagnie aeree come livello aggiuntivo al sistema PNR esistente. Le tecnologie di nuova generazione per offerte e ordini di Sabre, menzionate nel rinnovo del contratto con WestJet per il 2026, indicano questa come la strada da seguire, non una sostituzione del PSS, ma l'aggiunta di un moderno livello commerciale che crescerà nel tempo per gestire una quota sempre maggiore di prenotazioni, mentre il sistema PNR principale gestirà la parte restante.

Cosa significa questo per qualsiasi modernizzazione di sistemi legacy di importanza critica

La storia del sistema di prenotazione aerea non è un caso isolato nel settore dell'aviazione. È l'esempio più lampante di uno schema che si riscontra nei sistemi centrali delle banche, nella gestione delle polizze assicurative, nella fatturazione delle telecomunicazioni e nell'elaborazione delle prestazioni sociali: un software che diventa la specifica autorevole delle regole aziendali, funge da hub di integrazione per decine di sistemi dipendenti e opera con requisiti di scalabilità e affidabilità tali da rendere una sostituzione radicale semplicemente impraticabile.

Le lezioni apprese sono valide in ogni settore:

Estrarre le regole aziendali dal codice, prima di iniziare qualsiasi modernizzazione, non è facoltativo. I programmi COBOL e TPF che implementano la costruzione delle tariffe, la logica degli accordi di codeshare e le regole di conformità normativa sono l'unica documentazione superstite di tali regole. Una modernizzazione che non estragga e convalidi prima questa logica non può produrre una soluzione sostitutiva che si comporti correttamente in tutti i casi, perché non può conoscere tutti i casi senza analizzare tutto il codice.

La mappa delle dipendenze determina la sequenza di migrazione. Nessuna compagnia aerea è mai riuscita a sostituire con successo il proprio PSS partendo dal componente più critico e integrato. Ogni modernizzazione di successo è iniziata dai componenti periferici, ovvero dai sistemi di reporting, dai servizi ausiliari, dalle funzioni amministrative non critiche, per poi procedere gradualmente verso l'interno. Tale sequenza deriva dal grafo delle dipendenze: i componenti con il minor numero di dipendenze in entrata sono quelli più sicuri da affrontare per primi.

La validazione operativa in ogni fase è imprescindibile. L'approccio di validazione a doppio ciclo, che prevede l'esecuzione del nuovo sistema in parallelo con il vecchio, il confronto dei risultati e la verifica dell'equivalenza prima di qualsiasi trasferimento di traffico, è l'unico in grado di soddisfare i requisiti di affidabilità dei sistemi in cui i guasti possono avere conseguenze fisiche, finanziarie e normative.

Come SMART TS XL Si applica all'analisi del patrimonio pregresso delle compagnie aeree.

Le compagnie aeree che utilizzano Sabre o Amadeus PSS insieme ai propri programmi COBOL, sistemi di calcolo delle tariffe, contabilità dei ricavi, calcolo dei punti fedeltà e reporting normativo, si trovano ad affrontare la stessa sfida analitica di ogni programma di modernizzazione dei mainframe aziendali: comprendere cosa contiene effettivamente il codice prima di decidere come utilizzarlo.

SMART TS XL'S analisi statica del codice Questo processo estrae la logica delle regole aziendali incorporate nei programmi COBOL, le regole di convalida delle tariffe, i calcoli di contabilità dei ricavi, la logica di idoneità ai livelli di fidelizzazione, che non esiste in nessun altro luogo se non nel codice del programma. Per le compagnie aeree che intendono modernizzare i sistemi adiacenti senza intervenire sul nucleo del PSS, questa estrazione produce le specifiche che il sistema di sostituzione deve rispettare.

La mappatura delle dipendenze dell'applicazione crea il grafo delle dipendenze che determina la sequenza di migrazione: quali programmi lato compagnia aerea dipendono da quali flussi di dati provenienti dal PSS, quali programmi di reporting dipendono da quali output batch COBOL, quali sistemi a valle devono essere aggiornati quando un componente cambia. Il grafo delle dipendenze è ciò che rende possibile una modernizzazione incrementale e sicura, lo stesso approccio che Sabre e Amadeus hanno utilizzato per i sistemi core, applicato al codice lato compagnia aerea che li circonda.

La capacità di analisi d'impatto risponde alla domanda che precede ogni decisione di modernizzazione: se questo programma cambia, cos'altro ne risentirà? Per i sistemi delle compagnie aeree, dove una modifica di calcolo in un programma di contabilità dei ricavi può influire contemporaneamente sulla rendicontazione normativa, sulla liquidazione dei partner e sul consolidamento finanziario, conoscere la portata dell'impatto prima di apportare qualsiasi modifica è il prerequisito per un controllo delle modifiche che soddisfi i requisiti di affidabilità della compagnia aerea.

L' analisi di modernizzazione dei sistemi legacy fornisce un inventario completo del sistema preesistente: ogni programma in esame, la sua complessità, le sue dipendenze, la percentuale di codice obsoleto e la sua classificazione del rischio di migrazione. La lezione appresa da ogni programma di modernizzazione delle compagnie aeree, ovvero iniziare dai margini, procedere verso l'interno e validare a ogni passo, richiede la conoscenza dei margini e della struttura delle dipendenze. Tale conoscenza deriva dall'analisi strutturale del codice effettivo, non dalla documentazione redatta prima che il codice si evolvesse.

Gli strati geologici del software critico per le missioni

Quando prenoti un volo su smartphone nel 2026, interagisci con un software composto da diversi livelli geologici distinti. L'interfaccia moderna in superficie. Il livello API sottostante. Il motore di transazione PSS ancora più in basso, che gira su un'infrastruttura sostanzialmente cambiata dagli anni '1960, ma che conserva la semantica delle transazioni e i modelli di dati che erano corretti al momento della loro progettazione e si sono dimostrati troppo affidabili per essere abbandonati.

Il sistema di prenotazione delle compagnie aeree non è un fallimento della modernizzazione. È il risultato di sei decenni di decisioni razionali prese da ingegneri e dirigenti che, ogni volta che veniva proposta una sostituzione, comprendevano che il rischio di sbagliare superava il costo di mantenere ciò che funzionava. I sistemi che sopravvivono così a lungo lo fanno perché se lo meritano, transazione dopo transazione, volo dopo volo, stagione dopo stagione.

La lezione pratica per qualsiasi team di modernizzazione non è che i vecchi sistemi non debbano mai essere sostituiti. È che la decisione di sostituirli dovrebbe essere presa con una conoscenza completa di ciò che contengono, di cosa dipende da essi e di quale sia effettivamente la portata del cambiamento, non con stime ottimistiche fatte prima di aver misurato la complessità. Il settore aereo lo ha imparato a sue spese. Gli strumenti di analisi che forniscono una conoscenza strutturale completa prima ancora che venga scritta la prima riga di nuovo codice sono ciò che rende possibile impararlo in modo meno costoso.