Caso Utente

La “lezione” di Enel sulla cloud transformation

Chi avesse eventualmente pensato di scegliere il cloud per poter dormire sonni tranquilli, avrebbe avuto un brusco risveglio nell’ascoltare Fabio Veronese, Head of Global Infrastructure & Networks Digital Hub di Enel. La cloud transformation è un percorso irto di trabocchetti e non finisce mai. Ce lo insegna l’esperienza di una grande azienda che ormai da anni opera con successo totalmente in cloud. Ma lo sforzo vale la candela.

Pubblicato il 13 Gen 2022

5793

Una “lezione”, interessante e istruttiva su cosa sia e a cosa davvero serva il cloud native deployment, viene dal keynote speech di Fabio Veronese, Head of Global Infrastructure & Networks Digital Hub di Enel, in occasione del convegno “Cloud transformation: pronti per il sorpasso?”, organizzato dell’Osservatorio Cloud del Politecnico di Milano. Ricordiamo che Enel ha rappresentato uno dei primi esempi, particolarmente impegnativa e al tempo stesso rapida, di cloud transformation.

Cosa è (e cosa non è) cloud native

Veronese sgombra innanzi tutto il campo da posizioni che identificano il cloud native con operazioni lift e shift o serverless, implementazioni a microservizi o conteinerizzazione. Si tratta di metodologie utili ma che generano aspettative esagerate con il rischio di fare errori e pasticci che la stessa Enel ha sperimentato e poi corretto.

“Per definire invece cosa è native, bisogna capire perché è nato il cloud – suggerisce e spiega – L’obiettivo è industrializzare e astrarre dall’hardware fisico l’hardware virtuale; proprio l’effetto di astrazione aiuta l’industrializzazione”. L’industrializzazione è fondamentale per aumentare la velocità di sviluppo e l’affidabilità del software, riducendo errori manuali e interventi ripetitivi, per massimizzare il riuso e standardizzare i requisiti non funzionali. L’effetto astrazione che si focalizza sugli aspetti funzionali consente di sviluppare il massimo potenziale del cloud che consiste consente di vedere l’infrastruttura come un codice software.

“Ci vuole un ecosistema per generare prodotti verticali e completi: la collaborazione è indispensabile per generare risultati che altrimenti non sarebbero raggiungibili – aggiunge – Ma per collaborare bisogna definire delle regole, non per andare a limitare la nostra libertà ma per permettere a tutti di muoversi nel modo corretto. Chi ha fatto il developer, tuttavia, sa che è molto difficile seguire le regole degli altri mentre è molto facile cercare di imporre le proprie”.

Se riusciamo dunque ad andare al cuore delle cose, proporre un ecosistema e regole condivise, possiamo ottenere una cloud native platform, un ambiente che consente di sviluppare nella maniera più efficiente e veloce, ottenendo i maggiori vantaggi possibili dal cloud.

Verso una cloud native platform

Le caratteristiche di una digital platform efficace sono, secondo Veronese:

  • Federazione che si traduce nella capacità di far lavorare più team, in maniera autonoma, senza la necessità di un coordinamento gerarchico, decentrando la responsabilità, anche grazie alla condivisione di principi comuni, di template…Ne risulta un avvio rapido di nuovi progetti, un basso time-to-market, una migliore qualità del risultato.
  • Democratizzazione, che vede i dati come patrimonio comune e dunque abilita l’accesso ai dati in modo libero, pur nella salvaguardia dei principi della privacy; per default ogni owner del dato lo deve rendere disponibile. Indispensabile a suo parere un approccio domain drive design (DDD).

Ne consegue la certezza della correttezza dei dati e della loro consistenza per tutta l’organizzazione, la loro qualità, il controllo sull’accesso.

  • Standardizzazione che rappresenta la lingua comune e necessita di una definizione centralizzata del “come”, attraverso un ecosistema consistente per gli sviluppatori, che riescono così a “vedere” le stesse cose. Fra i risultati, la maggiore velocità di sviluppo e l’aumento della qualità, la possibilità di focalizzazione sugli aspetti funzionali, la facilità di rotazione delle persone, l’attuazione della cybersecurity by design. La standardizzazione inoltre abilita l’automazione.
  • Automazione (a sua volta presupposto per l’industrializzazione) del set up dei nuovi progetti, della produzione, del testing e dell’inspection, dell’allocazione delle risorse, del provisioning del cloud, del deployment del software… In pratica consente di gestire tutto via software. Fra i maggiori benefici, la riduzione degli errori e dei costi, la scalabilità, la rapidità dei processi di deployment, la possibilità per le persone di focalizzarsi sulle attività di maggior valore.

Attenti alla sindrome del monolite

“Per uscire dal mondo dei silos è indispensabile separare il mondo dei dati da quello delle soluzioni con un sistema di disaccoppiamento necessario per rompere la sindrome del monolite”, sostiene Veronese, portando ad esempio piattaforme recenti, di mercato, magari realizzate con una logica a microservizi, che presentano tuttavia un basso grado di integrazione con altri sistemi. “Di fatto sono esse stesse monoliti perché tengono all’interno il dato, facile da inserire, difficile da estrarre”, commenta.

Per andare oltre i monoliti si deve adottare una logica architetturale da piattaforma di piattaforme, andando ad alimentare continuamente l’ecosistema. È necessario migliorare l’apertura by design introducendo nuovi template, seguire l’evoluzione delle tecnologie, spingere sull’efficienza introducendo nuovi strumenti e servizi. È necessario scalare, con l’impiego di tecnologie e metodologie aggiornate, ampliare il perimetro della piattaforma a ogni area aziendale, integrare con altre piattaforme e prodotti aziendali.

“La soluzione sviluppata da Enel è un modello di apertura ma potrebbe a sua volta diventare un monolite. Per evitarlo è necessario nutrire continuamente l’ecosistema, partendo da una piattaforma che di per sé consenta l’apertura, venga gestita in modo aperto e inglobi continuamente nuove tecnologie”, sintetizza Veronese, ricordando che, per evitare il rischio di diventare un monolite, Enel ha previsto un meccanismo di interazione della sua con altre n piattaforme”.

La trasformazione continua; è tuttavia utile sintetizzare i pilastri che hanno guidato fin qui il percorso:

  • insourcing delle competenze, perché lo sviluppo di una piattaforma cloud native non è appaltabile;
  • comunicazione, indispensabile per evitare che la piattaforma cloud native venga percepita come un’idea balzana dell’IT; la visione e il percorso vanno condivisi con il management aziendale;
  • conoscenza, fondamentale per tener conto del rapido cambiamento delle tecnologie, delle esperienze e delle esigenze; inevitabile dunque continuare a informarsi, a imparare, a studiare, a leggere…
  • condivisione della visione, a livello aziendale, presupposto per il successo.

CTA_PMI pronte per la ripartenza con Avaya Cloud Office

Valuta la qualità di questo articolo

La tua opinione è importante per noi!

Articoli correlati

Articolo 1 di 3