Gli Sla sono statici, o per lo più si evolvono secondo necessità contrattuali. Una dichiarazione forte, che richiede di essere verificata. Per farlo è necessario visualizzare le nostre metriche. Al tal fine userò un grafico che ho ideato tempo fa. Il grafico ha due assi. Nel primo mettiamo il “Massimo volume applicabile”, cioè la massima quantità di lavoro in ingresso che è ancora coperta dalle metriche. Questo è il valore oltre il quale il servizio non è più soggetto alla metrica. Nel secondo indichiamo la “Performance minima richiesta”. Qualora le unità di misura in ciascun asse fossero diverse, si può procedere in due modi: riportare scale diverse su ciascun asse (ad esempio, per la performance potremmo avere due scale: percentuale e tempo), o creare grafici diversi. Per i nostri scopi la scelta è irrilevante. Quindi inseriamo sul grafico ogni metrica del nostro Sla.
Questo è il grafico di base. In alcuni contesti è necessario aggiungere un terzo asse, collegato alla priorità. Sarà un asse con un numero limitato (2 o 3) di valori predefiniti: a ogni livello di priorità definito per ciascuna metrica, corrisponderà un punto diverso.
L’insieme dei punti è la rappresentazione visuale delle nostre metriche, e ogni tripletta di valori (volume, prestazione, priorità) rappresenta un singola metrica puntuale.
Una volta generato il grafico, si può verificare la correttezza della tesi iniziale. Bisognerà infatti chiedersi quali siano le occasioni che generano una modifica a questo insieme di punti. Per esperienza, le uniche ragioni sono correlate a cambiamenti di tipo contrattuale: aggiunta o rimozione di servizi, e rinnovi di contratto con relativa rinegoziazione delle metriche.
In altri termini, se si eliminano gli aspetti commerciali, non vi è nessun elemento interno al sistema che ne determini l’adattabilità alle fluttuazioni del sistema stesso.
Ovvero il sistema manca di quel feedback che gli permetterebbe di adattarsi in modo efficace alle mutate condizioni in cui il servizio si trova a operare. La mancanza di un sistema di controreazione genera di fatto un sistema statico (e rigido).
L’indipendenza dal Sistema
In realtà la staticità e rigidità degli Sla ha una ulteriore causa: essi sono anche generalisti. Tendono infatti a definire una tipologia di attività e ad assegnarle una metrica indipendentemente dal target specifico a cui è applicata. Questo poteva già essere rilevato dal grafico, notando che nessuno degli assi presenta una relazione con il sistema target della metrica. In realtà i sistemi sono diversi: una tripletta pensata per un sistema con bassi volumi mal si adatta ad uno con alti volumi e viceversa. Facciamo un esempio. Una metrica del 90% da soddisfare in un dato intervallo di tempo, applicata ad un sistema con 100 eventi in quel lasso di tempo, significa che potremo fallire in 10 occasioni. Ma se la applichiamo ad un sistema con solo 3 eventi, allora il senso cambia completamente: la metrica non è del 90%, ma in realtà del 100%, non permettendo neanche un fallimento del relativo obiettivo. E lo stesso si potrebbe dire in casi di sistemi stabili accumunati sotto la stessa metrica ad altri instabili, ignoti a conosciuti, nuovi a obsoleti, etc. Il tutto senza considerare che, nel tempo, lo stato di un sistema cambia, passando da un tipo ad un altro, e che il sistema include anche chi fa il lavoro: anche il suo stato cambia nel tempo, con l’assunzione di esperienza sui sistemi nuovi e con l’incremento di efficacia in quelli già noti, con la modifica degli strumenti e/o della quantità di forza lavoro.
Ma quante variabili!
Cercare di caratterizzare nelle nostre metriche ciascun sistema in modo individuale renderebbe il tutto talmente complesso da vanificare i benefici di flessibilità e adattabilità che si vogliono raggiungere. Innanzitutto non tutte le variabili sono rilevanti allo stesso modo, nel contesto lavorativo specifico, ed è solo necessario individuare quelle di maggior rilevanza.
Inoltre molte delle variabili sono correlate tra loro, e quindi non è necessario considerarle individualmente. Infine è sufficiente identificare (poche) classi di Sistemi, sulla base delle variabili chiave definite.
Capability maturity model
Uno degli strumenti più interessanti per la caratterizzazione di un sistema, che ne considera diversi aspetti in un unico approccio, è il Cmm (Capability maturity model), ed in particolare la sua ultima stabile evoluzione, Cmmi (Capability maturity model integration). Esso racchiude in un unico indice elementi apparentemente diversi come stabilità, competenze acquisite, complessità, processi, obiettivi, etc. evitando così di dover considerare queste variabili in modo atomico nelle nostre metriche dinamiche. Cmm affonda le radici in studi iniziati negli anni 60, come tentativo di rendere robusto ed efficace il processo di sviluppo del software in ambito militare. La fase di reale maturazione inizia nel 1986 e si concretizza nel 1988, con la pubblicazione della prima versione del Cmm, sotto l’egida del SEI (US Department of Defense Software Engineering Institute), e quindi come pubblicazione dell’IEEE l’anno successivo. Nel 2002 fu pubblicata la prima versione del Cmmi, evoluzione e sostituzione del Cmm verso ambiti anche diversi dallo sviluppo software, supportata da industrie, organi governativi e istituti (incluso il SEI). Ad oggi lo standard si divide in tre branche: sviluppo di prodotti e servizi, definizione, gestione e fornitura di Servizi, acquisizione di prodotti o servizi. Il modello prevede di raggruppare le attività da svolgere (compresi i relativi sistemi, risorse, procedure per effettuarle), in 16 Aree di Processo considerate chiave, estese poi a seconda dello standard. Ciascun Area di processo racchiude gruppi di processi omogenei al raggiungimento di obiettivi comuni. Gli obiettivi da raggiungere (definiti in generali e specifici) sono parte integrante della descrizione dell’Area stessa.
Il Modello può essere usato definendo, per ciascuna Area di Servizio, il livello di Capability o Maturity da raggiungere (oltre a quello attuale): la scelta di quale punto di vista usare è selezionabile dall’utilizzatore. Sono previsti 4 livelli di Capability e 5 di Maturity, in cui il livello più alto rappresenta l’eccellenza.
Si può procedere assegnando a ciascuna Process Area un livello desiderato di Capability, e farle evolvere indipendentemente, a partire dal livello attuale. Oppure si può lavorare per livelli di Maturity, che sono trasversali alle singole Process Areas. In questo secondo caso, non tutte le Process Areas devono essere implementate sin dall’inizio. Il modello si configura sia come un ottimo sistema di definizione dello status quo, ma anche come un altrettanto valido ausilio per la definizione di un percorso evolutivo quantificabile. Entrare in maggiori dettagli esula dal contesto di questo articolo: per approfondimenti si vedano i riferimenti nel box dedicato.
Cmmi e Sla: un connubio efficace
Un metodo efficace per inserire un meccanismo di regolazione dentro il sistema che permetta un aggiornamento delle metriche al cambiare delle condizioni è di collegare il cambiamento di queste ultime al livello di Capability e/o Maturity raggiunto dai processi e sistemi coinvolti. Una volta stabilito per ciascuna metrica o gruppo di metriche quali processi siano dominanti, si possono definire le regole che guideranno il loro cambiamento al variare del livello di Capability/Maturity. Il cambiamento può essere basato sul livello più basso raggiunto, o su una formula pesata dei vari contributi dei processi coinvolti. La cosa interessante da sottolineare è un effetto collaterale di questo approccio. Il miglioramento di un’area di processo importante può infatti generare in modo armonico e semplice un cambiamento positivo delle metriche in tutte le aree che effettivamente beneficiano della miglioria. E il contrario è anche vero: analizzando il contributo e peso di ciascun processo al miglioramento delle metriche, si possono ottimizzare gli investimenti di risorse, riconoscendo le aree di processo che permettono di ottenere il massimo risultato (miglioramento delle prestazioni offribili al cliente o da esso richiedibili) con il minimo sforzo.
Conclusione
Fare evolvere un Sla sulla base di aspettative e scadenze contrattuali non permette di ottenerne una evoluzione efficace, cioè in grado di massimizzare il risultato al minimo costo. Anche se così accade in pratica. Cmmi può aiutare a introdurre quel meccanismo di feedback che colleghi l’evoluzione del servizio/sistema a quella delle metriche che lo gestiscono. Si deve fare comunque attenzione a un punto. Se alcune metriche si prestano a una evoluzione monotona migliorativa, altre, piu sensibili alle fasi del sistema, sono invece soggette a un cambiamento a campana in cui, ad una fase di miglioria, segue una stabile e poi una di peggioramento.
