Una delle maggiori paure per le aziende che pensano di passare all’application modernization è quella di rimanere vincolate ad un unico fornitore trovandosi in una posizione di dipendenza. Per questo oggi è importante più che mai far comprendere appieno alle imprese che cos’è in concreto la modernizzazione delle applicazioni e soprattutto far capire loro che la flessibilità non solo è possibile, ma garantita.
LineaEDP.it ha parlato con Mirko Gubian, Global Demand Senior Manager di Axiante, busines innovation integrator globale a valore aggiunto, per capire in cosa consiste davvero l’application modernization e per creare cultura sul tema di modo che le aziende possano essere traghettate serenamente verso questo tipo di modello.
Si tratta infatti proprio di una questione di cultura: delle giuste pratiche, della giusta metodologia di lavoro e solo in un secondo momento dell’adozione della tecnologia più adeguata alle esigenze del cliente.
Modernizzare le applicazioni legacy è un percorso necessario da compiere per completare la trasformazione digitale ed è una priorità strategica delle aziende per poter competere nel mondo di oggi. Quali sono i vantaggi?
“I benefici per un’impresa che decide di modernizzare le proprie applicazioni sono innanzitutto economici in termini di Total Cost of Ownership (TCO) perché se non si modernizzano le applicazioni le aziende affrontano un costo che invece non si ha se si decide di dare il via a un percorso di application modernization. Molte ricerche dimostrano che modernizzare un’applicazione riduce il costo di ownership dell’applicazione stessa.
Un altro aspetto da evidenziare è anche quello legato al fatto che disporre di applicazioni che utilizzano tecnologie obsolete richiede l’accesso a risorse e consulenti esterni, con il rischio che più la tecnologia diventa ‘vecchia’ e più sarà difficile trovare competenze specifiche sul mercato per quella determinata tecnologia. Il rischio è quello che si venga a creare una dipendenza tra l’azienda che detiene un’applicazione legacy basata su tecnologie obsolete e chi dispone di quelle poche risorse che consentono di lavorare su quell’applicazione. Spesso, quando si parla di costo della trasformazione, non si sottolinea in maniera adeguata che non evolversi ha un costo di dipendenza esplicita da risorse che diventano sempre più scarse”.
Un secondo vantaggio è più legato al business. Spiegaci meglio…
“Il secondo vantaggio dell’application modernization fa riferimento a una dimensione strategica, perché la modernizzazione delle applicazioni consente di fronteggiare anche scenari di incertezza come quello che stiamo vivendo, donando flessibilità e velocità nel far evolvere un’applicazione a seconda delle esigenze del momento contingente. L’agilità con cui l’azienda riesce a introdurre nuove funzionalità o addirittura a cambiare radicalmente alcuni funzionamenti, perché cambiano i processi che l’applicazione va a coprire, è uno dei vantaggi all’inizio meno tangibili ma senza dubbio più importanti che il processo di modernizzazione porta con sé”.
Per molte aziende modernizzare le applicazioni si traduce nel trasferimento dei carichi di lavoro esistenti su nuove piattaforme più innovative e nella partizione delle applicazioni monolitiche in microservizi più piccoli, anche se vedremo che la questione non è tutta qui. Ma iniziamo a capire quali sono le tecnologie chiave per la modernizzazione delle applicazioni…
“Prima di parlare di tecnologie occorre parlare di pratiche: l’impostazione verso applicazioni cloud native e tutto ciò che ne deriva sono oggi la chiave per la modernizzazione.
Lato tecnologia mi riferisco invece più specificatamente alle tecnologie abilitanti, cioè al mondo dei container e tutto quel che ruota loro attorno.
Le tecnologie principali fanno quindi riferimento ai container come Docker o Kubernetes e i relativi mondi per orchestrarle e a tutta la parte dell’Infrastructure-as-code (IaC) che aiuta ad automatizzare, stabilizzare e mantenere la piattaforma su cui girano le applicazioni”.
La tecnologia da sola però non basta perché contemporaneamente occorre anche adottare nuove metodologie di lavoro, come il DevOps. Perché modernizzare le applicazioni è un processo che va al di là della scelta dei giusti tool tecnologici?
“La domanda da porsi sempre all’inizio, anche prima di pensare alla tecnologia più giusta, è quali siano i veri vantaggi per il business: una domanda in realtà molto complessa a cui si risponde fissando gli obiettivi del business, settando le aspettative legate alla modernizzazione e stabilendo un budget per raggiungere tali obiettivi.
Una volta fatto questo, diventa tutto una questione di metodo: le metodologie moderne come quelle di DevOps devono essere prima conosciute e padroneggiate e solo dopo si vanno a tarare sulle tecnologie specifiche, con le quali occorre avere la giusta dimestichezza. Motivo per cui è necessario anche procedere con una formazione continua delle risorse”.
Che cos’è il DevOps?
“DevOps è un vero e proprio paradigma culturale che rientra nell’ambito di sviluppo e gestione delle applicazioni ma non solo. Nel modello tradizionale il team di sviluppo (chi si occupa di sviluppare, modificare o aggiungere funzionalità) e il team delle Operations (che si occupa della gestione dell’infrastruttura e della gestione dell’applicazione una volta che questa è stata implementata) hanno sempre avuto due obiettivi diversi.
La parte di sviluppo ha sempre avuto l’obiettivo di fornire velocemente funzionalità, perché il business ne ha chiaramente bisogno, mentre la parte di Operations ha un fine contrapposto, cioè quello della stabilità del sistema: una volta messa live, l’applicazione deve funzionare senza dare problemi e senza creare malfunzionamenti.
È logico che i due team, se visti come separati, sono in contrapposizione, perché ogni volta che il sistema viene cambiato per introdurre una nuova funzionalità cresce il rischio che venga generata instabilità. Inoltre, più velocemente cambio il sistema e più velocemente rischio di introdurre problemi nella gestione delle applicazioni”.
Partendo da queste premesse, che vede i due reparti storicamente in contrapposizione, perché il problema di modernizzare le applicazioni è soprattutto un problema culturale?
“Si tratta di un tema di cultura perché l’application modernization dipende sì dal team di sviluppo e di Operations, che sono stati sempre in contrasto perché in contrasto erano i loro obiettivi, ma dipende oggi soprattutto da come il management misura questi due team e la qualità del loro lavoro. Se il management continua a misurare il team di sviluppo sulla base della velocità di delivery delle applicazioni e il team di Operations in base a quanto il sistema è stabile, il processo di modernizzazione è destinato a fallire. Perciò il problema prima che dal punto di vista tecnico va affrontato sotto il profilo culturale”.
Qual è il primo step?
“Il primo passo da fare è quello di far evolvere la cultura aziendale nella concezione dei due team, ripensandoli come un unico soggetto. Cambiare mentalità è difficile perché molto spesso esiste un rapporto anche conflittuale tra i due team e quindi lavorare per fare questo salto di mentalità è un passaggio cruciale”.
Gli step successivi?
“Per abbattere la barriera tra le due squadre occorre creare gruppi di lavoro multidisciplinari per la diffusione della cultura e lo stesso coordinatore dell’iniziativa deve essere super partes e non parteggiare per nessuno dei due team”.
Cosa significa diffondere la giusta cultura?
“Diffondere la cultura significa lavorare per far capire che questa nuova metodologia porta dei vantaggi di business, ma anche personali. Quando è raggiunto il cambio culturale si passa a parlare di metodologie e solo a questo punto emergono le caratteristiche proprie di ciascuna azienda che portano alla costruzione di un processo di DevOps ad hoc e personalizzato a seconda delle esigenze”.
Torniamo ai nostri step per intraprendere un corretto percorso di modernizzazione…
“Una volta diffusa in maniera trasversale la cultura, dopo che il team di DevOps ha capito di essere un team unico, è necessario che questo team si coordini per comprendere qual è il processo di DevOps su cui vuole lavorare.
Una volta stabilito questo è ovvio che le persone che lavorano su quel processo, che si presuppone siano formate adeguatamente e abbiano assorbito questa cultura, devono scegliere quelli che sono gli strumenti tipici di DevOps.
La scelta tecnologica, quindi, viene dal basso solo nel momento in cui è stato fatto un lavoro per abbattere le barriere culturali, presupponendo poi la presenza di personale tecnico formato e adeguatamente skillato. Importante coinvolgere nel team anche gli esperti di sicurezza, una tematica che, come sappiamo, oggi è sempre più all’ordine del giorno”.
Axiante come supporta le aziende in questo processo?
“Seguendo la logica di cui ho parlato fino a questo momento, la prima cosa su cui va a lavorare Axiante è l’aspetto di formazione. Anche Axiante non è nata in un mondo cloud native e quindi cerca di replicare il percorso che ha affrontato in prima persona partendo con la formazione sulle metodologie e dando ormai per assodato che la base culturale è stata trasmessa e assimilata. Una volta completata la formazione sulle metodologie, si passa alla tecnologia con investimenti forti in formazione per avere a disposizione risorse che padroneggino in maniera adeguata queste tecnologie.
Nel momento in cui Axiante si trova a dover fornire soluzioni ai suoi clienti, conformemente al suo metodo, ha introdotto la metodologia agile e un progetto di sviluppo coerente. Come conseguenza si ha l’abbattimento delle barriere con un rilascio continuo di funzionalità ogni due settimane, avendo un sistema stabile e testato e disponendo di tutto ciò che dà sicurezza e stabilità, ma che al contempo regala flessibilità e garantisce un’evoluzione.
Questo è ciò che Axiante fa quando i clienti le chiedono di realizzare o cambiare pezzi di applicazioni che già hanno in uso”.
Qual è il valore aggiunto di Axiante?
“Axiante è un system integrator e questo presuppone l’integrazione tra sistemi e la realizzazione di applicazioni, ma il nostro principale valore aggiunto è quello di saper lavorare per integrare gruppi di lavoro.
Quando si parla di application modernization i clienti hanno numerose perplessità nella scelta di un partner perché di fronte a uno sviluppo custom il cliente ha timore di dover poi dipendere da quel partner. Una delle grandi diversità di Axiante è che se il cliente lo vuole non deve necessariamente dipendere da Axiante”.
Come funziona?
“Axiante coinvolge il cliente lavorando sulla promozione della cultura fin dalla fase progettuale, individuando il personale che il cliente mette a disposizione con l’obiettivo di trasmettergli sia la cultura di cui parlavamo sia le competenze in ambito DevOps.
In questo senso siamo un integratore di team e non di sistemi: facciamo sì che il nostro team sia integrato con quello del cliente di modo che il cliente abbia sempre il controllo delle attività e del processo lasciando poi la possibilità, alla fine di un processo di application modernization, di internalizzare il processo con le risorse che abbiamo formato oppure di scegliere se usare quelle risorse solo per il controllo dell’esecuzione e andare a proseguire il percorso con Axiante o ancora con un qualsiasi altro fornitore.
Questa libertà che noi vogliamo per i nostri clienti, senza andare a vincolarli, è un modello vincente. Se il cliente vuole, continua ad affidare ad Axiante la gestione dell’applicazione che ha realizzato, ma se il cliente non vuole o ha una politica di insource o di outsource particolare, è libero di muoversi senza alcun vincolo.
Altra cosa che contraddistingue Axiante sono i suoi modelli di ingaggio. Prediligiamo infatti un modello di ingaggio chiavi in mano: il nostro obiettivo non è creare dipendenza presso il cliente ma dargli valore aggiunto”.
Parlavamo prima della resistenza culturale tipica delle aziende ad andare verso questo tipo di modelli e metodologie: le imprese italiane sono mature e quali sono i vertical più ricettivi? A che punto siamo?
“Axiante opera in diversi settori e non abbiamo individuato un vertical più ricettivo di un altro: il tema della consapevolezza della maturità è sempre legato alle persone.
Mi riferisco in particolare all’It Manager, che generalmente è la figura che ha l’onere di far entrare il cambiamento in azienda: ne esistono di molto propensi al cambiamento così come di meno propensi e attenzione perché questo dipende comunque dalle esperienze pregresse.
Come accennavo, c’è una paura molto forte quando si parla di application modernization o di sviluppo custom ed è il timore di andare a creare un vincolo di dipendenza col fornitore. Credo quindi che Axiante, così come i suoi competitor, debbano lavorare per togliere questo vincolo.
È chiaro che anche noi di Axiante miriamo a stabilire un rapporto di continuità con il cliente, ma il rapporto deve essere scelto da entrambi e va rinnovato di volta in volta: non deve esserci un vincolo che lega l’uno all’altro in un rapporto di necessarietà.
Quello che spesso gli It Manager meno ricettivi non comprendono è che l’application modernization lavora proprio nella direzione contraria ai loro timori, per dare maggiore flessibilità al business. Il che si traduce in maggiori opportunità, mantenendo il controllo dei processi e riuscendo a padroneggiare le tematiche di DevOps, per poi riuscire a presidiare in maniera corretta e consapevole quello che i fornitori (system integrator o software house) vanno a fare presso di loro.
Se un It Manager capisce che riesce a mantenere il controllo sulle applicazioni e poi demanda a un system integrator/software house la realizzazione delle applicazioni passando tranquillamente da un fornitore all’altro, questo It Manager può procedere sereno nel processo di modernizzazione”.
Per concludere, quali sono gli obiettivi di Axiante a breve – medio termine sulla parte di application modernization?
“Obiettivo interno di Axiante è quello di continuare a far crescere il team digital per poter seguire il numero crescente di richieste che stanno arrivando dal mercato. Abbiamo un team corposo, ma molto del suo tempo è impiegato in formazione: motivo per cui, volendo mantenere un elevato standard qualitativo e volendo continuare a formare in maniera massiccia, dobbiamo investire per continuare a far crescere la nostra squadra.
Per quello che riguarda il mercato, invece, il primo obiettivo è quello di far crescere la cultura DevOps e dell’application modernization. C’è molto da fare e se la cultura si diffonde la conseguenza naturale sarà quella dell’instaurarsi di un rapporto win-win tra chi si occupa di system integration e le aziende”.
