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

• Parte quarta: l'architettura condivisa per l'interoperabilità

8 agosto 2003

In quest'ultimo scritto, prima della opportuna pausa estiva, cercherò di completare il discorso, avviato con i precedenti articoli, sugli standard comuni e sull'architettura condivisa della futura teleamministrazione italiana. Mi propongo di approfondire con maggior dettaglio questo tema, inclusi i servizi web XML/SOAP, nei prossimi articoli a partire dal prossimo Settembre.

Riprendiamo la parte destra della slide di Elena Tabet (presentazione pdf, 440 k) relativa all'architettura prevista dal Piano di eGovernment, alla quale abbiamo fatto una leggera modifica per indicare che anche le Pubbliche Amministrazioni, così come i cittadini e le imprese, devono poter accedere ai servizi erogati potenzialmente da ogni ente pubblico, anche attraverso interfaccia specializzate.

In questa architettura, ben descritta dal punto di vista organizzativo nell'allegato uno e da quello tecnico nell'allegato due al primo avviso del Piano di eGovernment, possiamo quindi individuare tre attori principali:

1. Gli utenti, che sono tutti quei soggetti che chiedono servizi alla Pubblica Amministrazione.

2. Il sistema di Front Office, rappresentato dai canali di accesso a questi servizi

3. Il sistema degli enti erogatori dei servizi

1 - Gli utenti, possono essere classificati in tre gruppi: cittadini, imprese ed altre Pubbliche Amministrazioni:

2 - Il Front Office unico ed integrato, è formato da canali telematici e canali fisici. Il Front Office è realizzato sia da Pubbliche Amministrazioni (di regola i Comuni) sia da altri soggetti convenzionati (lottomatica, banche, tabaccai, gestori di portali e call center, ecc.), e fornisce tutti i servizi della Pubblica Amministrazione accessibili per via elettronica. 

Nell'allegato 1 invece di computer si parla di Portale. Noi abbiamo preferito definire l'oggetto a cui l'utente si rivolge per accedere al servizio, in quanto l'accesso tramite portale è un elemento costante del Front Office.  

Da notare che la differenza tra Front Office telematico e fisico riguarda il lato utente. Questo può essere per un computer da casa o dall'ufficio, il cellulare, un chiosco o ogni altro strumento telematico. L'ente erogatore del servizio dovrebbe invece relazionare con il front office telematico o fisico, solo per via telematica, attraverso documenti elettronici.

3 - Il terzo componente fondamentale è costituito dagli Enti della Pubblica Amministrazione erogatori dei servizi, e nello specifico dalle Aree Organizzative Omogenee (AOO) di riferimento, che dovranno fornirli per via telematica, secondo degli standard definiti.

I diagrammi che stiamo usando sono UML standard (diagrammi delle classi), e, come vedete, sono molto semplici da comprendere. Potete comunque trovare materiali e tutorial sull'UML in italiano su internet, ad esempio nel sito di analisi-disegno.com.

Questi tre attori principali nello scenario di eGovernment, interagiscono principalmente attraverso la richiesta/erogazione di servizio (tralasciamo per il momento il meccanismo della notifica di evento):

E' evidente che per far funzionare questa architettura occorre garantire l'interoperabilità di tutti i sistemi informatici, non solo di quelli degli enti della Pubblica Amministrazione, ma anche quelli dei cittadini, delle imprese e di eventuali soggetti terzi coinvolti nell'erogazione dei servizi. Da qui la centralità degli standard internet, che garantiscono l'interoperabilità dei sistemi tecnologici a livello mondiale.

Se isoliamo gli utenti come attori esterni, e chiamiamo sistema "Pubblica Amministrazione elettronica" il sistema integrato costituito dal Front Office e dagli Enti erogatori dei servizi, possiamo definire il caso d'uso "l'utente accede ad un servizio" come la funzionalità principale del sistema di eGovernment:

La cui realizzazione può essere schematizzata come segue:

E' evidente come il sistema informativo del Front Office ha bisogno di un sistema per cercare, trovare e cooperare con il sistema informativo che gestisce il servizio richiesto dall'utente.

Da qui la centralità del registro o indice dei servizi, che sarà fornito dall'indice delle Pubbliche Amministrazioni (IPA), già avviato dal Centro Tecnico e previsto dalle regole tecniche sul protocollo informatico (DPCM 31/10/2000). 

Inserendo quest'oggetto nel nostro diagramma delle classi, otteniamo:

Ogni ente dovrebbe pubblicare i propri servizi su un registro standard (UDDI), rendendoli così accessibili alle applicazioni (portali) dei soggetti che andranno a formare il front office (portali nazionali, locali, applicazioni varie di Pubbliche Amministrazioni,  call center, ecc.).

Possiamo quindi disegnare il diagramma di sequenza che realizza il caso d'uso "accede ad un servizio" inserendo il ruolo del registro:

Il diagramma modella lo scenario principale ad alto livello, per evidenziare solo le interazioni principali, che possono essere così descritte: 

1. L'utente richiede il servizio ad un canale di Front Office, utilizzando un sistema di autenticazione (identificazione del soggetto che crea, visiona, modifica o invia dati elettronici) e i dati richiesti per l'erogazione del servizio. L'utente può disporre della firma digitale o della CIE/CNS per l'accesso diretto per via telematica, oppure anche solo della carta di identità cartacea, per l'accesso indiretto, attraverso lo Sportello Unico di Front Office, uno sportello realizzato da reti terze (ad esempio la rete lottomatica, che ha già avviato iniziative in tal senso).

2. L'applicazione di Front Office (un portale dell'utente, sia esso impresa, cittadino, altra PA o operatore dello sportello unico o del call center), utilizzando parte dei dati ottenuti dall'utente stesso (ad esempio un identificativo del comune dell'utente e un identificativo del servizio), ricerca il servizio sul registro, inviando una specifica richiesta.

3. il registro restituisce le informazioni necessarie all'accesso da parte del portale, eventualmente consultando altri registri collegati.  

4. Il Front Office, utilizzando le informazioni ottenute dal registro,  richiede i dati specifici del servizio all'utente.

5. L'utente fornisce i dati richiesti al Front Office

6. Il sistema di Front office, utilizzando le informazioni ottenute dal registro ed i dati dell'utente,  confeziona i documenti elettronici, li inserisce in un messaggio XML/SOAP (chiamato busta di eGovernment nell'allegato 2 al primo avviso), e li invia all'ente erogatore del servizio, insieme alle credenziali dell'utente (firma digitale dell'utente oppure firma digitale dello sportellista che ha identificato l'utente e dichiara che il contenuto dei documenti è stato approvato dall'utente). L'invio avviene utilizzando un sistema di posta elettronica certificata, che garantisce l'avvenuta consegna, come previsto dal DPR 445/2000.

7. L'ente erogatore del servizio restituisce al front office i documenti di risposta firmati elettronicamente dal responsabile del servizio (ricevute, certificati, dati), sempre utilizzando un servizio di posta elettronica certificata (in pratica, in caso di Front Office virtuale, vengono inviati direttamente alla casella di posta certificata dell'utente).

8. Il Front Office invia i documenti elettronici o direttamente in formato elettronico (se l'utente dispone di una casella di posta elettronica certificata), oppure lo Sportello di Front Office predispone una copia conforme cartacea della documentazione, e la consegna all'utente se presente allo sportello oppure la invia al domicilio di questo attraverso la posta tradizionale.

Nei precedenti articoli abbiamo iniziato ad identificare alcuni dei principali requisiti  che questi attori dell'eGovernment devono possedere per poter essere parte di questa architettura di eGovernment. 

1. Gli utenti: per accedere direttamente ai canali virtuali devono disporre di un idoneo dispositivo (computer, PDA, ecc), e di una Smart Card dotata di Firma digitale qualificata, o della CNS/CIE (art. 38, comma 2 del DPR 445/2000: "Le istanze e le dichiarazioni inviate per via telematica sono valide: a) se sottoscritte mediante la firma digitale, basata su di un certificato qualificato, rilasciato da un certificatore accreditato, e generata mediante un dispositivo per la creazione di una firma sicura; ovvero quando l'autore e' identificato dal sistema informatico con l'uso della carta d'identita' elettronica o della carta nazionale dei servizi". Gli stessi strumenti sono idonei per l'accesso a banche dati che richiedano l'identificazione dell'utente (art. 59, comma 3 DPR 445/2000).  Inoltre per poter ricevere dei documenti dalla Pubblica Amministrazione, che richiedano la garanzia dell'avvenuta consegna, deve dotarsi di una casella di Posta Elettronica Certificata.  

2. Il Front Office: deve disporre di applicazioni web in grado di "consumare" servizi web (web services consumer), e di interfacciarsi direttamente con i registri UDDI. Le applicazioni possono essere utilizzate direttamente dagli utenti (portali per gli utenti finali), oppure da un operatore autorizzato (portali degli sportelli unici, del call center, delle PA), che agisce come intermediario nella erogazione dei servizi elettronici, identificando gli utenti che non dispongono di firma digitale, e trasformando i documenti cartacei eventualmente forniti dagli utenti, in documenti elettronici.  Il front office è realizzato da un ente pubblico (principalmente Amministrazioni Comunali), ma anche da enti o aziende private convenzionate (lottomatica, poste, banche, ecc). 

3. Gli enti che erogano i servizi: come abbiamo visto negli articoli precedenti, per poter partecipare all'architettura di eGovernment, devono attivare il nuovo servizio di protocollo  informatico, con la casella di posta certificata, per poter ricevere, inviare protocollare e gestire i documenti elettronici; devono inoltre trasformare gli attuali servizi di sportello in "servizi elettronici di interoperabilità" erogati attraverso la porta delegata del proprio sistema informativo, come servizi web. 

4. La Pubblica Amministrazione Centrale, ed in particolare il Ministero per le Innovazioni e le Tecnologie, dovranno attivare i "servizi di interoperabilità", a cominciare dall'indice delle Pubbliche Amministrazioni, che andrà integrato in un vero e proprio registro dei servizi di eGovernment, realizzato come servizio web (standard UDDI).

Vediamo più in dettaglio, utilizzando un semplice diagramma delle attività (UML), il flusso di comunicazione che si stabilisce tra le applicazioni del Front Office (client), cioè i portali, che danno accesso agli utenti umani a servizi elettronici distribuiti (web services):  

Nell'architettura di eGovernment l'interoperabilità si ottiene esponendo sul web "servizi applicativi" in modalità standard (XML/SOAP), e pubblicandoli su un apposito registro, in modo da poter essere scoperti, compresi e utilizzati da altre applicazioni che non hanno alcuna conoscenza a priori della loro esistenza.

 L'interoperabilità è la condizione indispensabile per poter attuare il disegno di eGovernment. 

Possiamo distinguere una interoperabilità di base, garantita principalmente dall'aderenza agli standard tecnologici, standard Internet definiti dal consorzio w3C, dall'IETF e da altre autorità di normazione riconosciute, ed una interoperabilità specifica, che dovrà essere garantita da standard definiti da autorità centrali della Pubblica Amministrazione, a livello nazionale o sovranazionale (in particolare europeo),  

A tal proposito, è di questi giorni il documento della Commissione Europea sull'interoperabilità dei sistemi informativi e dei servizi delle Pubbliche Amministrazioni, che si occupa dell'interoperabilità tra le pubbliche amministrazioni e tra queste e le imprese. 

Il documento distingue tre tipi di interoperabilità:

1. tecnica: per far relazionare fra di loro i sistemi informativi e far interoperare le applicazioni. 

2. semantica: per assicurare l'univoco e preciso significato delle informazioni scambiate tra sistemi informativi non noti a priori. Standard di questo tipo sono, ad esempio, i DTD della segnatura di protocollo o quello di Norme in Rete, l'indice delle Pubbliche Amministrazioni, gli standard per la CIE e la CNS. Su questo punto sarà essenziale formalizzare la classificazione dei servizi delle Pubbliche Amministrazioni, già iniziata con l'allegato 1 al primo avviso con il piano di eGovernemnt, per definire ciascun servizio in maniera univoca a livello nazionale o europeo.

3. organizzativa: per attribuire ruoli, doveri e responsabilità precise ad ogni organizzazione coinvolta in processi condivisi, come quelli che si aprono nello scenario dell'eGovernment. E' forse la parte più complessa, perché presuppone la definizione di un'architettura di eGovernment e che ciascun attore coinvolto la comprenda, la condivida e modifichi di conseguenza la propria organizzazione ed i propri processi. Un esempio di regole che possono garantire l'interoperabilità organizzativa sono date dalle norme sul protocollo informatico. 

 Spero di riprendere questi argomenti a Settembre. Intanto vi auguro buone vacanze.

(continua)