​Difficilmente l'adozione del cloud viene associata dalle aziende a una vera e propria rivoluzione industriale. Questo perché molto spesso l'adozione è legata principalmente a fattori tecnologici e di costo, senza considerare che dietro una scelta di questo tipo si nascondono variabili organizzative, di competenze, strategiche e tattiche.Dal mio personale osservatorio posso evidenziare che spesso la scelta di adottare il cloud all'interno della propria azienda, sia esso nella formula di private cloud o di public cloud, viene presa senza considerare le implicazioni legate al fattore umano come competenza, organizzazione e motivazione.Adottare il cloud senza considerare questi elementi, ma soffermandosi solo su aspetti economici, porta al fallimento del progetto, dove spesso prevalgono performance e ottimizzazione dei sistemi informativi.

Queste ottimizzazioni sono spesso aleatorie e con costi molto elevati nel medio e lungo periodo. Prendiamo ad esempio l'adozione dei microservizi: molte aziende adottano il modello Kubernetes senza considerare gli aspetti legati alle competenze del proprio team, l'impatto che l'adozione di nuovi paradigmi applicativi ha sull'organizzazione, la leadership aziendale non preparata a questa trasformazione e la frustrazione del fallimento dovuto alle pressioni del mercato.Anche la demotivazione dei collaboratori, che si sentono esclusi dal processo di modernizzazione per mancanza di competenze, è un fattore fondamentale nel successo dell'adozione del cloud.













Come ovviare a questi ostacoli all'innovazione?

Può essere utile fornire ai responsabili IT le risorse finanziarie e gli strumenti tecnologici e organizzativi necessari per analizzare le competenze disponibili, definire gli skill gap e ridisegnare l'organizzazione aziendale in modo da rispondere pienamente ai requisiti dei nuovi modelli. Ad esempio, oggi la maggior parte delle competenze IT sono legate alla virtualizzazione e chi decide di adottare Kubernetes senza un adeguato reskilling rischia un fallimento sicuro, poiché utilizza vecchi paradigmi per adeguarli alle nuove ed emergenti richieste del mercato.Gestire un ambiente virtuale non è la stessa cosa che gestire e orchestrare microservizi. Sviluppare un'applicazione verticale, seppur virtualizzata, è molto diverso dallo sviluppare un'applicazione a microservizi e coordinarne l'utilizzo all'interno di logiche applicative o di esposizione di dati tramite API. 

Occorre quindi definire un piano che traghetti le competenze dal mondo virtuale tradizionale a quello Kubernetes nativo. Solo guardando al presente posso garantirmi un futuro! Il passato può aiutarmi a evitare gli errori, ma devo saper distinguere tra le esperienze acquisite, le cosiddette best practices, che mi permettono di evitare errori, e gli schemi e bias che mi limitano o mi deviano dal percorso corretto di modernizzazione.Pensare con la mentalità della virtualizzazione è l'errore più grande che si possa fare in una strategia di adozione dei container. Spesso si utilizza un classico bias interpretativo per interpretare nuove esigenze associandole al vecchio modello. Studi scientifici hanno dimostrato che l'interpretazione può essere appresa e quindi anche l'utilizzo di schemi interpretativi nell'adozione dell'innovazione può essere formato attraverso l'apprendimento di schemi interpretativi orientati a nuovi modelli cloud rispetto ai tradizionali legati alla virtualizzazione.

Oggi Red Hat sta portando avanti una politica di adozione di OpenShift (la piattaforma Kubernetes di Red Hat) che prevede, prima di tutto, una revisione degli skill e delle competenze per permettere alle aziende di aggiornare le competenze del proprio personale al fine di affrontare questa nuova rivoluzione tecnologica.Nella mia pratica quotidiana, consiglio sempre ai miei clienti di affiancare al progetto di adozione di OpenShift anche un percorso formativo sia per il team IT che per il team di sviluppo, al fine di ottenere le competenze necessarie alla trasformazione e al deployment dei nuovi modelli applicativi. Ho visto molti progetti fallire perché si pensa che le competenze siano un extra costo inutile. 

Questa prospettiva però presuppone una cecità da parte del management nel non considerare che il valore dell'azienda del 21° secolo dipende proprio dalle competenze e dalla motivazione dei propri collaboratori.Spesso si affida la gestione di un progetto di adozione di OpenShift alle strutture che gestiscono il mondo virtuale, ma nel nuovo approccio alla container adoption, questo è uno degli errori peggiori che si possa fare. 

Alcuni modelli organizzativi prevedono la creazione di nuove figure che abbiano competenze sia infrastrutturali che di sviluppo. Questa è la visione corretta per affidare la gestione di un progetto di trasformazione applicativa a container.Esistono rischi legati all'obsolescenza della conoscenza, che spesso portano le aziende a ridurre il personale per non sostenere l'onere della trasformazione delle competenze. Un altro approccio utilizzato è quello di lasciare il personale a "fare da sé", con il rischio di incorrere in errori e bias interpretativi. 

Pochi ci pensano, ma una competenza acquisita con il fai da te rischia di essere deviata dagli schemi ormai acquisiti nel proprio bagaglio culturale. 

Per evitare che schemi vecchi condizionino modelli emergenti è necessaria una formazione strutturata, gestita da esperti che siano in grado di rimodellare le nozioni acquisite, ristrutturale verso i nuovi modelli e consolidarle.Ci vorrebbero pagine e pagine per illustrare tutto il percorso necessario per l'adozione di una strategia cloud e di containerizzazione dei microservizi, ma non è lo scopo di questo breve articolo.

 Vi consiglio solo di approfondire l'offerta formativa Red Hat e degli Innovation Lab, che nascono proprio per aiutare le aziende a comprendere i gap nell'ambito delle competenze e a fornire un percorso corretto e professionale di aggiornamento degli skill.

This site was created with the Nicepage