Architettura o Accrocchio? Come smettere di pagare gli interessi sulla propria obsolescenza.

Questa non è una saga spaziale. È il solito casino.

In agenzia, che sia a Rosignano o a Kampala, c'è una frase che sentiamo ronzare più spesso del dovuto, una di quelle citazioni colte che servono a nobilitare un problema molto più terra-terra: "The old protect the young, and then the young protect the old." Bello, eh? Peccato che nel nostro campo, quello dell'architettura software, la traduzione sia quasi sempre: "il vecchio sistema legacy tiene in ostaggio quello nuovo, finché entrambi non vanno a gambe all'aria". Vi suona familiare? L'applicazione che è il cuore del business, quella che non si può toccare, che all'improvviso inizia a tossire. Rallenta. O, peggio, collassa sotto il peso dell'ennesima richiesta del marketing. Ecco, quello è il momento esatto in cui il "vecchio" smette di proteggere e diventa una zavorra. E la promessa che il "giovane" – l'innovazione, la nuova feature geniale – un giorno ripagherà il favore, si dissolve nel fumo denso del debito tecnico.

Il costo di non fare nulla: il debito tecnico è un parassita con un tasso d'interesse da usura

Smettiamola di chiamarlo "debito tecnico". Chiamiamolo per quello che è: un parassita. Un costo invisibile ma molto reale che si annida nel software e che, oggi, ha raggiunto proporzioni epidemiche. Le ultime stime dicono che questo scherzo può arrivare a mangiare fino al 40% del budget IT. Non in innovazione, no. In manutenzione. In pezze messe su sistemi che andavano pensionati quando ancora si usava il floppy disk. Le aziende americane bruciano circa 370 milioni di dollari l'anno per colpa di 'sta roba, tra manutenzione, tentativi di modernizzazione falliti e quel freno a mano tirato che impedisce qualsiasi scatto in avanti. Non è un'ipotesi. È una passività a bilancio. I sintomi li conoscete: lentezza esasperante, bug che resuscitano come zombie, i nuovi sviluppatori che guardano il codice come se fosse scritto in aramaico antico. E quella sensazione di panico strisciante a ogni deploy. Andare avanti così non è "risparmiare sul software". È finanziare la propria, costosissima, obsolescenza.

C'è solo un modo per uscirne: smontare e ricostruire. Con criterio.

Modernizzare il legacy non è più un progetto da fare "quando ci sarà tempo". È una questione di sopravvivenza. Il mercato globale della modernizzazione, valutato quasi 30 miliardi di dollari, è previsto crescere con un ritmo quasi del 18% annuo. Ma attenzione a non fare il giro del fumo. Se fino a ieri la parola d'ordine era re-platforming (sposto il monolite da A a B), oggi la strategia che sta staccando tutte le altre è il re-architecting. La ristrutturazione profonda. Le aziende che hanno capito il gioco stanno smontando i loro monoliti pezzo per pezzo, trasformando la logica di business in microservizi e design basati su domini. Usano tool che automatizzano l'estrazione e la decomposizione. Il dogma è cambiato: le applicazioni non sono più un blocco unico, ma un ecosistema di componenti distribuite. Alcune on-prem, altre su hyperscaler per sfruttare AI e scalabilità dove serve, e solo quando serve.

Architettura Continua: l'antidoto alla vecchiaia del software

Da noi, a ThinkPink, abbiamo smesso da tempo di pensare all'architettura come a un progetto con un inizio e una fine. Abbiamo interiorizzato la filosofia della Continuous Architecture. Non è un monolite da scolpire nel marmo, ma un organismo che si adatta. Brian Graves di Forum One la definisce un processo di miglioramento iterativo. Tradotto dal gergo da conferenza: si assicura che il sistema sia sempre ottimizzato per quello che deve fare *oggi*, non per quello che pensavamo dovesse fare due anni fa. Per le PMI italiane che vogliono provare a giocare fuori dal cortile di casa, questo approccio è l'unica via. Permette di reagire, di gestire picchi di domanda e di cambiare pezzi in corsa senza buttare giù tutta la baracca.

Come ci si arriva? Smettendo di pensare per progetti e iniziando a pensare per prodotti. Concentrandosi sugli attributi di qualità (scalabilità, sicurezza, manutenibilità), non solo sulle funzioni. Ritardando ogni decisione di design che non sia strettamente necessaria, perché ogni scelta fatta troppo presto è un potenziale vicolo cieco. I nostri ragazzi a Kampala ce lo insegnano ogni giorno: la flessibilità è la risorsa più preziosa quando le condizioni non sono ottimali. Bisogna architettare per il cambiamento, usando la "potenza del piccolo": componenti piccole, indipendenti. I microservizi non sono una moda da curriculum, sono una necessità operativa. E, soprattutto, bisogna architettare pensando a chi dovrà poi buildare, testare, deployare e far funzionare quella roba. Se architetti e DevOps non si parlano, stai solo costruendo un altro, costosissimo, problema.

L'AI non è la bacchetta magica. È un martello pneumatico.

L'intelligenza artificiale sta cambiando le regole del gioco, è innegabile. Dai suggerimenti di codice ai test automatici, sta oliando ingranaggi che prima erano arrugginiti. L'AI generativa, poi, accelera la conversione di codice legacy e aiuta a ripensare interi sistemi. IBM usa GitHub Copilot per migrare codice COBOL, AWS ha sviluppato agenti AI per smontare architetture mainframe. Tutto bellissimo. Ma veniamo al punto: in Italia, il mercato AI vale quasi 2 miliardi di euro, ma solo l'8% delle PMI ha avviato un progetto concreto. Questo non è un "gap tecnologico", è un problema di fondamenta. Prima si costruisce un'infrastruttura dati solida, poi si comprano i giocattoli AI. Chi lo ha fatto (il 92% degli early adopter) riporta un ritorno medio del 49% sull'investimento. Un segnale piuttosto chiaro che il rischio più grande, oggi, è stare fermi.

Dalla Toscana all'Uganda: la resilienza come unico standard

Avere un piede a Rosignano e uno a Kampala ci ha insegnato una cosa: la resilienza non è un'opzione. La pignoleria toscana ci impone di fare software "fatto bene", non "purché funzioni". L'esperienza in Uganda ci obbliga a trovare soluzioni che massimizzino l'impatto con il minimo delle risorse. Vediamo PMI italiane incatenate a sistemi rigidi, mentre la modernizzazione permetterebbe loro di avere infrastrutture distribuite e scalabili. Prendete Alpitour World: hanno migrato e rifattorizzato le loro applicazioni core su AWS in 16 mesi. Risultato? Scalabilità, manutenibilità e accesso a strumenti di AI che prima si sognavano. Il loro CIO, Francesco Ciucciareli, l'ha messa giù semplice: "il rischio della 'non-azione' [...] è ormai più grande e più forte di quello per affrontare il cambiamento". Qui in ThinkPink la vediamo allo stesso modo. Investire in un'architettura continua non serve solo a schivare i costi del debito tecnico. Serve a costruire le fondamenta su cui poggerà il business di domani. È l'unico modo per far sì che i "vecchi" (un'architettura solida) proteggano davvero i "giovani" (l'innovazione), e che i "giovani" (i nuovi moduli) rendano tutto il sistema più forte. Giorno dopo giorno.