L’esperienza di INAIL e il DevOps nella pubblica amministrazione

La complessità crescente delle infrastrutture digitali e l’adozione dei moderni pattern applicativi richiede l’adozione di nuovi approcci per governare il cambiamento, senza perdere di vista l’obiettivo: semplificare i servizi rivolti ai cittadini e aumentare l’efficienza della pubblica amministrazione.

In questo contesto, le metodologie Agile e le pratiche DevOps emergono come le soluzioni fondamentali proposte dall’ingegneria del software per gestire la complessità. Agile, per esempio, è molto più ragionevole del Waterfall, che invece è basato su una semplificazione della realtà, sul presupposto (sempre più infondato) che i requisiti dei sistemi non siano soggetti al cambiamento continuo, ma che si possano considerare stabili per un significativo lasso di tempo. Il DevOps a sua volta completa l’approccio Agile con quell’idea che si porta appresso di pensare fin da subito che un sistema (o servizio) ha tre stakeholder: chi lo sviluppa (Dev), chi lo usa (Cliente) e chi lo rende disponibile nel tempo su una infrastruttura (Ops).

L’infrastruttura poi è sempre più orientata a rendere disponibili risorse di elaborazione secondo il modello “Cloud”. I Cloud sono oramai percepiti come i nuovi “sistemi operativi” su cui si sviluppano i servizi ed è sempre più diffusa la consapevolezza che anche il parco applicativo legacy debba essere riscritto per il Cloud e non migrato sul Cloud.

DevOps nella pubblica amministrazione

Implementare DevOps in una pubblica amministrazione richiede una comprensione matura degli impatti organizzativi che ne conseguono. Spesso, il management desidera seguire le promesse del mercato e i bisogni di cittadini e imprese, ma non ha, non può avere, esperienza concreta riguardo ai “costi” che assecondare tali desideri comporta. Tale comprensione matura si sviluppa nel tempo, mentre si cambia e non prima di cambiare. Nel tempo i desideri astratti diventano possibilità concrete e richiedono scelte organizzative sempre più consapevoli e puntuali. Le amministrazioni, infatti, sono diverse l’una dall’altra ed è fondamentale che i desideri di cambiamento di ognuna si irrobustiscano e prendano la forma delle singole realtà in cui si vogliono applicare. Non si tratta di imitare ciò che fanno altri, ma di trovare un modo in cui, nella propria realtà, un desiderio astratto diventi possibile e utile.

La realtà di Inail

In Inail lo sviluppo (Dev) è delegato ad aziende fornitrici per mezzo di gare d’appalto periodiche. Il software viene sviluppato presso il fornitore e consegnato, come codice sorgente, a chi in Inail ha la responsabilità di renderlo disponibile come servizio ai suoi utilizzatori (Ops). Anche la conduzione infrastrutturale e applicativa è delegata ad aziende fornitrici per mezzo di gare d’appalto periodiche.

Il personale interno è assunto tramite concorso pubblico e l’approvvigionamento di tecnologie segue l’iter delle gare d’appalto. Questo contesto, sebbene complesso, è la realtà in cui noi oggi lavoriamo.

La piattaforma di delivery

Inail ha introdotto una piattaforma di delivery che consente a Dev di descrivere il software da rilasciare secondo formalismi che abilitino la gestione automatizzata dei rilasci dei suoi componenti su infrastrutture eterogenee, che abilitino il DevOps. La piattaforma consente una gestione strutturata dei rilasci ed è in grado di adeguarsi a futuri cambiamenti tecnologici introdotti dallo sviluppo e dall’utilizzo di nuove risorse di elaborazione.

Gli elementi di base che danno alla piattaforma gli strumenti per descrivere il software da rilasciare sono le blueprint, ossia file testuali in formato YAML che descrivono classi di prodotto istanziabili tramite la piattaforma di delivery. Dopo aver associato il software da rilasciare a una blueprint, il Dev si limita a dettagliarne i contenuti in piattaforma e ad associare i sorgenti che, accanto a tale descrizione, rendono possibile il DevOps.

La piattaforma di delivery consente poi di associare una release al software da rilasciare e si integra con i processi di accettazione, interfacciandosi con i sistemi di test management e gestendo i processi autorizzativi interni associati al rilascio.

La piattaforma, quindi, lavora gestendo un catalogo di blueprint e alimenta un catalogo di prodotti software generati e rilasciati a partire dalle blueprint definite a catalogo.

Il governo del cambiamento

Introdurre una nuova tecnologia o una nuova architettura applicativa richiede la definizione di nuove blueprint (o l’adeguamento di quelle esistenti) e poi la creazione degli automatismi necessari alla gestione del rilascio dei componenti previsti in tale blueprint. È un modo per governare il cambiamento dal punto di vista tecnologico, indirizzandolo verso modalità che lo rendano comprensibile e gestibile dalla piattaforma di delivery. Antonio Tommaso, responsabile DevOps e Cloud transformation: “Su questa base noi pensiamo di affrontare la complessità del cambiamento continuo, fornendo strumenti per gestire il futuro digitale di Inail”.