Intervista a Maurizio Irlando, Responsabile Software Architectures and Shared Digital Plaftforms di TIM.

Le organizzazioni odierne sono alle prese con una domanda crescente di servizi proveniente specialmente da canali digitali, caratterizzata da volumi significativi di accessi in tempi molto concentrati (picchi di carico). Quali sono oggi le componenti tecnologiche e di processo, o organizzative, basilari per passare a nuovi modelli di sviluppo, basati su Agile, container, devops, microservizi? il tema racchiude numerose complessità, ma è possibile individuare un percorso ottimale, come chiarisce nel seguente articolo Maurizio Irlando, Responsabile Software Architectures and Shared Digital Plaftforms di TIM, ripreso dal suo intervento nel corso del “Digital Infrastructure Summit” di The Innovation Group dello scorso 27 marzo 2019.

Ormai da qualche anno si riscontra il forte impegno delle Aziende appartenenti alle diverse Industry  in programmi più o meno estesi di “trasformazione digitale”: è lecito chiedersi il perché un’Azienda del Lusso o che semplicemente produce capi di abbigliamento decida di inserire tra le priorità la trasformazione delle proprie architetture informatiche e delle modalità con cui le utilizza, nonostante il core business sia diverso.

La presenza di aziende “digital native”, detti anche OTT, ormai nella totalità dei settori merceologici, sia come provider diretti di beni e servizi, sia come piattaforme di aggregazione di domanda e offerta (esempi ormai classici: Uber per le esigenze di trasporto personale, AirB&B per la ricerca di accomodation) ha determinato un profondo cambiamento delle regole del Business e nel comportamento dei Clienti.

Questi ultimi si mostrano ormai abituati dai Big Digital Players a ottenere (quasi) tutto, in tempi ridotti, spesso gratis (ovvero: in cambio di una più o meno consapevole cessione di proprie informazioni) e con una experience gradevole.

Ciò ha determinato un mutamento radicale delle aspettative anche quando approcciano i canali di contatto di una Azienda “tradizionale”. La sfida quindi non risiede tanto nella sorgente della domanda (il canale), ma dalla peculiarità della stessa: è una domanda “nervosa”, che richiede tempi di soddisfacimento certi e ridotti, che l’esperienza di interazione sia continua e anche appagante (“wow” experience) e che in caso di insoddisfazione genera rigetto e perdita del cliente, pronto a cambiare.

Considerando il tema dei volumi, citato sopra, accanto alla concentrazione degli stessi in tempi ridotti (il cosiddetto “effetto campagna”), è da tenere presente la impredicibilità delle variazioni dei volumi di richieste, che mette in discussione tutti i modelli di capacity management infrastrutturale classici, più o meno statici.

Per continuare quindi a giocare un ruolo primario nella arena competitiva del Digitale, occorre fornire costantemente ai Clienti con aspettative allineate ai modelli dei Player digital native, una ragione per spendere il loro tempo e denaro con noi.

Non si deve dare per scontata la fedeltà dei Clienti, adoperandosi invece per conquistarla ogni giorno, attraverso:

• Continua evoluzione, innovazione e personalizzazione di prodotto (velocità, economie di scala, personalizzazione).
• Fruizione intuitiva (il “costo di fruizione” deve essere sempre minore del valore percepito).
• Continuità di esperienza nella transizione da un canale all’altro (omnicanalità e convergenza).
• Performance e continuità di servizio delle applicazioni e delle piattaforme preposte alla loro erogazione. Resilienza ai carichi imprevisti.

Il problema nasce quando le Aziende “tradizionali” e con una lunga storia alle spalle hanno valutato la propria capacità oggettiva di inseguire il mutato Mercato mettendo in gioco rapidità di cambiamento ed efficienza.  Le architetture informatiche sono risultate non pronte a soddisfare i nuovi requisiti di Business orientati alla convergenza e alla persona, al continuous improvement di prodotto, alle iniziative d’impulso utili a monetizzare trend spesso transitori.

Stratificazioni successive o giustapposizione di tecnologie al servizio di un mercato storicamente segmentato per canale e cluster di clientela, hanno generato una picture architetturale che rende costosa, lenta e produttrice di debito tecnico la realizzazione di offerte e use cases incentrati sulla persona e sulla continuità di esperienza al variare del canale.

Questo è il motivo della necessità di una trasformazione tecnologica talmente radicale da introdurre altri tipi di discontinuità, sulle competenze necessarie, sui processi interni, sui modelli di sourcing (forniture e partnership).

Si parla di Digital Transformation perché l’obiettivo è la generazione e lo sviluppo di revenue del nuovo “Digital Customer”.

Dal punto di vista realizzativo per cogliere questi obiettivi è necessario progettare e agire una sorta di “Internal Transformation”, un programma di azioni tali per cui l’Azienda passa coscientemente attraverso una fase di revisione delle sue modalità di creazione di valore per il  cliente in cui rinuncia a ritenere validi i suoi modelli operativi tradizionali, propedeutica alla sua rifondazione in termini di strumenti di conoscenza, processivi, organizzativi, di regole di interlavoro tra reparti.

Una volta chiarita la relazione tra cambiamento del Mercato, revisione degli obiettivi di Business e impatto su pratiche e architetture tecnologiche, si passa al problema successivo: quali strumenti e modelli adottare, da quali driver farsi guidare nella scelta e – soprattutto – come gestire la transizione per utilizzarli in maniera matura e senza incontrare ostacoli interni.

Per il fatto che l’obiettivo trasformativo ultimo è la acquisizione di FLESSIBILITA’ nelle architetture e nei processi produttivi, l’abilitatore tecnologico principale è l’utilizzo pervasivo (in special modo nei processi core) del SOFTWARE e dei nuovi  modelli operativi ad esso associati.

Per Aziende che progettano, sviluppano applicazioni (sia allo scopo di proporle sul Mercato sia per utilizzo interno), i processi core da velocizzare ed efficientare sono principalmente:

• Il ciclo di sviluppo, test, e modifiche successive delle applicazioni (Development),
• Il relativo Deployment (ossia il rilascio sugli ambienti di test e produzione),
• Il Delivery delle piattaforme di erogazione.

I modelli e le tecnologie “software defined” che agilizzano e rendono questi processi rispondenti alle aspettative digital si riflettono in:

• Sviluppo del codice componentizzato e con accoppiamento/dipendenza lasca o nulla tra le componenti (Microservizi e sviluppo in paradigma cloud native).
• Automazione dei cicli di test e rilascio delle applicazioni: CI/CD (Continuous Integration, Continuous Delivery).
• Piattaforme governate da un Software Orchestrator in grado di aggiungere o rilasciare risorse virtualizzate di piattaforma a seconda delle fluttuazioni dei volumi di accesso. Container Platforms e PaaS (Platform as a Service).

Un’applicazione realizzata a componenti disaccoppiati consente di sviluppare una richiesta evolutiva isolando le componenti interessate, modificarle e rilasciarle senza impiegare tempo in lunghi test di regressione, quindi consente di acquisire velocità a minor costo.

Automatizzare i cicli di rilascio significa aumentare la velocità ma anche guadagnare in ripetibilità e qualità dei processi.

Scrivere il codice in maniera tale da assecondare la capacità delle moderne piattaforme di scalare in base alla richiesta conferisce resilienza e affidabilità nei confronti di accessi impulsivi e molto variabili nel tempo (ad esempio, a seguito di promozioni limitate nel tempo).

Vanno quindi cambiati gli approcci (processi e strumenti) allo sviluppo delle applicazioni, orientati tradizionalmente a rilasci molto cadenzati, figli di requisiti documentali corposi e dalla lunga gestazione, all’origine di prodotti dalla scalabilità non sempre facile e garantita.

È necessario studiare i nuovi linguaggi, imparare a gestire le nuove piattaforme (versatili ma aventi peculiarità più vicine al mondo delle applicazioni che non delle infrastrutture), capire a quale contesto organizzativo affidare questa gestione che richiede competenze quanto meno diverse da quelle possedute dai tradizionali gruppi di Operations. Alla bisogna, occorre pensare a nuclei organizzativi ad hoc e a come cambiano di conseguenza le mimiche con cui si relazionano i vari dipartimenti, in modo che sia sempre chiaro chi deve fare cosa, attivato da quali eventi o persone, ecc…

In un contesto IT (o tecnologico in genere) costituito da centinaia o migliaia di addetti preposti al governo di mappe applicative di cardinalità e criticità di business significativa, erogate in una molteplicità di Data Center, attuare un cambiamento simile non è semplice. Nel seguito alcune best practices derivate da esperienze di successo.

Obiettivi della Trasformazione: il suggerimento principale è partire da una definizione chiara e quantitativa di cosa si voglia ottenere e in quali tempi dal processo di trasformazione, in termini di impatto positivo sul business: percentuale obiettivo  di incremento delle vendite, percentuale di riduzione del Time to Market, percentuale di configurazioni rispetto a sviluppi sul totale rilasci annui … sono alcuni esempi.

Strategia/path di trasformazione: step successivo, è efficace che derivi dalla visione chiara sugli obiettivi e sui tempi. In questa fase si stabilisce come (in termini di azioni e tempi) si intende avvicinare la ideale curva delle effettive capacità di reazione dei comparti tecnologici a quella delle aspettative del business.

Digital/Architectural principles: sono i modelli che vengono selezionati dal tipo di strategia adottata e che dovranno ispirare tutti i progetti realizzativi del programma di trasformazione. Si stabilisce ad esempio che le applicazioni nuove vanno sviluppate a microservizi, si decide se continuare a utilizzare una logica orchestrata (con la presenza ad es. di un BPM) piuttosto che passare a una logica coreografata, disaccoppiando processi e dati, con quali pattern gestire i dati che hanno una diversa “temperatura” (rilevanza per il business e probabilità/frequenza di accesso). Esempi sono la applicazione di strategie di Data Readiness e Data Preparation. Ed altri.

Linee Guida Operative: vanno predisposte e presidiate come manuali operativi della trasformazione, supportano e allineano la progettazione degli stream esecutivi ai principi architetturali.

Solution Selection: attività di comparazione di piattaforme e soluzioni (principalmente) software ispirate ai principi e linee guida architetturali stabiliti,  che conducono alla determinazione e successivo approvvigionamento degli abilitatori tecnologici (“right tools for right jobs”). Il tutto in armonia con le strategie di spending dell’Azienda sulla natura software e con quanto già eventualmente presente e utilizzabile nel software porftolio aziendale, che può trarre dalla trasformazione importanti opportunità di modernizzazione e reshaping economico.

In un successivo articolo si parlerà di come sia necessario presidiare in maniera unitaria l’attuazione ordinata di queste best practices, l’adozione dei nuovi paradigmi digital e come preparare l’intero contesto Aziendale ad accogliere con spirito costruttivo il cambiamento (in alcuni casi la disruption) digitale, evitando e gestendo le possibili cause di resistenza.

Sarà data anche evidenza della roadmap di TIM e di come gli obiettivi siano stati poi ottenuti.