Il modello strategico di evoluzione del sistema informativo della PA, previsto nel Piano Triennale per l’informatica nella pubblica amministrazione, stabilisce i principi architetturali di attuazione dell’Agenda Digitale ai quali le amministrazioni dovranno aderire attraverso un percorso di “convergenza”, di supporto all’innovazione dei servizi a cittadini ed imprese e alla razionalizzazione della spesa ICT nella pubblica amministrazione.
Sebbene il modello proceda da un punto di vista incentrato sulla domanda di servizi e quindi sulla evoluzione del “front-end” dei servizi digitali della pubblica amministrazione, si vede subito come il suo svolgimento richieda di allargare l’attenzione anche allo sviluppo dei sistemi informativi di “back-end”.
E soffermandoci sui sistemi di back –end alcune domande sorgono spontanee.
Come potranno i sistemi di back-end attuali sostenere l’accelerazione del carico di lavoro che passa da una velocità oggi dettata quasi esclusivamente da tempi “analogici” ad una velocità digitale?
Nel contesto futuro di servizi “digital first”, aperti alla multicanalità di accesso, in che modo i back-end attuali, così frammentati, articolati e disomogenei, potranno supportare con coerenza e adeguati livelli di servizio i canali tradizionali di accesso ai servizi ed i nuovi canali di accesso digitale?
E come ultima domanda, non meno importante, ci si chiede in che modo e con quali strumenti, gli impiegati ed i dirigenti della pubblica amministrazione, potranno essere motivati e quali saranno gli strumenti che gli consentiranno di sviluppare le competenze necessarie per svolgere il proprio lavoro, anche secondo nuove procedure native digitali?
E’ opportuno prepararsi ad affrontare un antico drago, un po’ particolare, che si presenta agli utenti ignari con il volto ingannevole di un’attraente sirena, ma che dietro nasconde i nemici di sempre dello sviluppo e dell’innovazione: la staticità ed il peso di sistemi e soluzioni legacy, misteriosamente affastellati, la difficoltà ed i rischi del cambiamento, la necessità di favorire la motivazione degli impiegati e dei dirigenti della pubblica amministrazione dotandole di strumenti adeguati, lo sforzo di mettere in campo le competenze progettuali, esecutive e soprattutto di governance strategica necessarie per riuscire a snellire il corpo del drago al pari di quello di una gentile sirena.
Ed è proprio la governance, che rende fattiva l’esecuzione dell’intero Piano Triennale, che merita un’attenzione particolare e richiederebbe, come già scritto in altro articolo dedicato specificatamente a questo tema, la messa in campo di almeno tre elementi chiave:
· la gestione unificata degli investimenti nella trasformazione digitale;
· il coordinamento con le amministrazioni, attraverso un’organizzazione dedicata al supporto nell’esecuzione della strategia di crescita digitale;
· l’attivazione di un modello multi-stakholder finalizzato a raccogliere e proporre soluzioni innovative.
In merito agli aspetti tecnologici, invece, si deve tener conto che il back-end delle amministrazioni presentano caratteristiche diversificate caratterizzate per lo più dalla presenza contemporanea di architetture e tecnologie legacy e di livelli diversi di maturità della digitalizzazione. Da questi diversi contesti dovranno nascere piani di sviluppo, convergenti nell’obiettivo, ma con risorse e percorsi diversi.
È tuttavia possibile individuare, prendendo come riferimento quanto indicato nel piano triennale, quali dovranno essere i requisiti minimi dei sistemi informatici di back–end delle amministrazioni oggetto di trasformazione.
– la convergenza con il modello strategico:
· clustering fisico delle infrastrutture materiali (efficienza di impianto, sicurezza, continuità operativa);
· integrazione applicativa e dati con le infrastrutture immateriali (SPID, ANPR, PagoPA, NoiPA, ecc.) ;
· interfacciamento con gli ecosistemi (domini applicativi verticali, a partire da Sanità digitale, Scuola digitale, Giustizia digitale, Turismo digitale, Agricoltura digitale, Smart cities & communities);
– la semplificazione dell’architettura dati ed applicativa dei sistemi informatici con l’obiettivo di eliminare i dati duplicati, usare i dati disponibili negli ecosistemi e nelle infrastrutture immateriali, disaccoppiare l’architettura dati dalle logiche applicative;
– l’adozione strutturale di “enterprise systems” declinati in ottica pubblica amministrazione, da condividere in un contesto multi-tenant all’interno dei cluster, o nel contesto delle infrastrutture immateriali;
– l’innovazione funzionale del workplace, in quanto elemento integrante del processo di digitalizzazione della pubblica amministrazione:
· delocalizzazione degli strumenti di lavoro e di conoscenza; supporto al lavoro agile;
· ampliamento della dotazione a supporto di nuovi modelli operativi (collaboration, knowledge sharing, individuazione esperti, supporto alla motivazione) e di relazione con gli utenti finali (approccio consulenziale, proattivo).
I sistemi legacy nella PA
L’uso di sistemi “legacy” nei data center delle pubbliche amministrazione è una pratica molto diffusa, soprattutto nelle amministrazioni di grandi dimensioni quali ad esempio INPS, INAIL e MEF che, negli anni 80 e fino al 2000, hanno investito molto nell’acquisizione di tali sistemi, soprattutto perché rispondevano adeguatamente alle necessità di potenza elaborativa richiesta dalle amministrazioni.
Pur garantendo affidabilità ed elevate prestazioni, questi sistemi, essendo costituiti da hardware e software strettamente connessi tra loro, di esclusiva proprietà di un singolo fornitore, come ad esempio i Mainframe IBM o piuttosto i sistemi elaborativi proprietari Unisys e Bull, comportano il rischio di essere vincolati all’offerta di un solo fornitore. L’evoluzione nel campo dei sistemi di elaborazione spinge, invece, verso architetture aperte, basate sul rispetto di standard tecnici condivisi, sulla compatibilità e l’interoperabilità di prodotti anche di fornitori diversi. In questo modo è possibile porre in competizione i vari fornitori, con ricadute positive sulla trasparenza del processo di acquisizione e sul contenimento dei costi. Al contrario, investire in sistemi legacy significa dover acquisire da un unico fornitore che, grazie all’assenza di competitor, si trova in una palese condizione di forza nelle negoziazioni e può imporre la propria politica commerciale, le proprie metriche e i propri prezzi ed, eventualmente, anche l’acquisto di dispositivi secondari, software o servizi professionali.
AgID, attraverso la sua l’attività istituzionale di rilascio dei pareri tecnici e anche tramite linee guida, circolari e informative ha provato a disincentivare le Amministrazioni dal potenziare i sistemi legacy, consigliando di dirottare le nuove esigenze di potenza elaborativa verso i sistemi aperti. Ha suggerito alle amministrazioni di ridurre o eliminare i lock-in tecnologici nei confronti di tecnologie proprietarie, soprattutto per conseguire una posizione più forte nelle negoziazioni con i fornitori e consentire l’apertura delle gare. Ha raccomandato l’uso di standard condivisi, sia tecnologici che architetturali. Ma nonostante gli sforzi, i risultati, sono stati poco soddisfacenti.
Molte amministrazioni continuano ad usare i sistemi legacy. Temono che eventuali interventi sui mainframe siano rischiosi per l’operatività delle applicazioni informatiche che funzionano da decenni e su cui nel tempo hanno investito somme importanti. Applicazioni di cui, spesso, non si ha un’informazione completa magari perché hanno subito innumerevoli interventi stratificati nel corso degli anni non adeguatamente documentati, il che comporta la perdita di controllo di uno degli asset più importanti delle amministrazioni, vale a dire il parco applicativo.
Le amministrazioni, molto spesso, basano le scelte di prodotti e tecnologie sul mero confronto tra i prezzi iniziali d’acquisto, e non svolgono alcuna analisi di TCO (Total Cost of Ownership) e di ROI (Return of Investiment) calcolato su una finestra temporale adeguata. Questo induce i fornitori ad offrire sconti convenienti per i primi acquisti delle loro tecnologie proprietarie, consapevoli di poter poi rientrare nei costi nelle successive forniture di rinnovi e manutenzione.
Non viene presa affatto in considerazione la possibilità di ottenere la necessaria potenza d’elaborazione ricorrendo a servizi IAAS o PAAS, l’uso in cloud di sistemi legacy (tradizionali o nuovi), infatti, con forme contrattuali opportune potrebbe ridurre in misura significativa i costi e i rischi di lock-in tecnologico.
Particolare rilevo ha, infine, la sentenza della Corte Europea del 3 luglio 2012 che ha sancito che i contratti di licenza d’uso (con cui tipicamente le PA si dotano di prodotti software) sono di fatto contratti di compravendita, per cui il cliente può “rivendere” a terzi le licenze che non usa più. Questo vuol dire che le amministrazioni, in caso di abbandono di una tecnologia proprietaria (es. il DBMS Oracle, l’ERP SAP, MS Exchange …) possono recuperare in parte gli investimenti pregressi vendendo come “software usato” le licenze dismesse. E’ come dire che le Amministrazioni non hanno più motivi per non migrare propri sistemi legacy. Peraltro, a fronte della forte indicazione del Governo per il contenimento della spesa corrente nello ICT del settore pubblico, la PA non può procrastinare ulteriormente la soluzione delle criticità connesse alla presenza dei sistemi legacy.
Ed è proprio per incentivare tale migrazione che viene illustrato di seguito il percorso evolutivo messo a punto da AgID, così che sia di riferimento per tutte le Amministrazioni che si auspica, a breve, attiveranno tale iniziativa.
Migrazione dei sistemi legacy – indicazioni operative
Il percorso evolutivo definito da AgID, raffigurato nella figura seguente, è composto da fasi (alcune necessarie, altre opzionali) da compiere in sequenza secondo una metodologia che verrà illustrata nel seguito.
Assessment
La prima fase consiste in una ricognizione/censimento dei sistemi legacy, volta a completare e/o aggiornare la conoscenza di tutto ciò che è presente su dette piattaforme. Il risultato di questa fase dovrà comprendere:
– il dettaglio tecnico dei sistemi in oggetto (elenco dei sottosistemi, consistenza e tipologia dei vari apparati che costituiscono l’infrastruttura, vincoli e criticità, software di base e middleware, compilatori, capacità dei sistemi e consumi rilevati);
– la ripartizione della potenza elaborativa tra i diversi ambienti (produzione, sviluppo, test, integrazione e collaudo);
– l’inventario delle applicazioni che operano sulla piattaforma legacy. Per ogni applicazione va rilevato il linguaggio di sviluppo, il grado di utilizzo da parte dell’utenza, la disponibilità/qualità della documentazione, la rilevanza/criticità dell’applicazione per i compiti istituzionali dell’amministrazione, le interconnessioni con altri sistemi, i vincoli di compatibilità, l’uso di componenti di elevata complessità (es. assembler);
– l’inventario degli archivi (DBMS e d’altro tipo) installati sulla piattaforma legacy. Vanno rilevate le relazioni tra archivi e applicazioni, le dipendenze reciproche, la qualità della documentazione disponibile, il grado di conoscenza da parte del personale interno e dei fornitori coinvolti nella gestione degli archivi stessi.
Dal punto di vista metodologico, è consigliabile coinvolgere nell’assessment le aziende che lavorano nei sistemi legacy dell’amministrazione, in quanto a volte detentrici prioritarie o addirittura esclusive di informazioni importanti. È opportuno anche includere – tra il personale dell’amministrazione da intervistare – contabili e amministrativi, in modo da avere un quadro non solo tecnologico ma anche economico/finanziario della situazione (costi ricorrenti legati alle varie componenti della piattaforma, grado di ammortamento, vincoli contrattuali, ecc.). Sempre con riferimento al personale interno da coinvolgere nelle attività di assessment, si raccomanda di definire con precisione ruoli e responsabilità, nonché di informare adeguatamente il personale sulle finalità dell’operazione in corso, anche per motivarlo a fornire supporto in modo proattivo.
Dal punto di vista tecnico, si segnala che esistono strumenti software che – ad esempio – effettuano automaticamente il censimento degli oggetti applicativi. Questi strumenti possono comprimere i tempi della fase di assessment, e minimizzare l’impatto di quest’ultimo sull’operatività dei sistemi legacy. È evidente che occorre consentire a questi strumenti di accedere ai moduli sorgente nonché alle basi dati da censire, secondo politiche di sicurezza da definire accuratamente.
Dal punto di vista economico/finanziario, occorre tener conto non solo dei costi di acquisizione e manutenzione che sono facilmente documentabili, ma occorre stimare anche i costi nascosti causati dalla rigidità dei sistemi legacy, rigidità che impedisce alle amministrazioni pubbliche di rispondere con la dovuta velocità ai bisogni della società, introducendo ritardi che generano impatti e costi che vanno ben oltre i costi tecnici facilmente documentabili.
Scelta e pianificazione degli interventi
In questa fase si analizzano, alla luce dei risultati della fase precedente, le varie opzioni possibili, scegliendo il percorso progettuale più adeguato al contesto e anche alla strategia complessiva dell’amministrazione, secondo quanto illustrato nella figura che segue.
I risultati della fase precedente vengono adoperati, in questa fase, per individuare:
– le aree di intervento prioritario, e quelle che invece possono essere “aggredite” solo in un secondo tempo;
– le migliori opportunità di contenimento dei costi, anche sotto l’aspetto finanziario;
– le criticità più significative, i rischi di progetto;
– la tempistica più aderente a vincoli di contesto, la stima dell’impegno e della spesa di ogni singolo intervento.
Consolidamento
Si tratta di un intervento mirato a ridurre la complessità della situazione “as is” sui sistemi legacy, per consentire successivamente una più agevole migrazione delle applicazioni e delle basi di dati. Sono interventi di consolidamento l’eliminazione di sistemi e linguaggi obsoleti che hanno un costo di licenza significativo, o l’accorpamento di basi dati sulla piattaforma legacy.
Nel percorso progettuale illustrato in figura 1, si tratta di un passo opzionale, da compiersi se l’assessment ha identificato aree specifiche su cui intervenire in consolidamento.
Re-hosting
Per re-hosting si intende lo spostamento – da sistemi legacy ad aperti – delle applicazioni attuali, senza modificarle. Ciò si ottiene tramite sistemi software detti TP-Monitor in grado di emulare CICS, IMS, Batch/JES ed in grado di operare sulle piattaforme aperte “target”. Il re-hosting è un intervento che può essere portato a termine in tempi brevi, ed è utile anche per “scaricare” le piattaforme legacy, riducendo il carico di lavoro con riflessi positivi anche sui costi di licenza (che sono legati ai MIPS/MSU).
Si tratta in genere di un intervento intermedio, propedeutico a successive riscritture di codice. Esperienze in ambito bancario (le banche sono grandi utenti di legacy) suggeriscono che progetti di re-hosting limitati ad ambiti applicativi per cui il re-hosting ha senso (in termini soprattutto di potenza elaborativa) consentono risparmi che possono essere poi investiti in successivi progetti di trasformazione/re-engineering delle applicazioni. In alcuni casi, il re-hosting può essere visto come passo utile ad aggredire e “sbloccare” una situazione complessa che non è immediatamente risolvibile con un unico progetto di migrazione.
Il vantaggio principale del re-hosting è il tempo progettuale, che può essere estremamente ridotto: anche in Italia ci sono aziende specializzate in questo tipo di intervento, che detengono expertise e metodologie consolidate per minimizzare il rischio e l’impatto sulla operatività delle applicazioni.
C’è ovviamente bisogno, per un re-hosting, della disponibilità di potenza elaborativa adeguata nella piattaforma target. Ciò comporta, in molti casi, la necessità di acquistare hardware. Esperienze in ambito bancario hanno portato alla equivalenza di massima “un core = 60-80 MIPS”, con risparmi particolarmente importanti.
Si parla di re-hosting anche nel passaggio di basi dati tra sistemi legacy ad aperti (es. da VSAM a RDBMS), anche se – in questi casi – l’intervento può avere complessità maggiore, e comportare la necessità di acquisto di licenze d’uso del prodotto target. E’ importante in ogni caso che sia possibile evolvere quanto migrato attraverso tecnologia Open, cercando di non rimanere legati comunque a tecnologie, linguaggi e architetture che rimangono legacy pur girando su hardware open. Ad esempio è importante che sia possibile evolvere o integrare quanto migrato con linguaggi aperti come Java, come pure eseguire il deployment su sistemi open virtualizzati o addirittura su Docker (esistono TP-Monitor che eseguono codice Cobol e Java su Docker), permettendo così l’apertura verso modalità di sviluppo moderne ed addirittura verso lo sfruttamento della tecnologia Cloud.
Riscrittura applicativa
Questo intervento prevede la riscrittura, parziale o completa, del software applicativo che allo stato risiede sui sistemi legacy. Può essere opportuno in situazioni:
– dove l’amministrazione intenda sfruttare il “momento di discontinuità” anche per far evolvere il proprio parco software in termini di efficienza e prestazioni;
– in situazioni di difficile manutenzione delle applicazioni attuali (caso già citato dei programmatori Cobol sempre più rari);
– per la impossibilità di sfruttare nuove tecnologie e modalità di sviluppo Agile, Dev-Ops e Cloud;
– quando cambi normativi o di “mission” istituzionale dell’amministrazione rende comunque necessario intervenire modificando/incrementando le funzionalità attuali del parco software.
Si tratta chiaramente di un intervento complesso, che necessita di un impegno e di un tempo adeguato. Ove l’assessment individui aree applicative “circoscritte”, con un buon grado di isolamento rispetto al resto del parco software, si può procedere gradualmente intervenendo prima su tali aree e poi sul resto. Se invece l’assessment ha rilevato vincoli e interdipendenze estese tra le varie aree applicative, un intervento di tipo “big bang” risulta più indicato. Talvolta al posto di una riscrittura applicativa “custom” può essere vantaggioso eseguire la migrazione applicativa verso una applicazione “pacchettizzata” acquistata da un fornitore di mercato o da un’altra amministrazione, o addirittura erogata da un ente terzo in modalità SaaS (Software As A Service).
Dismissione del sistema
L’ultima fase consiste nella dismissione del sistema legacy. Essa si effettuerà al termine di un periodo di parallelo, e dopo il collaudo delle applicazioni che sono state migrate – attraverso i passi precedenti – sull’ambiente target.
Anche in questo caso, è possibile portare avanti l’intervento in modo graduale, riducendo progressivamente la piattaforma legacy fino alla completa eliminazione.
È bene ricordare che anche la potenza elaborativa della piattaforma target può essere acquisita non solo comprando fisicamente nuovo hardware on premise, ma utilizzando servizi cloud di tipo IAAS o PAAS.
Conclusioni
Per concludere qualche riflessione in ordine ai motivi per i quali ci si trova ancora in questa situazione e qualche suggerimento per come evitare di trovarsi in difficoltà nella fase di cambiamento.
Tipicamente le applicazioni sviluppate nei sistemi Mainframe sono estremamente “intrecciate” tra di loro ed uno dei motivi per cui storicamente si è fatta molta fatica ad eseguire progetti anche solo di rehosting è la difficoltà di “spezzare” il progetto in parti distinte ed indipendenti mentre l’approccio a “big bang” viene in genere ritenuto troppo rischioso.
Per questo, assieme agli strumenti di migrazione del codice e dei dati, è importante curare la comunicazione tra quello che si è già “rehosted” e quanto è rimasto all’interno del Mainframe, valutando la possibilità di dotarsi di tecnologie che permettano l’integrazione transazionale in “two-face-commit”, come pure strumenti che permettano di integrare code di esecuzione batch interne ed esterne al Mainframe all’interno dello stesso grafo di schedulazione.
Deve essere valutata la possibilità anche di dotarsi di strumenti di integrazione delle basi di dati, tali da permettere alle procedure migrate fuori dal Mainframe di continuare ad accedere in modo trasparente a porzioni di basi di dati che risiedono ancora all’interno del Mainframe, e viceversa.
Altro tema importante è la qualità del “rehosting”. Su questo punto va fatta una serie riflessione. Da un lato il vantaggio economico è indubbiamente significativo ma dobbiamo tener conto che se ad esempio il codice COBOL migrato rimane lo stesso, come pure ad esempio i batch JCL, la migrazione risulta più facile ma i vantaggi funzionali che ne derivano potrebbero risultare limitati, perché viene mantenuta tutta la rigidità di quelle tecnologie come pure i costi di manutenzione legati anche alla carenza di nuovo personale competente.
Oggi potrebbe essere possibile migrare applicazioni legacy verso tecnologie più moderne ed aperte, ad esempio eseguendo migrazioni automatizzate verso il linguaggio Java per le applicazioni on-line e verso lo scripting di shell per i processi batch.
Un tale approccio, se da un lato viene visto con favore per i vantaggi di innovazione che porta e inoltre permette da quel momento in poi di evolvere il sistema sfruttando le moderne tecnologie aperte, dall’altro può mettere in difficoltà la forza lavoro ancora abituata a lavorare sulle vecchie tecnologie, creando non pochi problemi di natura sindacale, per cui in alcuni casi si potrebbe mantenere attivo un processo di migrazione “automatica”, in modo tale da permettere ad alcuni tecnici e sviluppatori di continuare ad esercire e manutenere il sistema aperto come se fosse ancora su Mainframe (ad esempio sviluppando in COBOL che poi viene automaticamente tradotto in Java in fase di costruzione del codice).
Altro tema che potrebbe risultare genericamente sottovalutato è la capacità di scalare e di essere affidabile del sistema “rehosted”. Infatti se è vero che i microprocessori degli ambienti aperti (tipicamente Intel) sono molto potenti, è anche vero che la maggior parte dei TP Monitor disponibili in ambiente open sono nati come ambienti di emulazione dei TP Monitor Mainframe come CICS o IMS, e di conseguenza non scalano oltre una certa soglia (spesso attorno ai 5k MIPS) mantenendo un adeguato livello di alta affidabilità.
Infine, spesso a tecniche di “rehosting” vengono affiancate tecniche di “offloading” dei dati, soprattutto di quei sistemi legacy che sono esposti all’accesso del pubblico attraverso servizi on-line web o mobili.
Si tratta sostanzialmente di evitare che i servizi on-line vengano sviluppati come “passacarte” che trasmettono in modo sincrono al back-end Mainframe tutte le richieste ricevute. Viene a questo proposito costruito un “cuscinetto applicativo” che protegge il mainframe dagli “urti” provocati dai picchi di utilizzo utente che per loro natura non sono predicibili, ipotizzando ad esempio che gli accessi in sola lettura vengano risolti senza nessuna richiesta al Mainframe, lasciando a quest’ultimo il ruolo di gestire in maniera privilegiata i servizi “core” per evitare potenziali disservizi durante i picchi di accesso on-line.
Concludendo, l’iniziativa in questione non appare di semplice realizzazione, il percorso è denso di rischi, ma comporta vantaggi sia dal punto di vista economico che da quello di gestione di grande impatto. Solo per dare un’idea del perimetro dell’iniziativa, la PA nella sua interezza centrale e locale, per tutti i sistemi di natura proprietaria (IBM, Oracle, SAP, Microsoft,etc..) ha un indotto di spesa complessiva stimabile in almeno 300 milioni di euro all’anno che rappresentano un capitale aggredibile per traguardare obiettivi di efficientamento dei sistemi verso soluzioni aperte di mercato la cui valorizzazione va ben oltre la mera riduzione della spesa corrente anche del 50%.
AgID è disponibile ad affiancare le amministrazioni in questo intricato percorso per aiutarle nella trasformazione del Drago nella Sirena, consentendole così di nuotare libera nel mare aperto delle soluzioni di mercato.
