Nell’intervista che segue, Carlo Pellegrini, CTO di RGI Group, ci offre un’ampia panoramica delle sfide che il settore assicurativo sta affrontando nell’era digitale, nonché del ruolo in evoluzione del CTO in questo contesto. Durante la conversazione, vengono affrontate le implicazioni del debito tecnologico e vengono condivisi preziosi consigli su come gestirlo in modo efficace. Inoltre, Pellegrini riflette sulla trasformazione dell’informatica e sulle sfide legate alla standardizzazione. Questa interessante chiacchierata fornisce una visione approfondita del mondo tecnologico e delle strategie necessarie per guidare le aziende attraverso le sfide del futuro.
Quali sono le sfide che come CTO ti trovi ad affrontare in RGI Group?
RGI Group è un’azienda specializzata nel campo del software per il settore assicurativo, in grado di coprire l’intero ciclo di vita delle polizze, dalla fase di preventivazione , all’acquisizione in agenzia fino alla loro scadenza. Questo ciclo include la gestione di tutte le componenti delle polizze, così come la gestione dei sinistri.
Il nostro sistema core è ampiamente utilizzato in Italia e stiamo espandendo la sua adozione anche all’estero. RGI è il vendor con il maggior numero di installazioni in Europa, come si evince dai report degli analisti indipendenti, e la nostra suite copre tutti gli aspetti del business assicurativo.
Attualmente, le sfide principali riguardano la tecnologia in senso ampio. Siamo reduci dal passaggio al cloud. Nel nostro mercato le principali tecnologie da cogliere e sfruttare correttamente sono la robotica, la IOT, l’intelligenza artificiale, considerando le restrizioni normative ed etiche che influenzano il suo utilizzo in un campo altamente regolamentato.
Secondo la tua visione, come cambierà il ruolo del CTO nei prossimi anni?
Negli ultimi anni molte aziende stanno riconoscendo che il software non è più semplicemente un accessorio, ma una componente fondamentale del loro business. Questa tendenza si osserva anche in settori inaspettati, come l’agricoltura: l’agricoltura ‘di precisione’ ha introdotto numerose applicazioni tecnologiche basate su IOT e big data. Prima il reparto IT era spesso visto solo come un costo da gestire, magari per alcune attività contabili, ma ora le aziende stanno riconoscendo che la tecnologia, chi sviluppa software, gli algoritmi sono al centro del business.
Questa trasformazione sta coinvolgendo sempre più settori industriali, spingendo il ruolo del software developer a espandersi di conseguenza. Sarà sempre più importante avere professionisti in grado di comprendere le specifiche esigenze aziendali anche in ambiti insoliti e di tradurre il tutto in soluzioni tecnologiche adeguate.
C’è un libro che ti è stato particolarmente utile nel tuo ruolo di CTO?
Ho letto “The Manager`s Path” di Camille Fournier qualche anno fa, un libro che esplora il cambio di mentalità, il percorso personale e di responsabilità quando si passa da un ruolo di contributore individuale alla gestione di un team tecnico.
In Italia, a differenza degli Stati Uniti, la divisione tra chi rimane nel campo tecnico e chi abbraccia il percorso manageriale è meno netta. Spesso chi aspira a “far carriera” e a raggiungere un certo livello nell’organizzazione è spinto solo verso ruoli manageriali. Nella nostra azienda, abbiamo cercato di affrontare questa prospettiva creando percorsi anche per chi desidera far carriera in ambito tecnico. In questo modo è possibile ambire a riconoscimenti in termini di ruolo e di remunerazione basati sugli outcome forniti, senza la necessità di gestire persone e assumere ruoli manageriali.
Quali sono i maggiori rischi del debito tecnologico?
Uno dei principali rischi riguarda la sicurezza delle applicazioni, specialmente quelle più datate sviluppate nei primi anni 2000, che non vengono aggiornate adeguatamente. Questo genera un debito tecnologico che può diventare davvero problematico. La mancanza di test adeguati e la perdita di competenze sulle tecnologie più datate rendono difficile manutenere queste applicazioni e affrontare i conseguenti problemi di sicurezza.
Per contenere questo gap e per garantire la sicurezza delle applicazioni, è importante condurre un’analisi delle dipendenze ed effettuare prontamente gli aggiornamenti necessari, evitando di incorrere in incidenti di sicurezza come si è verificato in Equifax. Inoltre, è possibile pianificare una migrazione graduale da tecnologie obsolete a nuove soluzioni, semplificando così il lavoro del team e riducendo il debito tecnico complessivo.
L’intelligenza artificiale può contribuire a migliorare la sicurezza e la scalabilità. Le applicazioni legacy spesso richiedono adattamenti quando vengono spostate in ambienti cloud o verso framework e linguaggi più attuali, generando sfide anche in termini di costi economici, che l’intelligenza artificiale generativa può contribuire a ridurre.
Quali sono gli errori più comuni che portano al debito tecnologico?
Spesso non si tratta di errori, ma di idee che inizialmente sembravano promettenti perché portavano a risultati immediati. Il software deve soddisfare principalmente le esigenze degli utenti, quindi se una scorciatoia offre un vantaggio competitivo in tempi brevi, anche se comporta un accumulo di debito tecnico, può essere una scelta vantaggiosa. L’errore è omettere di programmare il rimborso del debito: non presentando un interesse fisso come in una banca, il tech debt viene ignorato e il suo accumulo può raggiungere quote sorprendentemente rilevanti. Se il debito tecnico cresce fuori controllo, può portare a situazioni complesse, come, nei casi peggiori, la necessità di una riscrittura completa del software.
Recentemente ho letto “Defining, Measuring, and Managing Technical Debt” un articolo molto interessante di Google che analizza le ragioni dell’accumulo di debito tecnico nelle organizzazioni e come viene percepito da diverse aree aziendali, offrendo ulteriori spunti di riflessione sull’argomento.
Perché è aumentato così tanto questo deficit negli ultimi anni?
Ricordo un periodo agli inizi della carriera, in cui le organizzazioni e i grandi vendor di application server si accordavano per stabilire standard informatici che fossero largamente adottati e mantenuti per lungo tempo. C’era un impegno ad uniformare e semplificare il panorama informatico, con tutti i grandi player che collaboravano per creare una piattaforma interoperabile.
Mi focalizzo meglio sul mio background Java Enterprise: un framework che permette di sviluppare applicazioni in grado di essere eseguite su diversi server applicativi e diversi sistemi operativi senza necessità di modifiche. Constato che metodologie come questa stiano scomparendo.
Attualmente, il challenge maggiore lo si riscontra in ambito Front-End. Ogni sviluppatore adotta il framework più alla moda, abbandonandolo quando qualcosa di più interessante cattura l’attenzione, creando un ciclo negativo e continuo. Grandi aziende come Google hanno riscritto completamente framework come AngularJS, proponendone in pochi anni una nuova versione incompatibile con la precedente, mentre Microsoft ha abbandonato Silverlight, creando non pochi problemi alle aziende che vi avevano investito, aumentando l’incertezza nell’ambiente.
La standardizzazione sta gradualmente scomparendo anche nel campo del backend, e persino nell’ecosistema Java, noto per la sua stabilità, stiamo assistendo a una crescente frammentazione. La situazione di Jakarta EE, successore di Java Enterprise, è ancora incerta: Oracle ha introdotto Helidon, una tecnologia completamente diversa, mentre RedHat sta proponendo Quarkus, che della specifica adotta solo un sottoinsieme.
Di fronte a queste tendenze divergenti, assume sempre più importanza un disegno attento dell’architettura del software, che sia in grado di isolare la logica di business dalle particolarità dei framework e che permetta di adeguarsi alle nuove tecnologie senza disperdere il patrimonio accumulato in anni di sviluppo.
Anche in questo ambito la AI generativa può svolgere il ruolo di acceleratore, aiutando lo sviluppatore a convertire il codice boilerplate e semplificando molto la transizione a framework più moderni.
