Antipattern dell'organizzazione cloud
Nella struttura organizzativa dei clienti si presentano spesso antipattern per l'adozione del cloud. Questi problemi possono essere causati da diversi fattori:
- Set di strumenti
- Partner
- Tecnici
- Reparti IT non allineati
È importante comprendere il ruolo di questi fattori in uno scenario efficace di adozione del cloud.
Antipattern: considerare l'IT come centro di costo
Molte aziende considerano i reparti IT come centri di costo. Questo approccio può portare a pensare che l'IT non aggiunga valore all'azienda. I dipendenti possono scoraggiarsi se percepiscono l'IT come un provider invece che come un abilitatore. È anche difficile l'azienda attrarre talenti validi. Ne conseguono una scarsa motivazione e cicli di vita lunghi. La qualità del lavoro dell'IT può risentirne e possono crearsi silo e feudi.
Esempio: considerare l'IT come centro di costo
Un'azienda gestisce il reparto IT come centro di costo sotto la responsabilità del Chief Financial Officer (CFO). Il consiglio di amministrazione considera l'IT come un provider di servizi lento e come uno dei principali fattori di costo per l'azienda. Il consiglio di amministrazione non si rende conto che la business unit responsabile della mobilità sta utilizzando la maggior parte degli asset ordinati dal reparto IT. L'IT acquista un data center per tutte le business unit, ma questo asset è sovradimensionato per la business unit della mobilità. Il consiglio non vede l'IT come un abilitatore o un partner.
Risultato auspicabile: considerare l'IT come un abilitatore
Invece di gestire il reparto IT come centro di costo, prendere in considerazione uno di questi approcci:
- Chargeback: le business unit considerano i costi IT come spese operative nei budget.
- Showback o awareness-back: l'IT funziona come un agente. Nei report per l'azienda, l'IT attribuisce qualsiasi costo diretto alle business unit pertinenti.
Usare il cloud come strumento per aumentare la trasparenza aziendale e dei costi. Ad esempio, implementare una disciplina Gestione costi per aumentare la trasparenza dei costi. In questo modo si avrà una maggiore consapevolezza del costo delle diverse business unit. Il reparto IT verrà considerato come un abilitatore per tali unità.
Per migliorare la trasparenza, quando si passa al cloud, orientarsi su visibilità, responsabilità e ottimizzazione. Per altre informazioni, vedere Creare un'organizzazione attenta ai costi.
Antipattern: investire in nuove tecnologie senza coinvolgere l'azienda
I reparti IT spesso investono risorse umane e finanziarie significative nella creazione e distribuzione di piattaforme e set di strumenti affidabili. Tuttavia a volte l'IT non tiene in considerazione le business unit e le relative esigenze durante le fasi di progettazione e sviluppo. Questa omissione si traduce in nuove piattaforme con una rilevanza minima per le business unit. I dipendenti sono quindi riluttanti ad accettare la nuova tecnologia la cui adozione può essere scarsa o lenta. La frustrazione finisce per colpire anche l'IT dal momento che le business unit non usano le sue piattaforme.
Esempio: configurare una piattaforma senza coinvolgere le business unit
Il reparto IT di una società di analisi di dati configura e personalizza una piattaforma Azure senza coinvolgere alcuna business unit. Mentre usano la piattaforma, gli sviluppatori delle business unit:
- Si rendono conto di non avere le autorizzazioni necessarie per la distribuzione.
- Possono usare solo un numero limitato di servizi.
- Creano ticket di supporto, che allungano i cicli di approvazione.
- Iniziare a nutrire dubbi sulla nuova piattaforma.
Alla fine, alcuni sviluppatori acquistano di propria iniziativa una sottoscrizione di Azure per evitare il fastidio delle regole e delle normative IT. Lo shadow IT fa la sua comparsa. Poiché l'azienda ha poco controllo sullo shadow IT, emergono forti rischi di sicurezza.
Risultato auspicabile: coinvolgere le business unit nel processo decisionale
Evitare di creare silo IT quando si distribuisce una piattaforma cloud di livello aziendale. Coinvolgere gli sviluppatori e i Technical Decision Maker (TDM) delle business unit nei processi di progettazione e sviluppo. Per migliorare l'adozione della piattaforma, ascoltare i suggerimenti delle business unit.
Per le procedure consigliate di Azure e i principi di progettazione pensati per gli sviluppatori e in grado di velocizzare l'adozione, vedere Iniziare con le zone di destinazione su scala aziendale di Cloud Adoption Framework. Trovare il giusto equilibrio tra conformità e flessibilità, ad esempio individuando i modi per rispettare i criteri di governance e sicurezza, mantenendo tuttavia agili gli ambienti di sviluppo.
Antipattern: esternalizzare le principali funzioni aziendali
I partner di consulenza e i provider di servizi gestiti possono svolgere un ruolo importante in un percorso cloud, ma è importante che non siano i partner e i provider di servizi gestiti a conferire la maggior parte del valore al business delle aziende. Le aziende che esternalizzano le responsabilità ai provider di servizi gestiti o ai consulenti cloud non devono finire con il dipendere da tali provider.
Esempio: esternalizzare l'adozione e la migrazione al cloud
In un istituto di ricerca è in corso un progetto di migrazione al cloud in cui il tempo è un fattore critico. Per abbreviare il percorso di adozione del cloud, viene assunto un provider di servizi gestiti con il compito di creare una base per Azure e implementare la migrazione. Invece di acquisire le conoscenze necessarie per la fase di adozione del cloud e creare competenze, l'istituto sceglie di affidare tutta la responsabilità di Azure al provider di servizi gestiti. Poiché l'istituto non ha conoscenze in materia di cloud o di Azure, il provider di servizi gestiti diventa responsabile di tutte le decisioni, rendendo l'istituto dipendente da sé.
Risultato auspicabile: rendere le aree di progettazione critiche responsabilità dell'azienda
Considerare l'outsourcing come una valida strategia per ridurre i costi, ma prendere internamente le decisioni che coinvolgono queste aree di progettazione critiche:
- Governance
- Rischio
- Conformità
- Identità
Mantenere la responsabilità all'interno dell'azienda per queste e altre aree critiche per la struttura di sicurezza. Rivolgersi a partner esterni per velocizzare il percorso di adozione, ma non esternalizzare ogni attività per evitare di dipendere dai provider.
Antipattern: assumere Technical Decision Maker invece di formare tecnici cloud
Le aziende danno importanza nella ricerca del personale giusto. Di conseguenza, spesso assumono o formano i TDM durante le fasi iniziali di adozione del cloud. Il successo dei percorsi cloud è affidato ai TDM. Ma, ancora più importante, le adozioni del cloud richiedono ingegneri pronti a collaborare e con profonde competenze tecniche.
Esempio: assumere solo TDM
Un istituto di ricerca assume diversi TDM che dovranno gestire il percorso cloud. Al termine della fase iniziale di ideazione generale, viene avviata la fase di implementazione. L'istituto si rende quindi conto che il funzionamento delle distribuzioni cloud è diverso da quello delle distribuzioni locali. Per implementare correttamente i concetti di infrastruttura come codice (IaC) e la governance basata su criteri, è richiesto un lavoro aggiuntivo di progettazione del cloud.
Risultato auspicabile: usare i tecnici cloud per la fase di implementazione
Ricordare che i tecnici sono essenziali per implementare correttamente i concetti di automazione del cloud e zona di destinazione. Le responsabilità e le attività possono cambiare in modo significativo quando si adottano i modelli di servizio. Trasferendo le responsabilità a un provider di servizi cloud, è possibile passare più rapidamente alla fase di produzione. È anche possibile usare i TDM per il processo decisionale, ma è preferibile usare tecnici cloud competenti per le attività che richiedono conoscenze approfondite di progettazione. Si comprenderanno quindi i vantaggi offerti dal cloud.