Parliamo di eGovernment!

di Francesco Cotroneo
ASMTEL Area eGovernment 

Standard comuni ed architetture condivise per la Pubblica Amministrazione:

• Parte prima: partiamo dal Protocollo Informatico

• Parte seconda: identifichiamo i servizi ed i dati da rendere disponibili sulla rete

• Parte terza: scenari di eGovernment

18 luglio 2003

Nei due precedenti articoli abbiamo identificato due progetti strategici nella strada che porta all'eGovernment. 

Il primo è il nuovo servizio di protocollo  e gestione del documento informatico, per mettere gli enti in grado di gestire efficacemente il documento elettronico, in maniera sicura e giuridicamente valida. 

Il secondo è quello di trasformare, naturalmente con la necessaria gradualità ma nel quadro di un progetto globale, gli attuali servizi delle Pubbliche Amministrazioni (come da elenco contenuto nell'allegato 1 al piano di eGovernment, dove sono censiti un migliaio di servizi), oggi erogati da ciascun ente direttamente agli utenti, in servizi web di interoperabilità, erogati elettronicamente attraverso altre applicazioni di Front Office (portali per gli utenti, per gli sportelli, per i call center, ecc) o di back office (interoperabilità propriamente detta), proprie o di terzi autorizzati, che vi accedono attraverso un registro pubblico.

Questi obiettivi non sono né semplici né banali, in quanto presuppongono una sostanziale riorganizzazione degli enti, con il progressivo passaggio da una Pubblica Amministrazione che gestisce documenti cartacei trasmessi manualmente, con la necessità di un contatto fisico e diretto con gli utenti, attraverso specifici sportelli, ad una teleamministrazione, che gestisce documenti informatici trasmessi telematicamente, senza la necessità di un contatto fisico e diretto con gli utenti. 

Dal punto di vista tecnologico richiedono l'applicazione degli standard Internet di nuova generazione (XML e sue applicazioni, web services). 

Dal punto di vista organizzativo richiedono, quali importanti fattori di successo soprattutto per i progetti medio-grandi, adeguate iniziative di pianificazione e definizione degli obiettivi, di analisi e progettazione per la  reingegnerizazione dei processi dell'ente, possibilmente utilizzando linguaggi standard ed integrati con l'analisi e la progettazione del sistema informativo (UML, USDP), oltre ad opportune tecniche di gestione del cambiamento (change management) e di gestione dei progetti (project management).

Credo sia utile evidenziare gli elementi essenziali di quest'ultima affermazione.

In ogni progetto di realizzazione di servizi (e quindi di processi) ad alto contenuto tecnologico, che richieda la predisposizione di un sistema informatico in grado di cooperare con altri sistemi informatici esterni, non conosciuti a priori, come il caso del protocollo informatico, è utile ed opportuno:

1. Utilizzare le tecnologie internet, almeno per la parte di interoperabilità, ed in particolare i Servizi Web di nuova generazione (XML/SOAP) nel quadro di un'architettura orientata ai servizi (SOA), che approfondirò in questo e nel successivo articolo.

2. Utilizzare un linguaggio di analisi e progettazione standard, come l'UML (Linguaggio di Modellazione Unificato), per realizzare i documenti di analisi e di progetto non solo del sistema informativo, ma anche per i processi, ottenendo la riduzione dei costi della comunicazione ed un efficace riutilizzo dei progetti.

3. Utilizzare un processo di sviluppo del sistema informativo coerente con le indicazioni del cosiddetto "Processo Unificato" (USDP), la cui applicazione e corretta personalizzazione, consente di ridurre notevolmente i rischi di fallimento del progetto, solitamente molto alti per sistemi che prevedono l'integrazione di numerosi componenti software diversi. Il Processo Unificato prevede, tra l'altro, una definizione iniziale dell'architettura del sistema, l'approccio per oggetti e per componenti, l'anticipata risoluzione dei rischi, lo sviluppo iterativo e incrementale, e meccanismi di gestione della qualità del processo e di controllo dei cambiamenti.

4. Utilizzare, ove appropriato e utile, le moderne tecniche di gestione del progetto (Project Management), di reingegnerizzazione dei processi (BPR) e di gestione dei cambiamenti (change management). 

In questo articolo voglio approfondire l'argomento dei servizi web di nuova generazione, entrando il meno possibile in dettagli tecnici, per cercare di contribuire a far conoscere queste tecnologie, ed il ruolo che potranno avere nello sviluppo dell'eGovernment nella Pubblica Amministrazione Italiana, anche a coloro che non sono esperti di informatica.

I servizi web propriamente detti, in inglese "Web Services",  designabili anche con  le sigle XML/SOAP (acronimi di "Linguaggio di Marcatura Esteso e di Protocollo per l'Accesso a Oggetti Semplici), sono costituiti da un insieme di linguaggi per elaboratori, ma abbastanza comprensibili anche agli esseri umani, disposti a strati, che consentono ad applicazioni, anche realizzate con tecnologie differenti, di comunicare e cooperare. 

Sono peraltro le tecnologie indicate dagli allegati tecnici al piano di eGovernment, come  standard della cooperazione applicativa nella Pubblica Amministrazione ed elemento fondamentale dell'infrastruttura tecnologica dell'architettura di eGovernment, che prevede la cooperazione applicativa fra i vari enti e la realizzazione di un Front office multicanale integrato ed indipendente, che si relaziona per via telematica (utilizzando documenti elettronici e portali), con le varie unità organizzative titolari di servizi ai cittadini ed alle imprese. 

I vari standard che compongono i "Web Services" rendono possibile la realizzazione di questo disegno, anche tra enti che dispongono di sistemi informativi eterogenei, senza la necessità di una loro integrazione esplicita, attraverso progetti, fatto che richiederebbe tempi lunghi e costi elevati, considerato l'altissimo numero di enti della Pubblica Amministrazione (ciascuna magari dotata di molti sistemi informatici non cooperanti). Sarebbe comunque sbagliato uscire dagli standard internet, affermatisi nel mercato e approvati formalmente dal consorzio w3c, in quanto l'obiettivo strategico della Pubblica Amministrazione non può che essere  l'integrazione globale con i sistemi informativi utilizzati delle imprese private e dai cittadini.

Tutti i principali istituti di ricerca prevedono un fortissimo sviluppo di queste tecnologie in pochi anni. Ci limitiamo a citare IDC (che effettua costantemente delle ricerche di mercato sui web services) che prevede che, solo negli Stati Uniti, nei prossimi dieci anni si spenderanno oltre 184 miliardi di dollari per progetti che riguardano i web services, con un mercato USA che raggiungerà, in soli 4 anni (entro il 2007), un giro di affari di 21 miliardi di dollari, arrivando a 27 miliardi di dollari entro il 2010. Queste cifre ci dicono che le applicazioni basate sui "web services" si diffonderanno in pochissimi anni e diventeranno l'architettura di applicazioni distribuite dominante in meno di dieci anni. 

Ogni applicazione con architettura basata sui web services, può comportarsi più o meno  come noi, quando abbiamo la necessità di accedere ad un servizio che si trova su un sito web. Noi utilizziamo un'applicazione chiamata browser, per effettuare: 

1. Ricerca: dobbiamo trovare il sito web che contiene il servizio che ci interessa: usiamo un indice o registro, ad esempio di un motore di ricerca, per trovare l'indirizzo del sito, fornendo delle parole chiavi o sfogliando un catalogo, comunicando attraverso protocollo HTTP e messaggi HTML.

2. Connessione: ottenuto l'indirizzo, ci colleghiamo, di solito con un semplice click del mouse, al server del sito (con protocollo HTTP).

3. Istruzioni: sul sito leggiamo le istruzioni su come il servizio è fornito (ricevendo messaggi HTML)

4. Utilizzo: utilizziamo infine il servizio, inviando dei dati e ricevendo dal sito dei dati in risposta, utilizzando messaggi HTML.

Per le applicazioni in grado di consumare "web services", il meccanismo è simile, ed avviene attraverso documenti elettronici che sono messaggi standard (XML):

1. Ricerca: l'applicazione cerca un sito web che disponga del servizio desiderato, utilizzando un'apposito registro standard (UDDI), sul quale effettua ricerche inviando parametri opportuni, utilizzando protocollo HTTP e messaggi standard XML/SOAP

2. Connessione: ottenuto l'indirizzo, l'applicazione si collega al server del sito (con protocollo HTTP).

3. Istruzioni: dal server ottiene le istruzioni su come il servizio è fornito (ricevendo messaggi XML/SOAP)

4. Utilizzo: l'applicazione utilizza il servizio, inviando i dati richiesti e recuperando i dati di risposta,  attraverso messaggi XML/SOAP.

Per chiarire meglio questi concetti faremo degli esempi concreti, individuando dei possibili scenari di servizi che il Piano di eGovernment intende realizzare. Nel prossimo articolo vedremo più in dettaglio l'architettura orientata ai servizi in grado di realizzare questi scenari.

Immaginiamo di essere fra qualche anno nel futuro, ad esempio fra 4 anni, nel 2007.

Ho appena cambiato casa, trasferendomi da Settimo Torinese a Torino. Devo quindi comunicare questa informazione alla Pubblica Amministrazione, anzi,  dovevo probabilmente farlo prima, perché sono già partito per le vacanze: un mese a Santo Domingo, nella Repubblica Dominicana.

Nessun problema comunque.  Il Piano di eGovernment dovrebbe essere  in gran parte attuato, come previsto dal Ministero (80% dei servizi essenziali on line entro fine legislatura iniziata nel 2001 e finita regolarmente nel 2006), e dovrei quindi poter accedere a gran parte dei principali servizi della Pubblica Amministrazione Italiana senza problemi, attraverso Internet, anche da una lontana isola dei Caraibi.

Per di più il servizio che io chiedo è il semplice inoltro di una dichiarazione alla Pubblica Amministrazione. Come posso fare, o meglio come potrò fare fra qualche anno?

Proviamo ad immaginare tre possibili scenari, andando, diciamo, dal peggiore al migliore:

1. Scenario 1: il servizio che chiedo non è disponibile in quanto il mio comune non ha attivato il servizio di protocollo informatico previsto dal DPR 445/2000 e non è quindi in grado di gestire (accettare, verificare, smistare, archiviare) i documenti informatici.

2. Scenario 2: il comune ha attivato il servizio di protocollo informatico, si è accreditato presso l'Indice delle Pubbliche Amministrazioni fornendo il proprio indirizzo di posta elettronica istituzionale, ma non ha pubblicato nessun servizio web relativo al servizio "comunicazione di cambio di residenza".

3. Scenario 3: il comune ha attivato il servizio di protocollo informatico, si è accreditato presso l'Indice delle Pubbliche Amministrazioni,ed ha pubblicato sull'apposito registro un servizio web per la comunicazione del cambio di residenza.

Aggiungeremo alla fine un quarto scenario: come nello scenario tre il mio comune è stato bravissimo, ma sono io che ho dimenticato la mia Smart Card in Italia e non posso quindi usare la firma digitale.

Ammettiamo che il comune di Torino ed il Governo hanno fatto molto bene la loro parte, il primo attivando il servizio di protocollo informatico e pubblicando sull'apposito registro un servizio web per la comunicazione del cambio di residenza, il secondo attivando in tutte le sue funzionalità necessarie l'indice delle Amministrazioni Pubbliche e dei loro servizi, esponendo i dati come servizio web (UDDI). 

Eccomi quindi sotto una palma dei tropici. In un momento  di relax decido di compiere il mio dovere di cittadino.

Apro il mio portatile, effettuo il collegamento internet attraverso il servizio wireless (senza fili) reso disponibile dall'hotel che contiene la spiaggia, e mi collego al Portale Nazionale della Pubblica Amministrazione. 

L'indirizzo del portale sta nell'agenda di indirizzi Internet del mio computer (chiamata "preferiti"), e mi collego quindi con un semplice click del mouse sulla voce di menu "Portale Nazionale".

Già da questa semplice operazione possiamo riflettere sull'importanza dei registri pubblici che operano su Internet. 

Io voglio accedere al "portale nazionale" che ha come indirizzo www.italia.gov.it.  ed Il mio browser (programma per accedere al web) invia la richiesta ad un server (un computer) di Codetel, l'azienda che presumibilmente fornisce il servizio wireless al mio hotel. 

Questo computer ha un registro (un elenco) di indirizzi di siti web e fornisce per ogni indirizzo le informazioni necessarie a localizzare il computer che fornisce i relativi servizi.

Arriva la mia richiesta che viene inviata al servizio di registro (chiamato DNS, Domain Name System). Il registro trova l'indirizzo, anche interrogando altri registri sparsi per il mondo (il DNS, così come UDDI, è una banca dati distribuita), e invia la mia richiesta ad un server della rete che gestisce il portale, che è in grado di soddisfare la mia richiesta.

Un meccanismo simile a questo, che oggi consente ad Internet di funzionare per gli esseri umani attraverso il sistema degli indirizzi (o domini), funzionerà per le applicazioni. E' bene riepilogare la differenza tra le attuali applicazioni web standard, e applicazioni web con architettura SOA (Service Oriented):

• Applicazioni web standard: una persona  accede ad un'applicazione presente su un sito web, trovando o digitando il nome del sito, che è pubblicato su un registro chiamato DNS, che ha le informazioni per raggiungere il server che eroga il servizio.

• Servizi web XML/SOAP: una persona accede ad una applicazione come sopra, la quale, sulla base delle esigenze della persona, accede ad uno o più servizi web, erogati da altre applicazioni, trovando o indicando il nome del servizio, che è pubblicato su un registro chiamato UDDI, che ha le informazioni per raggiungere il server che eroga il servizio. 

La figura seguente, tratta da una presentazione di Elena Tabet (file pdf, 440 k), del Ministero per l'Innovazione e le Tecnologie, sintetizza il tipo di trasformazione della Pubblica Amministrazione previsto dal Piano di eGovernment e rende evidente come questa trasformazione, dal punto di vista delle applicazioni, dovrà coincidere con un'architettura di tipo SOA,  basata sulla cooperazione applicativa, attraverso servizi web.

Teniamo inoltre conto che le applicazioni degli enti che erogano i servizi dovranno anche cooperare fra di loro (oltre che con le applicazioni di front office).

Dalla figura appare chiaro come:

• Nello situazione attuale, gli utenti accedono ad applicazioni standard su siti web degli enti erogatori dei servizi (migliaia di applicazioni che comunicano con grande difficoltà fra di loro), trovando o digitando il nome del sito, che è pubblicato su un registro chiamato DNS, che ha le informazioni per raggiungere il server che eroga il servizio.

• Nello scenario di eGovernment, gli utenti (cittadini, imprese, funzionari di altre amministrazioni) accedono ad applicazioni di Front Office (o di Back Office), in grado di consumare servizi web. Queste applicazioni, sulla base delle esigenze dell'utente, accedono ad uno o più di questi servizi web presenti sulla rete, erogati da altre applicazioni, trovando o indicando il nome del servizio necessario utilizzando un registro (UDDI). 

Torniamo all'esempio. 

Mi sono collegato al portale nazionale della Pubblica Amministrazione. Nel portale posso identificarmi utilizzando una qualunque carta (Smart Card) compatibile con la "Carta nazionale dei servizi" (CNS), rilasciata da una Pubblica Amministrazione qualsiasi.  

Utilizzo la mia carta di firma digitale, rilasciata da un certificatore accreditato (nel mio caso Infocamere), che sarà sicuramente compatibile con le specifiche della CNS.

Inserisco la carta ed il sistema mi chiede di digitare il numero segreto (PIN), che consente l'accesso al microprocessore della smart card che contiene la mia chiave privata, idonea ad identificarmi in maniera certa (autenticarmi, equivale a firmare dei documenti non ripudiabili, che attestano il mio ingresso sul portale e le operazioni che faccio). 

Inserisco il numero segreto come si conviene, al riparo da sguardi indiscreti, e vengo riconosciuto (la mia richiesta di ingresso firmata viene accolta).

Il portale è molto amichevole. Mi accoglie con un "Benvenuto Francesco". Se ho qualche difficoltà e voglio parlare con qualcuno,  posso anche contattare un operatore e chiedere informazioni.

Ma è tutto chiaro. 

Dall'elenco degli eventi della vita, scelgo l'evento "avere una casa". Poi scelgo cambiare casa e quindi il servizio "comunicazione cambio residenza".

Oggi il portale da solo informazioni e fornisce dei collegamenti ai siti di vari comuni, dove si reperiscono informazioni. Solo il comune di Milano da informazioni sullo stato della pratica di cambio di residenza via email, un esempio di servizio informativo utile,  ma aggiuntivo, che fa aumentare i costi dell'ente invece di ridurli ed in buona sostanza da poco valore aggiunto.

Ma nel 2007 l'accesso multicanale integrato a tutti i principali servizi della Pubblica Amministrazione sarà una realtà (o almeno speriamolo).

Quindi dovrebbe succedere quanto segue:

Scenario 1: comune di Settimo Torinese senza servizio di protocollo informatico e senza servizi di cooperazione applicativa.

Dal Portale Nazionale scelgo il servizio "comunicazione cambio residenza",  mi appare una maschera che mi chiede di indicare il comune di residenza attuale: scrivo Settimo Torinese, e poi il comune di nuova residenza: scrivo Torino. 

Una nuova maschera si scusa, dicendomi che non mi è possibile usufruire del servizio in quanto non è possibile inoltrare documenti elettronici al comune di Settimo Torinese, che non possiede ancora la casella di posta elettronica istituzionale. 

Mi invita per ulteriori informazioni a consultare il sito internet del comune. Consulto il sito, mi spiega che devo andare personalmente allo sportello dell'anagrafe. Ci andrò al mio ritorno, lamentandomi con la sorte che mi vede nel 20% dei cittadini che non può ancora usufruire dei servizi di eGovernment.

In un'ipotesi migliore: sul sito internet del comune vi è un  modulo elettronico che io posso inviare, ma senza firma digitale (Il comune non ha attivato il protocollo informatico, e quindi gestisce solo documenti cartacei con firma autografa). Posso inviare l'istanza, ma dovrò comunque passare con calma a firmare dall'anagrafe. 

Scenario 2: comune di Settimo Torinese ha il servizio di protocollo informatico ma non ha un servizio web di cooperazione applicativa per la comunicazione del cambio di residenza.

Dal Portale Nazionale scelgo  il servizio "comunicazione cambio residenza",  mi appare una maschera che mi chiede di indicare il comune di residenza attuale: scrivo Settimo Torinese, e poi il comune di nuova residenza: scrivo Torino. 

Una nuova maschera mi informa che posso inoltrare la richiesta presso la casella di posta elettronica istituzionale dell'ente, e mi fornisce l'indirizzo. Mi invita anche a consultare il sito internet del comune per reperire le informazioni sulla modulistica da utilizzare per l'istanza. 

Io giudico ovvie le informazioni da inviare, e quindi clicco subito sull'indirizzo di posta istituzionale. 

Si apre un messaggio di posta elettronica correttamente indirizzato, e scrivo una dichiarazione in cui metto le mie informazioni anagrafiche, i dati della mia residenza attuale, di quella futura, e clicco su invio. 

Se la Smart Card non è inserita nel lettore, mi appare una finestra in cui mi si richiede di inserirla, per la firma del messaggio. Lo faccio ed il sistema mi chiede il codice segreto o PIN. Lo inserisco. Fatto. Il documento firmato digitalmente è stato inviato. Ricevo una ricevuta di presa in carico dal mio sistema di posta certificata di Infocamere e subito dopo la ricevuta di avvenuta consegna dal sistema di posta certificata del mio comune. 

Dopo qualche ora ricevo un messaggio di conferma dell'avvenuta protocollazione dell'istanza, con il numero di protocollo. 

Ho fatto il mio dovere, anche se, in mancanza di uno specifico servizio, anche se per istanze più complesse, avrei prima dovuto preliminarmente procurarmi copia della modulistica da utilizzare. 

L'anagrafe di Settimo Torinese, che ha ricevuto l'istanza, controlla la correttezza della documentazione, facendo eseguire accertamenti se necessario, poi invia per posta elettronica certificata documentazione firmata alla casella di posta istituzionale del comune di Torino oppure utilizzando un'applicazione di back office in grado di interfacciarsi con il relativo web services del comune di Torino. 

Anche qui viene eseguito quanto previsto dal procedimento, che si conclude con la mia iscrizione nella anagrafe dei residenti in Torino. 

Alla conclusione della pratica viene inviata al mio indirizzo di posta elettronica certificata, il documento di avvenuta iscrizione, firmato dal funzionario dell'anagrafe del comune di Torino.

Scenario 3: comune di Settimo Torinese ha il servizio di protocollo informatico ed un servizio web di cooperazione applicativa per la comunicazione del cambio di residenza.

Dal Portale Nazionale scelgo  il servizio "comunicazione cambio residenza",  mi appare una maschera che mi chiede di indicare il comune di residenza attuale: scrivo Settimo Torinese, e poi il comune di nuova residenza: scrivo Torino. 

Il portale mi fa apparire i dati della mia residenza attuale oltre ai miei dati personali (luogo e data di nascita) e mi chiede di confermarli. Io mi sono autenticato con la mia Smart Card, quindi il sistema sa chi sono, e ha reperito via servizi web tutti i miei dati. Ha inoltre verificato la correttezza del codice fiscale utilizzando un servizio web sul sito del ministero delle finanze. Leggo tutti i dati, sono corretti, e quindi scelgo il pulsante ok. 

Un messaggio mi chiede inoltre di fornire o confermare il mio indirizzo di posta elettronica certificata, in modo da consentire lo scambio sicuro di documenti (con la garanzia dell'avvenuta consegna, come previsto dalla normativa).

Mi chiede poi di inserire Il mio nuovo indirizzo a Torino: io scrivo Corso Parco 21. 

Il portale mi fa apparire il nome completo e corretto, anche questo recuperato da un servizio web: Corso Regio Parco, insieme ad una cartina che mi visualizza graficamente la via, e  mi chiede di scegliere tra il numero 21 semplice ed il numero 21 bis. La seconda risposta è quella giusta, mi ero dimenticato di indicare il bis, quindi lo scelgo.

Infine il sistema mi fa apparire il testo completo dell'istanza che sarà inoltrata, con un testo che dice all'incirca: "Io sottoscritto Francesco Cotroneo, nato a.., il.., comunica di cambiare residenza da..a..ecc."

Controllo la correttezza delle informazioni e quindi seleziono il pulsante "firma ed invia", che compare sotto il testo da sottoscrivere.  

Il sistema mi chiede di reinserire il numero riservato (la mia carta è sempre inserita nel lettore) per la firma dell'istanza. Lo faccio ed il sistema mi da la conferma che la mia istanza è stata firmata, inviata e presa in carico dal mio sistema di posta certificata. 

Anche in questo caso riceverò ricevuta di avvenuta consegna nella casella di posta elettronica istituzionale del comune di Settimo Torinese, e successivamente la ricevuta di avvenuta protocollazione.

Scenario 4: come lo scenario 3, ma ho lasciato a casa la mia Smart Card con la firma digitale.

Che peccato, ora che iniziava ad essere utile dimentico la carta di firma a casa. 

Per l'accesso al servizio però, nessun problema! Siamo nell'era della multicanalità. Utilizzerò un canale che non richiede la mia firma digitale. 

Mi reco all'ambasciata italiana, che è un po' come il comune per gli italiani che sono all'estero, e quindi ritengo che abbia il compito di attivare gli sportelli unici di Front Office, come previsto dal Piano di eGovernment. 

Mi presento allo sportello unico della Pubblica Amministrazione. L'operatore mi chiede un documento, gli fornisco la mia carta di identità, ancora cartacea (anche il mio ottimismo ha qualche limite). 

L'operatore scrive i dati che io gli fornisco su un computer, e fa esattamente quello che avrei fatto io, utilizzando un portale ed una carta di firma. Alla fine stampa un modulo, me lo fa firmare. Invia poi l'istanza elettronica, firmandola digitalmente e dichiarando di aver accertato la mia identità. Siccome dispongo di posta certificata che ho indicato, riceverò io tutte le comunicazioni in quella casella.  Altrimenti, come opzione alternativa, le avrei ricevute mezzo posta tradizionale al mio nuovo indirizzo di residenza.  

Nel prossimo articolo vedremo come questi scenari saranno possibili, entrando in maggior dettaglio sui web services e sull''architettura orientata ai servizi. 

parte quarta