Ci sono molte ragioni per farlo. Ad esempio, potrebbero esserci stati cambiamenti nelle esigenze dell’utente o nella tecnologia che rendono necessario adattare o aggiornare l’applicazione. Inoltre, un’applicazione può diventare obsoleta a causa di bug o problemi di sicurezza che devono essere risolti. Infine, più semplicemente, il bisogno di rinnovare l’interfaccia utente o per aggiungere nuove funzionalità per rendere l’applicazione più interessante e utile per gli utenti.
Molto spesso i CIO si trovano di fronte ad una scelta:
Cosa fare con le piattaforme e le soluzioni meno recenti?
Queste applicazioni sostengono l’operatività quotidiana, ma magari sono appoggiate su un ambiente obsoleto o essere sviluppate in linguaggi non più al passo con i tempi, magari sviluppato da un fornitore che non fa più application management oppure da un team che non lavora più in azienda.
Anche se sarebbe ovvio optare per una sostituzione, spesso il processo (tra selezione, implementazione e transizione) è più complicato di quanto possa sembrare. Tra reverse engineering, implementazione delle funzionalità personalizzate, integrazioni, migrazione dei dati e delle politiche di visualizzazione, unit test, end-to-end test, acceptance test, vale la pena considerare se può essere aggiornata per allinearla con le esigenze attuali del business o per prepararsi ad una sostituzione.
Un modo per modernizzare le applicazioni è spostarle su un approccio basato a microservizi, operazione fattibile senza influire (o influire in minima parte) sulle altre applicazioni (in quanto puoi modificare i singoli componenti senza incidere sugli altri). Questo tipo di transizione può sembrare complessa e difficoltosa all’inizio, ma permette di procedere a step, individuando e dividendo le funzionalità dell’applicativo monolitico in, appunto, diversi microservizi, trattandoli singolarmente e potendoli suddidivere tra vari team di sviluppo.
Facciamo un esempio che può rendere più comprensibile il processo.
Abbiamo un applicativo monolitico e-commerce; come primo step possiamo individuare le diverse funzionalità, semplificando avremo un processo di login, un catalogo prodotti, un carrello prodotti, un processo di checkout e pagamento, un’area preferenze utente.
Trattando queste funzionalità come microservizi standalone, è possibile anche parallelizzare lo sviluppo, ad esempio un team si occupa del microservizio “login” (e magari questo microservizio potrà essere riutilizzato in applicativi diversi da quello e-commerce) mentre un secondo team si occupa del microservizio “carrello prodotti”.
Il team “login” non deve preoccuparsi e conoscere come è fatto il carrello, ma deve solo permettere ad un utente di accedere al sito con le proprio credenziali e, allo stesso modo, il team “carrello” non deve preoccuparsi di come l’utente si logga, ma deve presentare il catalogo dei prodotti acquistabili nel e-commerce.
Un’altra modalità è quella che ruota intorno alla UX. Possiamo paragonarla alla verniciatura della carrozzeria di un’auto: in molti casi, il miglioramento dell’interfaccia aumenta esponenzialmente la soddisfazione dell’utente finale e ne aumenta il grado di usabilità. Questo genere di approccio mantiene tutte le funzionalità, core e personalizzazioni della vecchia applicazione, ma la rende del tutto nuova agli occhi dell’utente finale.
Riprogettare un front end non significa solo replicare la vecchia grafica in maniera moderna, ma uno studio su cosa potrebbe essere utile mostrare ai vari gruppi di stakeholder così da renderli più efficaci e efficienti.
Ultimo (ma non ultimo) è il considerare le prestazioni e il costo della manutenzione dell’hardware sottostante, che possono essere considerati il motivo principale per procedere con una sostituzione. Passare ad un ambiente cloud consente di acquistare solo la capacità e lo spazio secondo le reali necessità attuali, lasciando l’onere di manutenzioni e aggiornamenti hardware al provider.
Inoltre, una migrazione cloud può preparare la strada alla transizione ad un’architettura che si basa su microservizi, in quanto è un ambiente consolidato e che facilita la comunicazione tra applicazioni e servizi interni e esterni.
Non è necessario buttarsi in una sostituzione quando ci si trova ad avere a che fare con un sistema obsoleto: è possibile combinare gli approcci descritti qualche riga fa, così da rinviare una decisione che impiegherà un copioso numero di risorse e denaro, che potrebbero essere utilizzate altrove.
Questo argomento è di tuo interesse e vorresti trasformare la tua idea in realtà con noi? Non esitare a contattarci.
Resta sintonizzato per altri approfondimenti, tramite la nostra sezione Insights oppure sulla nostra pagina Linkedin.
