Si parla di DevOps con Mirko Gubian, Global Demand Senior Manager di Axiante - Business Innovation Integrator al fianco delle aziende nella trasformazione digitale. La nuova metodologia operativa per lo sviluppo applicativo trova ancora resistenze all’interno delle aziende strutturate con team interni a disposizione. Allo stesso tempo, però, chi ha scelto il cambio di paradigma si sta mostrando più veloce e concreto nel cogliere nuove opportunità di business. E anche tra le startup e le aziende di piccole e medie dimensioni senza team interni, il DevOps può mostrare tutto il suo valore. In questo caso, partner come Axiante giocano un ruolo fondamentale nell’accompagnarle verso la necessaria application modernization.

“L’approccio DevOps – spiega Mirko – porta degli indubbi vantaggi, non tanto dal punto di vista tecnico ma da quello del business. Il primo è ben noto e riguarda la riduzione del TCO. Utilizzare tecnologie obsolete (legacy) spesso richiede l'accesso a risorse esterne. Parlo di persone con competenze specifiche che diventano sempre più rare e più costose. E questa dipendenza spesso è dannosa per il business. Il secondo aspetto da considerare è strategico. Parlo della flessibilità e della velocità con cui è possibile modificare un'applicazione modernamente strutturata”.

Rispetto agli obiettivi dell’application modernization, attualmente le richieste delle aziende riguardano soprattutto il lift & shift. “È un primo approccio utile a prendere dimestichezza con le potenzialità del modello DevOps – prosegue il manager. Chi, invece, ha già dimestichezza, invece, intraprende un vero e proprio percorso cloud native, cimentandosi in una vera e propria attività di rebuild e replace, con l'obiettivo di modernizzare le applicazioni e dare valore aggiunto alla propria azienda”.

Le resistenze ad abbracciare il paradigma DevOps

Tutto bellissimo, insomma, sulla carta. Ma poi ci si scontra con una certa resistenza. “Spesso manca la necessaria cultura aziendale sul tema DevOps e su ciò che riguarda il rapporto tra lo sviluppo e la gestione delle applicazioni - prosegue il manager. Sappiamo che nel modello “tradizionale” lo sviluppo e le operations hanno obiettivi diversi. Il team di sviluppo deve fornire nuove funzionalità il più rapidamente possibile. L'obiettivo è la velocità. Mentre il team di gestione dell'applicazione ha tradizionalmente un altro obiettivo, la stabilità del sistema. Ed è logico che i due team sono in contrapposizione. E a ogni cambiamento corrisponde un rischio di instabilità. Più velocemente si cambia, più si rischia di introdurre nuovi problemi all'interno dell'applicazione. Si tratta di un tema di cultura aziendale, perché dipende da come si misurano i due team. Lo sviluppo dalla velocità di rilascio, quello delle operations sulla stabilità del sistema”.

E, dunque, che fare? “Prima fra tutte è necessario coinvolgere le risorse di business (il management) – spiega Mirko -. l'Application Modernization non deve essere fine a sé stessa, ma deve essere frutto di un ragionamento sui vantaggi che porta al business. Perché l'Application Modernization può essere una grande occasione per rivedere tutti i processi aziendali”.

“Detto questo – prosegue il manager - oltre al business si devono individuare e coinvolgere in un vero e proprio progetto di management chi fa sviluppo e chi gestisce le operations. Nel DevOps, sviluppo e gestione dell'applicazione avvengono nello stesso ambiente e non vi devono essere più confini retti. In altri termine, non c'è più un confine fra gli sviluppatori e gli amministratori di sistema. L'obiettivo del team di DevOps deve essere di affrontare velocemente nuove sfide, di aggiungere funzionalità e sviluppare rapidamente nuove applicazioni, garantendo al contempo stabilità e scalabilità dell'applicazione. Questo paradigma si può applicare sia in contesti nuovi che in contesti già esistenti. Per questo, per prima cosa è necessario promuovere una nuova cultura. E non è facile, perché in molte realtà esiste una situazione a dir poco conflittuale fra chi è responsabile dello sviluppo e chi è responsabile dell'infrastruttura o della sicurezza”.

Rompere le barriere dipartimentali, agire a livello culturale

“In definitiva - conclude Mirko -, si devono riuscire a rompere queste barriere dipartimentali, costruite da anni. Per farlo si devono creare uno o più gruppi di lavoro multidisciplinari e chi li coordina deve essere super partes. Conviene fissare obiettivi precisi alle persone coinvolte e bisogna chiarire fin da subito che il fallimento non è accettato come azione. La condivisione di intenti, l’azione sull’aspetto culturale può avvenire anche in corso d’opera, mentre si costruiscono le metodologie”.

“Di strumenti, ne esistono tantissimi. Sta ai gruppi di lavoro, e a chi li supervisiona, scegliere metodi e strumenti più adeguati in ogni fase. Su questo è necessario demandare ai team la scelta dei tool e i processi da mettere in atto. Perché i team di DevOps, anche esterni all’azienda, hanno tutte le competenze per scegliere gli strumenti migliori da utilizzare”.