Termine prestato all’Ict dall’ingegneria, dove indica la capacità di un materiale di resistere agli urti senza rompersi né deformarsi, la resilienza è la capacità di un sistema informatico di resistere sia ad eventi imprevisti sia all’uso continuato per garantire la disponibilità del servizio erogato e limitare al massimo (idealmente, in modo inavvertibile dall’utente) il degrado delle prestazioni. Questa dote, ovviamente primaria per qualsiasi servizio che occorra al business e all’attività di un’impresa, dipende da tre elementi: la qualità dell’infrastruttura (hardware e piattaforma operativa), quella del software erogante il servizio e la capacità di governare entrambi, in ambienti It articolati e in evoluzione come sono oggi quelli della maggior parte delle organizzazioni. Una tematica complessa che soprattutto negli aspetti riguardanti la governance, è stata affrontata in una tavola rotonda organizzata da Cast e sponsorizzata da Ibm Italia, con la collaborazione del Boston Consulting Group e di ZeroUno, che si è svolta lo scorso dicembre a Milano e alla quale hanno partecipato Executive It del comparto Finance e Assicurazioni.
Un momento della Tavola Rotonda organizzata da Cast
Dopo il saluto di Massimo Crubellati, Country manager di Cast, ai presenti, in massima parte Cio e ‘C level’ manager di banche e assicurazioni, Fabrizio Pessina, responsabile Technology Advantage Practice del Boston Consulting Group, ha mostrato come in mancanza di un approccio alla sicurezza end-to-end, che integri strategie, infrastrutture e asset applicativi, anche sistemi ad altissima affidabilità possano essere colpiti da incidenti gravi. Un rischio che la digitalizzazione del business e la diffusione dei servizi cloud non fanno che aggravare. Poiché, così come per la sicurezza, il costo della resilienza cresce in modo esponenziale rispetto al livello di riduzione del rischio, occorre una strategia che bilanci i risultati attesi agli interventi necessari. Ciò porta a scegliere diversi tipi di sistema resiliente, secondo la loro collocazione in un piano (frutto dell’approccio globale di cui s’è detto) che incrocia l’oggettiva resilienza con i livelli di customer experience percepiti e di protezione delle revenue e del profitto.
Sul “che fare” è intervenuto Andrea Pettinelli, Vp per i servizi finanziari di Ibm Italia Global Business Services, che dopo aver ricapitolato i punti che portano al bisogno di un sistema resiliente (senza trascurare gli aspetti normativi imposti dagli enti di vigilanza) ha esposto la metodologia che Ibm ha sviluppato allo scopo. Partendo dall’indispensabile preliminare identificazione degli obiettivi di business, questa si basa su tre linee d’azione: assessment, proving e maturity. Detto in estrema sintesi, con la prima si esamina lo stato delle cose, se ne considerano i rischi e si danno delle priorità agli interventi da fare; con la seconda si verifica l’efficacia dei progetti e delle operazioni attuate tramite un opportuno schema di scorecard e con la terza si dimostra la ‘maturità’ dell’insieme delle attività svolte secondo in una matrice che le incrocia con le best practices riconosciute nei singoli campi d’azione.
La parola è quindi tornata a Crubellati, che ha focalizzato il suo intervento sulla possibilità di governare la resilienza in tutte le sue componenti: strategia, organizzazione, processi, infrastruttura e digital asset (cioè, l’insieme del capitale informativo e del parco applicativo di un’impresa). “Governare significa soprattutto misurare e conoscere – ha detto Crubellati – ma non vi sono standard di resilienza per le applicazioni con i quali potersi confrontare. Esistono però dei segnali deboli, sintomi di vizi di struttura e di architettura del software che possono colpire l’affidabilità, l’integrità dei dati e l’efficienza operativa dell’applicazione e che si possono intercettare”. A tal fine aiutano le norme Cisq (Consortium It Software Quality), relative appunto alla misura di tali segnali, che sono state esposte in dettaglio e che permettono di valutare la resilienza di un sistema prima di erogare i servizi. Il Country manager Cast ha fatto quindi riferimento ai metodi Agile e DevOps, mostrando come si possa dare al software una resilienza intrinseca con l’inserimento periodico nel processo di sviluppo di un “hardening sprint” (un momento di focalizzazione sul progetto e sugli ulteriori passi di sviluppo) che serva a verificare ciò che si è fatto. Conviene però che questo compito sia affidato a una rete di controllo esterna al team It. Crubellati ha infine concluso il proprio intervento con il modello di scorecard Cast per la resilienza applicativa (figura).
Il ruolo del software
Il confronto in Tavola Rotonda ha fatto emergere alcuni punti forti. Uno è il conflitto tra la presa di coscienza del cambiamento epocale dato dall’impresa digitalizzata, “il software è il business”, ha ricordato Uberti Foppa e la scarsa priorità data alla resilienza applicativa. Su questo punto Dario Bonavitacola, I&O Director di Cedacri ha ammesso il ritardo nell’affrontare il problema: “Investire sulla piattaforma era più semplice”, ha detto, ma ha anche aggiunto: “Credo che quello della resilienza applicativa sarà un fattore di selezione molto forte. Ciò che hanno fatto molte banche negli ultimi anni è stata sostanzialmente un’operazione volta a migliorare più l’interfaccia utente del sistema informativo, che il suo cuore. Abbiamo investito parecchio per adattare i sistemi a nuovi canali e specialmente in questo momento si fa fatica a trovare la adeguata copertura per gli investimenti più importanti”. In effetti esiste, come ha osservato anche Pettinelli (Ibm), “una differenza evidente in termini di reperibilità di budget fra le applicazioni di front-end e quelle di core banking”. Che, come detto da Bonavitacola proseguendo nel discorso: “Sono vecchie talvolta anche di trent’anni, ma si continuano ad usare perché è troppo difficile e costoso oggi cambiarle in modo più radicale”.
I limiti di spesa sono stati, come sempre, un problema avanzato da più parti. In particolare, la discussione tra Pessina e Bonavitacola sul costo del rinnovamento applicativo e, di conseguenza, su quello della resilienza in funzione delle attese sul servizio, ha portato Franco Nesci, SW Metrics & Quality di Generali Business Solutions, al tema di base del livello accettabile di rischio: “Se per giungere al 99,9% e più di resilienza vado a impattare su ambiti applicativi troppo costosi, allora la soluzione non sta nel raggiungere il top della scorecard ma nell’individuare quale sia il livello di robustezza che il cliente s’attende e che viene percepito e lì intervenire”. Cosa comunque tutt’altro che facile. Primo perché, come ha osservato Julius Bijlsma, Cio dell’Ict Group Threats & Controls di UniCredit, “La robustezza ha due anime: una intrinseca all’applicazione e al suo codice e l’altra appunto relativa a ciò che viene rilevato nella realtà e quindi percepito dall’utente”. Pertanto se qualcosa non va: “è importante rilevare anomalie in modo continuo, se no è difficile sapere che cosa non funziona e soprattutto capire perché”.
Ma prima di decidere che livello di resilienza cercare c’è un altro nodo da sciogliere: sapere da quale livello si sta partendo. Come sintetizzato da Crubellati richiamandosi al proprio intervento, è una questione di misure: “Se non so dove sono, come faccio a sapere dove andare?” Constatazione pienamente condivisa da Gianpiero Lombardini, It Quality Manager di Allianz Italia: “Dopo aver fatto un check completo del parco applicativo per le agenzie per capire come eravamo messi ed avere una misura oggettiva della salute delle applicazioni, siamo partiti con l’analisi dei servizi dell’applicazione anagrafica centralizzata di fondamentale importanza perché punto di ingresso di tutte le applicazioni di business (centralità del cliente)”.
Resta il fatto, sollevato da Massimo Rapetti, Quality Manager di Icbpi, ma condiviso da quasi tutti i partecipanti, che “piaccia o no il cambiamento ci sarà”. Perché non c’è più chi sappia mettere le mani sui vecchi programmi e, soprattutto “Non ci sono solo le banche italiane a competere”. In effetti, come ha sottolineato anche Bijlsma “Le applicazioni cambieranno perché le banche stanno cambiando i loro servizi”. Cosa confermata da Raffaele Lanna, Business Development Manager di Hogwart, che dal punto di osservazione privilegiato di un integratore di sistemi ha detto che “…molti segnali di attenzione al problema di garantire la resilienza nel rinnovo applicativo ci sono giunti dai nostri clienti”.
Si potrebbero superare questi problemi delegando la produzione del software all’esterno, ma, posto che ciò sia possibile o conveniente farlo, nasce, per Piero Bafaro, Head of IT Supplier Management di Barclays, il problema di contrattualizzare una materia complessa e ‘fluida’ come la resilienza, da cui l’importanza di definire standard di resilienza applicativa essendo, come aveva detto Crubellati “la misura necessaria ma non sufficiente”. Sui controlli a garanzia della qualità del software, e quindi sui relativi standard, è intervenuta Gisella Arienti, Quality Assurance Leader di Aviva Italia, per la quale “la resilienza è una delle sfide che deve essere necessariamente affrontata soprattutto a fronte di inevitabili cambiamenti quali ad esempio il passaggio dall’ambiente mainframe ad altre piattaforme, come quelle adottate nel mondo sinistri e general insurance. Un tema con il quale ci si dovrà confrontare per garantire corretti livelli di servizio”.
A queste difficoltà oggettive si somma infine il solito problema degli impatti organizzativi e della resistenza al cambiamento, pesante soprattutto per ciò che riguarda i modelli di sviluppo: “Gli errori umani saranno sempre un problema – ha detto Alberto Faggian, Responsabile Metodi e Qualità SW di Sia – l’Agile ne può ridurre le conseguenza ma va a scardinare dei ruoli aziendali”. Un ostacolo che la tecnologia non può eliminare.
