Sia che parliamo di applicazioni SaaS, web, mobile, microservizi, container o funzioni, le app sono tornate al centro della scena. Con le strategie di digital transformation che iniziano a produrre risultati tangibili stiamo, infatti, assistenza a una sorta di “rinascimento applicativo”.
Paradigmi, linguaggi, architetture e metodologie di sviluppo hanno attraversato diverse fasi di evoluzione, lasciando ai CIO un alto livello di complessità, spesso correlato alla legacy. Questo rappresenta una sfida soprattutto quando si devono gestire le richieste delle linee di business in un contesto in cui è necessario agire molto velocemente
Un’azienda è spesso un mondo estremamente complesso: business unit diverse, persone che operano in nazionalità diverse con diversi modelli di business, ognuno con il proprio insieme di requisiti. Tutto ciò comporta una varietà di software e di modelli di delivery davvero significativa sia che siano sviluppati in casa, sia che vengano acquistati in modalità off-the-shelf o SaaS, installati fisicamente, virtualizzati o utilizzati attraverso un browser o un dispositivo mobile. Le applicazioni aziendali sono un mondo difficile. E assorbono anche una parte significativa del budget IT.
La mappa di Citrix su sfide e opportunità per i CIO
Ecco perché Citrix ha messo a punto una sorta di “viaggio applicativo”, un modello in cui, in ciascuna fase, ogni CIO può riconoscersi e capire quali sono sfide le opportunità da affrontare e da cogliere. Prima di tutto, bisogna dire che questo modello non intende rappresentare un ciclo continuo né una sequenza di rigide cose da fare. È invece possibile che le categorie non siano così rigide e si sovrappongano, ma possiamo fare in ogni caso alcune osservazioni per ciascuna di esse.
RETIRE — Si tratta di una serie di iniziative spesso finalizzate a identificare e ritirare le tradizionali applicazioni legacy dal portfolio. Nelle grandi aziende accade spesso che esistano versioni multiple della stessa applicazione insieme ad applicazioni “orfane”, cioè che non abbiano un proprietario o non si capisce chi le abbia richieste o non siano più state allocate risorse di sviluppo su di esse. La maggior parte delle attività di ritiro hanno l’obiettivo di ridurre il rischio operazionale o il costo di continuare a far girare applicazioni non più a valore aggiunto.
REPLACE — Generalmente appannaggio delle linee di business, iniziative di questo tipo si basano spesso sull’identificare applicazioni off-the shelf, SaaS o, in alcuni casi, sviluppate in casa. Le app commerciali off-the shelf vengono spesso installate on-premise o su IaaS pubblico. L’obiettivo di questo tipo di operazioni è di solito la riduzione del gap tecnologico (e dei costi associati) e l’ottimizzazione del flusso di lavoro attraverso strumenti standard e non su misura.
RELOCATE — Una delle ragioni più sopravalutate ma anche meno capite per passare al cloud è migrare le applicazioni in modalità “lift and shift”. Note anche come Rehosting, questo tipo di iniziative sono appannaggio di pochi clienti che hanno la tecnologia abilitante per prendersi il rischio operazionale su IaaS pubblico, creando reti sicure e migrando come step finale i database.
RE-PLATFORM — Con le applicazioni legacy tradizionali può accadere che i componenti core sottostanti vengano ritirati da produttori e provider originali, anche se il ciclo di vita dell’applicazione non è concluso. Le iniziative di Re-platform vengono spesso eseguite “in-situ” (con l’obiettivo di ridurre al minimo il down-time ) e possono variare in termini di obiettivo e livello di complessità, includendo cambiamenti che permettono alle app a cui è stata cambiata piattaforma di funzionare ed essere operative su cloud pubblico ma mantenendo molti degli stessi componenti verticali e orizzontali da una prospettiva architetturale.
REBUILD — La maggior parte degli esempi di pratiche di rebuild si concentra sia sulla sostituzione di componenti esistenti, sia sulla realizzazione di semplici interfacce utente web con tecnologie nuove, per una migliore esperienza. Hanno l’obiettivo di modernizzare tecnologie web non più supportate o raggiungere un maggior numero di utenti o dispositivi.
RE-USE — Il Re-use è una strategia per le aziende che vogliono nuove esperienze utente creando uno strato di astrazione (di solito un costrutto API) tra il nuovo UX e il sistema esistente.
RE-ARCHITECT — Molti clienti hanno processi di lavoro che sono considerati proprietà intellettuale e sono supportati da applicazioni sviluppate da loro. I casi più comuni di Re-architect riguardano la modernizzazione e lo sviluppo di app per le quali non esistono alternative off the shelf, spesso reimmaginando l’intera tecnologia e le logiche di business a essa associate così come le regole e i flussi di lavoro.
