Eravamo seduti ad un tavolo. Ero in uno spazio di co-working che univa lavoratori provenienti da diversi settori, pronti a condividere la loro conoscenza e le loro competenze con altri professionisti di altre aziende. Un’esperienza nuova per me. Era il 2014 ed avevo appena ottenuto la mia certificazione ITIL V3. Stavo preparando la formazione di 60 miei colleghi.
Un giovane, fresco di studi, monopolizza non tanto l’attenzione quanto la conversazione, convinto di avere qualcosa da dire a tutta questa gioviale assemblea… Il suo discorso è piuttosto perentorio, sembra abbastanza sicuro di sé e ha un forte desiderio di criticare ITIL…
Lo sento dire: «bisogna assolutamente eliminare la burocrazia dovuta all’implementazione di ITIL nelle organizzazioni. Io difendo una progettazione della gestione dei servizi che è molto più flessibile ed efficace. Il mio sistema di riferimento è facile da applicare, sostituirà rapidamente ITIL, che costa troppo e blocca le organizzazioni in processi pesanti e inutili. Tutti coloro che implementano ITIL si stanno pentendo perché oggi vorrebbero uscirne e non ne hanno più la possibilità.»
Avevo appena investito una settimana del mio tempo e stavo per firmare un ordine d’acquisto di 40.000 € per formare tutto un team sulla best practice ITIL, potete immaginare la mia inquietudine. Allo stesso tempo, avevo bisogno di saperne di più.
Feci quindi delle domande veloci:
- Come si risolvono gli incidenti secondo il tuo framework?
- Bè non c’è una spiegazione, quindi un ritorno ad Excel è più che sufficiente.
- Wow… Ma quindi c’è una gestione del rischio a monte, una risoluzione proattiva degli incidenti potenziali sulla base degli eventi?
- Neppure, i sistemi sono stabili per natura…
- Ok bene, e questo grazie a un insieme di particolari scelte tecnologiche?
- Sì certo, ma soprattutto grazie ad un metodo di sviluppo che elimina qualsiasi errore alla fonte…
- Un metodo Agile ?
- Cosa, ci sono altri metodo di sviluppo?
Lì ho pensato «Andiamo avanti»!
- Dimmi, hai degli esempi concreti di organizzazioni che sono bloccate in ITIL e vorrebbero uscirne? Mi interesserebbe conoscere la loro esperienza per evitare gli stessi errori nel mio servizio.
- Bè l’ho già detto, tutte!
In quel momento ho capito di avere di fronte un giovane brillante abituato ad argomentare e parlare, ma senza alcune esperienza e conoscenza in gestione dei servizi. Ho lasciato finire la discussione in questo modo, rimandando a dopo la continuazione del mio interrogatorio.
Mentre tornavamo al nostro posto di lavoro, mi sono avvicinato a chiedergli il nome di questa best practice magica. Mi ha risposto distrattamente: si chiama ‘DevOps’. Questo è stato il mio primo contatto con DevOps, e avevo già l’idea che questo ragazzo aveva imparato bene le lezioni del suo guru, ma non ne aveva catturato l’essenza. Ho quindi indagato in autonomia… ho trovato un buon percorso e sono finalmente entrato nel mondo DevOps, senza mai abbandonare ITIL.
A quei tempi c’era veramente poca documentazione su questo tema. Inizialmente si trattava di buone idee che insieme formavano un magma pieno di buone intenzioni di cui non potevamo che sentire l’enorme potenziale.
È stato proprio durante quell’anno che è uscita la prima formalizzazione. Un libro su IT e DevOps chiamato «The Phoenix Project». Il racconto di una trasformazione di un’organizzazione attraverso il cambiamento radicale dei suoi servizi IT. Leggere questo libro è come acquisire dell’esperienza senza far nulla: è pieno di insegnamenti.
È vero che all’inizio del libro alcuni processi ITIL vengono criticati per la loro complessità, ma in alcuni casi non è consigliato disfarsene completamente. Andando avanti nel libro, ci si rende conto dell’influenza essenziale di best practice come ITIL sulla riuscita della trasformazione DevOps, ma anche dell’importanza di poter eliminare da questa best practice tutto ciò che non produce valore. Possiamo quindi passare ad un concetto di Lean-ITIL, percorrendo una parte del cammino verso DevOps.
Con il tempo, DevOps ha guadagnato maturità, come anche i suoi utilizzatori e esperti, ed è chiaramente indicato, nelle prime pagine della formazione ‘Foundations’, che le tre fonti d’ispirazione di DevOps sono ITIL, Lean e l’Agilità. Per insistere ancora un poco, l’obsolescenza di ITIL è considerata come uno dei falsi miti su DevOps. Io credo fortemente che l’IT Service Management e il movimento DevOps non sono opposti. Al contrario, offrono un matrimonio culturale perfetto (queste le parole di Gene Kim, autore – insieme ad altri – di Phoenix Project e del DevOps Handbook, traduzione libera dell’autore di questo articolo).
Questa citazione risale a prima dell’uscita di ITIL 4… che è diventato più agile. Se DevOps non ha frenato l’interesse per ITIL V3, inutile dire che non ha frenato ITIL 4.
Resta quindi essenziale per i servizi IT prendere atto ed applicare le pratiche ITIL per poter utilizzare DevOps con successo.
Ripenso spesso a quel giovane ragazzo. Non posso che ringraziarlo per aver avviato questa messa in discussione. Non gli rimprovero la sua leggerezza spensierata… Al contrario, gli auguro di aver acquisito maturità allo stesso ritmo del movimento che oggi rappresentiamo insieme.
Tutti parlano di DevOps: e tu sei pronto/a a parlarne? Scopri quali sono secondo noi le cinque cose che non puoi assolutamente non sapere su DevOps
Quali sono le difficoltà per le organizzazioni che vogliono usare DevOps e quali sono le sfide che DevOps può aiutare ad affrontare? Leggi la nostra intervista all’esperto Fabio Mora: Quali sono le difficoltà più grandi per le organizzazioni che vogliono utilizzare DevOps?
