La gestione del rischio software è un ambito in rapido sviluppo grazie ai numerosi ed eclatanti “disastri a 9digit” che hanno riempito i giornali, specializzati e non, negli ultimi anni. Questo sviluppo, soprattutto di approccio oltre che di investimenti, è di fatto stato forzato dai limiti degli approcci tradizionali alla produzione del software, che non sono in grado di prevenire tali rischi stimandone in modo ragionevole la probabilità di accadimento e quindi rendendo impossibili efficaci strategie di mitigazione.
Un secondo aspetto che rende difficile dirigere la mitigazione del rischio è l’individuazione delle root causes dei potenziali rischi, cause per determinati eventi negli asset applicativi sempre più complessi architetturalmente sia per ragioni storiche che di evoluzione tecnologica. Il terzo aspetto è la difficoltà nella stima dell’effort necessario per rimediare le root causes quando anche queste siano individuate.
Questi aspetti si legano tra loro determinando spesso un fenomeno di Analysis Paralysis, o peggio ancora di Pretended Analysis, che a sua volta lascia spazio a pratiche di gestione del rischio artigianali che mancano di basi oggettive. Alcuni team mitigano le incertezze investendo pesantemente nella fase di testing, altri abbracciano paradigmi agili per gestire le incertezze, sia a livello funzionale che implementativo, con maggiore rapidità e quindi minimizzandone l’impatto, più che agendo sulle cause.
In ogni caso nessuna di queste strategie permette di evitare in maniera efficace, come dimostrano le recenti classifiche, i disastri software a 9digit :
Alcuni disastri recenti:
Su ComputerWorld UK potete trovare informazioni su ulteriori disastri.
A latere dei disastri operativi, esistono disastri che colpiscono le fabbriche del software, che rallentano sommerse dai costi, fino ad arrestare la produzione, chiuse da executives infuriati per il continuo aumento dei costi ( Deutsche Post, NHS)
Il tratto comune che hanno tutti questi eventi dirompenti, a volte fatali, è di non rispecchiarsi in un difetto isolato di un componente tecnologico specifico, ovvero in una sola specifica root cause, ma di essere originati da una pluralità di cause che si annidano all’interno della struttura degli applicativi, delle interazioni tra i componenti, determinando collassi inaspettati e non prevedibili dalle normali attività di QA “discrete” messe in opera, per quanto automatizzate. Una delle strategie più promettenti del software engineering, da attuare sui sistemi di larga scala, è quella del cosidetto chaos testing a livello di sistemi e di fault injection a livello di applicazione [IBM bluemix blog], che permette di evidenziare eventuali carenze strutturali a livello sistemico. Purtroppo tale approccio può intervenire solamente quando si è molto vicini al momento del rilascio e con costi estremamente elevati.
La soluzione invece va cercata in uno spostamento a sinistra nel ciclo di vita del software [shift-left metrics] di attività di analisi strutturale che permettano di vedere questi potenziali rischi, delle vere e proprie time-bomb, già nelle prime fasi di integrazione. Questa capacità di avere insight strutturale “olistico” [The Holistic Approach: Preventing Software Disasters] è il punto di forza della piattaforma di software analytics & risk prevention di CAST. Si tratta di una soluzione in grado di individuare gli elementi rischiosi all’interno dell’architettura applicativa e ricondurli all’impatto sulla digital customer journey ottenendo dei piani di mitigazione circostanziati ed efficaci.
Ovviamente un approccio organico ed integrato di analisi strutturale già durante il processo di sviluppo degli applicativi è la scelta ottimale per innescare un processo di stabilizzazione e poi mitigazione dei rischi. I ritmi di cambiamento “digitali” e l’operatività su sistemi stratificati impongono ai responsabili degli applicativi di essere in grado di reagire a situazioni di contingenza eliminando ulteriori time-bomb di applicativi già in produzione, a volte nell’immediatezza di un disastro già avvenuto, per minimizzarne le conseguenze.
Fortunatamente, grazie alla nostra lunga esperienza nell’analisi di tutti i possibili risvolti strutturali che caratterizzano una gestione del rischio software non completa, siamo riusciti ad enucleare ed a mettere a disposizione dei responsabili applicativi una serie soluzioni di Assessment Applicativo estremamente mirate atte ad ottenere l’annullamento di rischi specifici in tempi molto rapidi.
Analizzando gli asset software nella loro interezza è infatti possibile trovare una soluzione rapida e certa ad un certo numero di problematiche ricorrenti, dando gli elementi oggettivi essenziali per evitare o rimediare ai disastri:
- Resilienza strutturale: indagine per individuare cause potenziali o ricorrenti di degrado nel servizio o peggioramento nel profilo dei costi: a valle dell’attività di indagine viene stilato un piano d’azione prioritizzato in base agli health factors, alle transazioni e all’impatto applicativo. Inoltre il piano d’azione viene ottimizzato sulla base dei requisiti temporali e delle disponibilità di risorse a disposizione.
- Sicurezza architetturale: l’assessment verifica aspetti di sicurezza strutturale, definiti a livello corporate, così come l’aderenza a specifici standard nel campo dell’application security [standards supportati] e a best practices nella prevenzione della perdita di informazioni. Può essere utilizzato come strumento per la verifica di compliance, per la mitigazione del rischio (secondo gli assi confidentiality, integrity e availability) e per l’implementazione di progetti di security by design.
- Efficientamento transazionale: i sistemi transazionali e gli ERP, crescendo, raggiungono livelli di scala per cui non sono stati progettati, manifestando un degrado applicativo tale da condizionare l’efficienza degli utenti e la disponibilità stessa del servizio. Sia nel caso di applicativi legacy che invece nell’affrontare problematiche di efficienza su applicazioni moderne, CAST offre visibilità sistemica per potere individuare le cause radice dei colli di bottiglia e delle interazioni a rischio di stallo, offrendo una guida per la loro prevenzione o per il loro fixing.
- Analisi strutturale per il ridisegno applicativo: negli ambiti in cui la visualizzazione delle interconnessioni interne ed esterne all’applicazione sia necessaria per potere effettuare il passaggio ad architetture a microservizi o per la migrazione su ambienti cloud, l’assessment di questo tipo permette di assicurare il dominio della situazione di partenza su cui effettuare una trasformazione e modernizzazione senza incertezze o addirittura rischi di fallimento.
- Analisi del vendor lock-in: la sovrapposizione di fornitori, il turnover nei gruppi di lavoro, gli stili diversi di programmazione e la scarsa o erronea documentazione, possono determinare la necessità di un’operazione di riscoperta dell’applicazione: questo tipo di assessment permette al Responsabile Applicativo non solo di di esplorare e documentare il codice dei diversi componenti applicativi e delle transazioni che li percorrono, attraverso più di 50 diverse tecnologie (nativamente e grazie ad un crescente set di estensioni), ma anche di valutare il grado di rischio che un cambiamento di sourcing potrebbe determinare.
- Migrazione di un’applicazione al cloud: nell’ottica di una migrazione al cloud permette di individuare e rimuovere quelle configurazioni e comportamenti che potrebbero rendere l’applicazione non funzionante o non performante in cloud: considerando aspetti di sicurezza, la dipendenza dai sistemi e dai contenitori applicativi ed infine le modalità di interazione tra componenti, questo assessment propone una linea d’azione per la rimozione dei rischi che assumono rilevanza nell’esecuzione sul cloud.
- Analisi di portfolio per piani di migrazione al cloud: allargando lo scopo dell’indagine rispetto alla precedente, la metodologia CAST unisce alla scansione del codice sorgente, effettuata completamente presso il cliente [ Guardi il recente webinar “Are Your Business AppsCloud-Ready?”], un’indagine sulle criticità di business e sugli aspetti di manutenzione del software che congiuntamente permettono di pianificare un passaggio al cloud graduale e a rischio controllato.
Ovviamente l’approccio a questi scenari non può essere squisitamente tecnologico ma è basato su una collaudata metodologia che segue un processo standardizzato che ci permette di garantire tempi di esecuzione contenuti, da una a poche settimane in funzione della complessità della applicazione da analizzare, e risultati efficaci e puntuali in termini di annullamento dei rischi.
Alla base delle analisi fornite ci sono le engine tecnologiche fornite da CAST: CAST AIP e CAST Highlight, nonché i dati di benchmark raccolti nella attività pluri decennale di CAST: AppMarq.