32 centimetri di legacy
Guardate l'immagine qui sopra. In alto, una vignetta classica: operai disperati davanti a due binari che non si incontrano mai, ognuno costruito con la propria logica, la propria misura, il proprio standard. In basso, la realtà: decine di tecnici fermi su un cantiere, a chiedersi come risolvere un problema che qualcuno, decenni prima, non aveva previsto.
Sembrano due mondi diversi. Eppure raccontano la stessa storia.
I 32 centimetri che bloccano l'Europa su rotaia
Oggi Il Fatto Quotidiano riporta una notizia che ha del grottesco: i treni TGV francesi a due piani, con i loro 4,32 metri di altezza, sarebbero troppo alti per molti tunnel della rete ferroviaria convenzionale italiana, costruiti nell'Ottocento.
La differenza? Trentadue centimetri rispetto ai convogli di Trenitalia e Italo, fermi a 4 metri esatti.
Il problema non riguarda i binari dell'Alta Velocità, progettati per accogliere i treni moderni. Riguarda la rete di emergenza, quella "di riserva" su cui i treni vengono dirottati quando qualcosa va storto sull'AV. In caso di guasto, i TGV instradati sulla linea convenzionale rischierebbero di bloccare anche quella, non essendo compatibili con le gallerie ottocentesche.
Il risultato? Una battaglia legale tra Ferrovie dello Stato, SNCF e l'Autorità di regolazione dei trasporti, con il TAR del Piemonte che a novembre ha dato ragione a Trenitalia e Italo, ritenendo insufficientemente motivate le deroghe concesse.
Un problema da 32 centimetri sta (forse) rallentando la liberalizzazione ferroviaria europea.
Dove l'avevo già visto? Nell'informatica
Chi lavora con sistemi software legacy riconosce immediatamente questa storia. La chiamano integration hell, il purgatorio dell'integrazione: due sistemi perfettamente funzionanti, ognuno nel proprio dominio, che si rivelano incompatibili quando qualcuno prova a farli parlare.
La vignetta nella testata di questo post non è una battuta sui ferrovieri. È il simbolo più usato negli anni '90 e 2000 per descrivere il problema dei sistemi siloed: applicazioni costruite in isolamento, con standard proprietari, che poi devono convivere su una stessa infrastruttura non progettata per entrambi.
Il parallelo è quasi chirurgico:
Il tunnel ottocentesco → Il sistema legacy che funziona benissimo per i propri scopi, ma non è stato progettato con in mente i requisiti futuri.
Il TGV a due piani → Il nuovo software (o il nuovo attore di mercato) che porta innovazione reale, ma è dimensionato secondo parametri diversi da quelli dell'infrastruttura esistente.
I 32 centimetri di differenza → L'impedance mismatch, quel piccolo ma invalicabile disallineamento di formati, protocolli, aspettative tra due sistemi apparentemente compatibili.
Il piano di emergenza che non funziona → Il fallback che si scopre inutilizzabile proprio nel momento del bisogno, perché nessuno aveva verificato la compatibilità fine a fondo.
Il vero problema non è la differenza. È che nessuno l'aveva mappata
Quello che colpisce nella vicenda TGV-tunnel italiani non è che esista una differenza di altezza. È che questa differenza sia emersa a posteriori, quando SNCF aveva già ottenuto il via libera per operare in Italia dal settembre 2027.
Rete Ferroviaria Italiana ha sollevato il problema attraverso il Pir 2026, il documento che regolamenta l'accesso alla rete. Troppo tardi? Forse strategicamente opportuno? Non sta a noi dirlo. Ma il pattern è noto a chiunque abbia gestito un progetto di integrazione software:
Il problema non viene scoperto in fase di design. Viene scoperto in produzione, o quasi.
Nelle architetture software, questo succede quando i team lavorano in parallelo senza una governance condivisa degli standard. Quando ogni sistema adotta le proprie convenzioni pensando di essere nel giusto — e lo è, nel proprio contesto. Il guaio nasce ai confini.
La soluzione? Non è tecnica. È di governance
Sia nel caso ferroviario che in quello informatico, la soluzione raramente è "abbassare il treno" o "allargare il tunnel". Quelle sono soluzioni costose, lente, spesso impossibili.
La soluzione vera è a monte: definire gli standard condivisi prima che i sistemi vengano costruiti (o acquistati). Nel software si parla di interface contracts, di API-first design, di governance architetturale. Nelle ferrovie si chiamano specifiche tecniche di interoperabilità, e l'Europa ci sta lavorando da decenni con il sistema ETCS.
Ma quando lo standard condiviso non c'è stato — o c'è stato ma qualcuno lo ha ignorato, o qualcuno ha costruito un'eccezione senza documentarla — allora ci si trova davanti a un cantiere con decine di tecnici fermi, a guardare due binari che non si parlano.
Proprio come in quella vignetta.
Cosa ci insegna questa storia
Che i problemi di integrazione non sono una specialità del software. Sono un problema sistemico ogni volta che entità diverse — aziende, paesi, sistemi informatici, reti ferroviarie — devono condividere un'infrastruttura comune senza aver concordato in anticipo le regole di convivenza.
I 32 centimetri del TGV sono anche i 32 caratteri in più che un campo di un database legacy non riesce a contenere. Sono il timestamp in formato europeo che un sistema americano non interpreta. Sono il protocollo OAuth 2.0 che un'applicazione del 2008 non supporta.
E la soluzione, in tutti i casi, passa per la stessa cosa: qualcuno che si sieda al tavolo prima, non dopo, e che faccia le domande scomode mentre c'è ancora tempo per rispondervi.
Commenti