La PA al centro di un ecosistema digitale per cambiare l’Italia

Il primo approccio all’adozione di un modello di cooperazione applicativa nasce dallo studio di fattibilità della Rete Unitaria della PA (RUPA) del 1995 dove vengono individuati tre strati di sistema:

• Trasporto
• Interoperabilità
• Cooperazione applicativa

Mentre sui primi due livelli si è operato tempestivamente (l’AIPA ha bandito la gara nel 1998 per assegnare rispettivamente lo strato del Trasporto a Telecom Italia e quello dell’Interoperabilità a EDS), non è stato dato seguito in quegli anni al terzo strato, quello della Cooperazione applicativa, in quanto, già all’interno della stessa Autorità, albergavano visioni differenti per le soluzioni da adottare.

Semplificando al massimo in AIPA convivevano tre approcci.

1) L’adozione di standard internazionali come Corba e DCOM orientati a dare delle regole per consentire alle amministrazioni di realizzare in autonomia applicazioni all’interno del proprio dominio, lasciando alle porte di dominio standardizzate e alla busta di e-Gov il metodo per definire un’interfaccia e il formato dati da adottare per lo scambio applicativo.

2) Un approccio molto pratico basato sull’idea che ogni progetto trasversale (il sistema delle Anagrafi, Il SAIA, il SUAP, Il SIAP, ecc.), costituisse un sistema di cooperazione a se stante e “proprietario” che non necessitava, come avviene nella maggior parte dei casi, di colloquiare con gli altri. Tanti “standard” invece di uno.

3) L’altra tendenza cercava di portare avanti un modello di cooperazione di tipo gerarchico (simile a quello adottato in quel periodo dalla SIA). Un sistema di Governo centrale che adottasse una serie di black-box presso le porte di dominio di ogni amministrazione che consentissero alle diverse amministrazioni di cooperare in base a progetti specifici da attivare su tale modello.

Negli anni successivi fino all’avvento del SPCcoop del 2006 non sono mai state imposte decisioni tecniche in tal senso lasciando libertà alle amministrazioni e agli attori del mercato di settore di scegliere la soluzione ritenuta più adeguata. Ciò ha prodotto un panorama variegato di soluzioni che ha favorito i desideri di autonomia di alcuni soggetti pubblici e privati abdicando come Stato centrale, almeno in parte, al disposto dell’art. 117 comma 2 lettera r) della Costituzione.

Nel 2001, prendendo spunto dal modello inglese, il Centro Tecnico dell’AIPA individua nella busta di e-Government, lo standard da adottare per il formato dati della Cooperazione applicativa in merito alla quale si cercano contributi attuando le politiche di cofinanziamento per l’e-Government sui fondi ex-UMTS (circa 800 miliardi delle vecchie lire stanziati anche sui sistemi di cooperazione), senza però una Governance tecnica di tali fondi che orientasse le soluzioni architetturali verso una visione unitaria del sistema cooperativo, producendo così scarsi risultati.

Parallelamente sul fronte delle Reti pubbliche, a seguito dell’avvio della RUPA che veniva vista dalle Regioni come un’imposizione del Governo centrale, veniva proposta (per essere poi abbandonata definitivamente) l’idea della Rete Nazionale di cui allo specifico Decreto Bassanini (circa 20 NAP regionali uno per Regione in una logica di replica della rete VPN auto-motive ANX). Nasce quindi, cercando la condivisione di tutti gli stakeholder (regioni, province comuni, mondo accademico, associazioni di categoria), l’iniziativa del Sistema Pubblico di Connettività e della Rete internazionale della PA (DLGS 28 febbraio 2005).

Queste due ultime iniziative vivevano, al contrario dei fondi per l’e-Government stanziati per le regioni, di fondi di gran lunga inferiori (più di un ordine di grandezza in meno rispetto ai bandi di e-Government) e hanno prodotto risultati molto più tangibili con la gara multi fornitore per la Connettività e la Sicurezza (SPConn) e con il modello di Cooperazione Applicativa (SPCoop).

Un sistema centrale (SICA) che rappresentava il cuore dell’Architettura con il registro dei servizi di Cooperazione, con la disponibilità di servizi di sicurezza applicativa e di identificazione federata, con il catalogo delle Ontologie e con il registro degli accordi di servizio. A livello decentrato, ogni dominio di amministrazione aveva a disposizione un modello di porta di dominio da realizzare secondo gli standard predefiniti e la busta di e-Gov per il formato dati da scambiare nel sistema di cooperazione.

In Europa si stavano affermando modelli architetturali di cooperazione applicativa per i servizi di e-Government. Dal modello inglese (e-GIF, Government Interoperability Framework) basato sui Web Services e successivamente sugli Open Data, si passava al modello tedesco (SAGA, Standards und Architekturen für e-Government) orientato alla SOA, per essere integrati nel 2011 nel quadro generale fornito dall’IDABC Interoperable Delivery of Pan-European e-Government Service to Public Administrations, Business and Citizens) e consistente nello EIF (European Interoperability Framework), progetto internazionale nato con lo scopo di fornire una piattaforma di cooperazione comune agli Stati membri.

Cnipa, DigitPA e successivamente Consip hanno bandito e gestito le gare ed i contratti per la realizzazione del SPCconn e del SPCcoop. Tuttavia, tale modello di cooperazione è stato applicato in maniera puntuale soltanto da alcune regioni attraverso il programma ICAR e da qualche altro caso sporadico della PA centrale. Sono stati inseriti a listino servizi che avrebbero dovuto costituire elementi abilitanti per lo sviluppo del Sistema, ma invece di realizzare sistemi coerenti con il modello SPCcoop le Amministrazioni hanno acquisito function point per la realizzazione e manutenzione dei propri servizi e sistemi applicativi. La situazione attuale del contesto normativo con la conversione in legge del DL 83/2012 ha previsto il passaggio dall’Agenzia per l’Italia Digitale a Consip della responsabilità di fatto di progettare e bandire le nuove gare SPC che, almeno per quanto riguarda la connettività, ha ripercorso i vecchi paradigmi, senza che venisse effettuata una necessaria revisione del modello architetturale dell’intero sistema verso un nuovo scenario.

Evoluzione verso un ecosistema digitale

L’evidente arretratezza del nostro Paese rispetto ai parametri di diffusione della digitalizzazione a livello europeo richiede un momento di riflessione per poter ridisegnare un percorso virtuoso che porti l’Italia almeno tra i primi dieci paesi nella classifica europea e non al 25esimo posto su 28 come risulta oggi dai sistemi di metrica adottati (DESI). La PA finora ha realizzato sistemi dedicati per supportare le proprie iniziative digitalizzando il processo burocratico esistente, senza invece reingegnerizzarlo ripensandolo in ottica digitale e senza porre particolare attenzione, né alle esigenze del cittadino, né ai trend di mercato ed al livello di attrattività e di utilizzo delle piattaforme rese disponibili. Quando la tendenza era quella di condividere le infrastrutture, la PA ha realizzato sistemi dedicati per la PA stessa. Si pensi alla Rete della PA, la Rupa, alla mail della PA (la CEC PAC), alle applicazioni specifiche per la PA, ai sistemi trasversali dedicati, ecc. Ciò ha portato alla proliferazione dei siti web pubblici (oltre 50.0000 attivi), mentre i cittadini e le imprese che interagiscono con la PA devono adeguarsi alle differenti interfacce e servizi offerti dalle PA, causando l’effetto negativo di disaffezione e mancanza di utilizzo verso detti sistemi. Parallelamente l’Italia però è tra i primi paesi in Europa nell’utilizzo della tecnologia mobile e dei Social Networks; segno che l’italiano comunque non è lontano dalla tecnologia.

Forse sarebbe opportuno ripensare ai modelli di erogazione dei servizi pubblici tenendo conto di questa tendenza e prendendo spunto da altri che si sono già orientati in questa direzione, come ad esempio la città di San Francisco. Questa città ha realizzato un’applicazione Facebook che consente l’adozione di un modello architetturale a due livelli: la parte dei dati gestita dall’Amministrazione in una logica Linked Open Data, e la componente delle App realizzate dal mercato interfacciandosi con le API messe a disposizione dall’Amministrazione stessa. In questo scenario per sviluppare un dialogo efficace tra cittadini, imprese e amministrazioni pubbliche non è più sufficiente quindi ricorrere alla sola interoperabilità delle banche dati e alla realizzazione di un modello di cooperazione applicativa, ma è necessario intervenire almeno in tre direzioni.

1) La Rete. Accelerare l’attuazione del piano Banda Ultra Larga cercando di individuare soluzioni per le reti pubbliche in linea con l’iniziativa del Governo. Il Sistema Pubblico di Connettività è l’infrastruttura nazionale della PA che dovrebbe rappresentare anche il volano per la crescita e la diffusione della Banda Ultra Larga nel Paese. La gara SPC2 bandita da Consip ha riproposto invece la stessa struttura della gara aggiudicata dal Cnipa nel 2006 senza tener conto dell’apporto che il piano strategico per la diffusione della Banda Ultra Larga avrebbe potuto fornire al soddisfacimento della sempre crescente domanda di capacità di banda da parte delle Amministrazioni pubbliche. Ad esempio, un ipotetico modello per coniugare la strategia BUL e le esigenze di connettività della PA si potrebbe basare su tre livelli di intervento: il primo livello è l’infrastruttura di “rete di accesso della PA” ultrabroadband a più di 100 Mbps estesa a tutto il territorio nazionale, incluse le aree C e D dei cluster BUL a fallimento di mercato. Il secondo livello (Data Plane) è costituito dagli apparati necessari per l’instradamento di rete al livello protocollare IP; questo strato potrebbe anche essere gestito da una società inhouse pubblica. Il terzo livello è l’intelligenza di rete: networking e security, articolato secondo i principi dell’architettura Software Defined Network (SDN) che disaccoppia il Data Plane dai piani di controllo e di management e che prevede l’esecuzione delle logiche più complesse (algoritmi di routing, load balancing, security, ecc.). Questo ultimo strato potrebbe essere affidato mediante gara ad un Consorzio costituito da operatori italiani di TLC fornitori di servizi alle Amministrazioni. Un tale consorzio potrebbe ispirarsi alla forma giuridica e allo statuto dell’attuale QXN.

2) I Servizi. Riclassificare i servizi pubblici per filiere di interesse sociale per soddisfare al meglio la domanda del cittadino ponendolo al centro rispetto al ruolo servente della PA. Tale riclassificazione è analoga a quella effettuata da OECD, che costituisce il modello adottato nella maggior parte dei paesi europei e che Formez, nel caso italiano, ha cosi rappresentato.

3) l’Ecosistema digitale. Ipotizzare un ecosistema digitale della PA (il mercato e i cittadini) che preveda un disaccoppiamento tra il back-end ed il front- end dei sistemi informativi pubblici, una rappresentazione delle basi dati secondo il paradigma dei Linked Open Data, e la pubblicazione di API certificate sulle quali lasciar costruire al mercato un ecosistema di App che consentano la fruizione dei servizi pubblici al cittadino identificato tramite il Sistema Pubblico di Identità Digitale (SPID). In questo contesto, la cooperazione applicativa diventa un ulteriore elemento di vincolo rispetto ai vincoli già esistenti dei sistemi informatici. L’elemento centrale dello scenario ipotizzato è rappresentato dall’introduzione di una Piattaforma Digitale sicura (grazie anche allo SPID) che permetterebbe di:

1. creare un ecosistema di Aziende, Enti, Sviluppatori, Fornitori di Servizi, Fornitori di Applicazioni, in grado di sviluppare applicazioni sempre più innovative e utili per i cittadini, con le stesse tecnologie con cui oggi vengono costruite applicazioni che utilizzano servizi di Google,
2. disaccoppiare e proteggere i sistemi legacy delle singole Amministrazioni che non saranno chiamati ad interagire direttamente con l’esterno in queste nuove forme, ma saranno intermediati dalla piattaforma,
3. sfruttare nuove tecnologie e best practice come Mobility e Cloud in modo aperto ed integrato, ma senza costringere le singole Amministrazioni ad investimenti cospicui ed all’utilizzo di tecnologie lontane dalla cultura della maggior parte degli enti pubblici e dei loro tipici fornitori.

L’ecosistema applicativo necessita di una “community” di utilizzatori attivi, che vanno sostenuti ed incentivati nell’adottare le API esposte per sviluppare le loro soluzioni applicative per l’erogazione di servizi pubblici nuovi. Queste community devono anche essere “ascoltate”: si pensi al link “Request an API?” del sito Open Data americano.

Tanto più la PA saprà ascoltare la domanda delle community, tanto più nasceranno servizi innovativi che trasformeranno il rapporto tra la PA e il cittadino costituendo il motore primo della Economia digitale. La PA potrebbe finalmente partecipare a quel processo di Digital Transformation nel quale ha sempre fatto fatica ad entrare, forse perché deve rendersi conto che non lo può guidare, ma deve semplicemente farne parte ed accettarne le regole ripercorrendo il paradigma delle fasi della vita lavorativa: il fare, il far fare e il lasciar fare. Dopo il primo periodo del make delle Amministrazioni, il secondo periodo dell’outsourcing, finalmente si lascia al mercato ciò che sa fare meglio: realizzare direttamente i servizi pubblici che soddisfino la domanda del cittadino secondo principi e regole ben definiti.