Intervista a Giovanni Chiappe, IT Strategy and Architecture, Agos Ducato.

Un’architettura in grado di rispondere alle mutate esigenze del business, sempre più scalabile, flessibile e dinamica, è oggi necessariamente un’architettura software-defined, come spiega Giovanni Chiappe, IT Strategy and Architecture di Agos Ducato, in questa intervista che riprende i contenuti del suo intervento durante il Digital Infrastructure Summit che si è svolto a Milano lo scorso 27 marzo 2019.

Nel vostro caso, quali erano le esigenze legate alla Trasformazione Digitale del business e come queste hanno impattato sull’architettura IT?

I nostri obiettivi erano avere un’architettura scalabile e flessibile, in grado di reagire al cambiamento e far fronte a nuove necessità quando queste si presentano. Ciò ha richiesto una profonda riflessione sul concetto stesso di infrastruttura: in Agos, abbiamo avviato una trasformazione da un elemento originariamente statico, per questioni di security e continuità del servizio, ad un elemento dinamico e leggero, in grado di essere portabile rispetto a vari modelli di deployment presenti nello scenario tecnologico. Nel nostro caso, pensare al sistema IT come confinato nelle 4 mura del datacenter era riduttivo: assistiamo oggi a nuovi modelli di delivery e gestione molto sfidanti rispetto a quelli tradizionali. La priorità è stata quindi quella di costruire una governance centralizzata per un’infrastruttura che necessariamente sarà decentralizzata, per i modelli e le tecnologie adottate.

Quale architettura avete disegnato per la nuova piattaforma digitale? quali gli elementi caratterizzanti?

L’architettura è a più livelli, di API esposition, di integration, e di business comprendendo nel disegno anche sistemi legacy. Importante è stato rivedere il concetto di security come trasversale a tutta l’infrastruttura. Inoltre, abbiamo un livello di gestione tale da verificare il comportamento del workload utente nei vari layer.  Questo per facilitare l’integrazione sia all’esterno di Agos sia all’interno, utilizzando Solution Building Block predefiniti (con capability pronte e integrate) per consentire uno sviluppo Agile delle soluzioni, facendo leva su aspetti centrali come automazione e scalabilità. Abbiamo considerato la security by design: rispetto ad architetture più tradizionali è stato importante impersonificare le chiamate ai servizi propagando le identità digitali sia degli utenti che delle applicazioni usate attraverso i vari layer.

Il vostro è un caso di realizzazione di una “Infrastructure-as-code”, la realizzazione e gestione dell’intera infrastruttura come un software. Quali sono gli elementi di dettaglio che oggi vi caratterizzano?

A livello di integrazione, si gestiscono eventi e dati provenienti dal front end (come la navigazione di un utente) o che sono originati dal back end. Il mainframe, componente che rimane core nella picture complessiva, è stato maggiormente integrato, migliorandone la sicurezza e la duttilità, introducendo capability in grado di esporre logiche Cobol come API da poter integrare agilmente in nuove applicazioni. Per il layer di security, ci siamo basati su standard e abbiamo integrato gli user repository aziendali.

In aggiunta, un’importante novità è la piattaforma di continuous configuration e automation che governa l’intera infrastruttura, e che è gestita nell’insieme attraverso codice, come da filosofia di Infrastructure-as-code appunto. Elemento base è il concetto di “stato”, che descrive il target di comportamento di un determinato aspetto dell’infrastruttura, che è arricchito di logica, ne gestisce i dati ed è applicato continuamente.  Con una gestione ciclica, questi stati sono applicati giornalmente e a fronte di eventi. Eventuali incident che si verificano possono originare bug, con cicli virtuosi di sviluppo e miglioramento dell’infrastruttura.

Quali sono state le conseguenze della scelta fatta?

Rispetto al pregresso di Agos, per cui parte della conoscenza era demandata ai partner a cui ci si appoggiava, oggi abbiamo un grosso insourcing della conoscenza sull’architettura, pur facendo leva sulle competenze e sulla scalabilità che i partner ci danno. Ciò ha consentito di avere un provisioning molto veloce in virtù dell’automazione, un’elevata affidabilità, la riproducibilità degli ambienti, quindi la possibilità di propagarne di complessi e con cardinalità elevata in termini di numero di nodi. Inoltre, riapplicare il software ci dà garanzia della sua qualità. Con riferimento al controllo del change, ogni cambiamento infrastrutturale viene oggi tracciato nella “storia” dell’infrastruttura, nei source repository dove teniamo traccia di tutti i cambiamenti fatti e della relativa documentazione.

Infine, portabilità dell’infrastruttura: i 4 elementi base di un software sono la logica, i dati (che servono a descrivere l’infrastruttura), template e librerie, ossia il software riutilizzabile. Tutto ciò ci ha permesso di realizzare un’architettura che può essere facilmente ricostruita from scratch in diversi contesti infrastrutturali, nelle 4 dimensioni fondamentali partendo ad esempio per la security da segmentazione e hardening fatto continuamente; per il livello applicativo da tutto il processo di continuous integration e delivery; per il layer tecnologico, facilità di installazione, upgrade e configuration management. Anche il sistema di monitoraggio e di log management (strumenti IT di observability che si appoggiano all’intelligenza artificiale e sono in grado di gestire metriche business, supportando le decisioni in tempo reale, con dashboard e viste specifiche) sono parte del disegno complessivo.

Quali raccomandazioni fareste a chi sta intraprendendo oggi questa strada? Quali sono i fattori di successo di un modello “Infrastructure-as-code”?

Bisogna progettare un modello dell’infrastruttura adeguato al contesto tecnologico e di servizio, il più possibile ampio e scalabile, per coprire tutte le casistiche di implementazione che si considerano e poter evolvere nel tempo. Deve essere aperto ma comunque basato su relazioni di partnership, tenendo però presente che il ruolo del partner cambia: si acquisisce maggiore conoscenza, che è trasferita nel codice dell’infrastruttura. La comunicazione efficace nell’organizzazione IT è un elemento fondamentale: bisogna evitare di fare troppi scatti in avanti e coinvolgere sempre tutte le aree. Infine, è necessario avere una strategia di adozione graduale: evitare “cattedrali nel deserto” e cercare di avere cicli di delivery che deliverano valore in tempo breve, giustificando gli investimenti.