Visto che la persona che ho menzionato nel post precedente e' pure venuta qui a sbandierare certificazioni, adesso dedico un post "piu' puntuale" a chiarire, con esattezza, che cosa ESATTAMENTE questo signore, figlio della cultura "l'amico che ne capisce e che ci lavora da un sacco di tempo" , NON SA. E NON SA perche', molto semplicemente, e' uno dei tanti guru 2.0 che girano per il paese, devastandone l' IT con idee farlocche.
Lezione numero 1: esistono gli NFR.
Il tizio non lo sa, ma non tutti i requisiti di un sistema sono requisiti funzionali. E di conseguenza, il problema di capacita' si ripercuote, necessariamente, anche al di fuori del semplice delivery del servizio.
Un NFR e' un requisito non funzionale. facciamo un esempio: una banca.
Una banca di solito ha un sistema di Disaster Recovery. Significa che se ha un mainframe o un data center da qualche parte, lo ha collegato con un sistema analogo, o perlomeno con un sistema capace di contenere una copia aggiornata quasi di continuo, a qualche KM di distanza.
Diciamo che (per fare un esempio), materialmente questo sistema di DR sia a una cinquantina di KM (per dare ridondanza geografica, come fanno le telco e come fanno le grandi banche). C'e' allora un cavo in fibra (o piu' di uno) che continuamente aggiornano questa copia del sistema centrale , e uno storage adeguato (o una copia del mainframe).
Perche' si fa questo? Perche' in caso di un evento come il terremoto dell' Aquila, per dire, non vogliamo che si perdano i dati sui conti in banca. Si chiama ridondanza geografica. Lo scopo e' di essere in grado di ripristinare un determinato sistema in caso di disastro, e/o sostituirlo in emergenza con un altro che e' una riserva a freddo.
Ora, arriva il Guru 2.0 e dice : la nostra banca deve diventare social, deve avere l'interfaccia WEB, AJAX, LAMP, e tutta la fuffa che vomitano di solito. Diciamo che magari, facendolo, la quantita' di transazioni effettuate debba aumentare del 20%.
Ora, il problema e': il nostro NFR, che non ha nulla a che vedere in se' con il servizio fornito al cliente, resistera'? Fatto 100 quanto fa oggi, riuscira' a fare 120%?
Cosi', non basta convincere l'utente ad usare la banca online: bisogna PRIMA fare un forecast , capire che traffico aggiuntivo avremo. A quel punto, SE necessario, dovremo chiedere un nuovo link in fibra (1), col che dovremo aspettare diciamo , quando va bene, 1/2 mesi. Oggi, con le tecniche di separazione per colore, in genere succedera' che allargare la banda richiede meno temp, qualche settimana.
Poi bisognera' ordinare un'espansione dello storage, aspettare l'hardware, pianificare una maintenance window, appiccicare il nuovo hardware, metterlo online e fare "babysitting", ovvero testarlo per qualche tempo senza scommetterci le palle.Infine, fare un test di DR, cioe' simulare un disastro e vedere quanto tempo impieghiamo per ripristinare il tutto. Una banca probabilmente aspettera' i cinque giorni "spare" dell'anno per farlo. Diciamo in totale un tre/quattro mesi di progetto.
E qui siamo al punto primo: non possiamo semplicemente cambiare la cultura del cliente e dirgli "fai la banca 2.0, vai online e diventa social". Se lo fa PRIMA che abbiamo adeguato il sistema di DR, corriamo il rischio che un evento grave (incendio, allagamento, terremoto) possano causare la perdita irrimediabile dei dati.
Punto secondo: il servizio non e' da solo al mondo, ovvero l'arte del change management.
Diciamo che siamo Amazon. Diciamo che grazie alle nostre tecnologie di cloud computing, possiamo offrire da domani il delivery di libri in formato ebook via mms.
Avremo in qualche modo bisogno di un link verso gli MMSC, o verso qualcosa che prenda un servizio VASP e lo colleghi. Benone. A quel punto, c'e' un problema: QUANTO servizio compriamo? Cioe', la telco che ci fa da entry point vorra' sapere quanto spendere in risorse, e quindi all'incirca quanti MMS intendiamo mandare.
Allora, noi abbiamo un forecast, cioe' una previsione, e gli diciamo "data la nostra campagna, prevediamo di vendere centomila (bum!) libri al giorno". Allora la telco dimensiona un apparato che ne gestisce tanti.
Finito li'? No.
L' MMS passa, in genere, per un transcoder che prende lo SMIL e lo adatta al cellulare che lo riceve. Il problema di Amazon, a questo punto, e' di chiedersi se in Italia i transcoder sappiano gestire iPDF, ovvero ebook. Dovra' capire se le telco principali (TIN, Vodafone, Wind, etc) sono in grado di fare transcoding di quel formato.
Poi dovra' capire se e quanti cellulari, per CoS, sono capaci di ricevere l' ebook sul mercato italiano. Una volta stabilito questo dobbiamo decidere se il mercato italiano sia supportabile. Chiameremo le telco e diremo: "ehi, contiamo di far transitare per i vostri transcoder 30.000 ebook al giorno! Ce la fate"?
La risposta sara': ce la faremo fra 4 mesi, dateci il tempo di ingrandire un pelo il sistema.
Cosi', Amazon sa che gli serviranno 4 mesi per arrivare in Italia.
Ma la cascata non si ferma qui. Il pagamento arriva via carta di credito. Se il delivery fallisce, il cliente vorra' indietro i soldi. La cosa verra' gestita dal customer care di VISA, AMEX, etc. Morale: qualcuno in Amazon dira' "signori, prevediamo di vendere 100.000 libri al giorno. Di questi, 5000/giorno NON arriveranno a destinazione, e il cliente chiedera' di avere indietro i soldi. Potete supportarlo?
VISA, AMEX & co diranno: beh, dacci tre settimane e mettiamo in piedi la struttura.
Morale: prima milestone del nostro progetto. Amex, VISA & co devono mettere su il customer care. Seconda milestone: TIN, Vodafone, Wind, etc, devono aumentare la caapcita' dei loro transcoder ED eventualmente aggiungere funzionalita' di gestire SMIL con dentro degli ebook.
Quindi, siamo gia' ad un livello di pianificazione che richiede sei mesi. Ma non finisce qui. Dal punto di vista telco, ogni MMS deve essere pagato. Se e' il cliente che lo paga, allora bisogna chiedersi se l'interfaccia Diameter per il billing supporti questi 30.000/giorno in piu'. Puo' darsi di si, puo' darsi di no.
Inoltre, dobbiamo loggare tutto e tenerlo a disposizione del ministero per 3 anni. Abbiamo capacita' per 30.000x1000 record in piu'? Probabilmente si', o forse no. Dipende. Se non l'abbiamo dobbiamo metterla in piedi.
Morale: parlare della diffusione degli ebook , della cultura dell'ebook, di Copernico e tutto quanto non basta. Bisogna che l'infrastruttura sia pronta. Altrimenti succedera', come succede, che Amazon dica "sul mercato italiano non ci siamo ancora".
Lezioncina numero 3: io essere Germania, tu essere Albania, ovvero della service pipeline.
I servizi hanno, di solito, un erogatore ed un fruitore. Supponiamo che Vodafone D2/DE decida, con il suo bacino di utenti emigrati dall'albania, di offrire la videochat gratis da germania ad albania. Ma si scordano di avvisare gli albanesi.
Domani, una quantita' di immigrati albanesi in germania raddoppia, se non triplica , il traffico UMTS verso Albania. Aha. La rete albanese ce la fa? No, va a puttane.
Morale: se notiamo che un sacco di immigrati albanesi vorrebbero chiamare casa e mostrare il proprio ghigno alla moglie, non ci basta fare una tariffa ad hoc. Dobbiamo proprio accordarci con l'altro capo del servizio, e chiederci se esiste capacita' dall'altro lato.
Quindi, quello che faremo sara' agire su quella che ITIL chiama "service pipeline": abbiamo in conto di offrire questo servizio a prezzi competitivi. Magari lo annunciamo al pubblico, ma partira' quando tutta la catena, o se preferite tutti i servitori del nostro processo, sono pronti. Cosi', se l'immigrato vuole diventare 2.0, dovra' aspettare. E il cambio va pianificato con mesi di anticipo.
Ancora una volta, il cambiamento culturale non c'entra: se non c'e' infrastruttura, non c'e' infrastruttura.
Lezioncina numero quattro:le nazioni hanno delle leggi, a volte.
Una delle buzzword piu' diffuse e' che in tal caso basta comprare cloud. Bene. Probabilmente pensate che se TIN si trovasse in difficolta' a fare transcoding degli MMS per natale, potrebbe comprare potenza su Amazon. vero? Non tanto, e non per l'assurdita' commerciale dell'operazione o dell'esempio, ma per una questione giuridica.
Se prendiamo per esempio il mio lavoro, io NON posso portare fuori da qui alcun log. Un'azienda che doveva esaminarli e farci dei grafici, per dire, ha dovuto portare i PROPRI server dentro il datacenter che usiamo, perche' per policy quei dati NON possono uscire da quell'edificio. MAI.
Allora, signori, in Italia chi detiene fisicamente i dati e' titolare del loro trattamento. Per TIN si tratterebbe di prendere i vostri MMS e portarli negli USA, presso un'altra azienda. Solo questo richiede delle modifiche PESANTI al contratto che TIN ha con voi, perche' ovviamente il titolare di questi dati, potenzialmente, per un certo periodo sarebbe Amazon. LA quale, per esempio, potrebbe non accettare la legislazione italiana in merito.
Cosi', muovere dati a spasso (ammesso di avere banda per farlo, ma TIN non avrebbe questo problema. Forse lo avrebbe Amazon, e torniamo al punto di cui sopra) per i cloud non e' semplice, non solo per problemi di capacita', ma per questioni meramente giuridiche.
Lezione numero cinque: le metriche.
ITIL parla chiaramente di metriche. Per metriche si intende un qualsiasi sistema che, dopo aver disegnato i processi e fatte le debite matrici RACI, riesca a stabilire il costo di ogni operazione, in termini di tempo , di ore uomo e di costi strutturali.
Addirittura, dopo lo scandalo ENRON, il governo americano impose a tutte le aziende che vogliono quotarsi al NYSE l'uso di sistemi di gestione dei flussi aziendali (detti "ticketing systems") nei quali quando io chiedo ad operations si darmi uno storage, apro una richiesta su questo sistema. Operations si vede comparire la richiesta, la soddisfa (o meno) e la richiesta viene tracciata, infine terminata.
ovviamente, lavorando in questo modo qualcuno potra' andare sul nostro ticketing system NYSE-aware e calcolare quanto tempo impieghi Operations per fare una Change Request, quanto costino in media le CR sui dischi, e se non sia il caso di usare un sistema diverso per gli storage.
Allo stesso modo, s eun preparto lavora male o lentamente me ne accorgero' perche' i ticket assegnati a quel reparto vengono chiusi tanto tempo dopo.
Questo e' quello che si chiama "METRICA" . Senza questo, i costi dell'azienda sono fuori controllo.
Adesso torniamo al discorso del Guru in questione, e vediamo perche' gronda estrema ignoranza, visibile con evidenza da chiunque sia un addetto ai lavori.
1)Egli pensa che tutti i requisiti di un servizio siano funzionali. Pensa che per offrire il servizio occorra semplicemente disegnare il servizio. Non si chiede quanti annessi e connessi servano per supportare capacita' maggiore, e quanti NFR dovranno tener conto delle nuove utenze. Pensa che semplicemente cambiando la cultura , si possano portare le masse ad usare i servizi. Palle. Pensa che le masse possano avere il servizio semplicemente perche' cambiano cultura e decidono di usarlo. Palle.
2)Pensa che tutti i sistemi siano isolati, e quindi una modifica nelle abitudini e nel sentire degli utenti possano essere considerate come variabili indipendenti. Facebook puo' crescere semplicemente crescendo, e chissenefrega se la telco che gli manda via gli SMS non ce la fa. Pensa che qualsiasi social network possa crescere a seconda di quanto la gente decida di usarlo. Palle.
3)Dimentica che tutti i servizi di rete sono end-to-end, ovvero che bisogni considerare l'intero processo, comprese le asimmetrie fra l'infrastruttura di chi ne vuole fruire e quella di chi eroga il servizio in se'. Possiamo modificare le abitudini di una popolazione quanto vogliamo, se poi volete chiamare l'amazzonia in videoconferenza, qualche problema di banda lo avrete. Pensa che Internet sia come l'aria, che sia ovunque e sempre, con la stessa qualita'. Palle.
4)Dimentica gli aspetti giuridici legati all'implementazione dei sistemi, il trattamento dei dati, la loro gestione, la responsabilita' di servizio che ne deriva. Pensa che qualsiasi azienda o PA possa trattare i dati col sistema che preferisce, come l'instant messaging, o come il "be social", semplicemente perche' decide che sia meglio cosi'. I dati, spesso hanno una posizione precisa nello spazio: sarebbe bello se le infermiere ricevessero via sms le istruzioni da un server centrale: dai le medicine a tizio, a caio. Certo. Ma questi dati sono riservatissimi, e non possono andare su una rete pubblica.
5)Quando propone di rendere social le aziende, di farle lavorare con gli RSS anziche' con l'email, dimentica semplicemente che esistono delle pratiche sancite , per esempio da ITIL , per i quali richiediamo di avere delle metriche di servizio, degli SLA e degli OLA. In che modo sia possibile calcolare queste metriche "di condivisione" basate su instant messaging, blog aziendali, rss feed ed altro non viene mai detto, per la semplice ragione che NON si puo' fare.Il nostro guru parla della PA e delle aziende come se un sistema avesse come requisito solo l'efficacia quale mezzo di comunicazione, dimenticando tracciabilita' e metrica di produzione. Incompetenza allo stato puro.
In definitiva, questo signora manca proprio di cio' che vanta di avere, ovvero dal suo parlare si evidenzia che manca proprio di cultura dell' IT. E' evidente ad ogni sua parola, e vantare certificazioni o sbrodolarsi su Linkedin non serve a molto. Impressionera' molti, ma non gli addetti ai lavori.
A bologna si dice che la merda piu' la mescoli e piu' puzza. Hai voluto fare il guru post-newage, fallo pure. Ma non metterti a ficcare il naso nelle cose serie, la PA italiana ha bisogno di ben altro che la chat, la condivisione e tutte le belle buzzword che dici.
Avrebbe bisogno, prima di tutto, di buoni tecnici.
Uriel
(1)Oggi, con i DWD, non serve piu' tanto, almeno non sul piano fisico del "posare del cavo".
Questo blog fa "profiling" (® Yossarian) di quelli che scrivono i commenti. Il profiling sta alla censura come le escort stanno alle mignotte: e' la stessa cosa, ma suona meglio. E' una parola inglese, quindi vi piacera'. Siete gia' eccitati, lo so. Prima di postare, per non perdere tempo, leggete SIA le REGOLE DEL BLOG e le FAQ: eviterete di perdere tempo e di venire "profilati".
