Gerarchia del portfolio

Per comprendere il funzionamento di un portfolio di carichi di lavoro, asset e servizi di supporto, è necessario stabilire una gerarchia portfolio. Questo articolo fornisce definizioni chiare per i livelli della gerarchia del portfolio, insieme alle indicazioni per i team per soddisfare le aspettative per ogni livello. In questo articolo ogni livello della gerarchia viene definito anche ambito.

Carichi di lavoro

Una raccolta di tecnologie che offre valore aziendale definito è denominata un carico di lavoro. La raccolta può includere applicazioni, server o macchine virtuali, dati, dispositivi e altri asset raggruppati in modo analogo. La maggior parte delle aziende si basa su più carichi di lavoro per garantire le funzioni aziendali fondamentali.

In genere, gli stakeholder aziendali e i responsabili tecnici condividono la responsabilità per il supporto continuo di ogni carico di lavoro. In alcune fasi del ciclo di vita del carico di lavoro, questi ruoli sono chiaramente dichiarati. Nelle fasi più operative del ciclo di vita di un carico di lavoro, questi ruoli potrebbero essere trasferiti a un team di gestione delle operazioni condiviso o a un team delle operazioni cloud. Con l'aumentare del numero di carichi di lavoro, i ruoli (dichiarati o impliciti) diventano più complessi e più strutturati.

I carichi di lavoro e i relativi asset di supporto sono alla base di qualsiasi portfolio. Gli ambiti o i livelli definiscono il modo in cui questi carichi di lavoro vengono visualizzati e nella misura in cui sono interessati dalla matrice di potenziali team di supporto.

Anche se i termini possono variare, tutte le soluzioni IT includono asset e carichi di lavoro:

• Asset: la più piccola unità di funzione tecnica che supporta un carico di lavoro o una soluzione.
• Carico: la più piccola unità di supporto IT per l'azienda. Un carico di lavoro è una raccolta di asset di infrastruttura, applicazioni e dati che supportano un obiettivo aziendale comune o l'esecuzione di un processo aziendale comune.

Quando si distribuisce il primo carico di lavoro, il carico di lavoro e i relativi asset potrebbero essere l'unico ambito definito. Gli altri livelli possono essere definiti in modo esplicito quando vengono distribuiti più carichi di lavoro.

Portfolio IT

Quando le aziende supportano i carichi di lavoro tramite approcci strutturati o centralizzati, è probabile che esista una gerarchia più ampia per supportare tali carichi di lavoro:

• Zone di destinazione: Le zone di destinazione forniscono carichi di lavoro con le utilità di base necessarie o l'impianto idraulico condiviso necessari per supportare uno o più carichi di lavoro. Le zone di destinazione sono così critiche nel cloud che l'intera metodologia Ready del Cloud Adoption Framework è incentrata sulle zone di destinazione. Per una definizione più dettagliata, vedere Che cos'è una zona di destinazione?
• Utilità di base: questi servizi IT condivisi sono necessari per il funzionamento dei carichi di lavoro all'interno del portfolio tecnologico e aziendale.
• Piattaforma di base: questo costrutto organizzativo centralizza le soluzioni di base e consente di garantire che tali controlli vengano imposti per tutte le zone di destinazione.
• Piattaforme cloud: A seconda della strategia complessiva per supportare il portfolio completo, i clienti potrebbero avere bisogno di più piattaforme cloud con distribuzioni distinte della piattaforma di base per gestire più aree, soluzioni ibride o anche soluzioni multicloud.
• Portfolio: attraverso un obiettivo tecnologico, il portfolio è una raccolta di carichi di lavoro, asset e risorse di supporto che si estendono su tutte le piattaforme cloud. Attraverso un obiettivo aziendale, il portfolio è la raccolta di progetti, persone, processi e investimenti che supportano e gestiscono il portfolio tecnologico per ottenere risultati aziendali. Insieme, questi due obiettivi acquisiscono il portfolio.

Responsabilità della gerarchia e linee guida

Un team responsabile gestisce ogni livello della gerarchia del portfolio. Il diagramma seguente illustra il mapping tra il team responsabile e le linee guida per supportare le decisioni aziendali, le decisioni tecniche e l'implementazione tecnica.

Nota

I team indicati nell'elenco seguente possono essere team virtuali o singoli utenti. Per alcune varianti di questa gerarchia, alcuni dei team responsabili possono essere compressi come descritto più avanti nelle varianti di responsabilità.

• Portfolio: Il team di strategia del cloud e il centro di eccellenza cloud (CCoE) usano le metodologie strategia e piano per guidare le decisioni che influiscono sul portfolio complessivo. Il team di strategia loud è responsabile del livello aziendale della gerarchia del portfolio cloud. Il team di strategia cloud deve anche essere informato delle decisioni relative all'ambiente, alle zone di destinazione e ai carichi di lavoro ad alta priorità.
• Piattaforme cloud: Il team di governance del cloud è responsabile delle discipline che garantiscono la coerenza tra ogni ambiente in linea con la metodologia di governance . Il team di governance cloud è responsabile della governance di tutte le risorse in tutti gli ambienti. Il team di governance cloud deve essere consultato in merito alle modifiche che potrebbero richiedere un'eccezione o rettifiche ai criteri di governance. Il team di governance cloud deve anche essere informato dello stato di avanzamento dell'adozione di carichi di lavoro e asset.
• Zone di destinazione e piattaforma di base cloud: il team della piattaforma cloud è responsabile dello sviluppo delle zone di destinazione e delle utilità della piattaforma che supportano l'adozione. Il team di automazione cloud è responsabile dell'automazione dello sviluppo e del supporto continuo per tali zone di destinazione e utilità della piattaforma. Entrambi i team usano la metodologia Ready per guidare l'implementazione. Entrambi i team devono essere informati dello stato di avanzamento con l'adozione del carico di lavoro e di eventuali modifiche all'azienda o all'ambiente.
• Carichi di lavoro: l'adozione avviene a livello del carico di lavoro. I team di adozione del cloud usano le metodologie di migrazione e innovazione per stabilire processi scalabili per accelerare l'adozione. Al termine dell'adozione, è probabile che la proprietà dei carichi di lavoro venga trasferita a un team operativo cloud che usa la metodologia Di gestione per guidare la gestione delle operazioni. Entrambi i team devono avere familiarità con l'uso di Microsoft Azure Well-Architected Framework per prendere decisioni dettagliate sull'architettura che influiscono sui carichi di lavoro supportati. Entrambi i team devono essere informati delle modifiche apportate alle zone di destinazione e agli ambienti. Entrambi i team possono occasionalmente collaborare alle funzionalità della zona di destinazione.
• Asset: gli asset sono in genere responsabilità del team delle operazioni cloud. Tale team usa la baseline di gestione nella metodologia Di gestione per guidare le decisioni di gestione delle operazioni. Deve anche usare Azure Advisor e Azure Well-Architected Framework per apportare modifiche dettagliate alle risorse e all'architettura necessarie per soddisfare i requisiti delle operazioni.

Varianti di responsabilità

• Ambiente singolo: quando un'azienda necessita di un solo ambiente, in genere non è necessario un Centro di eccellenza cloud.
• Zona di destinazione singola: se un ambiente ha una sola zona di destinazione, è probabile che le funzionalità di governance e piattaforma possano essere combinate in un unico team.
• Carico di lavoro singolo: Alcune aziende necessitano di un solo carico di lavoro, o di alcuni carichi di lavoro, in una singola zona di destinazione e in un singolo ambiente. In questi casi, non è necessaria una separazione dei compiti tra i team di governance, piattaforma e operazioni.

Esempi comuni di carichi di lavoro e responsabilità

Gli esempi seguenti illustrano la gerarchia del portfolio.

Carichi di lavoro COTS

Tradizionalmente, le aziende preferiscono basare i propri processi aziendali su soluzioni software COTS (Commercial-Off-The-Shelf). Queste soluzioni vengono installate, configurate e quindi gestite. Dopo la configurazione è stata apportata una piccola modifica all'architettura delle soluzioni.

In questi scenari, qualsiasi adozione cloud di soluzioni COTS termina con una transizione a un team delle operazioni cloud. Il team delle operazioni cloud diventa quindi il proprietario tecnico del software e assume la responsabilità della gestione della configurazione, dei costi, dei cicli di applicazione di patch e di altre esigenze operative.

Questi carichi di lavoro includono pacchetti di contabilità, software di logistica o soluzioni specifiche del settore. Nella terminologia Microsoft i fornitori di questi pacchetti sono denominati fornitori di software indipendenti (ISV). Molti ISV offrono un servizio per distribuire e gestire un'istanza del proprio pacchetto software nelle sottoscrizioni. Possono anche offrire una versione del pacchetto software che viene eseguita nel proprio ambiente ospitato nel cloud, offrendo un'alternativa PaaS (piattaforma distribuita come servizio) al carico di lavoro.

Ad eccezione delle offerte PaaS, i team operativi cloud sono responsabili di garantire i requisiti di conformità operativi di base per tali carichi di lavoro. Un team delle operazioni cloud deve collaborare con il team di governance cloud per allineare costi, prestazioni e altri pilastri dell'architettura.

In fase di sviluppo con revisioni attive

Quando una soluzione COTS o un'offerta PaaS non è allineata alle esigenze aziendali o non esiste alcuna soluzione, le aziende sviluppano carichi di lavoro personalizzati. In genere, solo una piccola percentuale del portfolio IT usa questo approccio al carico di lavoro. Questi carichi di lavoro, tuttavia, tendono a generare una percentuale sproporzionatamente elevata del contributo dell'IT ai risultati aziendali, in particolare quelli relativi ai nuovi flussi di ricavi. Questi carichi di lavoro si adattano bene alle nuove idee di innovazione.

A seguito dei vari movimenti basati su metodologie Agile e procedure DevOps, questi carichi di lavoro promuovono un allineamento aziendale/DevOps rispetto alla gestione IT tradizionale. Per questi carichi di lavoro, il trasferimento al team delle cloud potrebbe non avvenire per diversi anni. In questi casi, il team di sviluppo funge da proprietario tecnico del carico di lavoro.

A causa di vincoli di tempo e di capitale estesi, le opzioni di sviluppo personalizzate sono spesso limitate a opportunità di valore elevato. Esempi tipici sono le innovazioni delle applicazioni, l'analisi approfondita dei dati o le funzioni aziendali cruciali.

Sviluppo break/fix o ritiro

Quando un carico di lavoro personalizzato raggiunge il picco di maturità, il team di sviluppo potrebbe essere riassegnato ad altri progetti. In questi casi, la proprietà tecnica passa in genere a un team delle operazioni cloud. Quando sono necessarie piccole correzioni, il team delle operazioni integrerà gli sviluppatori per risolvere l'errore.

In alcuni casi, il team di sviluppo passa a un progetto che sostituirà il carico di lavoro corrente. In alternativa, il team potrebbe proseguire perché l'opportunità aziendale supportata dal carico di lavoro viene eliminata gradualmente. In questi scenari di tramonto, il team operativo del cloud funge da proprietario tecnico fino a quando il carico di lavoro non è più necessario.

In entrambi gli scenari, il team delle operazioni cloud agisce in qualità di proprietario tecnico e di decisore a lungo termine. È probabile che il team integrerà gli sviluppatori di applicazioni quando le modifiche operative richiedono variazioni significative dell'architettura.

Carichi di lavoro di importanza cruciale

In ogni azienda, alcuni carichi di lavoro sono così importanti che non possono permettersi errori. Con questi carichi di lavoro cruciali, in genere sono presenti proprietari di operazioni e sviluppo con vari livelli di responsabilità. Questi team devono allineare le modifiche operative e le modifiche dell'architettura per ridurre al minimo le interruzioni nella soluzione di produzione.

Questi scenari richiedono un'attenzione particolare alla separazione dei compiti. Il team operativo in genere terrà conto delle modifiche operative quotidiane nell'ambiente di produzione. Quando queste modifiche operative richiedono una modifica dell'architettura, verranno completate dal team di sviluppo o adozione in un ambiente non di produzione, prima che il team delle operazioni applichi le modifiche all'ambiente di produzione.

Esempi di carichi di lavoro cruciali che necessitano della separazione dei compiti includono carichi di lavoro come SAP, Oracle o altre soluzioni ERP (Enterprise Resource Planning), che si estendono su più business unit dell'azienda.

Allineamento del portfolio alla strategia

È importante comprendere gli obiettivi strategici dell'impegno di adozione del cloud e allineare il portfolio per supportare tale trasformazione. Alcuni tipi comuni di allineamento strategico del portfolio consentono di modellare la struttura della gerarchia del portfolio. Le sezioni seguenti forniscono esempi dell'allineamento e dell'effetto del portfolio sulla gerarchia del portfolio.

Portfolio basato sull'innovazione o sullo sviluppo

Alcune aziende, in particolare le startup in rapida crescita, hanno una percentuale superiore alla media dei progetti di sviluppo personalizzati. Nei portfolio a elevato utilizzo di sviluppo, l'ambiente, la zona di destinazione e i carichi di lavoro vengono spesso compressi, quindi potrebbero esserci ambienti specifici per carichi di lavoro specifici. Il risultato è un rapporto 1:1 tra ambiente, zona di destinazione e carico di lavoro.

Poiché l'ambiente ospita soluzioni personalizzate, la pipeline DevOps e la creazione di report a livello dell'applicazione potrebbero sostituire l'esigenza rispetto alle funzioni di operazioni e governance. Questi clienti ridurranno probabilmente l'attenzione su operazioni, governance o altri ruoli di supporto. È anche tipica un'enfasi maggiore sulle responsabilità dei team di adozione del cloud e di automazione del cloud.

Allineamento del portfolio: il portfolio IT si concentrerà probabilmente sui carichi di lavoro e sui proprietari dei carichi di lavoro per prendere decisioni critiche sull'architettura. È probabile che questi team trovino più valore nelle linee guida di Azure Well-Architected Framework durante le attività di adozione e delle operazioni.

Definizioni dei limiti: i limiti logici, anche a livello aziendale, saranno probabilmente concentrati sulla segmentazione dell'ambiente di produzione e non di produzione. Potrebbe anche essere presente una segmentazione chiara tra i prodotti nel portfolio software dell'azienda. A volte, potrebbe essere presente anche la segmentazione tra lo sviluppo e le istanze dei clienti ospitate.

Portfolio basato sulle operazioni

Le organizzazioni aziendali multinazionali con team delle operazioni IT più affermati in genere si concentrano più sulla governance e sulle operazioni rispetto allo sviluppo. In queste organizzazioni, una percentuale più elevata di carichi di lavoro è in genere allineata alle categorie ALIGN o BREAK/fix, gestite dai proprietari tecnici all'interno del team operativo cloud.

Allineamento del portfolio: il portfolio IT sarà allineato ai carichi di lavoro, ma tali carichi di lavoro vengono quindi allineati alle unità operative o alle business unit. Potrebbe anche essere presente un'organizzazione in base a modelli di finanziamento, settore o altri requisiti di segmentazione aziendale.

Definizioni dei limiti: è probabile che le zone di destinazione raggruppino le applicazioni in archetipi dell'applicazione per mantenere operazioni simili in una segmentazione simile. Gli ambienti faranno probabilmente riferimento a costrutti fisici come data center, nazione, area del provider di servizi cloud o altri standard dell'organizzazione operativa.

Portfolio basato sulla migrazione

Analogamente ai portfolio basati sulle operazioni, un portfolio basato in gran parte sulla migrazione sarà fondato su fattori di business specifici che hanno determinato la migrazione degli asset esistenti. In genere, il data center è l'elemento più importante di questi fattori.

Allineamento del portfolio: il portfolio IT potrebbe essere allineato ai carichi di lavoro, ma è più probabile che sia allineato agli asset. Se si sono verificate transizioni alle operazioni IT nella storia dell'azienda, è possibile che molti asset attivamente usati non siano facilmente mappati a un carico di lavoro finanziato. In questi casi, per molti asset potrebbe non essere presente un carico di lavoro definito o un proprietario del carico di lavoro chiaro fino a una fase inoltrata del processo di migrazione.

Definizioni dei limiti: è probabile che le zone di destinazione raggruppino le applicazioni in limiti che riflettono la segmentazione locale. Anche se non è una procedura consigliata, gli ambienti spesso corrispondono al nome del data center locale e alle zone di destinazione che rappresentano le procedure di segmentazione di rete. È consigliabile adottare una segmentazione più strettamente allineata a un portfolio basato sulle operazioni.

Portfolio basato sulla governance

L'allineamento ai team di governance deve avvenire il prima possibile. Grazie alle procedure di governance e agli strumenti di governance cloud, i portfolio e i limiti ambientali possono bilanciare al meglio le esigenze di innovazione, operazioni e attività di migrazione.

Allineamento del portfolio: i portfolio basati sulla governance tendono a includere punti dati che acquisiscono i dettagli dell'innovazione e delle operazioni, ad esempio carico di lavoro, proprietario delle operazioni, classificazione dei dati e criticità operativa. Questi punti dati creano un'ampia panoramica del portfolio.

Definizioni dei limiti: i limiti in un portfolio basato sulla governance tendono a promuovere le operazioni rispetto all'innovazione, usando al contempo una gerarchia basata su gruppi di gestione mappata ai criteri per le business unit e gli ambienti di sviluppo. A ogni livello della gerarchia, un limite di governance cloud può prevedere diversi gradi di imposizione dei criteri per consentire sviluppo e flessibilità creativa. Allo stesso tempo, è possibile applicare requisiti di livello produzione alle sottoscrizioni di produzione per garantire la separazione dei compiti e la coerenza delle operazioni.

Passaggi successivi

Informazioni su come i prodotti Azure supportano la gerarchia del portfolio.