Esaminare e confrontare i modelli operativi cloud comuni

Articolo
12/15/2024

I modelli operativi sono univoci e specifici per l'azienda che supportano, in base ai requisiti e ai vincoli correnti. Ma i modelli operativi non sono fiocchi di neve. Esistono diversi modelli comuni nei modelli operativi dei clienti; questo articolo illustra i quattro modelli più comuni.

Confronto tra modelli operativi

L'immagine seguente esegue il mapping dei modelli operativi comuni in base alla gamma di complessità, dalla meno complessa (decentralizzata) alla più complessa (operazioni globali). Le tabelle seguenti confrontano gli stessi modelli operativi in base al valore relativo di alcuni altri attributi.

Diagramma che mostra i gradi di complessità del modello operativo.

Priorità o ambito

Un modello operativo cloud è principalmente guidato da due fattori:

Priorità o motivazioni strategiche
Ambito del portfolio da gestire

	Operazioni decentralizzate (ops)	Operazioni centralizzate (ops)	Operazioni aziendali (ops)	Operazioni distribuite
Priorità o Motivazioni Strategiche	Innovazione	Controllo	Democratizzazione	Integrazione
ambito portfolio	Carico di lavoro	Zona di atterraggio	Piattaforma cloud	Portfolio completo
Ambiente di lavoro	Complessità elevata	Bassa complessità	Complessità media	Complessità media o variabile
zona di atterraggio	N/D	Complessità elevata	Complessità da media a bassa	Bassa complessità
utilità della fondazione	N/D	Supporto non applicabile o basso	Supporto centralizzato e maggiore	Il maggior supporto
Cloud Foundation	N/D	N/D	Basi ibride, specifiche del fornitore o regionali	Distribuito e sincronizzato

Priorità strategiche o motivazioni : ogni modello operativo offre le motivazioni strategiche tipiche per l'adozione del cloud. Ma alcuni modelli operativi semplificano motivazioni specifiche.
Ambito del Portfolio: L'ambito del portfolio identifica il più ampio ambito supportato da una specifica progettazione del modello operativo. Ad esempio, le operazioni centralizzate sono progettate per alcune zone di destinazione. Tuttavia, la decisione del modello operativo potrebbe creare rischi operativi per un'organizzazione. I rischi operativi comportano un tentativo di gestire un portafoglio complesso di grandi dimensioni. Questi portfolio potrebbero richiedere molte zone di destinazione o complessità variabile nella progettazione della zona di destinazione.

Importante

L'adozione del cloud spesso provoca una riflessione sul modello operativo corrente e potrebbe comportare un passaggio da un modello operativo comune a un altro. Ma l'adozione del cloud non è l'unico trigger. Le priorità aziendali e l'ambito dell'adozione del cloud possono cambiare il modo in cui il portfolio deve essere supportato. Inoltre, potrebbero esserci altri cambiamenti nel modello operativo allineato in modo più appropriato. Quando il consiglio di amministrazione o altri team esecutivi sviluppano piani aziendali da 5 a 10 anni, questi piani spesso includono un requisito (esplicito o implicito) per modificare il modello operativo. I modelli operativi sono un buon riferimento per guidare le decisioni. Questi modelli possono cambiare o essere personalizzati per soddisfare i requisiti e i vincoli.

Allineamento della responsabilità

Molti team e singoli utenti sono responsabili del supporto di funzioni diverse. Tuttavia, ogni modello operativo comune assegna la responsabilità finale per i risultati delle decisioni a un team o a un singolo utente. Questo approccio influisce sulla modalità di finanziamento del modello operativo e sul livello di supporto fornito per ogni funzione.

	Operazioni decentralizzate	Operazioni centralizzate	Operazioni d'impresa	Operazioni distribuite
allineamento aziendale	team gestione carichi di lavoro	Strategia centrale del cloud	CCoE	Variabile: formare un ampio team per la strategia del cloud?
operazioni cloud	team di lavoro	IT centrale	CCoE	Basato sull'analisi del portafoglio - vedere Allineamento aziendale e Impegni aziendali
cloud governance	team di gestione dei carichi di lavoro	IT centrale	CCoE	più livelli di governance
Sicurezza del Cloud	team di lavoro	centro operazioni di sicurezza (SOC) / funzione DevSecOps	CCoE + SOC	Misto: vedere Definire una strategia di sicurezza
Automazione cloud e DevOps	team di gestione del carico di lavoro	IT centrale o N/A	CCoE	Basato sull'analisi del portfolio - vedere l'allineamento aziendale e gli impegni aziendali

Accelerare l'implementazione del modello operativo in Azure

Come illustrato in Definire il modello operativo, ogni metodologia di Cloud Adoption Framework fornisce un percorso strutturato per lo sviluppo del modello operativo. Queste metodologie possono aiutare a superare i blocchi che derivano da lacune nell'adozione del modello operativo cloud.

La tabella seguente illustra i modi per accelerare l'implementazione del modello operativo.

	Operazioni decentralizzate	Operazioni centralizzate	Operazioni aziendali	Operazioni distribuite
punto di partenza	Azure Well-Architected Framework (WAF)	Zone di atterraggio Azure: opzioni per iniziare in piccolo	Zone di atterraggio di Azure: Framework di Adozione al Cloud per le imprese	allineamento aziendale
Iterazioni	Concentrarsi sui carichi di lavoro permette al team di lavorare iterativamente all'interno del WAF.	L'opzione start-small richiede più iterazione su ogni metodologia, ma può essere eseguita man mano che le attività di adozione del cloud maturano.	Come illustrato dalle implementazioni di riferimento, le iterazioni future si concentrano in genere sulle aggiunte di configurazione secondarie.	Esaminare le opzioni di implementazione della zona di destinazione di Azure iniziare con l'opzione più adatta alla baseline operativa. Seguire il percorso di iterazione definito nei principi di progettazione di tale opzione.

Operazioni decentralizzate

operazioni decentralizzate

Le operazioni sono sempre complesse. Se si limita l'ambito delle operazioni a un carico di lavoro o a una piccola raccolta di carichi di lavoro, è possibile controllare la complessità. Le operazioni decentralizzate sono il meno complesso dei modelli operativi comuni. In questa modalità operativa, ogni carico di lavoro opera in modo indipendente grazie ai team dedicati.

Priorità: La tua squadra valuta l'innovazione rispetto al controllo centralizzato o alla standardizzazione tra più carichi di lavoro.
Vantaggio Distintivo: Massimizzare la velocità dell'innovazione dando ai team aziendali e del carico di lavoro il pieno controllo della progettazione, dello sviluppo e delle operazioni.
Distinti svantaggi: riduzione della standardizzazione tra carichi di lavoro, economie di scalabilità tramite servizi condivisi e attività di conformità centralizzate di governance coerenti.
Risk: questo approccio introduce rischi nella gestione di un portafoglio di attività. I team del carico di lavoro potrebbero avere team specializzati dedicati alle funzioni IT centrali. Questo modello operativo è considerato un'opzione ad alto rischio da parte di alcune organizzazioni, in particolare le aziende che devono rispettare i requisiti di conformità di terze parti.
Indicazioni: le operazioni decentralizzate sono limitate alle decisioni relative ai carichi di lavoro. Microsoft Azure Well-Architected Framework supporta le decisioni prese all'interno di tale ambito. I processi e le linee guida all'interno di Cloud Adoption Framework potrebbero comportare un sovraccarico non richiesto dalle operazioni decentralizzate.

Vantaggi delle operazioni decentralizzate

Gestione dei costi: il costo delle operazioni è facilmente assegnabile a una singola business unit. Le operazioni specifiche del carico di lavoro supportano un'ottimizzazione maggiore del carico di lavoro.
Responsabilità: in genere, questo tipo di operazioni dipende in modo elevato dall'automazione per ridurre al minimo i costi generali. Le responsabilità tendono a concentrarsi su DevOps e sulle pipeline per la gestione delle versioni. Questo tipo di operazioni supporta distribuzioni più veloci e cicli di feedback più brevi durante lo sviluppo.
standardizzazione: usare un codice sorgente e una pipeline di distribuzione per standardizzare l'ambiente da un rilascio all'altro.
Il supporto delle operazioni: le decisioni che influiscono sulle operazioni sono rivolte solo alle esigenze di quel carico di lavoro e rendono più semplici le decisioni operative. I membri della comunità DevOps affermano che il sostegno delle operazioni è la forma più pura delle operazioni a causa dell'ambito operativo più stretto.
Expertise: I team DevOps e di sviluppo sono più abilitati da questo approccio e sperimentano la minore resistenza nel promuovere il cambiamento del mercato.
progettazione della zona di destinazione: nessun vantaggio operativo specifico.
utilità di base: nessun vantaggio operativo specifico.
Separazione dei compiti: nessun vantaggio operativo specifico.

Svantaggi delle operazioni decentralizzate

gestione costi: i costi aziendali sono più difficili da calcolare. La mancanza di team di governance centralizzati rende più difficile implementare controlli o ottimizzazioni uniformi dei costi. Su larga scala, questo modello può essere costoso, perché ogni carico di lavoro potrebbe avere duplicazione in asset distribuiti e assegnazioni di personale.
Responsabilità: La mancanza di supporto centralizzato implica che il team di lavoro è completamente responsabile della governance, della sicurezza, delle operazioni e della gestione delle modifiche. La mancanza di supporto è problematica quando tali attività non sono state automatizzate nelle pipeline di revisione e rilascio del codice.
Standardizzazione: La standardizzazione in un portafoglio di carichi di lavoro è variabile e incoerente.
il supporto delle operazioni: spesso le efficienze di scalabilità non vengono soddisfatte durante la creazione di procedure consigliate in più carichi di lavoro.
esperienza: i membri del team hanno una maggiore responsabilità di prendere decisioni saggie ed etiche sulla governance, la sicurezza, le operazioni e la gestione delle modifiche all'interno della progettazione e della configurazione dell'applicazione. Per migliorare le competenze necessarie, consultare la revisione di Microsoft Azure Well-Architected e il Framework di Azure Well-Architected.
progettazione della zona di atterraggio: le zone di atterraggio non sono specifiche per carichi di lavoro e non sono considerate in questo approccio.
Servizi di base: Pochi (se presenti) servizi fondamentali vengono condivisi tra carichi di lavoro, riducendo le efficienze di scala.
Separazione dei compiti: requisiti più elevati per i team DevOps e di sviluppo aumentano l'uso dei privilegi elevati da parte di quei team. Se è necessaria la separazione dei compiti, potrebbe essere necessario investire pesantemente nella maturità di DevOps per operare con questo approccio.

Operazioni centralizzate

operazioni centralizzate

Gli ambienti di stato stabili potrebbero non richiedere l'attenzione sull'architettura o sui requisiti operativi distinti dei singoli carichi di lavoro. Le operazioni centrali tendono a essere la norma per gli ambienti tecnologici costituiti principalmente da carichi di lavoro a stato stabile. Esempi di operazioni in stato stazionario includono applicazioni commercial-off-the-shelf (COTS) o applicazioni personalizzate ben consolidate che hanno una cadenza di rilascio lenta. Se una frequenza di modifica è determinata da aggiornamenti e patch regolari, la centralizzazione delle operazioni potrebbe essere un modo efficace per gestire il portfolio.

Priorità: Le priorità sono il controllo centrale sull'innovazione e misurano i processi operativi esistenti in relazione al cambiamento culturale verso le moderne operazioni cloud.
Vantaggio distintivo: la centralizzazione introduce economie di scala, controlli di eccellenza e operazioni standardizzate, e funziona meglio con l'ambiente cloud. Questi ambienti richiedono configurazioni specifiche per integrare le operazioni cloud in processi e operazioni esistenti. La centralizzazione è più vantaggiosa con un portfolio di poche centinaia di carichi di lavoro con modeste complessità e requisiti di conformità dell'architettura.
Svantaggio distinto: Il ridimensionamento per soddisfare le esigenze di un ampio portafoglio di carichi di lavoro può mettere una significativa pressione sui team centralizzati che prendono decisioni operative per i carichi di lavoro di produzione. Se gli asset tecnici prevedono una scalabilità superiore a 1.000 macchine virtuali, applicazioni o origini dati, è possibile prendere in considerazione un modello aziendale se è entro 18-24 mesi.
Rischio: Questo approccio limita la centralizzazione a un numero inferiore di sottoscrizioni (spesso una singola sottoscrizione di produzione). Il rischio significativo è dovuto al refactoring in un secondo momento nel percorso cloud e potrebbe interferire con i piani di adozione. Per evitare di rielaborare, provare a concentrarsi sulla segmentazione, sui limiti dell'ambiente, sugli strumenti di identità e su altri elementi fondamentali.
Linee guida: le opzioni di implementazione della zona di atterraggio di Azure allineate alla velocità di sviluppo "iniziare in piccolo e espandersi" creano un solido punto di partenza. È possibile usare queste opzioni per accelerare le attività di adozione. Ma per avere successo, definire criteri chiari per guidare gli sforzi di adozione precoce entro le tolleranze di rischio accettabili. La governance e la gestione delle metodologie aiutano a creare processi per maturare le operazioni in parallelo. Seguendo questi passaggi, è necessario completare le tappe obbligatorie prima di consentire un rischio aumentato man mano che le operazioni maturano.

Vantaggi delle operazioni centralizzate

Gestione costi: centralizzare i servizi condivisi in molti carichi di lavoro crea economie di scalabilità ed elimina le attività duplicate. I team centrali possono implementare rapidamente riduzioni dei costi tramite ottimizzazioni di ridimensionamento e scalabilità a livello aziendale.
Responsabilità: la competenza centralizzata e la standardizzazione possono portare a una maggiore stabilità, prestazioni operative migliori e interruzioni minime correlate alle modifiche. Questo approccio riduce le ampie pressioni di competenze sui team incentrati sul carico di lavoro.
standardizzazione: in generale, la standardizzazione e il costo delle operazioni è più basso con un modello centralizzato perché sono presenti meno sistemi o attività duplicati.
Il supporto delle operazioni: la riduzione della complessità e della centralizzazione delle operazioni rende più semplice per i team IT più piccoli supportare le operazioni.
competenze: Centralizzazione dei team di supporto consente agli esperti di sicurezza, rischio, governance e operazioni di guidare decisioni critiche per l'azienda.
progettazione della zona di destinazione: l'IT centrale riduce la complessità riducendo al minimo il numero di zone di destinazione e sottoscrizioni. Le progettazioni della zona di destinazione tendono a simulare le progettazioni dei data center precedenti, riducendo il tempo di transizione. Man mano che l'adozione procede, le risorse condivise potrebbero essere spostate in un'iscrizione separata o in una fondazione della piattaforma.
Utilità fondamentali: Trasportare le progettazioni esistenti dei data center nel cloud comporta servizi condivisi fondamentali che imitano gli strumenti e le operazioni locali. Quando le operazioni locali sono il modello operativo principale, potrebbe essere un vantaggio, ma tenere presente alcuni svantaggi. Le operazioni locali riducono il tempo di transizione, sfruttano le economie di scala e supportano processi operativi coerenti tra carichi di lavoro ospitati in locale e nel cloud. Questo approccio può ridurre la complessità e il lavoro a breve termine e consentire ai team più piccoli di supportare le operazioni cloud con curve di apprendimento ridotte.
Separazione dei compiti: la separazione dei compiti è chiara nelle operazioni centrali. L'IT centrale mantiene il controllo sull'ambiente di produzione e riduce la necessità di autorizzazioni elevate da parte di altri team. Questo approccio riduce le violazioni limitando il numero di account con privilegi elevati.

Svantaggi delle operazioni centralizzate

Gestione costi: i team centrali non sempre comprendono le architetture dei carichi di lavoro per produrre ottimizzazioni con impatto a livello di carico di lavoro. Questa mancanza di comprensione limita la quantità di risparmi sui costi derivanti da operazioni di carico di lavoro ben ottimizzate. Una comprensione non completa dell'architettura del carico di lavoro potrebbe influenzare le ottimizzazioni centralizzate dei costi, che possono, a loro volta, influenzare le prestazioni, la scala e altri pilastri di un carico di lavoro ben architettato. Prima di applicare modifiche ai costi aziendali ai carichi di lavoro di alto profilo, il team IT centrale deve comprendere e completare la revisione di Microsoft Azure Well-Architected.
responsabilità: centralizzare il supporto e l'accesso alla produzione comporta un carico operativo elevato su poche persone e una maggiore pressione su ogni individuo. Le pressioni eseguite su queste persone causano la necessità di eseguire revisioni più approfondite dei carichi di lavoro distribuiti, che convalidano la conformità ai requisiti dettagliati di governance e conformità della sicurezza.
standardizzazione: gli approcci IT centrali rendono difficile ridimensionare la standardizzazione senza una scalabilità lineare del personale IT centrale.
Il supporto delle operazioni: i maggiori svantaggi di questo approccio sono associati a una scala significativa e a cambiamenti significativi che misurano l'innovazione.
Competenze: Gli esperti sviluppatori e DevOps sono a rischio di essere sottovalutati o troppo limitati in questo tipo di ambiente.
progettazione della zona di destinazione: le progettazioni dei data center si basano sui vincoli degli approcci precedenti, che non sono sempre rilevanti per il cloud. Seguendo questo approccio si riducono le opportunità di ripensare la segmentazione dell'ambiente e di potenziare le opportunità di innovazione. La mancanza di segmentazione della zona di atterraggio aumenta il potenziale effetto di una violazione della sicurezza, la complessità della governance e dell'adeguamento alla conformità e potrebbe creare ostacoli all'adozione nel percorso verso il cloud. Vedere la sezione relativa ai rischi precedente.
utilità di base: durante la trasformazione digitale, il cloud potrebbe diventare il modello operativo principale. Strumenti centrali, creati per le operazioni locali, riducono le opportunità di modernizzare le operazioni e aumentare l'efficienza operativa. Anche la scelta di non modernizzare le operazioni all'inizio del processo di adozione è un'opzione. La modernizzazione può essere ottenuta creando una sottoscrizione di base della piattaforma nel percorso di adozione del cloud. Questo sforzo può essere complesso, costoso e dispendioso in termini di tempo senza una pianificazione avanzata.
Separazione dei compiti: le operazioni centrali seguono in genere uno dei due percorsi e entrambi potrebbero ostacolare l'innovazione.
- opzione 1: ai team esterni all'IT centrale viene concesso l'accesso limitato agli ambienti di sviluppo che simulano la produzione. Questa opzione impedisce la sperimentazione.
- opzione 2: Teams sviluppa e testa in ambienti non supportati. Questa opzione impedisce i processi di distribuzione e rallenta i test di integrazione post-distribuzione.

Operazioni aziendali

operazioni aziendali

Le operazioni aziendali sono lo stato di destinazione consigliato per tutte le operazioni cloud. Le operazioni aziendali bilanciano la necessità di controllo e innovazione semplificando decisioni e responsabilità. L'IT centrale viene sostituito da un centro cloud più facilitante di eccellenza o da un team CCoE che supporta i team di gestione dei carichi di lavoro. Il team CCoE rende i team di lavoro responsabili delle decisioni, anziché controllare o limitare le loro azioni. Ai team di gestione del carico di lavoro viene concesso più potere e maggiori responsabilità per promuovere l'innovazione, all'interno di vincoli ben definiti.

Priorità: La democratizzazione delle decisioni tecniche è una priorità. La democratizzazione delle decisioni tecniche sposta le responsabilità precedentemente detenute dall'IT centrale ai team del carico di lavoro. Per realizzare questo cambiamento nelle priorità, le decisioni diventano meno dipendenti dai processi di revisione a esecuzione umana. Questo approccio supporta la revisione, la governance e l'applicazione automatizzate, usando strumenti nativi del cloud.
Vantaggio distinto: la segmentazione degli ambienti e la separazione dei compiti consentono di bilanciare il controllo e l'innovazione. Le operazioni centralizzate mantengono i carichi di lavoro che richiedono una maggiore conformità e operazioni di stato stabili o rappresentano maggiori rischi per la sicurezza. Al contrario, questo approccio supporta la riduzione del controllo centralizzato dei carichi di lavoro e degli ambienti che richiedono un'innovazione maggiore. Portafogli più grandi potrebbero lottare con l'equilibrio tra il controllo e l'innovazione. Questa flessibilità semplifica la scalabilità di migliaia di carichi di lavoro con una riduzione delle difficoltà operative.
Svantaggio distinto: ciò che ha funzionato in sede potrebbe non funzionare correttamente nelle operazioni cloud aziendali. Questo approccio alle operazioni richiede modifiche in molti fronti. I cambiamenti culturali nel controllo e nella responsabilità sono spesso la sfida più grande. I cambiamenti operativi che seguono i cambiamenti culturali richiedono tempo e sforzi costanti per essere implementati, maturare e stabilizzarsi. Le modifiche architetturali potrebbero essere necessarie in carichi di lavoro stabili, mentre gli strumenti sono necessari per facilitare e supportare i cambiamenti culturali, operativi e architetturali. Questi spostamenti potrebbero richiedere impegni per un provider di servizi cloud primario. Gli sforzi di adozione eseguiti prima di queste modifiche possono richiedere una rielaborazione significativa che va oltre i tipici sforzi di refactoring.
rischio: questo approccio richiede l'impegno esecutivo per la strategia di cambiamento. Richiede anche l'impegno dei team tecnici per superare le curve di apprendimento e fornire il cambiamento necessario. La cooperazione a lungo termine tra business, CCoE, IT centrale e team dei carichi di lavoro è necessaria per ottenere i vantaggi a lungo termine.
indicazioni: le opzioni della zona di destinazione di Azure vengono definite come su scala aziendale. Queste opzioni forniscono implementazioni di riferimento per dimostrare come le modifiche tecniche vengano implementate utilizzando strumenti cloud-native su Azure. L'approccio su scala aziendale guida i team attraverso i cambiamenti operativi e culturali necessari per sfruttare appieno tali implementazioni. Lo stesso approccio potrebbe personalizzare l'architettura di riferimento per configurare l'ambiente in modo da soddisfare i vincoli di adozione e di conformità. Quando si implementano le metodologie di governance e gestione su scala aziendale, è possibile definire i processi. Questi processi possono espandere le funzionalità di conformità e operazioni per soddisfare le esigenze operative.

Vantaggi delle operazioni aziendali

gestione dei costi: i team centrali agiscono sulle ottimizzazioni inter-portfolio e rendono i singoli team responsabili di un'ottimizzazione più approfondita del loro carico di lavoro. I team incentrati sul carico di lavoro sono autorizzati a prendere decisioni e a fornire chiarezza quando queste decisioni hanno un effetto negativo sui costi. I team centrali e quelli dei carichi di lavoro condividono la responsabilità per le decisioni sui costi al livello appropriato.
responsabilità: i team centrali usano strumenti nativi del cloud per definire, applicare e automatizzare le protezioni. Le attività del team di lavoro vengono accelerate tramite l'automazione e le procedure CCoE. I team di lavoro hanno la possibilità di promuovere l'innovazione e assumere decisioni all'interno di quei limiti.
Standardizzazione: Protezioni centralizzate e servizi fondamentali creano coerenza in tutti gli ambienti.
Supporto alle operazioni: i carichi di lavoro che necessitano del supporto delle operazioni centralizzate vengono assegnati in ambienti con controlli in stato stabile. La segmentazione e la separazione dei compiti consentono ai team di gestione operativa di assumersi la responsabilità del supporto operativo nei propri ambienti dedicati. Gli strumenti nativi del cloud automatizzati garantiscono una baseline minima delle operazioni per tutti gli ambienti con supporto operativo centralizzato.
Esperienza: La centralizzazione di servizi fondamentali come sicurezza, rischio, governance e operazioni garantisce una competenza centrale adeguata. I processi chiari e le linee guida educano e responsabilizzano i team di lavoro a prendere decisioni più dettagliate. Queste decisioni espandono l'effetto degli esperti centralizzati senza dover ridimensionare il personale in modo lineare con la scalabilità tecnologica.
progettazione della zona di destinazione: la progettazione della zona di destinazione replica le esigenze del portfolio, creando chiari limiti di sicurezza, governance e responsabilità. Questi limiti sono necessari per gestire i carichi di lavoro nel cloud. È improbabile che le procedure di segmentazione siano simili ai vincoli creati dalle progettazioni dei data center precedenti. Nelle operazioni aziendali, la progettazione della zona di atterraggio è meno complessa, consentendo una scalabilità più rapida e una riduzione delle barriere alla richiesta self-service.
utilità di base: le utilità di base sono ospitate in sottoscrizioni controllate centralmente separate, note come base della piattaforma. Gli strumenti centrali sono quindi instradati in ogni zona di atterraggio come servizi utilitari. La separazione dei servizi di base dalle zone di atterraggio massimizza la coerenza e l'economia di scala. Queste utilità creano anche chiare distinzioni tra responsabilità gestite centralmente e responsabilità a livello di carico di lavoro.
Separazione dei compiti: una netta separazione dei compiti tra le utilità di base e le zone di destinazione è uno dei principali vantaggi dell'approccio operativo. Gli strumenti e i processi nativi del cloud supportano l'accesso e il corretto bilanciamento del controllo tra team centralizzati e team del carico di lavoro. Questo approccio si basa sui requisiti delle singole zone di destinazione e dei carichi di lavoro ospitati nei segmenti di zona di destinazione.

Svantaggi delle operazioni aziendali

Gestione dei costi: I team centrali sono più dipendenti dai team di gestione del carico di lavoro per apportare modifiche di produzione all'interno delle zone di destinazione. Questo cambiamento crea un rischio per potenziali sovraccarichi del budget e ridimensionamento più lento della spesa effettiva. I processi di controllo dei costi, i budget chiari, i controlli automatizzati e le revisioni regolari devono essere applicati in anticipo per evitare sorprese sui costi.
responsabilità: le operazioni aziendali richiedono requisiti culturali e operativi maggiori. Questi requisiti garantiscono chiarezza nelle responsabilità e nella rendicontabilità tra i team centrali e i team operativi.
I processi tradizionali di gestione delle modifiche o i comitati di consulenza per le modifiche (cab) potrebbero non mantenere il ritmo e l'equilibrio necessari in questo modello di operatività. Questi processi si riflettono nell'automazione di processi e procedure che scalano in modo sicuro l'adozione del cloud.
La mancanza di impegno nel cambiare si materializza prima nella negoziazione e nell'allineamento delle responsabilità. L'impossibilità di allinearsi ai turni di responsabilità è un'indicazione che i modelli operativi IT centrali potrebbero essere necessari durante le attività di adozione del cloud a breve termine.
Standardizzazione: mancanza di investimenti in barriere centralizzate o automazione crea rischi per la standardizzazione, che è più difficile da superare tramite processi di revisione manuale. Le dipendenze operative tra i carichi di lavoro nelle zone di destinazione e i servizi condivisi creano rischi maggiori. Questi rischi si estendono alla standardizzazione durante i cicli di aggiornamento o le future versioni delle utilità fondamentali. Durante le revisioni delle fondamenta della piattaforma, è necessario migliorare o addirittura automatizzare i test per tutte le zone di atterraggio supportate e i carichi di lavoro che queste ospitano.
Il supporto delle operazioni: la linea di base delle operazioni fornita tramite l'automazione e le operazioni centralizzate potrebbe essere sufficiente per carichi di lavoro con effetti bassi o con bassa criticità. Tuttavia, i team del carico di lavoro o altre forme di operazioni dedicate potrebbero essere necessari per carichi di lavoro complessi o ad alta criticità. In tal caso, potrebbe creare uno spostamento nei budget operativi, richiedendo alle business unit di trasferire le spese operative a queste forme di operazioni avanzate. Se l'IT centrale è necessario per mantenere la responsabilità esclusiva per il costo delle operazioni, le operazioni aziendali potrebbero essere difficili da implementare.
Competenza: I membri del team IT centrale potrebbero dover acquisire competenze nell'automazione dei controlli centrali precedentemente forniti tramite processi manuali. Inoltre, questi team potrebbero sviluppare competenze per gli approcci di infrastruttura come codice per definire l'ambiente e comprendere la diramazione, l'unione e le pipeline di distribuzione. Almeno, un team di automazione della piattaforma potrebbe avere bisogno di competenze decisionali per comprendere le decisioni prese dal centro cloud di eccellenza o dai team operativi centrali. Ai team di lavoro potrebbe essere richiesto di sviluppare maggiori conoscenze sui controlli e sui processi che governano le loro decisioni.
progettazione della zona di destinazione: la progettazione della zona di destinazione dipende dalle utilità di base. I team del carico di lavoro devono comprendere cosa c'è nella progettazione e cosa non è consentito includere. Questa comprensione può aiutare a evitare la duplicazione di sforzi, errori o conflitti. Per creare flessibilità, è possibile tenere conto dei processi di eccezione nelle progettazioni delle zone di destinazione.
utilità di base: la centralizzazione delle utilità di base richiede tempo. Queste utilità alla fine prendono in considerazione le opzioni e sviluppano soluzioni che possono essere ridimensionate per soddisfare vari piani di adozione. Sono possibili ritardi nelle attività di adozione anticipata. I ritardi potrebbero essere compensati a lungo termine grazie alle accelerazioni e all'evitare i blocchi nel processo.
Separazione dei compiti: garantire una netta separazione dei compiti richiede processi di gestione delle identità maturi. Potrebbe esserci più manutenzione associata al corretto allineamento di utenti, gruppi e attività di onboarding e offboarding. Potrebbe essere necessario adottare nuovi processi per accomodare l'accesso just-in-time tramite privilegi elevati.

Operazioni distribuite

operazioni distribuite

Il modello operativo esistente potrebbe essere troppo radicato per l'intera organizzazione per passare a un nuovo modello operativo. Per altre, le operazioni globali e i vari requisiti di conformità potrebbero impedire a specifiche business unit di apportare modifiche. In questo caso, potrebbe essere necessario un approccio alle operazioni di distribuzione. Questo approccio è di gran lunga più complesso, perché richiede l'integrazione di uno o più dei modelli operativi indicati in precedenza.

Sebbene sia fortemente sconsigliato, questo approccio operativo potrebbe essere necessario per alcune organizzazioni. L'approccio riguarda principalmente le organizzazioni che dispongono di una raccolta separata di business unit diverse, una base diversificata di segmenti di clienti o operazioni regionali.

Priorità: Integrare più modelli operativi esistenti.
Stato transitorio con particolare attenzione allo spostamento dell'intera organizzazione in uno dei modelli operativi menzionati in precedenza.
Approccio operativo a lungo termine quando l'organizzazione è troppo grande o troppo complessa da allineare a un singolo modello operativo.
Vantaggio distintivo: integrare elementi comuni del modello operativo da ogni business unit. Questo approccio crea un veicolo per raggruppare le unità operative in una gerarchia che consente di maturare le operazioni usando processi ripetibili coerenti.
Svantaggio distinto: La coerenza e la standardizzazione tra più modelli operativi sono difficili da mantenere per periodi prolungati. Questo approccio operativo richiede una profonda consapevolezza del portfolio e del funzionamento dei vari segmenti del portfolio tecnologico.
rischio: la mancanza di impegno per un modello operativo primario potrebbe causare confusione tra i team. Usare questo modello operativo quando non è possibile allinearsi a un singolo modello operativo.
Linee guida: iniziare con una revisione approfondita del portfolio, che usa l'approccio descritto negli articoli allineamento aziendale. Provare a raggruppare il portfolio in base al modello operativo stato (decentralizzato, centralizzato o aziendale).
Sviluppare una gerarchia di gruppi di gestione che rifletta i raggruppamenti dei modelli operativi. Questa disposizione include altri modelli organizzativi per regioni, business unit o altri criteri che mappano i gruppi di carico di lavoro dai contenitori meno comuni a quelli più comuni.
Valuta l'allineamento dei carichi di lavoro con i modelli operativi per identificare il cluster di modello operativo più pertinente da cui iniziare. Seguire le indicazioni mappate al modello operativo per tutti i carichi di lavoro nella gerarchia del nodo e del gruppo di gestione.
Usare le metodologie di governance e gestione per trovare criteri aziendali comuni, incluse le procedure di gestione operativa necessarie in vari punti della gerarchia. Applicare criteri comuni di Azure per automatizzare i criteri aziendali condivisi.
Quando si testano le policy di Azure con varie distribuzioni, provare a spostarle più in alto nella gerarchia dei gruppi di gestione. I criteri possono essere applicati a molti carichi di lavoro, che potrebbero trovare comuni e esigenze operative distinte.
Nel corso del tempo, questo approccio può aiutarti a definire un modello che si scala tra vari modelli operativi. Questo approccio può anche unificare i team tramite un set di criteri e procedure comuni.

Vantaggi e svantaggi di questo approccio sono intenzionalmente vuoti. Dopo aver completato l'allineamento aziendale del portfolio, vedere la sezione relativa al modello operativo predominante precedente per maggiore chiarezza sui vantaggi e sugli svantaggi.

Passaggi successivi

Informazioni sulla terminologia associata ai modelli operativi. La terminologia consente di comprendere come un modello operativo si adatti al tema più grande della pianificazione aziendale.

terminologia del modello operativo

Scopri come una landing zone fornisce il blocco di costruzione fondamentale di qualsiasi ambiente di adozione del cloud.

Che cos'è una zona di destinazione?

Condividi tramite