Per diffondere in azienda la cultura DevOps, fondamentale per tradurre sul piano operativo le tematiche di application modernization, bisogna prima di ogni altra cosa chiarire quali sono le esigenze e gli obiettivi del business, coinvolgendo nel progetto di trasformazione l’intera popolazione aziendale. Se queste metodologie vengono affrontate esclusivamente come argomento ad appannaggio dei soli professionisti dell’IT, infatti, non riceveranno mai la giusta considerazione. E i processi, di conseguenza, non riusciranno a generare i risultati attesi.
I vantaggi del DevOps, sul piano teorico, sono ormai noti a tutti gli addetti lavori: il primo e più evidente riguarda la capacità delle applicazioni di sostenere in modo corretto i processi di business, riducendo il Total cost of ownership ed evitando le spese per il coinvolgimento di risorse e competenze esterne, tipiche della manutenzione di tecnologie obsolete. Il secondo attiene alla sfera tattica, che in certi casi può estendersi fino a coprire l’ambito strategico: la cultura DevOps porta infatti a sviluppare flessibilità e velocità di reazione quando si tratta di modificare (o creare ex novo) processi che rispondano alle nuove esigenze del mercato, minimizzando o eliminando del tutto l’impatto della trasformazione sui sistemi.
Ecco perché alcuni progetti DevOps rischiano di fallire
«Eppure ancora molte aziende falliscono nell’implementazione di questi progetti», spiega Mirko Gubian, Global Demand Senior Manager di Axiante, specialista delle soluzioni per la digitalizzazione del business.
Who's Who
Mirko Gubian
Global Demand Senior Manager di Axiante
«Il motivo? Troppo spesso processi e tecnologie vengono calati dall’alto, senza considerare che le persone hanno una loro storia, sono abituate a lavorare in un certo modo e non è certo stravolgendo le abitudini dall’oggi al domani che lo faranno meglio. In altre parole, non ci deve essere una imposizione, ma un trasferimento di cultura che tenga anche conto dei due grandi gruppi di lavoro che di solito operano intorno alle applicazioni dal punto di vista tecnico: chi le sviluppa e chi poi le mantiene up-to-date. Il che significa imparare a coniugare velocità e stabilità, facendo collimare obiettivi e metriche di due team che tradizionalmente adottano parametri diversi per definire l’efficienza e l’efficacia della propria attività. Creare gruppi di lavoro multidisciplinari, dalle figure Sales e Presales, passando per i referenti di Project Management, analisi funzionale e design tecnico, fino ad arrivare agli sviluppatori e ai responsabili delle Operations, permette di abbattere le barriere tra le due squadre e ottenere vantaggi comuni per il business».
Se Gubian si esprime così è perché la sua stessa azienda, Axiante, ha scelto di intraprendere un percorso di trasformazione interna, evolvendosi da classico system integrator a business innovation integrator. «D’altronde è comprensibile: quando si approcciano queste tematiche in molti casi ci si trova di fronte muri dipartimentali che somigliano a vere e proprie barricate, e ognuno è abituato a lavorare per silos e per fasi, utilizzando strumenti che non consentono di vedere oltre la propria scrivania. Condividendo invece la cultura del DevOps a tutti i livelli, ciascuna azienda può dotarsi di una roadmap peculiare, stabilita dalle stesse persone che poi dovranno lavorare nel nuovo contesto operativo».
La componente tecnologica arriva dunque solo in un secondo momento, quando le premesse metodologiche, validate dai responsabili di business e dagli owner di processo, vengono condivise anche con il personale tecnico, in modo che non si riscontrino incongruenze nei momenti più delicati della messa in produzione del progetto. Durante la quale, l’organizzazione nel complesso dovrà orchestrare la trasformazione in maniera agile. «Si tratta di un altro prerequisito, indispensabile per gestire correttamente le pratiche DevOps», aggiunge Gubian. «Affrontarle con i modelli organizzativi tradizionali, infatti, equivale a montare una bella carrozzeria sul telaio di una vecchia macchina: potrà sembrare à la page, ma di certo non correrà più veloce. E nemmeno andrà lontano, visto che una volta entrati nella dimensione digitale, il cambiamento diventa una costante per il futuro».
Non bisogna naturalmente dimenticare l’elemento (in realtà “il pilastro”, tiene a precisare Gubian) della sicurezza. «Continuo a sentir parlare di DevOps, ma in realtà da diverso tempo sarebbe più corretto usare il termine DevSecOps, il quale include anche tutti gli aspetti di security che non possono mancare all’interno delle applicazioni sviluppate in un ambiente cloud e che costituiscono ancora uno dei principali mal di pancia degli IT manager».
L’approccio di Axiante alla application modernization
Passando dalla teoria alla pratica, Axiante ha recentemente messo in atto questa filosofia realizzando un progetto di application modernization per un cliente attivo nella distribuzione moderna. «Si trattava di ampliare le funzionalità di una applicazione legacy sviluppata secondo i criteri tradizionali della GDO, e per questo particolarmente ingessata, al punto che non era possibile aggiungere ulteriori moduli», racconta Gubian. «Ciononostante, la richiesta del cliente era precisa: il software non andava riscritto e sostituito, ma semplicemente potenziato. Come abbiamo trovato la soluzione a questo paradosso? Ci siamo seduti insieme a un tavolo multidisciplinare, coinvolgendo anche il business e decidendo di operare in due fasi. È stato stabilito di creare una applicazione ex novo che fungesse da interfaccia nei confronti del software legacy e che consentisse di introdurre risorse su cui le nuove tecnologie potessero lavorare. Una volta realizzata l’interfaccia, durante la fase due è stata abilitata la possibilità di aggiungere funzionalità in modalità agile e con un approccio incrementale». La piccola attesa dovuta al primo step ha quindi permesso di abbattere notevolmente lo sforzo progettuale, visto che lo strato costruito sopra la vecchia applicazione, sulla quale transitano ancora tutti i dati di processo, lavora completamente in ottica DevOps.
«È questa la caratteristica principale di Axiante», rimarca Gubian: «l’approccio customer-centric. Ogni cliente porta problemi nuovi e diversi, e noi li affrontiamo, anche investendo nostre risorse per individuare soluzioni e metodologie innovative che poi siamo in grado di condividere e declinare in altri use case. Alla base di questa filosofia c’è comunque sempre l’idea di porci nei confronti dei nostri interlocutori con la massima trasparenza. Anche nel momento in cui gli studi preliminari sono a carico nostro, il cliente è libero di decidere se procedere con noi o meno, persino quando presentiamo proposte per ridisegnare i processi interni. Pensiamo sia fondamentale, in un contesto di mercato in cui molte organizzazioni temono il lock-in tecnologico, rassicurare le imprese sul fatto che rivolgersi ad Axiante garantisce totale libertà e autonomia: e per dimostrarlo non ci limitiamo a utilizzare tecnologie standard e interoperabili, ma applichiamo un modello di ingaggio che per il 90% è legato al risultato finale, e soprattutto al successo del progetto. È così che si crea vero valore sia per noi sia per i nostri clienti».
