Cloud e virtualizzazione, che hanno consentito di rendere più efficienti e semplificare le infrastrutture, non risolvono la complessità degli scenari applicativi. I Cio si trovano a sostenere le difficoltà legate all’utilizzo di soluzioni eterogenee, quando non addirittura la convivenza di soluzioni native in cloud con soluzioni legacy che può dare origine al moltiplicarsi di strumenti software su cui si perde il controllo, a scapito di efficienza, sicurezza e costi.
E’ indubbio però, e analisti ed esperti concordano che software (e i servizi collegati) siano oggi gli elementi strategici della trasformazione digitali. Senza le applicazioni è possibile fare poco, basta pensare a tutti i software as a service, alle applicazioni Web, ai microservizi, alle app mobile, alle applicazioni containerizzate.
Negli anni sono cambiati linguaggi e metodologie, ma anche paradigmi architetturali e linguaggi e proprio i Cio si trovano a gestire un alto livello di complessità, mentre le unità di business non hanno ancora imparato a dialogare tra loro e invece è richiesta agilità e trasformazione dei processi in questo senso, un bisogno che per alcune unità è addirittura cogente.
Le grandi aziende, che hanno sedi sparse per il mondo, in alcuni casi operative con modelli di business e non perfettamente sovrapponibili, richiedono software diversi e diversi modelli di erogazione indipendentemente dalla tipologia di licenza (off-the-shelf o SaaS) e dal canale di accesso (installazione fisica, virtualizzazione, Web app e Progressive Web App).
Per risolvere le criticità fino a qui evidenziate, Citrix propone una sorta di viaggio applicativo a tappe, in ognuna delle quali i Cio possono rispecchiarsi intravvedendo i punti di vantaggio offerti dalla propria posizione ed eventuali spostamenti da effettuare per ottenere altri vantaggi.
L’azienda mette in guardia. Le applicazioni rappresentano il sistema linfatico di ogni realtà, e si tratta di un sistema complesso che, se mal gestito, determina una significativa dispersione del budget IT in tanti rivoli. Allo stesso tempo il modello non prevede un percorso predeterminato, né detta una sequenza di cose da fare. Il ciclo proposto non è un ciclo continuo e alcune categorie, a seconda dei casi, possono trovarsi sovrapposte nell’esperienza dei Cio.
Il primo momento, come è giusto che sia ogni volta che si deve affrontare un problema, richiede il riconoscimento della situazione. Il momento Retire comprende una serie di iniziative per identificare e ritirare le applicazioni legacy dal portfolio.
Versioni multiple della stessa applicazione, applicazioni “orfane” (nessuno le usa, o ne riconosce l’utilità e o la paternità e quindi non sono più allocate risorse di sviluppo su di esse) dovrebbero essere ritirate, per abbassare il rischio operazionale. Continuare a far girare applicazioni di questo tipo costa.
Con le operazioni di Replacement si riesce a ridurre il gap tecnologico e relativi costi associati. Appannaggio delle linee di business, un passaggio di questo tipo si basa sull’identificazione delle applicazioni prêt-à-porter, SaaS, ma anche sviluppate in casa e spesso installate on-premise o su IaaS pubblico.
Non fa parte delle possibilità aperte a tutti, ma è comunque una possibilità concreta quella di trasferire (Relocate) e migrare le applicazioni in modalità lift and shift. Si tratta di fare rehosting, ma bisogna disporre della giusta tecnologia per affrontare il rischio operazionale e di solito prevede una scelta di Iaas pubblico, sulla scorta della disponibilità di una rete sicura, fino al passaggio finale della migrazione del database di dati.
Più articolata e complessa, ma in alcuni casi anche l’unico percorso possibile, è l’operazione di Re-platform. Vi sono alcune applicazioni legacy, che sono però anche applicazioni critiche, e devono restare disponibili sempre: spesso sono on-premise.
Si tratta di applicazioni ancora efficaci ma viene a mancare dai provider la componente core sottostante, la piattaforma. In questi casi, pur con obiettivi e difficoltà differenti, si può pensare ad un’operazione per renderle operative su cloud pubblico conservando molti dei componenti verticali e orizzontali caratterizzanti.
In altri , conviene invece del tutto concentrarsi riscrivendo le applicazioni (Rebuild), oppure sostituendo alcune componenti. E’ possibile per esempio realizzare nuove semplici interfacce Web e modernizzare tecnologie non più supportate o rendere disponibili le applicazioni così a un numero maggiore di utenti.
Quando invece il core applicativo di suo è ancora valido ma è necessario proporre all’utente una nuova esperienza applicativa, si può creare uno strato di astrazione (sfruttando per esempio le Api, Re-use) tra il sistema esistente e la user experience al passo con i tempi che si desidera offrire.
Siamo all’ultima tappa del viaggio, indubbiamente quella più impegnativa perché in questi casi è necessario reimmaginare da capo l’intero impianto tecnologico, per esempio anche in relazione a profondi cambiamenti nelle logiche di business e ai processi.
In altri casi, proprio perché le applicazioni sono nate per soddisfare specifici processi di lavoro che hanno richiesto lo sviluppo di applicazioni ad hoc, su cui magari vertono anche specifici diritti legati alla proprietà intellettuale.
In questi casi, quando non è possibile modernizzare quello di cui già si dispone, e non ci sono sul mercato applicazioni off the shelf (pret a porter) l’unico passaggio adeguato per affrontare il futuro è quello di ri-architettare l’app (Re-Architect)
© RIPRODUZIONE RISERVATA
