Qualche tempo fa mi è capitato di coordinare il rearchitect di un sistema software per la pubblica amministrazione. Un sistema interno, usato da meno di trenta persone, non tutte concorrenti, non tutti i giorni. Esposto anche ai cittadini, per funzionalità di consultazione e qualche richiesta semplice: quattro, cinque al giorno nei momenti di punta.

Quando ho aperto il codice, ho trovato un'architettura a più livelli che avrebbe retto senza problemi al più grande click day nazionale. Livelli di astrazione sovrapposti, interfacce per ogni componente, separazione formale tra ogni responsabilità del sistema. Tutto corretto. Tutto documentato. Tutto, per quel contesto, completamente inutile.

Non era un sistema mal costruito. Era un sistema sovradimensionato. E quella differenza, tra mal costruito e sovradimensionato, è il punto di questo articolo.

Due tipi di complessità

C'è una complessità che serve e una che non serve.

La prima nasce dal problema. Quando un sistema integra più fonti di dati, deve restare coerente sotto carico, gestire guasti senza perdere informazioni, gli strati di astrazione che lo governano hanno una ragione precisa. Si paga un costo architetturale, ma si risolve un problema reale. Questi casi esistono, ma sono la minoranza. La maggior parte del software prodotto per la PA non ha nulla di distribuito, nulla da integrare su scala, nulla che giustifichi quella struttura. Eppure quella struttura c'è quasi sempre.

La seconda è la complessità che non risponde a nessun bisogno del sistema. È presente perché ci si aspetta che ci sia: perché "si fa così", perché dà l'idea di un prodotto serio, perché nessuno si è mai fermato a chiedere se servisse davvero. È quella che chiamo complessità rituale: risponde a una forma, non a una funzione.

Il problema della PA italiana non è la complessità necessaria. È la quantità di complessità rituale che produce, paga e manutiene.

Perché il sistema la produce

Si tende ad attribuire questa complessità a chi scrive il codice. È un errore di prospettiva. La complessità rituale non nasce quasi mai da una scelta tecnica. Nasce dagli incentivi.

I capitolati tecnici della PA raramente impongono uno specifico modo di costruire il software. Quello che fanno è premiare, nei criteri di valutazione, ciò che è formalmente misurabile: la quantità di documentazione, la presenza di una struttura articolata, l'aderenza a un'idea generica di "soluzione enterprise". La semplicità, che è più difficile da misurare di un elenco di componenti, raramente viene valorizzata.

A questo si aggiunge l'avversione al rischio. In un appalto pubblico, sembrare troppo essenziali è pericoloso: espone alla domanda "è abbastanza robusto?", molto più di quanto un eccesso di struttura esponga alla domanda "serviva davvero tutto questo?". La prima domanda viene fatta ai collaudi. La seconda quasi mai.

Il fornitore, di fronte a questi incentivi, risponde in modo razionale: costruisce ciò che viene premiato. Non serve malafede. Serve solo un sistema che misura la qualità del software in base alla forma, e non all'efficacia. È quel sistema il problema, non chi vi si adatta.

Quanto costa

La complessità rituale ha un prezzo, e si paga due volte.

La prima volta è alla costruzione. Lo stesso software, a parità di funzioni richieste, costa per la pubblica amministrazione diverse volte tanto rispetto a quanto costerebbe per un'impresa privata di dimensioni paragonabili.

Una parte di questo divario è legittima: vincoli normativi, requisiti di accessibilità, sicurezza, interoperabilità con i sistemi pubblici sono costi reali, dovuti, giustificati. Ma una parte significativa non ha alcuna giustificazione tecnica. È il costo della struttura che nessuno ha messo in discussione, della documentazione prodotta per requisito, del tempo di sviluppo che cresce più che proporzionalmente con una complessità che non serviva.

Questo prezzo iniziale, però, è solo l'anticipo. Il costo vero arriva dopo, e si accumula nel tempo.

Tempo di ingresso. Chi subentra su un sistema in cui la logica è distribuita su molti livelli impiega settimane solo per orientarsi. Settimane in cui non produce, ma costa.

Tempo di diagnosi. Quando qualcosa non funziona, e prima o poi succede, risalire all'origine del problema significa attraversare ogni strato. In un sistema essenziale è questione di ore. In uno sovrastrutturato, di giorni.

Inerzia al cambiamento. Più il sistema è articolato, più ogni modifica tocca componenti diversi, richiede coordinamento, aumenta il rischio di regressioni. Il risultato pratico è che le modifiche si fanno sempre meno. Il software smette di evolvere e invecchia mentre è ancora in uso.

Il costo che non finisce mai

C'è un ultimo elemento che trasforma un costo alto in un costo permanente: la documentazione.

I capitolati la richiedono, e viene prodotta. Ma nella maggior parte dei casi che ho visto viene prodotta per soddisfare il requisito, non per essere utile a chi lavorerà sul sistema in futuro. Descrive la struttura, non il funzionamento. Elenca i componenti, ma non spiega perché esistono, come si comportano nei casi limite, quali decisioni sono state prese e per quale ragione. È documentazione che esiste e non documenta.

La conseguenza è che la conoscenza che conta, quella accumulata da chi ha costruito il sistema, non è scritta da nessuna parte. Resta dove è sempre stata: nella testa del fornitore.

Da qui nasce il lock-in. Un sistema sovradimensionato e documentato male non è cedibile in pratica, anche quando lo è formalmente: chiunque subentri deve ricostruire da zero la comprensione del sistema, e cambiare fornitore diventa troppo rischioso, troppo lungo, troppo costoso. Che questo sia un esito cercato o semplicemente il prodotto del modo in cui il sistema è stato costruito, per il committente cambia poco. Il risultato è lo stesso: paga la costruzione una volta, e la manutenzione per sempre, spesso allo stesso fornitore, perché alternative praticabili non esistono più.

Vale la pena ricordarlo quando si parla di modernizzazione: spostare un sistema su un'infrastruttura nuova non risolve questo problema, se l'architettura e la documentazione restano quelle di prima. Il lock-in non sta nel luogo dove il software gira. Sta nel software.

Cosa dovrebbe cambiare

Niente di quanto ho descritto richiede tecnologie nuove o principi rivoluzionari. Richiede di applicare con coerenza alcune cose che si dovrebbero già fare.

Requisiti proporzionati. La struttura di un sistema dovrebbe essere dimensionata sul problema reale: quanti utenti, quale carico concorrente, quale criticità operativa. Un sistema usato da trenta persone non dovrebbe essere progettato come se ne servisse trentamila. Sembra ovvio. Nella pratica, quasi mai lo è.

Documentazione utile. Una documentazione andrebbe valutata su un criterio solo: un soggetto terzo, con quella in mano, è in grado di riprendere il sistema in autonomia? Se la risposta è no, il numero di pagine non conta. Conta solo quello.

Reversibilità reale. La possibilità di cambiare fornitore dovrebbe essere un requisito esplicito, verificato e misurabile, non un'assunzione teorica mai messa alla prova. Un sistema che non si può lasciare è un sistema sul quale si è già ceduto il controllo.

Competenza lato committente. Tutto il resto è inutile senza qualcuno, dalla parte di chi commissiona, capace di valutare tecnicamente ciò che riceve. Di riconoscere la complessità rituale quando la vede, e di avere l'autorità per rifiutarla anche quando il capitolato sembrerebbe legittimarla. Senza questa figura, ogni requisito ben scritto resta sulla carta.

La semplicità non è una scorciatoia né una rinuncia alla qualità. È una scelta progettuale, e spesso la più difficile da difendere. Renderla la scelta premiata, invece che quella sospetta, è il vero cambiamento.

Una nota sull'intelligenza artificiale

Tutto questo precede l'intelligenza artificiale, ma l'AI lo rende più urgente, perché è un amplificatore.

Per impostazione predefinita, gli strumenti di AI generativa producono architetture elaborate: sono stati addestrati sul codice esistente, che di complessità rituale è pieno. Ma "per impostazione predefinita" è la parola chiave. Guidata con precisione, con il contesto del sistema definito chiaramente, i vincoli reali, il carico atteso, la natura delle operazioni, la stessa AI produce soluzioni essenziali e motivate. Può inoltre analizzare e documentare sistemi esistenti mal documentati, accelerare la diagnosi su codice che nessuno conosce per intero. Usata con competenza, è uno degli strumenti più efficaci per recuperare gestibilità su sistemi che l'hanno persa.

Usata senza competenza, fa il contrario. L'AI non riduce la complessità rituale: la produce più in fretta. Un sistema mal progettato che a mano richiedeva sei mesi con l'AI si genera in tre settimane. Si risparmia tempo. Il danno è identico.

La variabile decisiva non è lo strumento, e non è l'infrastruttura. È chi lo guida: una figura con competenza architetturale, conoscenza del dominio applicativo e capacità di valutare il risultato in modo critico, non solo di produrlo. Nella PA italiana questa figura esiste. È solo troppo rara. Ed è lì, più che altrove, che varrebbe la pena investire.