Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Strategia di prioritizzazione e migrazione

Un elemento chiave della pianificazione della migrazione consiste nello stabilire criteri di prioritizzazione. Lo scopo di questo esercizio è comprendere l'ordine in cui le applicazioni verranno migrate. La strategia consiste nell'adottare un approccio iterativo e progressivo per far evolvere il modello di prioritizzazione.

Assegnazione di priorità alle applicazioni

Questa fase di valutazione si concentra sulla definizione di criteri iniziali per dare priorità ai carichi di lavoro a basso rischio e bassa complessità. Questi carichi di lavoro sono ottimi candidati per applicazioni pilota. L'utilizzo di carichi di lavoro a basso rischio e bassa complessità nelle migrazioni iniziali riduce il rischio e offre ai team l'opportunità di acquisire esperienza. Questi criteri verranno evoluti in ulteriori fasi di valutazione per allineare la prioritizzazione ai fattori di business durante la creazione del piano di migrazione.

I criteri iniziali dovrebbero dare la priorità alle applicazioni con un numero limitato di dipendenze, eseguite in un'infrastruttura supportata dal cloud e da ambienti non di produzione. Un esempio potrebbero essere le applicazioni con 0-3 dipendenze pronte per essere riospitate così come sono in un ambiente di sviluppo o di test. Questi criteri sono validi per definire le applicazioni pilota e potenzialmente la prima e la seconda ondata di migrazione, a seconda del livello di maturità e dei livelli di confidenza nell'adozione del cloud.

Decidere quali criteri iniziali utilizzare

Seleziona da 2 a 10 punti dati da utilizzare per dare priorità ai primi carichi di lavoro. Questi punti dati provengono dall'inventario iniziale delle applicazioni e dell'infrastruttura (consulta la sezione sulla raccolta dei dati).

Successivamente, definisci un punteggio, o peso, per ogni valore possibile di ogni punto dati. Ad esempio, se è selezionato l'attributo environment e i valori possibili sono production, development e test, a ogni valore viene assegnato un punteggio, un numero maggiore che rappresenta una priorità più alta. Sebbene sia facoltativo, consigliamo di assegnare un fattore moltiplicatore per l'importanza o la pertinenza a ciascun punto dati. Questo passaggio facoltativo fornisce un elemento di differenziazione di livello superiore per enfatizzare ciò che è più importante, il che aiuta a mantenere allineati i criteri mentre si procede nell'assegnazione dei punteggi ai valori.

In base alla strategia di dare priorità alle applicazioni semplici e a basso rischio per le prime ondate di migrazione, la tabella seguente mostra esempi di selezione degli attributi e le relative assegnazioni di valore.

Assicurati di selezionare attributi che possano fungere da fattori chiave di differenziazione tra le applicazioni. In caso contrario, i criteri faranno sì che molti carichi di lavoro condividano la stessa priorità. Dopo aver applicato il modello, ti consigliamo di esaminare la parte superiore e inferiore della classifica risultante per vedere se sei d'accordo. Se in generale non sei d'accordo, puoi rivedere i criteri utilizzati per assegnare un punteggio ai carichi di lavoro.

Dopo aver ottenuto una classifica, esamina la distribuzione dei punteggi nell'intero portafoglio. I punteggi in sé non contano. È la differenza tra i punteggi che conta. Ad esempio, potresti scoprire che il punteggio totale più alto è 8.000 e il punteggio più basso è 800. Prendi in considerazione la possibilità di tracciare i punteggi risultanti sotto forma di istogramma, in modo da verificare di avere una buona distribuzione. La distribuzione ideale assomiglia a una curva a campana standard, con pochi carichi di lavoro ad altissima priorità e alcuni carichi di lavoro a priorità molto bassa. La maggior parte delle applicazioni si troverà da qualche parte nel mezzo.

Un altro aspetto fondamentale della prioritizzazione iniziale consiste nell'includere team interni o unità aziendali che mostrano interesse a diventare i primi ad adottare il cloud. Queste potrebbero essere una leva importante per ottenere supporto aziendale per la migrazione di una determinata applicazione, soprattutto nei primi giorni. Se questo è il caso della vostra organizzazione, includete l'attributo dell'unità di business nella tabella precedente. Assegnate un punteggio elevato alle unità aziendali disposte a presentare le proprie candidature. L'utilizzo dell'attributo business unit contribuirà a portare tali applicazioni in cima all'elenco.

Dopo aver accettato la classifica risultante, seleziona le prime 5-10 applicazioni. Questi saranno i candidati iniziali per la migrazione delle candidature. Perfeziona l'elenco in modo da confermare 3-5 candidature. Ciò consente di adottare un approccio mirato durante l'esecuzione di una valutazione dettagliata delle applicazioni. Per ulteriori informazioni, consulta Valutazione prioritaria delle applicazioni.

Determinazione del tipo R per la migrazione

La scelta di una strategia di migrazione per ogni applicazione e infrastruttura associata avrà implicazioni sulla velocità, sui costi e sul livello di vantaggi della migrazione. È fondamentale determinare la strategia sulla base di una combinazione equilibrata di fattori, tra cui fattori di business, principi guida tecnici, criteri di prioritizzazione e strategia aziendale.

A volte questi fattori creano opinioni contrastanti. Ad esempio, il motore principale della migrazione potrebbe essere l'innovazione e l'agilità. Allo stesso tempo, potrebbe essere necessario ridurre rapidamente i costi. La modernizzazione mirata di tutte le applicazioni ridurrà i costi a lungo termine, ma richiederà un investimento iniziale maggiore. In tal caso, un approccio consiste nel migrare le applicazioni utilizzando strategie che richiedano meno sforzi, come il rehosting o la ripiattaforma. Ciò può garantire una rapida efficienza e una riduzione dei costi a breve termine. Quindi reinvestite i risparmi nella modernizzazione dell'applicazione in una fase successiva e ottenete un'ulteriore riduzione dei costi.

Tuttavia, iniziare con un rehosting completo di tutte le applicazioni ritarda i maggiori vantaggi della modernizzazione. La chiave è trovare un equilibrio tra le strategie di migrazione in modo che le applicazioni strategiche aziendali abbiano la priorità per la modernizzazione, mentre le altre applicazioni possano essere riospitate o riorganizzate prima sulla piattaforma e poi modernizzate.

Come determinare una strategia di migrazione per le applicazioni?

In questa fase di valutazione, l'obiettivo è incorporare un modello iniziale per guidare la selezione della strategia di migrazione. Per convalidare la strategia di migrazione per le applicazioni iniziali, utilizzate il modello insieme ai fattori di business e ai criteri di prioritizzazione. La logica predefinita dell'albero decisionale vi aiuterà a determinare il trattamento iniziale per l'ambito. Nell'albero, gli approcci più complessi, come refactor o re-architect, sono riservati ai carichi di lavoro strategici.

Una versione draw.io personalizzabile di questo diagramma è disponibile nella sezione Allegati.

Il primo passaggio verso un modello iniziale consiste nell'aggiornare i driver aziendali nella parte superiore dell'albero con quelli definiti dall'organizzazione. Successivamente, applica l'albero ai componenti dell'applicazione anziché alle applicazioni nel loro insieme. Ad esempio, nel caso di un'applicazione a tre livelli con tre componenti (front-end, livello applicativo e database), ogni componente deve transitare nell'albero in modo indipendente e ricevere una strategia e un modello specifici. Questo perché in alcuni casi potresti voler riospitare o ripiattaforma un determinato livello e rifattorizzare (riprogettare) altri livelli.

L'assegnazione indipendente dei componenti vi porterà a definire una strategia di migrazione per l'infrastruttura associata. La strategia di infrastruttura potrebbe essere la stessa strategia del componente applicativo supportato o potrebbe essere diversa. Ad esempio, un componente applicativo che verrà riorganizzato in una nuova macchina virtuale con un sistema operativo più recente seguirà la strategia di ripiattaforma mentre la macchina virtuale corrente che lo ospita verrà ritirata. La strategia di migrazione per l'infrastruttura viene calcolata in base alla strategia scelta per i componenti dell'applicazione.

Prima di utilizzare l'albero decisionale per stabilire le strategie di migrazione, verifica la logica con alcune applicazioni e verifica se generalmente sei d'accordo con il risultato. L'albero decisionale delle 6 R è una guida che non sostituisce l'analisi necessaria per determinarne la correttezza. La logica ad albero potrebbe non essere applicabile a casi particolari. Tratta questi casi come eccezioni e procedi a sovrascrivere la decisione guidata dall'albero documentando la logica alla base dell'override anziché modificando la logica dell'albero. In questo modo si evitano versioni multiple dell'albero decisionale, che potrebbero diventare difficili da gestire. Le indicazioni generali indicano che l'albero deve essere valido per almeno il 70-80 percento dei carichi di lavoro. Per il resto, ci saranno delle eccezioni. Qualsiasi modifica alla logica dell'albero, in questa fase della valutazione, dovrebbe concentrarsi sulla definizione di un modello iniziale. Ulteriori iterazioni e perfezionamenti avverranno nelle fasi successive, come l'analisi del portafoglio e la pianificazione della migrazione.

Allegati

attachment.zip