ITIL® 4, i concetti chiave

Se ti sei perso la puntata precedente, puoi leggerla qui

Parliamo di creare valore. Pochi giri di parole, ma l’argomento su cui si basa l’intera teoria di ITIL® è il valore per gli stakeholders che si traduce in un outcome (risultato) per i clienti.

Poco romantico, direte voi. Eppure la creazione di valore è un concetto astratto applicabile a molti contesti concreti. Praticamente tutto quello che facciamo, in un modo o nell’altro, lo compiamo con questo fine: una mamma (provider, fornitore) che cucina la cena per i propri figli (customers, clienti) aiutata dal compagno (supplier) sta creando un prodotto (output) che a sua volta si trasformerà in sazietà, pancia piena e soddisfazione per la propria prole (outcome, risultato). Questo è un semplice processo di creazione di valore per gli stakeholders. Quello che fa ITIL® è definire delle buone abitudini perché, nel mondo dell’ITSM, il procedimento appena descritto sia il più efficiente possibile.

Per poter cominciare a descrivere questo procedimento è necessario individuarne i protagonisti e le relazioni tra di essi. Approfondiamo i concetti chiave di ITIL® utilizzando tre rapide domande.

Chi?
Chi sono i giocatori della partita? Chi occupa una parte attiva nella creazione di valore? Il cast è ricco. In generale, parliamo di organizzazioni: nel mondo reale aziende o enti, ma in questo contesto intendiamo un concetto più ampio. Per organizzazione si intende una persona o un gruppo di persone con delle proprie funzioni in termini di responsabilità, autorità e relazioni finalizzate al raggiungimento dei propri obiettivi.
Le organizzazioni, naturalmente, possono occupare profili e posizioni differenti. Questi i ruoli che si delineano sempre quando si analizza un processo di gestione di un servizio:
fornitore di servizi: è il ruolo che occupa una organizzazione che offre uno o più servizi;
consumatore di servizi: è il ruolo che occupa una organizzazione che riceve uno o più servizi. Un consumatore può essere un cliente (colui che definisce i requisiti per un servizio e si assume la responsabilità dei risultati ottenuti), un utente (che semplicemente utilizza un servizio), uno sponsor (che si occupa di autorizzare il budget per il consumo del servizio);
– altri stakeholders: fornitori terzi, consulenti, partners, investitori.
Per esempio, una società che offre servizi di connettività WiFi per delle strutture pubbliche agisce da fornitore. Il cliente è il board direttivo di un centro commerciale che vuole creare una rete WiFi per chi frequenta la propria struttura e si rivolge a tale società. Gli utenti sono coloro che frequentano il centro e che usano la rete WiFi. Gli sponsor sono coloro i quali hanno autorizzato il budget per questa operazione. Altri stakeholders possono essere dei fornitori esterni che si occupano di installare fisicamente gli Access Point.

Cosa?
Praticamente, cosa è questo valore? Di cosa si tratta?
Definiamo questa parola: il valore è il beneficio percepito, l’utilità, l’importanza di un qualcosa.
Siamo in un contesto ben preciso, ci muoviamo nel mondo dell’ITSM, quindi questo qualcosa è un servizio.
Tutta questa storia, alla fine, serve per fare in modo che ci sia un beneficio percepito da un consumatore di uno specifico servizio. Semplice, chiaro, lineare: se io, fornitore, offro un servizio e chi lo utilizza non ne percepisce un beneficio, semplicemente la volta dopo non lo userà più.
Ma pensandoci bene, siamo sicuri di avere chiaro cosa sia un servizio? A scanso di equivoci, precisiamo che un servizio non è un prodotto, sono concetti completamente diversi, anche se sono strettamente in relazione:
– un servizio è un mezzo per creare valore per un consumatore, facilitando la realizzazione dei suoi obiettivi, senza che debba gestire costi e rischi specifici;
– un prodotto è una configurazione delle risorse di una organizzazione progettata per creare valore per il consumatore.
In parole povere, il prodotto è lo strumento grazie al quale si offre un servizio che un consumatore potrà utilizzare per raggiungere i propri obiettivi e creare valore.

Come?
Siamo arrivati al punto di chiederci come viene creato valore.
Per rispondere a questa domanda è sufficiente utilizzare una parola: collaborazione.
Uno dei più importanti concetti di ITIL® 4 è che non può esistere creazione di valore se non sono presenti relazioni tra le organizzazioni. Esse devono cooperare tra di loro: è la base dell’ITSM. Semplicemente, fornire un servizio non basta, è necessario gestirne le relazioni. In questo senso, ITIL® 4 definisce la creazione di valore come una co-creazione, perché per ottenere i risultati sperati il consumatore ed il fornitore devono necessariamente interfacciarsi in maniera profonda e frequente. La relazione non è monodirezionale, bensì bidirezionale.

Ora le idee sono un po’ più chiare. Ma c’è un’ultima questione sulla quale porre attenzione: abbiamo parlato di organizzazioni, di ruoli e di relazioni tra essi; abbiamo accennato ai risultati e ai benefici percepiti come significato della creazione di valore.
Ma cosa sono questi risultati? Che caratteristiche hanno? Cosa dobbiamo perseguire principalmente per creare valore?
Ci sono due elementi, due peculiarità da tenere sempre in considerazione: il costo del servizio (la quantità di denaro speso su una specifica attività) e la sua percentuale di rischio (la quantità di possibili eventi che possono danneggiare l’esistente o che possono rendere difficile il raggiungimento dei risultati). Più queste due caratteristiche si allontanano da quanto il consumatore si aspetta in fase di stesura dei requisiti, più il beneficio percepito e il valore creato sarà basso.

Ok, gli ingredienti ci sono. Ora è necessario unirli con il giusto mix e trasformare i singoli elementi in una prelibata pietanza. Per fare ciò, la nostra ricetta si chiama Service Value System.

ITIL® 4, un modello per la gestione dei servizi IT

Nel mondo IT, da qualche mese a questa parte, si parla molto di ITIL® 4.

Di cosa si tratta? Cerchiamo di fare un po’ di chiarezza.

Cosa è ITIL®?

Dal sito di AXELOS, di cui ITIL® è marchio registrato, scopriamo che si tratta di questo:

ITIL® is the most widely accepted approach to IT service management in the world. ITIL® can help individuals and organizations use IT to realize business change, transformation and growth.

www.axelos.com

ITIL® è l’acronimo di Information Technology Infrastructure Library e, in sostanza, è l’insieme di diverse best practices che sono finalizzate a descrivere i processi e le funzioni presenti nel ciclo di vita di un servizio. Il focus principale di queste best practices è l’IT Service Management, o più semplicemente ITSM.

Cosa è ITSM?

L’ITSM è genericamente quella disciplina che si occupa di creare servizi IT per soddisfare i requisiti di business.

Un po’ di storia

1988 – Il muro di Berlino è ancora in piedi ma ITIL® viene resa disponibile pubblicamente come collana di libri sulla gestione di una infrastruttura IT

2000 – Sospiro di sollievo dopo il Millennium Bug, viene rilasciata la versione ITIL 2, nella quale il focus viene spostato più sui processi, rispetto all’infrastruttura IT

2007 – ITIL® viene rinnovata nei concetti (viene introdotta l’idea di gestione dei processi IT come un ciclo iterativo) e, soprattutto, diventa un marchio registrato. Siamo alla v3.

2011 – Finiti gli anni Zero, Lady Gaga è in cima a tutte le classifiche ed esce ITIL® 2011, un semplice aggiornamento nei concetti e negli argomenti trattati nella v3.

2019 – Sul finire del decennio, complici le incredibili innovazioni relative alle metodologie di gestione Agile, Lean, DevOps e all’esplosione del mondo Cloud, le best practices ITIL® vengono profondamente riviste ed aggiornate. Viene rilasciata ITIL® 4.

Perchè ITIL®?

  • Funziona, è stata accettata come guida da tantissime organizzazioni nel mondo, ad ogni livello
  • È basata su buone pratiche presenti nel mondo reale e sulla esperienza di chi ne ha fatto uso
  • È di dominio pubblico, può essere utilizzata gratuitamente
  • È adattabile a qualsiasi contesto ed è molto flessibile, può essere utilizzata in organizzazioni di qualsiasi dimensione ed a qualsiasi livello
  • È scalabile
  • È universalmente riconosciuta

In fin dei conti, di cosa parliamo?

In maniera più pratica, ITIL® 4 è un insieme di buone abitudini, di strutture e di processi (practices) che una qualsiasi organizzazione che crea, gestisce, fornisce o usufruisce di servizi IT può adottare per perseguire la creazione di valore per sé stessa e per i propri clienti e, in generale, per i propri stakeholders (ovvero le “parti interessate” al business di cui si occupa l’organizzazione stessa).

Contestualizziamo un po’. Quali sono i concetti chiave di ITIL® 4? Su quali elementi del Service Management si focalizza principalmente?

La risposta è contenuta nel paragrafo precedente, dal quale dobbiamo isolare le parole chiave: servizi, organizzazione, clienti e, soprattutto, valore. ITIL® 4 descrive in maniera dettagliata questi elementi e ne definisce le relazioni.

Soprattutto, si occupa di fornire dei modelli teorici che sono la base del Service Management e che sono facilmente replicabili nella pratica esperienza nel mondo reale. Specificatamente, ne definisce due:

ITIL® Service Value System (SVS), che rappresenta come i vari componenti e le attività di una organizzazione lavorano insieme per facilitare la creazione di valore attraverso i servizi IT e fornisce un modello operativo per la creazione, il rilascio, il miglioramento continuo di tali servizi.

Four dimensions model, che definisce quali sono le entità che devono essere prese in considerazione nel Service Management. ITIL® 4 ne identifica quattro, che devono essere sempre ben valorizzate e bilanciate all’interno del SVS, per garantire una offerta di servizi IT qualitativamente elevati.

Credo sia necessario andare un po’ più in profondità nella spiegazione di questi concetti apparentemente astratti.

Ok, approfondiamo…

Come fare code refactoring di un callback hell con async/await

Ok, hai riaperto una vecchia pagina Javascript (o addirittura monolitica) e ti si incrociano gli occhi. È più forte di te, scorri il codice e trovi una callback hell. Le tue letture sul clean coding e, soprattutto, il tuo forte senso del dovere da buon sviluppatore ti impongono di non fargliela passare liscia.

Che fare? Code refactoring. Inevitabile.

Prendiamo come esempio una funzione grazie alla quale è possibile effettuare il play audio di una frase. La situazione di partenza è questa:

function play_audio(sentence){
   if (sentence.match(/^([A-Za-z]*) ([A-Za-z]*)$/)) {
      var first_file=RegExp.$1;
      var second_file=RegExp.$2;

      var audio_play_first = new Audio(first_file+'.ogg');
         audio_play_first.onended = function() {
            var audio_play_second = new Audio(second_file+'.ogg');
            audio_play_second.play();
         }
         audio_play_first.play();
      }
   }
}

Con questo codice riusciamo ad effettuare il play audio di una semplicissima frase di sole due parole separate da uno spazio, senza particolari segni di interpunzione. La frase viene analizzata dalla regular expression che cattura le due parole separate da uno spazio. A quel punto, avendo a disposizione i file audio associati alle parole, possiamo eseguirli utilizzando l’oggetto Javascript Audio.

Pensiamo ad una frase più complessa, magari composta da quattro-cinque parole. Per effettuare il play audio é necessario innestare una callback ad ogni attributo onended dell’oggetto Audio precedente.

Per gestire una frase relativamente semplice ci sarebbero talmente tante callback innestate che il codice risulterebbe illeggibile, anche su Medium. Evito di presentare un esempio, sarebbe davvero troppo.

Inoltre, questo codice non si comporta dinamicamente: é in grado di gestire solo frasi di lunghezza predeterminata. Se volessi, ad esempio, effettuare una esecuzione di questa funzione passando come argomento una frase da tre parole e successivamente fare un’altra chiamata con una frase da cinque parole, semplicemente non potrei.

Abbiamo due obiettivi dichiarati: pulire e migliorare.

Callback hell

Pulire

In gergo, con “pulire” si intende organizzare meglio il codice e renderlo più leggibile, non variandone minimamente il comportamento. Tecnicamente, un code refactoring.

Come si risolve e si “pulisce” un callback hell? Utilizzando uno strumento Javascript creato appositamente: le Promises.

Le Promises sono dei costrutti che consentono l’esecuzione asincrona di istruzioni che eventualmente restituiranno dei valori. Senza andare nel dettaglio, sappiamo che una Promise va creata e va successivamente consumata con then e, nel momento in cui questo avviene, ne conosciamo il risultato (resolve o reject).

Le Promises consentono una scrittura di codice più organica e chiara perché sintatticamente e logicamente ricordano i linguaggi procedurali. Inoltre, sono concatenabili l’una con l’altra, andando a formare una Promise-chain che è esattamente quello che serve al nostro caso.

const play_file = file => {
   return new Promise(resolve => {
      const audio = new Audio(file+'.ogg');
      audio.onended = function() {
         resolve('audio played')
      }
      audio.play();
   })
}

play_file(first_file)
.then(res => {
   return play_file(second_file)
})
.then(res => {
   return play_file(third_file)
})

Migliorare

Decisamente più leggibile, soprattutto su frasi di diverse parole. Utilizzando le Promises si comprende a vista d’occhio quello che viene eseguito dal browser. Tuttavia, la soddisfazione non è completa. Le Promises hanno un difetto: è impossibile spezzarne la catena di then. Il che, nel nostro caso, significa solo una cosa: impossibile rendere dinamico il flusso audio.

In questo caso ci vengono in aiuto le funzioni async/await, che si basano sulle stesse primitive delle Promises ma sono, per l’appunto, funzioni: non esistono catene e, soprattutto, possiamo effettuare un ciclo sulla chiamata a funzione play_audio, passandogli come parametro un elemento di una lista composta da tutte le parole di una frase. Abbiamo reso il nostro codice dinamico e possiamo effettuare il play di frasi di diversa lunghezza, senza seguire un formalismo predefinito.

Questa la realizzazione finale:

const play_audio = file => {
   return new Promise(resolve => {
      const audio = new Audio(file+'.ogg');
      audio.onended = function() {
         resolve('audio played')
      }
      audio.play();
   })
}

async function play_audio_list(files) {
   for (const file of files) {
      await play_audio(file);
   }
}

let audio_words = []
audio_words = sentence.split(' ')

play_audio_list(audio_words)

Pulito, migliorato, leggibile. Un gran bel respiro di freschezza.