Fase 1. Valutazione delle applicazioni

Gli obiettivi di questa fase sono:

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

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

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

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

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

Utilizzo del manuale diagnostico di modernizzazione

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

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

Parametri della diagnosi

Il manuale di diagnostica sulla 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?

• Archiviazione: 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 continua e distribuzione continua (CI/CD)?

  • In caso affermativo, quali responsabilità dell'infrastruttura dovrebbero essere distribuite ai team applicativi e a chi?

  • In caso contrario, quali responsabilità infrastrutturali (ad esempio l'applicazione delle patch) dovrebbero rimanere a carico di un team operativo?

• Modello di consegna:

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

  • Quale parte della modernizzazione dovrebbe utilizzare i servizi cloud native?

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

  • Un background applicativo cloud per creare applicazioni con un'architettura modulare utilizzando tecnologie container e serverless da zero.

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

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

• Tempi di modernizzazione: quali sono le considerazioni sulla tempistica del portafoglio aziendale o altre considerazioni sul 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 in AWS base all'analisi economica?

La valutazione delle applicazioni rispetto a queste dimensioni ti aiuta a rimanere ancorato al business, alla tecnologia e all'economia mentre promuovi la tua modernizzazione verso il cloud.

Blocchi di costruzione

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 all'interno dell'azienda nel tradurre le esigenze aziendali in requisiti. Quanto è reattiva l'organizzazione delle 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 metodologia e DevOps cerimonie agili, nonché l'assegnazione e la chiarezza dei ruoli e la collaborazione, la comunicazione e l'abilitazione complessive in tutta l'organizzazione.

• Efficacia ingegneristica: pratiche di sviluppo relative alla garanzia 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 ai tuoi clienti, devi implementare misure che favoriscano il miglioramento e accelerino la consegna. Obiettivo, domanda, metrica (GQM) fornisce un quadro efficace per garantire che le misure soddisfino questi criteri. Usa questo framework per recuperare i tuoi obiettivi seguendo questi passaggi:

1. Identifica l'obiettivo o il risultato che stai perseguendo.

2. Individua le domande a cui è necessario 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 stia offrendo ciò che conta per i tuoi clienti.

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

Parametri del 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 pensiero sotto forma di un test che si concentri su ciò che sarebbe vero quando viene fornita una funzionalità di modernizzazione.

Ad esempio, se ritenete che la migrazione delle transazioni dai sistemi legacy sbloccherà nuove opportunità per l'onboard dei clienti, qual è il miglioramento? Quanta capacità deve essere creata per integrare il prossimo cliente? Come verrebbe costruito un test per convalidare questo risultato? Per questo scenario, le Parametri del prodotto possono includere le seguenti:

• Identifica il test o l'ipotesi del valore aziendale (ad esempio, liberando x percentuale della capacità di transazione si integrerà la percentuale y della nuova attività).

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

• Convalida il risultato (ad esempio, hai una capacità migliorata dell'x percento, quindi ora puoi incorporare nuove attività in percentuale y?)

Parametri dell'operazione

Per determinare se state migliorando il ciclo di vita di distribuzione del software e accelerando la modernizzazione, è necessario conoscere i tempi di consegna e 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 è necessario per implementare un ambito di lavoro, dall'inizio alla fine?

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

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

• Percentuale di errori nelle modifiche: qual è il tempo medio tra i guasti (MTBF)?