Cloud Strategy - Parte II: Prepararsi al Cloud

La cloud strategy non è solo un piano di migrazione o una roadmap tecnologica, ma un insieme di scelte che guida obiettivi, priorità, trade-off e decisioni organizzative. Questo articolo si concentra su leadership, governance, competenze, responsabilità, modello operativo e principi pratici necessari per trasformare il cloud da una serie di progetti tecnici scollegati in una reale capacità di business.

Questa serie offre una sintesi con annotazioni del libro di Gregor Hohpe, Cloud Strategy, disponibile su leanpub.com/cloudstrategy.

Executive summary

La cloud strategy non è un piano di migrazione, una roadmap tecnologica o un elenco di servizi cloud da adottare. È un insieme coerente di scelte che spiega perché l’organizzazione si sta spostando verso il cloud, quali risultati contano di più, quali trade-off è disposta ad accettare e come verranno guidate nel tempo le decisioni tecniche e organizzative.

Questa seconda parte della serie si concentra sul lato organizzativo dell’adozione del cloud. L’argomento centrale è che la trasformazione cloud non consiste principalmente nello spostare infrastruttura da un data center ad AWS. È un cambiamento di modello di business, modello operativo, competenze, leadership, governance e responsabilità. Il cloud può migliorare la velocità di delivery, la resilienza, la visibilità sulla sicurezza e la flessibilità dei costi, ma questi benefici non sono automatici. Devono essere conquistati attraverso priorità chiare, una base sicura, automazione, servizi gestiti, responsabilità sui costi, formazione e misurazione continua.

L’articolo propone principi pratici di cloud strategy come valore di business prima della migrazione, foundation prima della scala, guardrail prima della libertà, automazione prima del processo manuale, ownership di prodotto prima dei passaggi di consegne tra progetti e risultati prima delle metriche di attività. Questi principi non sono regole universali; sono esempi del tipo di scelte esplicite che ogni organizzazione deve adattare al proprio contesto.

Il messaggio chiave per i leader è semplice: il successo nel cloud dipende meno dal provider scelto e più dalla capacità dell’organizzazione di cambiare il modo in cui prende decisioni, finanzia il lavoro, sviluppa le persone, gestisce il rischio e misura il valore. Un modello di leadership debole o invisibile trasforma l’adozione del cloud in una collezione di progetti tecnici scollegati. Una strategia forte la trasforma in una capacità di business.

Che cos’è una strategia?

Una strategia non è un piano

Una strategia non è un piano, cioè una lista dettagliata di attività con scadenze e dipendenze precise. Una strategia non è un diagramma di Gantt.

Una strategia è un insieme coerente di scelte che spiega dove si vuole andare, perché conta, cosa si darà priorità, cosa non si farà e come si intende vincere o avere successo dentro vincoli reali. Nel contesto di una migrazione cloud:

Perché ci stiamo spostando nel cloud, quale risultato di business stiamo perseguendo, quali trade-off siamo disposti ad accettare e come guideremo le molte decisioni tecniche e organizzative?

Definizione di una buona strategia

Esempio di cloud strategy debole:

Migreremo ad AWS per ridurre i costi, migliorare l’agilità, aumentare la sicurezza, modernizzare le applicazioni, usare l’AI, migliorare la resilienza e abilitare l’innovazione.

Questa non è davvero una strategia. È una lista di desideri, troppo generica. Esempio di cloud strategy migliore:

Useremo AWS principalmente per aumentare la velocità di delivery e ridurre il carico operativo dei nuovi prodotti digitali. Non migreremo subito ogni sistema legacy. Per prima cosa costruiremo una landing zone multi-account sicura, stabiliremo guardrail di costo e sicurezza, formeremo i product team e daremo priorità alle applicazioni che beneficiano di servizi gestiti, automazione e scaling elastico. I sistemi legacy stabili, senza un chiaro business case, resteranno on-premises fino al rinnovo o alla sostituzione.

Questa è più vicina a una strategia perché contiene priorità, esclusioni, sequenza e trade-off.

Priorità: che cosa conta di più?

Una strategia debole cerca di perseguire tutto contemporaneamente:

Ridurremo i costi, miglioreremo la sicurezza, aumenteremo la velocità, modernizzeremo le applicazioni, miglioreremo la resilienza, abiliteremo l’AI e trasformeremo l’organizzazione.

Tutti questi obiettivi possono essere desiderabili, ma non possono essere tutti la priorità principale allo stesso tempo. Una vera strategia dice:

Per i prossimi 18 mesi, il nostro obiettivo principale è aumentare la velocità di delivery dei prodotti digitali rivolti ai clienti. L’ottimizzazione dei costi è importante, ma non è il primo driver del programma cloud.

Questo cambia le decisioni. Per esempio, se la velocità è la priorità, si possono accettare costi cloud più alti nel breve periodo in cambio di servizi gestiti, automazione e deployment più rapidi.

Esclusioni: cosa non faremo?

Strategia significa anche dire no. Per esempio:

Non migreremo subito ogni applicazione legacy. I sistemi di back office stabili, con bassa frequenza di cambiamento e senza un chiaro beneficio di business, resteranno on-premises per ora.

Senza esclusioni, i programmi cloud diventano spesso enormi esercizi di migrazione in cui tutto viene spostato semplicemente perché “il cloud è la strategia”.

Il cloud in sé non è la strategia. Il cloud è un mezzo per raggiungere risultati di business desiderati.

Sequenza: cosa viene prima?

Una buona strategia definisce l’ordine delle azioni. Per esempio:

Per prima cosa costruiremo la landing zone, il modello di identità, il logging, la connettività di rete, i guardrail di sicurezza e la governance dei costi. Solo dopo migreremo i workload di produzione.

Migrare applicazioni prima di costruire le fondamenta può sembrare più veloce, ma spesso crea lacune di sicurezza, dispersione dei costi, strutture di account incoerenti e confusione operativa.

La sequenza quindi risponde a questa domanda: cosa deve essere vero perché il passo successivo possa avere successo?

Nell’adozione del cloud, la risposta è spesso: foundation prima della scala, governance prima della libertà, competenze prima dell’autonomia e pilota prima della migrazione di massa.

Trade-off: cosa siamo disposti a sacrificare?

Ogni decisione cloud significativa contiene un trade-off. Per esempio:

Preferiremo i servizi gestiti AWS quando riducono il carico operativo, anche se questo aumenta la dipendenza da AWS.

Questo è un trade-off strategico. Si sceglie velocità e riduzione delle attività operative rispetto alla massima portabilità.

Una strategia debole finge che non esistano trade-off:

Vogliamo massima velocità, costo minimo, zero lock-in, pieno controllo, automazione completa, flessibilità totale e nessuna perturbazione organizzativa.

Questa non è una strategia; è pensiero magico.

Una strategia significativa si basa su creatività e disciplina.

Creatività: pensare in grande e fare brainstorming. Disciplina: piano concreto e trade-off. Esplorare opzioni, selezionarne alcune raggiungibili e capaci di generare valore, comunicare le proprie scelte.

Come business leader che sceglie quali progetti finanziare, bisogna evitare di cadere nelle promesse più infondate o esagerate. La realtà presenta sempre il conto. Quando un’iniziativa irrealistica fallisce, il problema non è solo l’esecuzione; può essere l’iniziativa stessa e la decisione di finanziarla.

Gregor Hohpe definisce poi una checklist per valutare i principi strategici:

• Se l’opposto di un principio è assurdo, probabilmente non è un buon principio. Tutti vogliono clienti soddisfatti e un prodotto di alta qualità, quindi trasformarli in un principio non guiderà molte decisioni.
• I principi che includono nomi di prodotto o architetture specifiche, di solito sotto forma di buzzword, rischiano di essere decisioni elevate artificialmente a principi: una forma indesiderata di reverse engineering.
• I principi dovrebbero superare la prova del tempo. Nessuno è chiaroveggente, ma aiuta immaginare se il principio continuerà ad avere senso tra qualche anno. Un buon proxy può essere guardare indietro di tre anni e cercare cattivi esempi.
• Aiuta se la lista dei principi usa il parallelismo, cioè la stessa costruzione grammaticale. Per esempio, è utile se tutti i principi sono frasi complete oppure solo sostantivi. Mescolare le due forme li renderà goffi.
• I principi dovrebbero essere memorabili. Pochi team andranno in giro con la lista dei principi su un foglietto, quindi principi che nessuno ricorda difficilmente influenzeranno molte decisioni. Se li state mettendo su poster motivazionali appesi alle pareti dell’ufficio, probabilmente vi state prendendo in giro.
• Anche se non esiste un numero magico di principi, meno di una manciata potrebbe essere poco, mentre più di una dozzina sarà difficile da ricordare.

Un principio è debole se il suo inverso è assurdo. Per esempio, “vogliamo clienti soddisfatti” è difficile da usare come principio strategico perché nessuna organizzazione seria sceglierebbe il contrario. Riflettendo sul mio percorso, tuttavia, ho osservato spesso che anche questi obiettivi fondamentali e autoevidenti vengono trascurati nella pratica. In una cloud strategy non li scarterei del tutto; li renderei abbastanza concreti da guidare le decisioni. “Migliorare la soddisfazione del cliente” diventa più utile quando viene tradotto in priorità misurabili, come ridurre la durata degli outage, accelerare la delivery delle funzionalità o migliorare i tempi di risposta delle applicazioni rivolte ai clienti.

Principi di cloud strategy

Dopo aver stabilito i criteri per principi efficaci, possiamo esaminare alcuni esempi specifici. È importante riconoscere che, a mio avviso, non esiste una lista universale; il numero di variabili organizzative richiede che ogni strategia sia adattata agli obiettivi di business e alle competenze interne specifiche dell’azienda. Una cloud strategy è definita non da ciò che l’azienda dice di volere, ma dalle decisioni che è disposta a prendere.

Valore di business prima della migrazione

L’adozione del cloud dovrebbe partire dai risultati di business, non dal desiderio di spostare infrastruttura. L’obiettivo non è migrare il maggior numero possibile di server. L’obiettivo è migliorare la capacità dell’azienda di generare valore: delivery più rapida dei prodotti, maggiore resilienza, migliore visibilità sulla sicurezza, accesso a servizi gestiti, migliori capacità sui dati o modelli di costo più flessibili.

Guida decisionale: dare priorità ai workload in cui le capacità cloud creano valore visibile per il business o per le operations.

Foundation prima della scala

Prima di scalare l’uso del cloud, l’organizzazione ha bisogno di una base sicura e governata: struttura degli account, identità, networking, logging, monitoring, baseline di sicurezza, backup, controlli di costo e processi operativi. Muoversi rapidamente senza foundation può creare problemi futuri: ambienti incoerenti, controllo degli accessi debole, log di audit mancanti, dispersione dei costi, architetture duplicate e ownership poco chiara.

Guida decisionale: costruire landing zone, guardrail e modello operativo prima della migrazione di produzione su larga scala.

Guardrail prima della libertà

I team dovrebbero potersi muovere velocemente, ma solo entro confini sicuri. Il self-service cloud è potente perché i team possono effettuare provisioning delle risorse senza aspettare settimane per l’infrastruttura. Ma senza guardrail, la stessa libertà può creare rischi di sicurezza, compliance e costo. L’obiettivo non è rallentare i team con approvazioni manuali. L’obiettivo è automatizzare le regole: regioni consentite, logging obbligatorio, crittografia, policy di identità, standard di rete, tagging dei costi e controlli di sicurezza.

Guida decisionale: sostituire il controllo manuale con guardrail automatizzati ovunque possibile.

Servizi gestiti prima delle operations indifferenziate

Il cloud dovrebbe ridurre la quantità di infrastruttura che l’organizzazione deve gestire direttamente. Quando un servizio gestito può ridurre in modo sicuro il carico operativo, migliorare l’affidabilità o accelerare la delivery, dovrebbe essere preferito rispetto alla costruzione e gestione manuale della stessa capacità.

Questo non significa usare ciecamente ogni servizio gestito. I servizi gestiti possono creare dipendenza dal provider, implicazioni di costo e vincoli architetturali. Ma evitare i servizi gestiti solo per preservare una portabilità teorica spesso riduce il valore del cloud.

Guida decisionale: usare deliberatamente i servizi gestiti quando il beneficio operativo è maggiore del rischio di dipendenza.

Automazione prima del processo manuale

L’infrastruttura cloud dovrebbe essere creata, modificata e governata attraverso l’automazione. Le operations cloud manuali non scalano bene. Sono difficili da auditare, difficili da riprodurre e facili da configurare male. Infrastructure as Code, pipeline CI/CD, policy as code, test automatizzati e controlli di sicurezza automatizzati sono essenziali per rendere il cloud affidabile e ripetibile.

L’automazione non riguarda solo l’efficienza. Riguarda anche coerenza, auditabilità, velocità e riduzione del rischio.

Guida decisionale: se un’attività sarà ripetuta, auditata o usata in produzione, automatizzarla.

Product team prima dei passaggi di consegne di progetto

Il cloud funziona meglio quando i team possiedono ciò che costruiscono ed eseguono. L’IT tradizionale spesso separa architettura, infrastruttura, sicurezza, sviluppo, operations e finanza in silos diversi. Il cloud cambia questo modello perché i team possono prendere decisioni continue su infrastruttura, sicurezza, deployment e costi.

Un modello operativo cloud dovrebbe muoversi verso la product ownership: i team dovrebbero comprendere le proprie applicazioni, infrastruttura, postura di sicurezza, salute operativa e costi. I team centrali dovrebbero fornire piattaforme, pattern riutilizzabili e guardrail, non diventare colli di bottiglia per ogni decisione.

Guida decisionale: organizzare il cloud attorno a ownership di lungo periodo, non a delivery di progetto una tantum.

Security by design, non by inspection

La sicurezza dovrebbe essere integrata nella foundation cloud e nel processo di delivery, non aggiunta alla fine. Nel cloud, molti rischi di sicurezza derivano da configurazione, identità, permessi, servizi esposti, log mancanti, design di rete debole e dati non governati. Questi rischi non possono essere gestiti efficacemente solo attraverso revisioni manuali occasionali.

La sicurezza deve essere progettata nella struttura degli account, nell’identità, nei confini di rete, nella crittografia, nel logging, nelle pipeline di deployment e nei controlli di policy.

Guida decisionale: rendere la configurazione sicura il default, e rendere difficile o impossibile la configurazione non sicura.

Responsabilità sui costi fin dal primo giorno

Il costo cloud dovrebbe essere visibile, allocato e posseduto fin dall’inizio. Il cloud trasforma la spesa infrastrutturale in un modello finanziario continuo e basato sull’uso. Questo crea flessibilità, ma anche rischio. Senza governance dei costi, i team possono creare risorse, duplicare ambienti, archiviare dati, generare log o sovradimensionare capacità senza comprenderne l’impatto finanziario.

L’ottimizzazione dei costi non dovrebbe essere trattata come un’attività di pulizia dopo la migrazione. Dovrebbe far parte di architettura, ownership, tagging, budgeting, monitoring ed economia del prodotto.

Guida decisionale: ogni risorsa cloud dovrebbe avere un owner, uno scopo e visibilità sui costi.

Resilienza attraverso l’architettura, non per assunzione

Usare il cloud non rende automaticamente resilienti le applicazioni. I cloud provider offrono regioni, availability zone, servizi gestiti, backup, replica, scaling e opzioni di disaster recovery. Ma il cliente deve progettare l’applicazione e il modello operativo per usarli correttamente.

Un workload spostato nel cloud senza cambiamenti architetturali può avere ancora single point of failure, procedure di recovery deboli, design di backup inadeguato o failover non testato.

Guida decisionale: definire esplicitamente i requisiti di resilienza, poi progettare e testare per raggiungerli.

Modernizzare dove conta

Non ogni applicazione merita lo stesso livello di modernizzazione. Alcuni sistemi dovrebbero essere dismessi. Alcuni dovrebbero restare dove sono. Alcuni possono essere temporaneamente rehosted. Alcuni dovrebbero essere sostituiti con SaaS. Alcuni meritano refactoring perché supportano capacità di business importanti.

La cloud strategy dovrebbe evitare entrambi gli estremi: migrare tutto senza cambiamenti, oppure rifattorizzare tutto inutilmente.

Guida decisionale: investire sforzo di modernizzazione dove crea valore significativo per il business, per le operations o per la riduzione del rischio.

Competenze prima dell’autonomia

Ai team non dovrebbe essere concessa libertà nel cloud prima che capiscano come usarla responsabilmente. L’adozione del cloud cambia le responsabilità di sviluppatori, operations, sicurezza, finanza, procurement e leadership. I team hanno bisogno di formazione non solo sui servizi cloud, ma anche sul modello di responsabilità condivisa, gestione dei costi, automazione, sicurezza, incident response e governance.

Senza competenze, il self-service diventa un rischio. Con competenze e guardrail, il self-service diventa velocità.

Guida decisionale: aumentare l’autonomia dei team man mano che aumentano la competenza cloud e la maturità della piattaforma.

Misurare i risultati, non l’attività

Un programma cloud non dovrebbe essere misurato solo dal numero di server migrati, account creati o servizi adottati. Queste metriche misurano attività, non valore. Misure migliori includono velocità di deployment, tempo di recovery, trasparenza dei costi, postura di sicurezza, tempo di provisioning dell’infrastruttura, sforzo operativo ridotto, impatto sui clienti e capacità di business abilitate.

Questo principio impedisce all’adozione del cloud di diventare un programma di migrazione basato su metriche di vanità.

Guida decisionale: misurare se il cloud sta migliorando il business, non solo se l’uso del cloud sta aumentando.

Iniziare in piccolo, imparare velocemente, poi scalare

L’adozione del cloud dovrebbe iniziare con apprendimento controllato, non con un enorme programma di trasformazione. Una prima wave di workload dovrebbe validare foundation, modello operativo, governance, controlli di costo e prontezza dei team. L’organizzazione dovrebbe imparare da workload reali prima di scalare la migrazione.

Questo riduce il rischio e impedisce che grandi errori strategici vengano ripetuti su molte applicazioni.

Guida decisionale: usare workload pilota per validare le assunzioni prima di industrializzare la migrazione.

Mantenere onesta la strategia

Una cloud strategy dovrebbe essere verificata rispetto alla realtà. Se i costi crescono senza valore, se i team diventano più lenti invece che più veloci, se aumentano le eccezioni di sicurezza o se i servizi gestiti creano più complessità di quanta ne rimuovano, la strategia va aggiustata.

La cloud strategy non è un documento scritto una volta sola. È un insieme di scelte che deve essere testato, misurato e raffinato.

Guida decisionale: rivedere regolarmente principi e priorità cloud sulla base di evidenze, non di entusiasmo.

Il cloud è una trasformazione del business

Il cloud non è solo un’iniziativa IT; è un processo di modernizzazione e trasformazione del business che coinvolge tutti gli aspetti dell’organizzazione, non solo la tecnologia. L’IT tradizionale on-premises si concentrava su capacity planning, prevedibilità, procurement, separazione dei ruoli e budget di lungo periodo. Al contrario, il cloud favorisce elasticità, automazione, feedback rapido e ownership di ogni aspetto e livello dell’applicazione.

Il cloud fornisce la piattaforma su cui gireranno le applicazioni e saranno archiviati i dati, un ecosistema di servizi che può essere integrato in molti modi per rimodellare il business e l’organizzazione.

Gregor Hohpe sottolinea che il cloud computing non è semplicemente un prodotto da acquistare o una soluzione di hosting più economica; piuttosto, è un nuovo modello di business che richiede alle aziende di adattare strutture e comportamenti interni, dal budgeting all’architettura.

Il cloud attira spesso con buzzword e promesse: costi inferiori, delivery più veloce, maggiore resilienza e migliore sicurezza. Queste sono aspirazioni, non strategie. Devono essere conquistate; non appaiono automaticamente né gratuitamente.

Come già osservato, le strategie efficaci richiedono trade-off, per esempio bilanciare la portabilità cloud con l’adozione di servizi gestiti. Rinunciare ai servizi gestiti spesso significa sacrificare proprio i fattori che guidano la velocità di sviluppo e la disponibilità delle applicazioni.

Le organizzazioni tradizionali sono spesso organizzate in silos funzionali:

• Team infrastrutturali
• Team di sicurezza
• Team di delivery o DevOps
• Team di governance e compliance

Mantenere una struttura tradizionale a silos nel cloud crea attriti e ritardi inutili attraverso passaggi di consegne. L’adozione del cloud favorisce un design dei ruoli e delle responsabilità centrato sull’applicazione. I team possono costruire, distribuire e gestire la propria infrastruttura usando codice, template e standard. Nel frattempo, i team operations e platform diventano più efficaci gestendo foundation condivise, come la landing zone, e sviluppando moduli e pattern riutilizzabili che incorporano best practice e policy di sicurezza.

Il cloud è gestione delle persone

La trasformazione del business inizia dalle persone ed è realizzata dalle persone. È il fattore più importante nel successo di una migrazione e spesso il più ignorato.

Hohpe estende il familiare vocabolario delle “R” della migrazione cloud alla gestione delle persone: retain, reskill, replace, retire.

Retain — Alcuni lavori non cambieranno, o cambieranno solo leggermente. Per esempio, i project manager possono spostarsi verso delivery agile e modalità di lavoro orientate al prodotto, invece che alla delivery di progetto una tantum.

Reskill — Alcuni ruoli possono mantenere il titolo ma richiedere competenze molto diverse. Per esempio, le operations IT possono spostarsi verso automazione, golden image, osservabilità, incident response e platform engineering. Il reskilling è di solito la prima scelta: il personale esistente conosce già il business, le applicazioni e l’infrastruttura attuale. Formare nuove persone richiede mesi, e assumere è spesso un processo lungo, doloroso e costoso, ammesso di trovare il candidato giusto.

Replace — Il reskilling non è sempre possibile o desiderabile. Alcune persone hanno passato anni a diventare esperte nel proprio campo, e potrebbe avere poco senso per loro, o per l’organizzazione, passare a un set di competenze completamente diverso.

Retire — Alcune responsabilità associate alla gestione diretta delle facility di data center possono ridursi o scomparire, come installazione hardware, pianificazione dei rack e gestione della capacità fisica. Altre responsabilità, come vendor management, procurement, controllo finanziario e risk management, non scompaiono; cambiano forma nel cloud.

Hohpe mette in guardia contro la “quinta R”: rinominare i ruoli. Per esempio, i project manager possono essere rinominati Scrum Master e i team “tribù” senza rimuovere gli ostacoli esistenti.

“Con strutture e incentivi esistenti che restano invariati, manovre di questo tipo non ottengono quasi nulla oltre a consumare tempo e denaro. Le organizzazioni non si trasformano applicando nuove etichette a strutture esistenti.”

A mio avviso, la formazione interna è la componente più critica della gestione delle persone per una migrazione cloud di successo e per la prosperità di lungo periodo del business. Senza formazione adeguata per tutti gli attori coinvolti, inclusi business leader e team finance, è impossibile implementare i cambiamenti richiesti dal nuovo modello cloud. Senza formazione per sviluppatori e software architect, operations e security passeranno la maggior parte del tempo a spegnere incendi causati da errori architetturali o a risolvere picchi di costo e fatture alle stelle. Senza formazione per i team operations, gli sviluppatori passeranno tempo a reinventare la ruota per affrontare problemi comuni di networking, monitoring e sicurezza. In ultima analisi, i leader non saranno in grado di formulare strategie solide o prendere decisioni architetturali critiche, fallendo nel cogliere tutti i benefici del cloud. L’ho visto accadere.

Per quanto riguarda la formazione, metto in guardia dal “pensiero magico” che presume che l’apprendimento possa avvenire nel tempo libero frammentato che gli sviluppatori hanno tra attività ad alta priorità e manutenzione quotidiana dei sistemi legacy. Affidarsi allo sforzo individuale e facoltativo per guidare una trasformazione aziendale è un’illusione pericolosa. Perché le iniziative cloud abbiano successo, le organizzazioni devono fornire tempo dedicato, risorse e incentivi per la formazione; altrimenti, semplicemente non accadrà.

Anche se il vero apprendimento nasce dall’esperienza pratica più che dai corsi online, un percorso formativo strutturato e basato sui ruoli è essenziale per stabilire il vocabolario condiviso e la comprensione di base su cui i team devono costruire.

Le certificazioni AWS sono una delle molte opzioni disponibili. Sebbene esistano numerose risorse gratuite e commerciali per aiutare a superare questi esami, l’obiettivo principale dovrebbe essere padroneggiare il materiale, non semplicemente prepararsi al test. Comprendere i contenuti fondamentali di questi corsi è spesso sufficiente. Di seguito ho delineato, come esempio, una mappatura standard tra ruoli organizzativi e certificazioni AWS rilevanti.

Uno dei molti aspetti positivi del cloud è la sua capacità di attrarre talenti di alto livello, perché i professionisti qualificati sono naturalmente attratti da ambienti che danno priorità all’innovazione rispetto alla manutenzione. Al contrario, la mancanza di modernizzazione e l’assenza di sfide tecniche significative possono spingere via i migliori ingegneri, causando una perdita di conoscenza istituzionale. Per evitarlo, le aziende dovrebbero premiare i top performer e metterli nelle condizioni di avviare un ciclo positivo in cui il talento attrae talento, semplificando il recruiting e riducendo i costi di assunzione.

Motivare gli ingegneri richiede un chiaro framework di progressione di carriera basato sulle competenze acquisite e sui risultati, insieme alla rimozione attiva dei processi rigidi e burocratici che soffocano la creatività. Questa trasformazione spesso rivela potenziale non espresso nella forza lavoro esistente: dipendenti motivati che sono stati frenati da procedure legacy ma sono pronti a eccellere quando il modello operativo viene modernizzato.

Inoltre, attrarre personale di alto livello richiede spesso degli “ice breaker”: persone entusiaste disposte a guidare la prima fase di una grande trasformazione e dimostrare la validità del nuovo modello. Concentrandosi sulla gestione delle persone e sul cambiamento culturale, le organizzazioni assicurano che il loro percorso cloud sia sostenuto proprio dalle persone responsabili della sua esecuzione.

Il cloud è una sfida di leadership

Poiché il cloud è una trasformazione del business, il successo dipende fortemente dalla leadership: gli executive devono stabilire priorità, prendere decisioni sui trade-off, finanziare le capacità giuste, responsabilizzare le persone giuste e restare coinvolti oltre la decisione iniziale di migrazione.

• I leader devono stabilire priorità e fornire una direzione chiara.
• I leader devono bilanciare il piano con le opportunità emergenti, correggendo la rotta quando ha senso.
• I leader devono allocare risorse in coerenza con la strategia: dire di volere qualcosa non basta a farlo accadere.

“Per capire la strategia di un’azienda, guarda ciò che fa davvero invece di ciò che dice che farà.” — Andy Grove, ex CEO di Intel

Non si può avere tutto: stabilire priorità significa fare scelte. Se tutto è ad alta priorità, allora niente lo è. Hohpe paragona l’IT a una macchina con molte parti in movimento, manopole e leve interconnesse che non possono essere tutte impostate su “10” allo stesso tempo. Questo richiama una frase spesso attribuita alla cultura ingegneristica e del project management:

Buono, veloce, economico: scegli due.

L’idea è che i risultati di progetto, inclusa la trasformazione cloud, siano vincolati da forze concorrenti, e che i leader debbano essere consapevoli dei trade-off e avere aspettative realistiche:

I leader, inclusi CTO e sponsor di business, devono guidare il momentum di una migrazione cloud. Una migrazione ha più probabilità di fallire quando i leader restano silenziosi e invisibili, trascurando di raccogliere feedback o prendere decisioni di alto livello.

La trasformazione cloud è una trasformazione culturale e, come dice Hohpe:

Non esiste uno Stack Overflow per la trasformazione dove basta tagliare e incollare il cambiamento culturale e compilarlo.

I consulenti esterni possono aiutare ad accelerare il percorso ed evitare errori comuni, ma alla fine sono la leadership e la cloud strategy a determinare il successo della migrazione.

“Se lasciate che esterni o vendor definiscano la strategia, resterete sorpresi da quanto bene i loro prodotti si adatteranno alla vostra strategia.” — Gregor Hohpe

Quando le migrazioni cloud falliscono, raramente la colpa viene attribuita a una leadership debole o assente. Invece, quei fallimenti vengono spesso nascosti dietro spiegazioni vaghe come sforamenti di budget, mancanza di governance, skill gap o architetture disordinate. Questo rischio emerge nel Cloud Readiness Report 2025 di Kyndryl, secondo cui il 70% dei CEO afferma che i propri ambienti cloud sono stati costruiti “per caso, invece che per disegno”. Questo non dimostra che ogni programma cloud sia accidentale, ma suggerisce fortemente che molte organizzazioni lasciano emergere l’adozione cloud attraverso progetti scollegati e reattivi, invece che attraverso una strategia deliberata.

McKinsey, una delle più grandi società di consulenza manageriale al mondo, ha rilevato che le aziende con performance migliori nella migrazione cloud avevano il 32% di probabilità in più di avere sponsor CEO attivi. Erano anche più propense a sviluppare upfront una roadmap completa, inclusi sicurezza e compliance, invece di finanziare iniziative isolate. McKinsey ha inoltre rilevato che gli outperformer nelle migrazioni cloud avevano il 57% di probabilità in più di assumere competenze avanzate come DevOps e FinOps. Questo conta perché una leadership debole spesso sottofinanzia il lavoro meno evidente: formazione, platform engineering, FinOps, automazione della sicurezza, change management e redesign del modello operativo. Il budget di migrazione può pagare strumenti ed esecuzione, ma non le capacità organizzative necessarie per gestire con successo il cloud dopo la migrazione.

Prima di iniziare una migrazione cloud, osservate seriamente ciò che è attualmente in esecuzione. Per costruire una vera strategia, i leader IT devono identificare dove si rompono le cose, cosa crea più dolore operativo e quali sistemi consumano budget senza creare valore proporzionale. Un buon punto di partenza è un inventario applicativo: cosa fa ogni applicazione, chi la possiede, da cosa dipende, quali dati usa, quanto è critica e se debba essere ritirata, mantenuta, sostituita, rehosted, replatformed o refactored. La migrazione cloud include un elemento di outsourcing, ma non risolverà magicamente i problemi IT esistenti.

“C’è una vecchia regola nell’outsourcing: se il tuo IT è un disastro, l’outsourcing lo renderà solo peggiore.” — Gregor Hohpe

Il cloud è un cambiamento organizzativo

Avviare il percorso cloud spesso inizia con la creazione di un Cloud Center of Excellence (CCoE). Si tratta di un piccolo team cross-funzionale responsabile di definire gli standard con cui l’organizzazione adotta, protegge, opera e scala il proprio ambiente cloud. Il CCoE funziona come team interno di abilitazione cloud, aiutando a tradurre la strategia complessiva dell’azienda in pattern pratici, guardrail e pratiche operative. Dovrebbe includere persone provenienti da team e aree diverse.

Questi team cloud centrali hanno alcune caratteristiche:

• Sono piccoli: meno di dieci persone.
• Sono composti da persone ad alte prestazioni, a proprio agio con le moderne tecnologie cloud.
• Operano con autonomia e sono auto-motivati.
• Hanno sponsorship esecutiva per rimuovere ostacoli e definire la direzione.

Il lato negativo di un CCoE è che, come molti team centrali, non scala bene. Man mano che l’azienda e la sua infrastruttura cloud crescono, il team rischia di diventare un collo di bottiglia. Inoltre, un’eccessiva dipendenza da un team centrale per la conoscenza cloud può ostacolare la distribuzione di queste competenze nell’organizzazione.

L’obiettivo è che tutti parlino “cloud” usando un vocabolario condiviso, cosa che non accadrà spontaneamente. Per riuscirci, i team dovrebbero promuovere pratiche collaborative come rotazioni di cloud expert, code review e pair programming.

I cambiamenti organizzativi, come quelli relativi a HR e struttura dei ruoli, richiedono più tempo di quelli tecnologici. Far avanzare uno senza l’altro porta a squilibri e, in ultima analisi, qualsiasi complessità tecnologica costruita senza una base culturale finirà per crollare.

Hohpe suggerisce di avere almeno i seguenti tre ruoli: Executive Sponsor, Chief Architect e Program Manager.

Executive Sponsor: responsabile di ottenere approvazioni, coinvolgere stakeholder e consiglio di amministrazione, proteggere il budget e assicurare che le risorse siano allocate in coerenza con la strategia.

Chief Architect: fonte ultima di conoscenza sull’infrastruttura e sull’architettura esistenti, arbitro delle decisioni tecniche e owner degli standard architetturali.

Program Manager: responsabile di tracciare il piano di migrazione, coordinare l’esecuzione tra team, gestire il flusso di informazioni ed evidenziare le decisioni importanti agli altri ruoli.

Conclusione

La cloud strategy è una disciplina di leadership prima ancora che una disciplina tecnologica. Le decisioni più importanti non riguardano solo quale provider scegliere, quali servizi adottare o quali workload migrare per primi. Le domande più profonde sono organizzative: quali risultati di business contano di più, quali trade-off sono accettabili, chi possiede le decisioni, come verranno formati i team, come saranno governati costi e sicurezza e come l’organizzazione misurerà se l’adozione del cloud sta davvero creando valore.

Una cloud strategy debole cerca di massimizzare tutto contemporaneamente: costi inferiori, maggiore velocità, migliore sicurezza, piena portabilità, più innovazione e nessuna perturbazione. Una strategia più forte accetta che le scelte siano necessarie. Definisce priorità, esclusioni, sequenza e trade-off. Costruisce la foundation prima di scalare la migrazione. Sostituisce il controllo manuale con guardrail automatizzati. Concede autonomia ai team solo quando hanno competenze, strumenti e accountability per usarla responsabilmente.

La lezione organizzativa è altrettanto importante. L’adozione del cloud non può avere successo se viene trattata come un progetto collaterale di proprietà dei soli team infrastrutturali. Richiede sponsorship esecutiva visibile, ownership orientata al prodotto, abilitazione tramite piattaforma, security by design, disciplina FinOps e formazione strutturata per leader, finance, operations, security, architetti e sviluppatori. Un Cloud Center of Excellence può aiutare ad avviare il percorso, ma l’obiettivo di lungo periodo è diffondere la competenza cloud in tutta l’organizzazione, non concentrarla in un piccolo team centrale.

In definitiva, il cloud non premia le aziende semplicemente perché spostano workload. Premia le aziende che imparano a operare in modo diverso. La vera trasformazione non è da un data center a un altro; è da un IT lento, manuale, a silos e orientato agli asset a un modello operativo basato su automazione, consumo di servizi, responsabilità condivisa, apprendimento continuo e valore di business misurabile.