Fase 1: Valuta le tue applicazioni

Gli obiettivi di questa fase sono:

• Comprendi a fondo il panorama delle tue applicazioni e prepara le applicazioni per le moderne piattaforme di dati, in modo da poter accelerare il time-to-value senza influire sul business, e quindi modernizzare, ottimizzare e scalare.

• Profilate il vostro panorama applicativo per identificare i vantaggi, i rischi e i costi associati al cambiamento.

• Fornisci una end-to-end serie di servizi: dalla strategia alla pianificazione, all'implementazione, alla migrazione e alla modernizzazione delle applicazioni, fino al supporto continuo.

• Crea politiche, raccomandazioni e controlli che forniscano pratiche e strumenti riutilizzabili per fornire valore aziendale continuo.

Nella fase di valutazione, i proprietari delle applicazioni e gli architetti utilizzano un manuale diagnostico di modernizzazione per convalidare gli obiettivi e le priorità di modernizzazione.

Utilizzo del manuale di diagnostica per la modernizzazione

Un manuale diagnostico di modernizzazione fornisce un processo per determinare il valore del passaggio dallo stato attuale a quello futuro per l'azienda. Ciò include i cambiamenti tecnologici che la modernizzazione comporta.

Utilizzate il playbook diagnostico per determinare la priorità della vostra applicazione o suite di applicazioni per la modernizzazione del cloud e per identificare i componenti da affrontare durante la modernizzazione.

Dimensioni diagnostiche

Il manuale di diagnostica di modernizzazione consente di comprendere le seguenti dimensioni dello stato attuale e di destinazione (dopo la migrazione) di un'applicazione o di un gruppo di applicazioni:

• Raggruppamento delle applicazioni: esiste un motivo per raggruppare le applicazioni (ad esempio, per tecnologia o modello operativo) per la modernizzazione?

• Sequenziamento: esiste un ordine in cui le applicazioni devono essere modernizzate, in base alle dipendenze?

• Tecnologia: quali sono le categorie tecnologiche (ad esempio middleware, database, messaggistica)?

• Dipendenze: le applicazioni hanno dipendenze chiave da altri sistemi o middleware?

• Ambienti: quanti ambienti di sviluppo, test e produzione vengono utilizzati?

• Storage: quali sono i requisiti di archiviazione (ad esempio, il numero di copie dei dati di test)?

• Modello operativo: tutti i componenti dell'applicazione possono adottare una pipeline di integrazione e distribuzione continue (CI/CD)?

  • In caso affermativo, quali responsabilità infrastrutturali devono essere distribuite ai team delle applicazioni e a chi?

  • In caso contrario, quali responsabilità relative all'infrastruttura (ad esempio, l'applicazione delle patch) dovrebbero spettare a un team operativo?

• Modello di consegna:

  • In base all'applicazione o al gruppo di applicazioni, è necessario ripiattaforma, rifattorizzare, riscrivere o sostituire?

  • Quale parte della modernizzazione dovrebbe utilizzare i servizi nativi del cloud?

• Set di competenze: quali competenze sono richieste? Per esempio:

  • Un background di applicazioni cloud per creare applicazioni con un'architettura modulare utilizzando sin dall'inizio tecnologie container e serverless.

  • DevOps esperienza per sviluppare soluzioni nelle aree dei processi CI/CD, dell'infrastruttura come codice e dell'automazione o dell'osservabilità delle applicazioni utilizzando strumenti e servizi open source. AWS

• Approccio alla modernizzazione: considerando lo stato attuale delle applicazioni, le scelte tecnologiche cloud, l'attuale debito tecnico, la CI/CD, il monitoraggio, le competenze e il modello operativo, qual è il lavoro di migrazione tecnica che deve essere svolto?

• Tempi di modernizzazione: quali sono le considerazioni relative alla tempistica del portafoglio aziendale o altre considerazioni relative al lavoro pianificato che potrebbero influire sui tempi di modernizzazione?

• Costo unitario e totale dell'infrastruttura: qual è il costo annuo del mantenimento del carico di lavoro in sede rispetto a quello esterno, in base all'analisi economica? AWS

La valutazione delle applicazioni rispetto a queste dimensioni vi aiuta a rimanere ancorati al business, alla tecnologia e all'economia mentre promuovete la modernizzazione verso il cloud.

Elementi costitutivi

Quando modernizzi le applicazioni, puoi classificare le tue osservazioni in tre elementi costitutivi: agilità aziendale, agilità organizzativa ed efficacia ingegneristica.

• Agilità aziendale: pratiche che riguardano l'efficacia aziendale nel tradurre le esigenze aziendali in requisiti. Quanto è reattiva l'organizzazione addetta alle consegne alle richieste aziendali e quanto controllo ha l'azienda nel rilasciare funzionalità negli ambienti di produzione.

• Agilità organizzativa: pratiche che definiscono i processi di consegna. Gli esempi includono la metodologia e DevOps le cerimonie agili, nonché l'assegnazione dei ruoli e la chiarezza e la collaborazione, la comunicazione e l'abilitazione complessive all'interno dell'organizzazione.

• Efficacia ingegneristica: pratiche di sviluppo relative al controllo della qualità, ai test, alla CI/CD, alla gestione della configurazione, alla progettazione delle applicazioni e alla gestione del codice sorgente.

Identificazione delle metriche

Per capire se stai offrendo ciò che conta per i tuoi clienti, devi implementare misure che favoriscano il miglioramento e accelerino la consegna. Goal, question, metric (GQM) fornisce un quadro efficace per garantire che le misure soddisfino questi criteri. Utilizzate questo framework per raggiungere i vostri obiettivi seguendo questi passaggi:

1. Identifica l'obiettivo o il risultato che intendi raggiungere.

2. Ricava le domande a cui rispondere per determinare se l'obiettivo è stato raggiunto.

3. Decidi cosa dovrebbe o potrebbe essere misurato per rispondere adeguatamente alle domande. Esistono due categorie di misure:

   • Metriche di prodotto, che garantiscono che tu fornisca ciò che conta per i tuoi clienti.

   • Metriche operative, che garantiscono il miglioramento del ciclo di vita della distribuzione del software.

Metriche di prodotto

Le metriche di prodotto si concentrano sui risultati aziendali e devono essere stabilite quando viene determinato il ritorno sull'investimento (ROI) per un nuovo ambito di lavoro. Una tecnica utile per stabilire una metrica di prodotto consiste nel chiedersi cosa cambierà nell'azienda quando verrà implementato quel nuovo ambito di lavoro. È utile formalizzare questo modo di pensare sotto forma di un test che si concentri su ciò che sarebbe vero se venisse fornita una funzionalità di modernizzazione.

Ad esempio, se ritieni che la migrazione delle transazioni dai sistemi legacy sbloccherà nuove opportunità per l'onboard dei clienti, qual è il miglioramento? Quanta capacità è necessario creare per l'onboarding del prossimo cliente? Come verrebbe costruito un test per convalidare tale risultato? In questo scenario, le metriche del prodotto potrebbero includere quanto segue:

• Identifica il test o l'ipotesi del valore aziendale (ad esempio, liberando l'x percento della capacità di transazione si accumulerà l'y percento di nuove attività).

• Stabilisci la linea di base (ad esempio, la capacità attuale di x transazioni supporta y clienti).

• Convalida il risultato (ad esempio, hai migliorato la capacità del x percento, quindi ora puoi incorporare l'y percento di nuove attività?)

Parametri operativi

Per determinare se state migliorando il ciclo di vita della distribuzione del software e accelerando la modernizzazione, dovete conoscere i tempi di consegna e i tempi di implementazione necessari per la distribuzione del software. Cioè, quanto velocemente è possibile convertire un'esigenza aziendale in funzionalità di produzione?

Le metriche operative utili includono:

• Tempi di consegna: quanto tempo impiega un ambito di lavoro per passare dalla richiesta alla produzione?

• Tempo di ciclo: quanto tempo occorre per implementare un ambito di lavoro, dall'inizio alla fine?

• Frequenza di implementazione: con che frequenza implementate le modifiche alla produzione?

• Tempo di ripristino del servizio: quanto tempo è necessario per il ripristino in caso di guasto (misurato come tempo medio di riparazione o MTTR)?

• Modifica della percentuale di guasti: qual è il tempo medio tra i guasti (MTBF)?