In informatica, il termine “legacy” indica un sistema informatico, un’applicazione o un componente obsoleto, che continua ad essere usato poiché l’utente non intende o non può rimpiazzarlo. Potremmo quindi dire che “legacy” equivale a “versione retrodatata”.
Tutte le tecnologie invecchiano e, di conseguenza, le applicazioni diventano legacy. Non si tratta solo di una questione di linguaggio, infatti è possibile oggi stesso scrivere un’applicazione in Java considerata legacy, se la si scrive come si faceva dieci anni fa.
Questo problema è aggravato dal fatto che sostanzialmente non esiste nessun software che possa essere scritto utilizzando una sola tecnologia, infatti, non c’è nessuno sviluppatore a cui sia sufficiente conoscere solo un linguaggio.
Uno studio di Statista.com valuta il mercato degli strumenti per la modernizzazione delle applicazioni oltre i 15 miliardi di dollari nel 2022 e stima che crescerà oltre i 32 miliardi di dollari entro il 2027.
Quali sono quindi le caratteristiche che associamo ad un software legacy?
- costi di manutenzione alti;
- elevati costi di introduzione di nuove funzionalità;
- impossibilità di introdurre nuove tecnologie (sia a causa di costi eccessivi che, talvolta, a causa dell’incompatibilità).
Perché succede tutto questo?
La risposta sta nella bassa disponibilità di pacchetti, strumenti “open” già pronti e persone. Gli sviluppatori che hanno conoscenze legacy sono pochi e tendono ad invecchiare come il software per, infine, andare in pensione. Questa scarsa disponibilità porta ovviamente a un aumento del loro costo.
L’insieme di questi elementi ci permette di dire che il software legacy ha un TCO (Total Cost of Ownership) antieconomico. Il TCO viene inteso come tutti i costi che gravitano intorno a un software, o prodotto, lungo tutta la sua vita. Quindi, potremmo anche parlare di costi lungo 10 anni. Nello specifico parliamo di acquisto di licenze, implementazioni, supporto ma anche costi più nascosti come il tempo utilizzato dalle persone.
Tutto quello di cui abbiamo parlato finora si contrappone al concetto di cloud native: ovvero un modello architetturale in cui vengono utilizzati strumenti e tecniche consolidate, spesso open, conosciute da tanti sviluppatori e che spesso si rifanno a degli standard. Tutto questo porta ad avere un’alta disponibilità di tool di supporto che è appunto in contrapposizione a tutto quello che abbiamo visto adesso relativamente al legacy. Le applicazioni cloud native devo essere:
- fullstack;
- multidatabase;
- serverless;
- decentralizzato;
- scalabili;
- aperte;
- espandibili;
- online;
- offline;
- integrate.
Citiamo anche online e offline perché progettare un software sapendo che alcuni front-end dovranno essere utilizzati in entrambe le circostanze porta spesso a progettare l’architettura in modo diverso.
Le soluzioni più comuni
Per le software house, il time-to-user è un KPI particolarmente importante, perché rappresenta quanto tempo è necessario affinché una nuova funzionalità arrivi all’utente finale.
Vediamo come funziona solitamente nelle aziende:
Software standard
Il fornitore produce software uguale per tutti, lo distribuisce. I clienti solitamente possono configurare o in alcuni casi fare anche delle piccole modifiche su questo software.
Il problema si riscontra nel momento in cui il cliente ha un’esigenza non risolta dal software standard. A questo punto il fornitore deve sviluppare nuove funzionalità rendendole abbastanza generiche in modo che non si adatti solo a quello specifico cliente, creare una nuova release, distribuirlo, etc…
Software custom
Sono software costruiti attorno alle esigenze specifiche del cliente al momento dello sviluppo. I problemi cominciano nel momento in cui i clienti hanno delle nuove e diverse esigenze per cui è necessario fare delle modifiche al software. Tipicamente succede che la complessità di questo software continua ad aumentare, causando un aumento del time-to-user fino, in alcuni casi, a dover riscrivere l’applicazione.
La soluzione ideale
L’ipotesi più evoluta prevede che le aziende siano in grado di distribuire e sviluppare dei componenti standard. Questi poi vengono utilizzati per comporre delle soluzioni standard ma anche delle soluzioni completamente Custom.
Componenti standard, software custom
I consulenti applicativi sono autonomi nello sviluppo delle soluzioni, quindi partendo dai componenti standard possono o costruire delle soluzioni custom specifiche per il cliente oppure decidere di modificare le applicazioni standard nel caso ci sia questa necessità.
Un altro motivo per cui le aziende così organizzate hanno un’elevata agilità è l’approccio con cui innovano. Queste, infatti, sanno bene che per innovare è necessario fornire rapidamente un risultato ai clienti, perché il loro feedback aiuta a capire se stanno andando nella direzione giusta. Rendendo i cicli di feedback più veloci riescono ad arrivare prima ad una soluzione ottimale.
Conclusione
Per superare le sfide legate al software legacy è importante adottare approcci cloud native, che sono flessibili, agili ed espandibili. L’implementazione di componenti standard combinati con soluzioni custom offre un equilibrio ottimale tra flessibilità e controllo, consentendo alle aziende di adattarsi prontamente alle mutevoli esigenze del mercato e fornire valore aggiunto ai clienti in tempi rapidi.
