Gerarchia portfolio

Per comprendere come un portfolio di carichi di lavoro, asset e servizi di supporto interagiscono tutti, è necessario stabilire una gerarchia di portfolio. Questo articolo fornisce definizioni chiare per i livelli della gerarchia del portfolio, insieme alle linee guida per i team per fornire le aspettative per ogni livello. In questo articolo, ogni livello della gerarchia viene chiamato anche ambito .

Carichi di lavoro

Una raccolta di tecnologie che offre valore aziendale definito è denominata 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 affida a più carichi di lavoro per offrire funzioni aziendali vitali.

In genere, uno stakeholder aziendale e un leader tecnico condividono la responsabilità per il supporto continuo di ogni carico di lavoro. In alcune fasi del ciclo di vita del carico di lavoro, tali ruoli sono chiaramente indicati. In più fasi operative del ciclo di vita di un carico di lavoro, questi ruoli potrebbero essere trasferiti a un team di gestione delle operazioni condivise o a un team operativo cloud. Man mano che aumenta il numero di carichi di lavoro, i ruoli (dichiarati o impliciti) diventano più complessi e più matriceti.

I carichi di lavoro e le risorse 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 in che misura 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 di lavoro: 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 potrebbero essere definiti in modo esplicito perché vengono distribuiti più carichi di lavoro.

Portfolio delle tecnologie dell'informazione

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

• Zone di atterraggio: Le zone di atterraggio forniscono ai carichi di lavoro le necessarie utilità di base, o infrastruttura condivisa, per supportare uno o più carichi di lavoro. Le zone di destinazione sono così critiche nel cloud che l'intera metodologia di Ready di 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 consentire ai carichi di lavoro di operare all'interno della tecnologia e del portfolio aziendale.
• Fondazione della piattaforma: Questa struttura organizzativa centralizza le soluzioni fondamentali e garantisce che tali controlli vengano applicati per tutte le zone di atterraggio.
• 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 per gestire più aree, soluzioni ibride o persino soluzioni multicloud.
• Portfolio: Attraverso una lente tecnologica, 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 favorire i risultati aziendali. Insieme, queste due lenti catturano il portfolio.

Responsabilità e linee guida per la gerarchia

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.

• Portfolio: Il team di strategia del cloud e il centro di eccellenza del cloud (CCoE) utilizzano le metodologie Strategia e Piano per guidare le decisioni che influiscono sul Portfolio complessivo. Il team di strategia cloud è responsabile del livello aziendale della gerarchia del portfolio cloud. Il team di strategia del 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 linee guida che garantiscono la coerenza tra ogni ambiente in conformità con la metodologia . Il team di governance del cloud è responsabile della governance di tutte le risorse in tutti gli ambienti. Il team di governance del cloud deve essere consultato sulle modifiche che potrebbero richiedere un'eccezione o una modifica ai criteri di governance. Il team di governance del cloud deve anche essere informato sullo stato di avanzamento del carico di lavoro e dell'adozione degli asset.
• Le zone di destinazione e le basi 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 quelle zone di destinazione e gli strumenti della piattaforma. Entrambi i team utilizzano la metodologia Ready per guidare l'implementazione. Entrambi i team devono essere informati sullo stato di avanzamento con l'adozione del carico di lavoro e le modifiche apportate all'organizzazione o all'ambiente.
• Carichi di lavoro: L'adozione avviene a livello di carico di lavoro. I team di adozione del cloud usano le metodologie migrate e innovazione per definire 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 Manage per guidare la gestione delle operazioni. Entrambi i team devono avere familiarità con Microsoft Azure Well-Architected Framework per prendere decisioni di architettura dettagliate 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 contribuire alle caratteristiche della zona di destinazione.
• Asset: Gli asset sono tipicamente di competenza del team di gestione del cloud. Il team utilizza la baseline gestionale nella metodologia Gestire per guidare le decisioni relative alla 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 operativi.

Varianti di responsabilità

• Ambiente singolo: Quando un'azienda necessita di un solo ambiente, in genere non è necessario un CCoE.
• Singola zona di destinazione: Se un ambiente ha solo una singola zona di destinazione, è probabile che le funzionalità di governance e piattaforma vengano combinate in un unico team.
• Singolo carico di lavoro: Alcune aziende necessitano di un solo carico di lavoro, o di pochi carichi di lavoro, in una singola zona di atterraggio e in un singolo ambiente. In questi casi, c'è poca necessità di separare i compiti tra i team di governance, piattaforma e operazioni.

Esempi comuni di carico di lavoro e responsabilità

Gli esempi seguenti illustrano la gerarchia del portfolio.

CARICHI DI LAVORO COTS

Tradizionalmente, le aziende hanno favorito soluzioni software pronte all'uso per gestire i processi aziendali. 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 del cloud di soluzioni COTS si conclude con una transizione verso un team di operazioni cloud. Il team operativo del cloud diventa quindi il proprietario tecnico del software e assume la responsabilità per la gestione della configurazione, dei costi, dei cicli di aggiornamento delle patch e di altre esigenze operative.

Questi carichi di lavoro includono pacchetti contabili, software logistico o soluzioni specifiche del settore. Nella terminologia Microsoft, i fornitori di questi pacchetti sono chiamati fornitori di software indipendenti (ISV). Molti ISV offrono un servizio per distribuire e gestire un'istanza del pacchetto software nelle loro sottoscrizioni. Possono anche offrire una versione del pacchetto software in esecuzione nel proprio ambiente ospitato nel cloud, fornendo un'alternativa PaaS (Platform as a Service) alle attività di elaborazione.

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 operativo cloud deve collaborare con il team di governance del cloud per allineare i costi, le 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 creano carichi di lavoro sviluppati in modo personalizzato. In genere, solo una piccola percentuale del portfolio IT usa questo approccio al carico di lavoro. Tuttavia, questi carichi di lavoro tendono a guidare una percentuale sproporzionatamente elevata del contributo it ai risultati aziendali, in particolare i risultati correlati ai nuovi flussi di ricavi. Questi carichi di lavoro tendono a corrispondere bene alle nuove idee innovative.

Dati i vari movimenti radicati nelle metodologie Agile e nelle procedure DevOps, questi carichi di lavoro favoriscono un allineamento aziendale/DevOps rispetto alla gestione IT tradizionale. Per questi carichi di lavoro, potrebbe non esserci un passaggio al team operativo del cloud 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 capitale estesi, le opzioni di sviluppo personalizzate sono spesso limitate a opportunità di valore elevato. Gli esempi tipici includono le innovazioni delle applicazioni, l'analisi approfondita dei dati o le funzioni aziendali cruciali.

Interruzione/correzione o tramonto dello sviluppo

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

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

In entrambi gli scenari, il team operativo del cloud funge in genere da proprietario tecnico e decision maker a lungo termine. È probabile che il team integri gli sviluppatori di applicazioni quando le modifiche operative richiedono modifiche architetturali significative.

Carichi di lavoro cruciali

In ogni azienda, alcuni carichi di lavoro sono troppo importanti per l'azienda perché non riescano. Con questi carichi di lavoro critici per la missione, in genere ci sono responsabili della gestione operativa e dello sviluppo con diversi livelli di responsabilità. Questi team devono allineare le modifiche operative e le modifiche dell'architettura per ridurre al minimo le interruzioni alla soluzione di produzione.

Questi scenari richiedono una forte attenzione alla separazione dei compiti. Il team delle operazioni sarà generalmente responsabile delle modifiche operative quotidiane nell'ambiente di produzione. Quando tali 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 operativo applichi le modifiche all'ambiente di produzione.

Esempi di carichi di lavoro cruciali con una separazione obbligatoria 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 portafoglio strategico

È importante comprendere gli obiettivi strategici dello sforzo 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 del portfolio e dell'effetto sulla gerarchia del portfolio.

Portfolio guidato dall'innovazione o dallo sviluppo

Alcune aziende, in particolare le startup in rapida crescita, hanno una percentuale superiore alla media dei progetti di sviluppo personalizzati. Nei portfolio con uso elevato 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 di applicazione potrebbero sostituire la necessità di operazioni e funzioni di governance. Questi clienti ridurranno probabilmente l'attenzione sulle operazioni, sulla governance o su altri ruoli di supporto. Un'enfasi più forte sulle responsabilità dei team di adozione del cloud e automazione del cloud è anche tipica.

Allineamento del portfolio: Il portfolio IT si concentrerà probabilmente sui carichi di lavoro e i loro proprietari per guidare decisioni architetturali critiche. È probabile che questi team trovino maggiore valore nelle linee guida di Azure Well-Architected Framework durante l'adozione e le attività operative.

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

Portfolio guidato dalle operazioni

Le organizzazioni multinazionali aziendali con team operativi IT più consolidati hanno in genere un focus più forte sulla governance e sulle operazioni rispetto allo sviluppo. In queste organizzazioni, una percentuale più elevata di carichi di lavoro è in genere allineata alle categorie COTS o break/fix, gestiti dai proprietari tecnici all'interno del team delle operazioni cloud.

allineamento portfolio: Il portfolio IT sarà allineato al carico di lavoro, ma tali carichi di lavoro vengono quindi allineati alle unità operative o alle business unit. Potrebbe anche essere presente un'organizzazione intorno ai modelli di finanziamento, al settore o ad altri requisiti di segmentazione aziendale.

definizioni di limiti: Le zone di atterraggio probabilmente raggrupperanno le applicazioni in archetipi di applicazioni per mantenere operazioni simili in una segmentazione simile. È probabile che gli ambienti facciano riferimento a costrutti fisici come data center, nazione, area del provider di servizi cloud o altri standard dell'organizzazione operativa.

Portfolio guidato dalla migrazione

Analogamente ai portfolio con gestione delle operazioni, un portfolio che viene in gran parte costruito tramite la migrazione si basa su driver aziendali specifici che hanno portato alla migrazione di asset esistenti. In genere, il data center è il fattore più importante per questi driver.

Allineamento del portfolio: Il portfolio IT potrebbe essere allineato al carico di lavoro, ma è più probabile che sia allineato agli asset. Se le transizioni alle operazioni IT sono avvenute nella storia dell'azienda, molti asset di uso attivo potrebbero non essere facilmente mappati a un carico di lavoro finanziato. In questi casi, molte risorse potrebbero non avere un carico di lavoro definito o un chiaro proprietario del carico di lavoro finché non si è vicini alla fase finale del processo di migrazione.

Definizioni dei confini: Le zone di atterraggio probabilmente raggrupperanno le applicazioni in confini che riflettono la segmentazione on-premises. 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. È una pratica migliore aderire a una segmentazione che si allinea in modo più stretto a un portafoglio guidato dalle operazioni.

Portfolio guidato dalla governance

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

allineamento del portafoglio: i portafogli guidati dalla governance tendono a includere punti di dati che raccolgono dettagli sull'innovazione e sulle operazioni, ad esempio il carico di lavoro, il responsabile delle operazioni, la classificazione dei dati e la criticità operativa. Questi dati creano una visione completa del portfolio.

Definizioni di Limiti: i limiti in un portfolio guidato dalla governance tendono a privilegiare le operazioni rispetto all'innovazione, utilizzando una gerarchia basata su gruppi di gestione che si mappa ai criteri per le unità aziendali e gli ambienti di sviluppo. A ogni livello della gerarchia, un confine di governance cloud può avere diversi gradi di attuazione delle policy per permettere lo sviluppo e la flessibilità creativa. Allo stesso tempo, i requisiti di livello di produzione possono essere applicati alle sottoscrizioni di produzione per garantire la separazione dei compiti e delle operazioni coerenti.

Passaggi successivi

Scopri come i prodotti Azure supportano la gerarchia del portfolio.