Quando le scelte tecnologiche sono prigioniere del passato

La fase di progettazione dovrebbe essere appannaggio di chi possiede competenze tecniche aggiornate, professionisti che conoscono a fondo l’arte di tradurre requisiti in soluzioni concrete. Nella realtà, questa fase critica viene spesso dominata da manager IT la cui cultura tecnologica si è cristallizzata decenni fa, ai primi anni 2000 o addirittura all’epoca dei mainframe.

Invece di delegare a chi ha competenze attuali, questi manager controllano ogni scelta: prodotti, linguaggi, framework, ambienti di sviluppo, infrastrutture, processi di deploy. Le decisioni tecnologiche vengono prese non in base al problema da risolvere, ma in base a cosa si conosce, cosa si è sempre fatto, cosa è considerato “sicuro”. Il risultato è un’architettura che riflette più le competenze obsolete del decisore che le reali esigenze del progetto.

La sindrome del “come si è fatto prima”

Nella maggioranza dei progetti IT, nessuna soluzione viene studiata in funzione delle esigenze specifiche. Si adotta il mantra “Come si è fatto nel progetto precedente”. La soluzione è sempre quella, “sicura e consolidata”. Non importa se il nuovo progetto ha requisiti diversi, vincoli differenti, volumi di dati diversi, utenti diversi. Se ha funzionato prima, funzionerà ora.

Questa mentalità ignora che ogni problema è unico. Un’architettura perfetta per un sistema gestionale interno può essere inadeguata per un’applicazione web ad alta concorrenza. Una soluzione ottima per pochi utenti specializzati diventa un disastro con migliaia di utenti anonimi. Ma l’analisi contestuale viene sacrificata per la familiarità.

Con il passare dei progetti, si stratificano modifiche su una base che non è più adeguata da anni. Pattern pensati per contesti specifici vengono applicati ovunque, perdendo di senso.

Il tradizionalista innovatore

Esiste una variante: il manager che a ogni progetto inserisce un pezzettino di novità per sentirsi moderno. Ma la relega a aree marginali e sicure, dove se qualcosa non funziona il danno è contenuto.

Il core rimane sempre obsoleto, basato su tecnologie di decenni fa. Ma si contorna con qualche novità che fatica a integrarsi con il legacy. App mobile moderne che comunicano con mainframe AS400. Frontend React che interrogano backend COBOL. Tecnologie separate da decenni che devono convivere, creando layer di adattamento sempre più complessi.

Il trauma da innovazione fallita

“L’ultima volta che abbiamo provato qualcosa di nuovo è stato un disastro”. Un tentativo fallito diventa la scusa per non provare mai più nulla di simile.

MongoDB non ha funzionato? Allora tutti i database NoSQL sono da evitare. Un framework JavaScript ha creato problemi? Torniamo alle tecnologie dei primi anni 2000. Il risultato è un’organizzazione paralizzata dalla paura. Ogni proposta di innovazione viene accolta con scetticismo e aneddoti di disastri passati.

I musei tecnologici viventi

Il risultato sono sistemi che funzionano come musei tecnologici viventi. Strati di codice fossile che raccontano la storia dell’informatica. Framework così vecchi che potrebbero essere esposti in musei. Librerie che non ricevono aggiornamenti di sicurezza da anni.

Queste architetture ibride creano problemi enormi. Gli sviluppatori devono essere esperti di tecnologie moderne e legacy quasi dimenticati. La documentazione è inesistente perché chi ha scritto quel codice è in pensione.

Mentre il mondo corre verso cloud computing e intelligenza artificiale, ci sono organizzazioni che discutono se passare da PHP 5 a PHP 7 sia troppo rischioso.

Il costo nascosto dell’immobilismo

Questa resistenza al cambiamento ha costi significativi. Gli sviluppatori competenti non vogliono lavorare con tecnologie obsolete. Il recruitment diventa difficile. La produttività soffre perché strumenti vecchi richiedono più tempo. La sicurezza è compromessa perché software non aggiornato accumula vulnerabilità.

E quando finalmente si decide di modernizzare, il debito tecnico accumulato rende l’operazione tremendamente costosa. Anni di patch e workaround hanno creato dipendenze nascoste. Nessuno osa toccare certi pezzi di codice perché nessuno capisce più come funzionano.

La stabilità come scusa

La giustificazione comune per mantenere tecnologie obsolete è la stabilità. “Il sistema funziona, perché cambiarlo?” È un argomento fallace. La stabilità non è attributo intrinseco di tecnologie vecchie.

Un sistema basato su tecnologie moderne, progettato bene, è stabile quanto uno basato su tecnologie vecchie. La vera ragione per cui i sistemi vecchi sembrano stabili è che sono cambiati poco. Ma questa stabilità è illusoria. Sotto la superficie si accumulano problemi: dipendenze da librerie non supportate, incompatibilità con nuovi sistemi operativi.

Quando le colpe vengono distribuite

Quando qualcosa non funziona in questi sistemi, la colpa viene imputata agli sviluppatori. Sono loro i responsabili delle lentezze, dei malfunzionamenti. Il fatto che stiano lavorando con architetture obsolete e decisioni prese decenni fa viene dimenticato.

Gli sviluppatori vengono criticati per non essere produttivi mentre devono imparare tecnologie che il mercato ha abbandonato. Vengono biasimati per bug in sistemi dove la documentazione non esiste.

L’equilibrio necessario

Trovare l’equilibrio tra innovazione e tradizione è complesso ma necessario. Non si tratta di adottare ciecamente ogni nuova tecnologia. Serve criterio, analisi, capacità di valutare quando una novità è matura.

Ma l’equilibrio non si ottiene copiando soluzioni di progetti precedenti. Si ottiene analizzando il problema specifico e costruendo l’architettura su misura. La progettazione è un atto creativo che definisce il successo del progetto. Serve il coraggio di dire: “In questo progetto facciamo diversamente, perché il contesto è diverso”.

Verso decisioni tecnologiche consapevoli

Le decisioni tecnologiche dovrebbero essere prese da chi ha competenze aggiornate. Serve coinvolgere gli sviluppatori che lavorano quotidianamente con le tecnologie, non solo i manager che le hanno studiate decenni fa.

Serve creare cultura di apprendimento continuo, dove provare tecnologie nuove è incoraggiato, dove i fallimenti sono opportunità di apprendimento. Serve riconoscere che la tecnologia evolve rapidamente e che restare fermi non è sicurezza ma lenta obsolescenza.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT