Impostare una roadmap di trasformazione digitale e impegnarsi a rispettarne le tappe è ormai una strada obbligata per qualunque impresa. Tuttavia, se si è privi di una solida software intelligence, vengono a mancare una prospettiva chiara e la capacità di guardare in profondità, all’interno della struttura del software, per comprenderne rischi intrinseci, architettura e complessità. Ciò è soprattutto vero quando occorre districarsi in uno stack tecnologico stratificato nel tempo, e non solo su sistemi legacy, che appare astruso, oscuro e faticoso da comprendere.
Un contesto in cui prendere decisioni efficaci, in merito alle iniziative di modernizzazione dei sistemi IT, si rivela davvero arduo.
Questo stato di cose è messo in evidenza da una survey realizzata da CAST, società specializzata nelle soluzioni di analisi e misurazione del software, nel recente Software Intelligence Report – CIO Priorities in the Digital Age.
Il Rapporto ha sondato i pareri di 500 IT leader (includendo fra questi 150 CIO, 125 software architect e 125 sviluppatori di applicazioni, in organizzazioni di medie e grandi dimensioni) riguardo gli obiettivi della tecnologia e la loro abilità di soddisfare tali obiettivi sulla base della Software Intelligence cui possono attingere, rispetto ai portfoli software esistenti.
Tra le principali conclusioni dello studio non solo emerge che i CIO non posseggono una visibilità adeguata sulla progettazione software per prendere decisioni valide sugli asset IT aziendali, ma anche che i reparti dei sistemi informativi non sono in grado di prevenire i rischi operativi, correggendo i difetti strutturali troppo tardi perché non ci sia un rallentamento nel processo di digitalizzazione.
Le competenze sull’architettura software sempre più complesse, preziose e largamente richieste per entrare davvero nella prossima era del digitale, rappresentano inoltre un asset aziendale sempre più raro.
Un aspetto interessante della survey, infatti, rileva che non sussistono carenze in termini di capacità tecnologiche; quando il business richiede soluzioni che implicano competenze anche tecnologicamente avanzate, i team IT sono in grado di svilupparle. Quello che manca, invece, è un’analisi chiara e coerente che sia in grado di esplorare a fondo i sistemi software, critici per le business operation.
In particolare si identificano due principali sfide: da un lato la prevalenza di sistemi legacy, ereditati nel tempo, che ancora supportano le business operation nevralgiche all’interno dell’organizzazione; dall’altro l’esistenza di dati incongruenti sulle attività di progettazione e manutenzione del software.
Troppa tecnologia legacy e conoscenze perdute
I sistemi IT ereditati, specie nelle istituzioni più grandi, continuano a ostacolare i progressi verso il paradigma digitale: la maggioranza dei rispondenti alla survey riporta che almeno un quarto dei propri sistemi ‘mission-critical’ è composto da software legacy, anche non i classici mainframe, e che di conseguenza risulterebbe molto difficile modernizzare o sostituire questi sistemi con un minimo sconvolgimento dell’attività di business. Anche perché, considerando che di solito è il 20% dei sistemi a far funzionare l’80% del business, sottolinea la survey, ciò significa che, nella maggioranza delle organizzazioni. Gran parte dei sistemi core per le operation è ancora legacy e rappresenta un ostacolo serio alla digitalizzazione (figura 1).
A ciò si aggiunge il fatto che normalmente gli sviluppatori, artefici da svariati decenni delle implementazioni di tali sistemi, o si dileguano in un mercato dinamico o si ritirano portando con sé tutta la conoscenza dell’architettura del sistema e delle dipendenze critiche. Accade così frequentemente, che la limitata conoscenza di questi sistemi legacy, da parte di chi nell’organizzazione ha il compito di governarli, rende estremamente difficoltosa la loro modifica senza commettere errori. Non a caso, una precedente survey sugli sviluppatori, condotta da CAST nel 2017, aveva scoperto che appena la metà (il 54%) dei team di sviluppo sa comprendere in toto l’architettura del sistema.
Dati incoerenti sui sistemi software
Oltre al problema rappresentato da uno stack tecnologico legacy, le aziende devono fare i conti con la carenza di dati affidabili. Molti IT leader continuano ad utilizzare metriche inadeguate e incoerenti per stimare gli sprechi di risorse nelle attività di manutenzione, che non tengono conto della complessità architetturale. Vi è un dato ampiamente accettato, sottolinea CAST, secondo cui il 50% dei budget IT è speso in attività di manutenzione applicativa e la survey lo conferma: un terzo dei rispondenti afferma di spendere il 50% del proprio budget IT sulla manutenzione del software, conservando l’altra metà per le iniziative di trasformazione (figura 2).
Alla domanda su “Come stabilire quali applicazioni richiedono più attenzione rispetto ad altre?”, il 51% dei CIO impegnato nel tentativo di ridurre le spese di manutenzione attraverso iniziative di refactoring o razionalizzazione, riporta di avere “qualche conoscenza delle attuali performance delle applicazioni”. Solo il 30% basa le proprie decisioni sul feedback diretto proveniente dai software architect, coloro che più comprendono le complesse operazioni sulle applicazioni, e il loro utilizzo all’interno dell’organizzazione (figura 3).
Emerge poi che il 42% dei CIO utilizza report di benchmarking esterni, il 38% basa la decisione controllando il budget dell’anno precedente e il 37% dice di analizzare il software stesso per comprendere l’onere di manutenzione. Essendo privi di strumenti efficaci per indirizzare i miglioramenti applicativi, i CIO sono quindi sempre più sotto pressione, in quanto ritenuti responsabili delle strategie di riduzione della complessità, del rispetto dei budget e soprattutto della velocità di modernizzazione, elemento chiave per stare al passo con le richieste del business.
Scarsa rapidità di risoluzione dei difetti software
La priorità massima per i CIO è quindi modernizzare l’ambiente dei sistemi legacy. Un modo per farlo è adottare la strategia DevOps, o qualche forma di automazione nei canali di rilascio del software, per velocizzare il raggiungimento della coerenza in fase di distribuzione. Ma non sempre queste iniziative hanno successo perché una strategia DevOps vincente significa sì automatizzare il testing del software, ma significa anche applicare la filosofia ‘fail fast’, cioè riparare in fretta gli errori, ad esempio ripristinando le funzionalità precedenti, se quelle nuove appena sviluppate dimostrano di non funzionare, una volta trasferite in produzione.
Un primo errore nell’applicazione di DevOps è fare troppo affidamento sui test automatizzati. Secondo i partecipanti alla ricerca, il 13% dei problemi di prestazione del software, che potrebbero impattare sulla ‘user experience’, non viene trovato prima che l’applicazione venga rilasciata. CAST cita anche uno studio dell’Università di Zurigo che, supportando questa conclusione, indica il problema più ampio di una eccessiva fiducia sul testing automatico (figura 4).
Secondo CAST, invece, i problemi di resilienza del software e i difetti di qualità e sicurezza potrebbero essere indirizzati dai team prima di trasformarsi in reali problemi. Al fine di evitare la ripercussione di questi ultimi su prodotti e servizi sperimentati dagli utenti, si potrebbe implementare una soluzione di Software Intelligence a partire dalle fasi iniziali del ciclo di sviluppo software, come ad esempio lo stadio di design dell’applicazione.
Integrata come parte della catena di tool DevOps, la Software Intelligence può eseguire la scansione di tutti i componenti all’interno dell’architettura del sistema ed essere automatizzata assieme agli altri processi di integrazione continua, per aiutare i team a rilasciare il software con maggior frequenza e con una maggiore probabilità e consapevolezza che il rischio sia stato ridotto da una parte, e che la qualità sia migliorata dall’altra.
Il secondo errore comune riguarda una tempistica di recupero troppo lunga: il 70% dei CIO riporta che i propri team spendono più del 50% del tempo a cercare un problema rispetto a quello dedicato a risolverlo. Così, la costante sfida di stabilire processi DevOps efficienti, assieme al problema degli apparati legacy, continua a impedire ai team di sviluppo di estirpare i difetti in modo rapido (figura 5).
L’integrazione di un sistema di misurazione dell’indicatore MTTR (Mean Time To Recovery) potrebbe invece aiutare i team a tracciare le metriche sulle prestazioni di sviluppo (tempo di ciclo, costo del ritardo) ed a quantificare il tempo necessario per migliorare la qualità e la sicurezza del software da una scansione all’altra.
Infine, meno del 50% dei CIO rispondenti ritiene che la propria organizzazione abbia visibilità sufficiente all’interno dell’architettura software per prendere le migliori decisioni in merito all’implementazione, all’acquisto o alla sostituzione del software (figura 6).
La Software Intelligence, conclude quindi la ricerca, è la risposta più efficace per affrontare questi problemi, permettendo alle aziende di reggere le future ondate di innovazione attraverso la diminuzione della complessità del software, la razionalizzazione del portafoglio applicativo, la riduzione del time-to-market ed il miglioramento della soddisfazione degli utenti finali.
