Esaminare e confrontare modelli operativi cloud comuni

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 di modelli operativi comuni in base alla gamma di complessità, dal meno complesso (decentralizzato) al più complesso (operazioni globali). Nelle tabelle seguenti vengono confrontati gli stessi modelli operativi in base al valore relativo di alcuni altri attributi.

Priorità o ambito

Un modello operativo cloud è basato principalmente su due fattori:

• Priorità strategiche o motivazioni
• Ambito del portfolio da gestire

• 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 portfolio: l'ambito del portfolio identifica l'ambito più grande supportato da una progettazione specifica 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 derivano dal 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.

Allineamento della responsabilità

Molti team e singoli utenti sono responsabili del supporto di funzioni diverse. Ogni modello operativo comune assegna tuttavia la responsabilità finale ai risultati delle decisioni a un team o a un singolo utente. Questo approccio influisce sul modo in cui viene offerto il modello operativo e sul livello di supporto fornito per ogni funzione.

Accelerare l'implementazione del modello operativo in Azure

Come illustrato in Definire il modello operativo, ogni metodologia del Cloud Adoption Framework fornisce un percorso strutturato per lo sviluppo del modello operativo. Queste metodologie possono aiutare a superare gli ostacoli 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

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 le meno complesse tra i modelli operativi comuni. In questa forma di operazioni, tutti i carichi di lavoro operano in modo indipendente dai team del carico di lavoro dedicati.

• Priorità: il team misura l'innovazione sul controllo centralizzato o la standardizzazione in più carichi di lavoro.
• Vantaggio distinto: ottimizzare la velocità dell'innovazione dando ai team aziendali e dei carichi di lavoro il controllo completo su progettazione, compilazione e operazioni.
• Svantaggio distinto: riduzione della standardizzazione tra carichi di lavoro, economie di scala tramite servizi condivisi e attività di conformità centralizzate di governance coerenti.
• Rischio: questo approccio introduce rischi durante la gestione di un portfolio di carichi di lavoro. I team del carico di lavoro possono avere team specializzati dedicati alle funzioni IT centrali. Questo modello operativo viene considerato un'opzione ad alto rischio da alcune organizzazioni, in particolare dalle aziende che devono soddisfare i requisiti di conformità di terze parti.
• Indicazioni: le operazioni decentralizzate sono limitate alle decisioni a livello di carico di lavoro. Microsoft Azure Well-Architected Framework supporta le decisioni prese nell'ambito. I processi e le linee guida all'interno di Cloud Adoption Framework possono aggiungere un sovraccarico che non è necessario per le operazioni decentralizzate.

Vantaggi delle operazioni decentralizzate

• Gestione dei costi: il costo delle operazioni viene facilmente mappato a una singola business unit. Le operazioni specifiche del carico di lavoro supportano un'ottimizzazione del carico di lavoro maggiore.
• Responsabilità: questa forma di operazioni dipende in genere dall'automazione per ridurre al minimo il sovraccarico. Le responsabilità tendono a concentrarsi sulle DevOps e sulle pipeline per la gestione del rilascio. 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 dalla versione alla versione.
• Supporto delle operazioni: le decisioni che influiscono sulle operazioni riguardano solo le esigenze di quel carico di lavoro e semplificano le decisioni relative alle operazioni. I membri della community DevOps affermano che il supporto delle operazioni è la forma più pura di operazioni per via dell'ambito operativo ristretto.
• Esperienza: i team di DevOps e di sviluppo hanno maggiori possibilità grazie a questo approccio e sono i meno resistenti quando si tratta di affrontare 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 dei costi: i costi Enterprise sono più difficili da calcolare. La mancanza di team di governance centralizzati rende più difficile implementare controlli uniformi su costi o ottimizzazione. Su larga scala, questo modello può essere costoso, perché ogni carico di lavoro potrebbe avere duplicazioni negli asset distribuiti e nelle assegnazioni del personale.
• Responsabilità: la mancanza di supporto centralizzato significa che il team del carico di lavoro è interamente responsabile della governance, della sicurezza, delle operazioni e della gestione delle modifiche. La mancanza di supporto è problematica quando tali attività non sono state automatizzate nella revisione del codice e nelle pipeline di rilascio.
• Standardizzazione: la standardizzazione in un portfolio di carichi di lavoro è variabile e incoerente.
• Supporto delle operazioni: l'efficienza della scalabilità spesso viene persa durante la creazione di procedure consigliate in più carichi di lavoro.
• Esperienza: i membri del team hanno maggiori responsabilità di prendere decisioni oculate ed etiche su governance, sicurezza, operazioni e gestione delle modifiche all'interno della progettazione e della configurazione dell'applicazione. Consultare l'Well-Architected Revisione di Microsoft Azure e Azure Well-Architected Framework spesso per migliorare le competenze necessarie.
• Progettazione delle zone di destinazione: le zone di destinazione non sono specifiche del carico di lavoro e non vengono considerate in questo approccio.
• Utilità di base: alcuni servizi di base (se presenti) vengono condivisi tra i carichi di lavoro, riducendo l'efficienza della scalabilità.
• Separazione dei compiti: requisiti più elevati per DevOps e team di sviluppo aumentano l'utilizzo di privilegi elevati da tali team. Se è necessaria la separazione dei compiti, potrebbe essere necessario investire pesantemente nella maturità di DevOps per operare con questo approccio.

Operazioni centralizzate

Gli ambienti con stato stabile potrebbero non richiedere particolare attenzione all'architettura o a 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 con stato stabile. Esempi di operazioni con stato stabile includono applicazioni COTS (Commercial-Off-The-Shelf) o applicazioni personalizzate ben stabilite con una cadenza di rilascio lenta. Se una frequenza di modifiche è basata su 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 rispetto al passaggio culturale alle operazioni cloud moderne.
• Vantaggio distinto: la centralizzazione introduce economie di scala, controlli ottimali e operazioni standardizzate e funziona meglio con l'ambiente cloud. Questi ambienti necessitano di configurazioni specifiche per integrare le operazioni cloud in operazioni e processi esistenti. La centralizzazione è la più vantaggiosa, con un portfolio di poche centinaia di carichi di lavoro con una complessità architetturale e requisiti di conformità modesti.
• Svantaggio distinto: la scalabilità per soddisfare le esigenze di un ampio portfolio di carichi di lavoro può mettere a dura prova i 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 considerare un modello aziendale se è entro 18-24 mesi.
• Rischio: questo approccio limita la centralizzazione a un numero inferiore di abbonamenti (spesso un abbonamento di produzione). Quando si esegue il refactoring in un secondo momento nel percorso cloud, esiste un rischio significativo e si potrebbe interferire con i piani di adozione. Per evitare rielaborazioni, provare a concentrarsi sulla segmentazione, sui limiti dell'ambiente, sugli strumenti di gestione delle identità e su altri elementi di base.
• Indicazioni: le opzioni di implementazione della zona di destinazione di Azure allineate alla velocità di sviluppo "start small and expand" creano un punto di partenza solido. È possibile usare queste opzioni per accelerare gli sforzi di adozione. Ma per avere successo, stabilire criteri chiari per guidare gli sforzi di adozione anticipata entro le tolleranze di rischio accettabili. Le metodologie di governance e gestione consentono di creare processi per far maturare le operazioni in parallelo. I passaggi seguenti fungono da gate di fase che devono essere completati prima di consentire un aumento del rischio durante la maturazione delle operazioni.

Vantaggi delle operazioni decentralizzate

• Gestione dei costi: la centralizzazione dei servizi condivisi in molti carichi di lavoro crea economie di scala ed elimina le attività duplicate. I team centrali possono implementare rapidamente la riduzione dei costi tramite il ridimensionamento a livello aziendale e le ottimizzazioni della scalabilità.
• Responsabilità: le competenze e la standardizzazione centralizzate possono portare a una maggiore stabilità, a prestazioni operative migliori e a interruzioni minime correlate al cambiamento. Questo approccio riduce le ampie pressioni di competenza sui team incentrati sul carico di lavoro.
• Standardizzazione: in generale, la standardizzazione e il costo delle operazioni sono i più bassi con un modello centralizzato perché sono presenti meno sistemi o attività duplicati.
• Supporto per le operazioni: la riduzione della complessità e della centralizzazione delle operazioni rende più facile per i team IT più piccoli supportare le operazioni.
• Competenza: La centralizzazione dei team di supporto consente agli esperti di sicurezza, rischio, governance e operazioni di guidare decisioni business-critical.
• Progettazione delle zone di destinazione: l'IT centrale riduce la complessità riducendo al minimo il numero di zone di destinazione e abbonamenti. Le progettazioni delle zone di destinazione tendono a simulare le progettazioni dei data center precedenti, riducendo i tempi di transizione. Con l'avanzamento dell'adozione, le risorse condivise potrebbero essere spostate in un abbonamento o in una piattaforma separata.
• Utilità fondamentali: si trasportano progetti di data center esistenti nel cloud risultati fondamentali, servizi condivisi che simulano strumenti e operazioni locali. Avere le operazioni locali come modello operativo principale potrebbe essere un vantaggio, ma occorre prestare attenzione ad alcuni svantaggi. Le operazioni locali riducono il tempo di transizione, sfruttano le economie di scalabilità e supportano processi operativi coerenti tra carichi di lavoro ospitati in locale e cloud. Questo approccio può ridurre la complessità e lo sforzo 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 gestisce il controllo degli ambienti di produzione e riduce la necessità di autorizzazioni elevate da altri team. Questo approccio riduce le violazioni limitando il numero di account con privilegi elevati.

Svantaggi delle operazioni decentralizzate

• Gestione dei costi: i team centrali non sempre comprendono le architetture dei carichi di lavoro per produrre ottimizzazioni di 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 conoscenza approfondita dell'architettura del carico di lavoro può condizionare l'ottimizzazione dei costi centralizzati, che influiscono sulle prestazioni, sulla scalabilità e su altri concetti fondamentali di un carico di lavoro ben strutturato. Prima di applicare modifiche a costi a livello aziendale ai carichi di lavoro ad alto profilo, il team IT centrale deve comprendere e completare l'Well-Architected Revisione di Microsoft Azure.
• Responsabilità: la centralizzazione del supporto e dell'accesso alla produzione pone un carico operativo elevato per poche persone e una maggiore pressione su ogni singolo utente. La pressioni esercitata su queste persone comporta la necessità di eseguire revisioni più approfondite dei carichi di lavoro distribuiti, che convalidano la conformità ai requisiti dettagliati di conformità e governance della sicurezza.
• Standardizzazione: gli approcci IT centrali rendono difficile la standardizzazione della scalabilità senza una scalabilità lineare del personale IT centrale.
• Supporto delle operazioni: i principali svantaggi di questo approccio sono associati a significativi cambiamenti e scalabilità che comporta l'innovazione.
• Competenze: gli sviluppatori e i DevOps esperti sono a rischio di essere sottovalutati o troppo vincolati 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 ridefinire la segmentazione dell'ambiente e di offrire opportunità di innovazione. La mancanza di segmentazione della zona di destinazione aumenta il potenziale effetto di violazione, complessità della governance e conformità e potrebbe creare blocchi per l'adozione nel percorso cloud. Vedere la sezione relativa ai rischi precedente.
• Utilità di base: durante la trasformazione digitale, il cloud potrebbe diventare il modello operativo principale. Gli strumenti centrali, creati per le operazioni locali, riducono le opportunità di modernizzare le operazioni e aumentare l'efficienza operativa. È anche possibile scegliere di non modernizzare le operazioni nelle prime fasi del processo di adozione. 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 richiede tempo senza pianificazione avanzata.
• Separazione dei compiti: le operazioni centrali seguono in genere uno dei due percorsi e entrambi potrebbero impedire l'innovazione.
  • Opzione 1: ai team esterni all'IT centrale viene concesso un accesso limitato agli ambienti di sviluppo che simulano la produzione. Questa opzione impedisce la sperimentazione.
  • Opzione 2: i team sviluppano e testano in ambienti non supportati. Questa opzione ostacola i processi di distribuzione e rallenta i test di integrazione post-distribuzione.

Operazioni aziendali

Le operazioni aziendali sono lo stato di destinazione suggerito per tutte le operazioni cloud. Le operazioni aziendali bilanciano necessità di controllo e innovazione semplificando le decisioni e le responsabilità. L'IT centrale viene sostituito da un centro di eccellenza cloud più agevolato o da un team CCoE che supporta i team del carico di lavoro. Il team CCoE ritiene che i team del carico di lavoro siano in grado di prendere decisioni anziché controllare o limitare le proprie azioni. Ai team del carico di lavoro sono concessi più potere e responsabilità per guidare l'innovazione rispettando protezioni ben definite.

• Priorità: le priorità sono la democratizzazione delle decisioni tecniche. La democratizzazione delle decisioni tecniche sposta le responsabilità prima detenute dall'IT centrale ai team del carico di lavoro. Per garantire questo cambiamento di priorità, le decisioni diventano meno dipendenti dai processi di revisione 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 l'equilibrio tra controllo e innovazione. Le operazioni centralizzate mantengono carichi di lavoro che richiedono 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. I portfolio più grandi potrebbero avere difficoltà a trovare l'equilibrio tra controllo e innovazione. Questa flessibilità semplifica la scalabilità di migliaia di carichi di lavoro con la riduzione di problemi operativi.
• Svantaggio distinto: ciò che funzionava in locale potrebbe non funzionare correttamente nelle operazioni cloud aziendali. Questo approccio alle operazioni richiede modifiche su molti fronti. I cambiamenti culturali nel controllo e nella responsabilità sono spesso la difficoltà principale. I cambiamenti operativi che seguono quelli culturali sono processi che richiedono tempo e impegno a livello di implementazione, maturazione e stabilizzazione. I cambiamenti dell'architettura possono essere necessari in carichi di lavoro stabili, mentre i cambiamenti di strumenti sono necessari per supportare i cambiamenti culturali, operativi e architetturali. Questi cambiamenti potrebbero richiedere impegni per un provider di servizi cloud primario. Gli sforzi di adozione eseguiti prima di queste modifiche possono richiedere operazioni significative che superano i tipici sforzi di refactoring.
• Rischio: questo approccio richiede l'impegno dei dirigenti per la strategia di modifica, oltre all'impegno dei team tecnici per superare le curve di apprendimento e fornire la modifica necessaria. La cooperazione a lungo termine tra business, CCoE e i team IT centrali sono necessari per visualizzare i vantaggi a lungo termine.
• Linee guida: le opzioni della zona di destinazione di Azure sono definite come scalabilità aziendale. Queste opzioni forniscono implementazioni di riferimento per illustrare il modo in cui le modifiche tecniche offrono l'uso degli strumenti nativi del cloud in Azure. L'approccio su scala aziendale guida i team nei cambiamenti operativi e culturali necessari per sfruttare al meglio tali implementazioni. Questo stesso approccio potrebbe personalizzare l'architettura di riferimento per configurare l'ambiente in modo che soddisfi la strategia di adozione e i vincoli di conformità. Quando si implementa la scalabilità aziendale, le metodologie di governance e gestione possono aiutare a 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 cross-portfolio e ritengono i singoli team del carico di lavoro responsabili dell'ottimizzazione del carico di lavoro più profondo. 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 dei carichi di lavoro condividono la responsabilità per le decisioni relative ai costi al livello giusto.
• Responsabilità: i team centrali usano strumenti nativi del cloud per definire, applicare e automatizzare le protezioni. Le attività del team del carico di lavoro vengono accelerate tramite l'automazione e le procedure CCoE. I team del carico di lavoro sono in grado di guidare l'innovazione e prendere decisioni rispettando tali protezioni.
• Standardizzazione: protezioni centralizzate e servizi di base creano coerenza in tutti gli ambienti.
• Supporto delle operazioni: i carichi di lavoro che richiedono il supporto delle operazioni centralizzate vengono segmentati in ambienti con controlli dello stato stabile. La segmentazione e la separazione dei compiti consentono ai team del carico di lavoro di prendere in considerazione il supporto operativo nei propri ambienti dedicati. Gli strumenti nativi automatizzati del cloud garantiscono una baseline operativa minima per tutti gli ambienti con supporto operativo centralizzato.
• Competenza: centralizzare i servizi di base, ad esempio sicurezza, rischio, governance e operazioni garantisce competenze centrali appropriate. Processi e protezioni chiare educano e autorizzano i team di lavoro a prendere decisioni più dettagliate. Queste decisioni espandono l'effetto degli esperti centralizzati senza dover ridimensionare il personale di pari passo con la scalabilità della tecnologia.
• Progettazione della zona di destinazione: la progettazione della zona di destinazione replica le esigenze del portfolio, creando limiti chiari 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 destinazione è meno complessa, consentendo una scalabilità più rapida e una riduzione delle barriere alla domanda self-service.
• Utilità di base: le utilità di base sono ospitate in abbonamenti separati controllati a livello centrale, noti come platform foundation. Gli strumenti centrali vengono quindi inviati in pipe in ogni zona di destinazione come servizi di utilità. La separazione delle utilità di base dalle zone di destinazione ottimizza la coerenza e l'economia di scalabilità. Queste utilità creano anche distinzioni chiare 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 equilibrio 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 della zona di destinazione.

Svantaggi delle operazioni aziendali

• Gestione dei costi: i team centrali dipendono maggiormente dai team del carico di lavoro per apportare modifiche di produzione all'interno delle zone di destinazione. Questo spostamento crea un rischio per potenziali sovraccarichi del budget e un ridimensionamento più lento della spesa effettiva. Processi di controllo dei costi, budget chiari, controlli automatizzati e revisioni regolari devono essere messi in atto presto per evitare sorprese sui costi.
• Responsabilità: le operazioni aziendali richiedono requisiti culturali e operativi maggiori. Questi requisiti garantiscono chiarezza nelle responsabilità e nella responsabilità tra i team centrali e i team del carico di lavoro.
• I processi tradizionali di gestione delle modifiche o le schede di consulenza per le modifiche (cab) potrebbero non mantenere il ritmo e l'equilibrio necessari in questo modello operativo. Questi processi si riflettono nell'automazione dei processi e delle procedure che ridimensionano in modo sicuro l'adozione del cloud.
• Mancanza di impegno per cambiare materializza prima nella negoziazione e nell'allineamento delle responsabilità. L'impossibilità di allinearsi ai cambiamenti in termini di responsabilità indica che potrebbero essere necessari modelli operativi IT centrali durante le attività di adozione del cloud a breve termine.
• Standardizzazione: la mancanza di investimenti in protezioni 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 maggiori rischi. Questi rischi si estendono dalla standardizzazione durante i cicli di aggiornamento o nelle versioni future delle utilità di base. Durante le revisioni di base della piattaforma, i test migliorati o addirittura automatizzati sono necessari per tutte le zone di destinazione supportate e i carichi di lavoro ospitati.
• Supporto delle operazioni: la baseline delle operazioni fornita tramite l'automazione e le operazioni centralizzate potrebbero essere sufficienti per carichi di lavoro a bassa influenza o 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 un turno nei budget delle operazioni, richiedendo alle business unit di concedere spese operative a tali forme di operazioni avanzate. Se l'IT centrale è necessario per mantenere l'unica responsabilità per il costo delle operazioni, le operazioni aziendali potrebbero essere difficili da implementare.
• Competenza: i membri del team IT centrale potrebbero essere necessari per sviluppare competenze nell'automazione dei controlli centrali forniti in precedenza tramite processi manuali. Questi team possono anche sviluppare competenze per gli approcci dell'infrastruttura come codice per definire l'ambiente e comprendere le pipeline di diramazione, unione e distribuzione. Almeno, un team di automazione della piattaforma potrebbe richiedere competenze decisionali per comprendere le decisioni prese dal centro cloud di eccellenza o dai team operativi centrali. I team del carico di lavoro potrebbero essere tenuti a sviluppare più conoscenze relative ai controlli e ai processi che regolano le 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 è nella progettazione e cosa non è consentito includere. Questa comprensione consentirà la duplicazione di sforzi, errori o conflitti. Per creare flessibilità, è possibile considerare i processi di eccezione nelle progettazioni delle zone di destinazione.
• Utilità di base: la centralizzazione delle utilità di base richiede tempo. Queste utilità alla fine considerano le opzioni e sviluppano soluzioni che potrebbero essere ridimensionate per soddisfare vari piani di adozione. Sono possibili ritardi nelle attività di adozione anticipata. I ritardi potrebbero essere compensati a lungo termine a causa di accelerazioni ed evitare blocchi più avanti nel processo.
• Separazione dei compiti: garantire una netta separazione dei compiti richiede processi di gestione delle identità maturi. Potrebbe esserci più manutenzione associata all'allineamento corretto di utenti, gruppi e attività di onboarding e off-board. Potrebbe essere necessario adottare nuovi processi per supportare l'accesso JITO tramite privilegi elevati.

Operazioni distribuite

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

Anche se 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 di transizione 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 per allinearsi a un singolo modello operativo.
• Vantaggio distinto: 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 è difficile 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 può 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 sull'allineamento aziendale. Provare a raggruppare il portfolio in base al modello operativo dello stato (decentralizzato, centralizzato o aziendale).
• Sviluppare una gerarchia di gruppi di gestione che rifletta i raggruppamenti del modello operativo. Questa disposizione include altri modelli organizzativi per area, business unit o altri criteri che eseguono il mapping dei cluster del carico di lavoro da bucket meno comuni ai bucket più comuni.
• Valutare l'allineamento dei carichi di lavoro ai modelli operativi per trovare il cluster del modello operativo più pertinente da cui iniziare. Seguire le indicazioni di cui è stato eseguito il mapping 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 di Azure comuni per automatizzare i criteri aziendali condivisi.
• Quando si testano i criteri di Azure con varie distribuzioni, provare a spostarli più in alto nella gerarchia dei gruppi di gestione. I criteri possono essere applicati a molti carichi di lavoro, che potrebbero trovare caratteristiche comuni ed esigenze di operazioni distinte.
• Questo approccio può essere utile nel lungo periodo per definire un modello scalabile in diversi modelli operativi, e potrebbe anche unificare i team tramite un set di criteri e procedure comuni.

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

Passaggi successivi

Informazioni sulla terminologia associata ai modelli operativi. La terminologia consente di comprendere il modo in cui un modello operativo si inserisce nel tema più ampio della pianificazione aziendale.

Informazioni su come una zona di destinazione costituisca il blocco predefinito di base per qualsiasi ambiente di adozione del cloud.