Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Il business value del paradigma DevOps

pittogramma Zerouno

Il business value del paradigma DevOps

16 Gen 2013

di Nicoletta Boldrini

La ricerca di ‘agilità’ del business passa anche dalla dinamicità ed elasticità con cui si sviluppano e rilasciano le applicazioni software. Il nuovo paradigma DevOps garantisce quell’agilità, dall’ideazione al rilascio applicativo, che consente di migliorare la capacità dell’It nel rispondere alle esigenze di business. Ne abbiamo parlato con Riccardo Sanna, Hp Software Application Practice Manager di Hp EMEA.

Con il termine DevOps, si intende definire un nuovo paradigma che coinvolge le figure professionali di sviluppatori e It operations all’interno di un nuovo modello di collaborazione finalizzato ad un più rapido ed efficace rilascio delle applicazioni software. Questo modello propone una metodologia grazie alla quale si creano dei legami tra queste due 'professioni’, attraverso forme di collaborazione più efficaci che portano a nuove metodologie di sviluppo e rilascio delle applicazioni. Per capire meglio di cosa si tratta, abbiamo incontrato Riccardo Sanna, Hp Software Application Practice Manager di Hp Emea, che esordisce subito precisando come “il termine DevOps, in realtà, identifica una stretta integrazione/collaborazione non solo tra sviluppatori e sistemisti ma anche con altre figure importanti che hanno un peso specifico all’interno dell’intero ciclo di vita delle applicazioni: parliamo di coloro che si occupano della quality assurance, di coloro che sono deputati alle fasi di testing, ma anche di altre It operations come gli  amministrazione della rete e dei database”.

Riccardo Sanna, Hp Software Application Pratice Manager di Hp Emea

“Ciò che introduce questo nuovo paradigma è un modello collaborativo che fino a qualche anno fa, senza le ultime innovazioni tecnologiche quali la virtualizzazione, il cloud, il social netowrking, la mobility, non sarebbe stato possibile”, commenta Sanna. “L’approccio metodologico mira a rimuovere i ‘colli di bottiglia’ dell'It e a ridurre così quella complessità che negli ultimi decenni ha frenato la velocità di innovazione delle imprese”.

È infatti nella velocità di risposta del business, nella miglior capacità competitiva grazie al rilascio più veloce dei servizi It a supporto del business che vanno ricercati i veri vantaggi del nuovo paradigma. “L'intero ciclo di sviluppo software ha subìto una notevole accelerazione spinto proprio da esigenze di velocità, dinamicità e flessibilità del business”, spiega Sanna. “Tale accelerazione non deve però diventare sinonimo di scarsa qualità e di inefficienza, perché i ‘danni’ sarebbero ‘letali’ sia per il dipartimento It sia per l’organizzazione di business stessa. Ed è qui che entra in gioco il paradigma DevOps, che propone tecniche e metodologie finalizzate all'ottimizzazione dell'efficienza dei processi iterativi e all'automazione di tutte quelle attività ripetitive che ‘consumano’ tempo”.

Stiamo parlando di un approccio piuttosto nuovo, quindi c’è ancora molta confusione attorno al tema. “Ovviamente, il primo passo è sempre quello dell’assessment. Bisogna ‘osservare’ il proprio portfolio It (inteso sia come tecnologie sia come modello organizzativo e di processo) per capire e stabilire se sia opportuno applicare la capacità delle soluzioni DevOps”, spiega Sanna. “Le soluzioni risultano efficaci se il modello organizzativo alla base, improntato su collaborazione spinta, automazione e replica dei processi, è efficace e condiviso”.

Un cambio importante, quindi, che coinvolge tutto l’It, in particolare, ovviamente, gli skill specifici nell’ambito dello sviluppo applicativo: “Il modello DevOps richiede ai team interni di non ragionare come sviluppatori, personale operativo, responsabili della quality assurance o della protezione/sicurezza del software , ma come ‘progettisti di soluzioni’ che collaborano con un obiettivo finale che non è tecnologico ma di business”, precisa meglio Sanna. “L'apporto essenziale dei membri dei team inizia nelle prime fasi di progettazione e si concentra su un solo obiettivo durante lo sviluppo, i test e il rilascio Con le nuove tecnologie è possibile automatizzare quelle procedure, come il rilascio delle applicazioni, che sono continua fonte di ritardi, ed in ultima analisi, di rischio per il business”.

Per molte aziende, si tratta di un cambiamento culturale enorme, ma i risultati possono essere davvero importanti: “i difetti del codice, per esempio, possono essere rilevati in una fase preliminare del processo di sviluppo, i rischi legati al progetto sono ridotti al minimo e il team risponde più rapidamente alle priorità aziendali in evoluzione”, aggiunge ancora Sanna.

Per creare questo tipo di collaborazione, si può partire ‘semplicemente’ con l'utilizzo di strumenti di diagnosi delle prestazioni comuni (da parte di sviluppatori e team operativi), la condivisione con gli altri team degli script di prestazioni usati, per esempio, dai responsabili della qualità software, in modo che le It operations non ne creino altri ma vi sia comunanza di strumenti e condivisione di viste e risultati; infine, è possibile iniziare a impostare ‘modelli collaborativi’ attraverso l'utilizzo di strumenti basati su social media per abilitare discussioni e scambi di idee/progetti/soluzioni tra i team.

Nicoletta Boldrini

Giornalista

Articolo 1 di 4