STUDIO DI FATTIBILITÀ SULLE AZIONI PER MIGLIORARE LA DISPONIBILITÀ DEI DATI PUBBLICI

Transcript

1 STUDIO DI FATTIBILITÀ SULLE AZIONI PER MIGLIORARE LA DISPONIBILITÀ DEI DATI PUBBLICI.

2 2.

3 INDICE PREMESSA IL PIANO D AZIONE NAZIONALE PER L E-GOVERNMENT OBIETTIVI E FINALITÀ DEL PIANO GLI STRUMENTI E LE AZIONI DEL PIANO Le azioni infrastrutturali Le azioni delle amministrazioni centrali I Portali informativi Portali per l'erogazione di servizi Le azioni delle amministrazioni locali Il ruolo delle Regioni nel Piano d'azione L'informatizzazione degli Enti locali La realizzazione dei progetti intersettoriali L'integrazione delle anagrafi Sistema di interscambio Catasto-Comuni La carta d'identità elettronica Promozione della firma digitale La gestione elettronica dei flussi documentali e-procurement Azioni di formazione LO STATO DI ATTUAZIONE DEL PIANO La gestione del piano I finanziamenti previsti La realizzazione delle infrastrutture la rete nazionale I progetti delle Regioni e degli Enti locali Ripartizione dei fondi per i Progetti delle Regioni ed Enti Locali Modalità di assegnazione dei fondi OBIETTIVI DELLO STUDIO SPECIFICI ED IN RELAZIONE AL PIANO DI E- GOVERNMENT OBIETTIVI E CONTENUTI GENERALI DEGLI SDF IN RELAZIONE ALLE DIVERSE DISPOSIZIONI VIGENTI NELLA PA OBIETTIVI SPECIFICI DELLO SDF IN RELAZIONE AL PIANO DI E-GOVERNMENT IL CONTESTO LEGISLATIVO E NORMATIVO DI RIFERIMENTO NORME INERENTI IL PROCESSO DI DECENTRAMENTO E SEMPLIFICAZIONE DELLA PA Leggi Bassanini sul decentramento e la semplificazione della Pubblica Amministrazione Il TU sulla documentazione amministrativa Le norme che regolano ed indirizzano specifici aspetti della semplificazione amministrativa NORME INERENTI LO SVILUPPO DELL INFORMATICA NELLA PA E L ACQUISIZIONE DI FORNITURE INFORMATICHE NORME INERENTI LA SICUREZZA DEI SISTEMI INFORMATIVI E LA TUTELA DELLA PRIVACY INQUADRAMENTO SULLE AZIONI NECESSARIE PER IL MIGLIORAMENTO DELLA DISPONIBILITÀ DI DATI PUBBLICI INTRODUZIONE DIVERSE MODALITÀ PER I DATI LE RACCOMANDAZIONI DELL AIPA CORRETTEZZA DEI DATI COERENZA E COMPLETEZZA TEMPESTIVITÀ DI AGGIORNAMENTO CENSIMENTO DELLE CARENZE DEFINIZIONE DELLE RESPONSABILITÀ PIANI DI MIGLIORAMENTO VALUTAZIONE DEI COSTI E BENEFICI

4 5. ANALISI DELLE ESIGENZE DI DATI PUBBLICI: LA METODOLOGIA PANORAMICA DELLE ARCHITETTURE MAGGIORMENTE PRESENTI NELLA PA Introduzione Tipologia di Architetture Architetture Client Server (2 livelli) Architetture Client Server (3 livelli web Orieted) Esempi della realtà della Pubblica Amministrazione...48 Applicativi Territoriali RICHIAMI SULLA RUPA Architettura della Rete Unitaria METODOLOGIA PER I DATI Metodologia per le azioni a breve termine Metodologia per le azioni a medio- lungo termine ARCHITETTURE DI RIFERIMENTO PER L'INTEROPERABILITÀ BASATA SULL'INTERSCAMBIO DEI DATI ARCHITETTURE DI RIFERIMENTO PER LA COOPERAZIONE APPLICATIVA COOPERAZIONE BASATA SU EVENTI COOPERAZIONE BASATA SU TRANSAZIONI MODALITÀ DI INTEGRAZIONE E SVILUPPO IMPATTO DELL'INTEGRAZIONE APPROFONDIMENTO DELL ANALISI SU ALCUNI FILONI OBIETTIVO INQUADRAMENTO SULLA MATRICE MATERIE/DATI/FORNITORI/FRUITORI Materia Dati Enti Servizi Competenze Possibili utilizzi FILONI INDIVIDUATI Popolazione Premessa Dati Enti Coinvolti Matrice dati/materie/fornitori/fruitori Catasto e dati territoriali Premessa Dati Enti Coinvolti Matrice dati/materie/fornitori/fruitori Attività economiche e tributi Premessa Dati Enti Coinvolti Matrice dati/materie/fornitori/fruitori Lavoro Premessa Dati Enti Coinvolti Matrice dati/materie/fornitori/fruitori Opere pubbliche Premessa Dati Enti Coinvolti Matrice dati/materie/fornitori/fruitori Ambiente Premessa Dati

5 Enti Coinvolti Matrice dati/materie/fornitori/fruitori LA QUALITÀ DEI DATI PUBBLICI: REQUISITI, ANALISI DELLA SITUAZIONE ATTUALE ED IPOTESI DI MIGLIORAMENTO INTRODUZIONE LE BASI DATI COME MODELLO DEL MONDO REALE MOTIVAZIONI PER MIGLIORARE LA QUALITÀ DEI DATI INCONSISTENZE Intensionali Estensionali Correttezza Sintattica REQUISITI DI QUALITÀ DEI DATI AZIONI PER MIGLIORARE LA QUALITÀ DEI DATI Analisi dei processi Correzione dei dati esistenti data cleaning Record Matching UNA METODOLOGIA PER IL MIGLIORAMENTO DELLA QUALITÀ DI BASI DATI ESISTENTI Le caratteristiche della metodologia Tipologie di interventi di bonifica Misura dei risultati Indice di Qualità CONCLUSIONI ANALISI PER LA DEFINIZIONE DI STANDARD PER ASSICURARE LA PIENA FRUIBILITÀ E LA CONDIVISIONE DEI DATI PUBBLICI LA COOPERAZIONE TRA LE AMMINISTRAZIONI NEGLI SCENARI E-GOVERNMENT ARCHITETTURE WEB-BASED CRITERI PER LA SICUREZZA IL LINGUAGGIO XML TECNOLOGIE MIDDLEWARE ALTERNATIVE PER INTERSCAMBIO DATI E COOPERAZIONE APPLICATIVA Il concetto di Web Service Simple Object Access Protocol LINGUAGGI PER LA DESCRIZIONE DELLE INTERFACCE ED INDICI DEI SERVIZI Web Service Description Language L'iniziativa Universal Description, Discovery and Integration L'INTEGRAZIONE DI APPLICAZIONI LEGACY ESTENSIONI DEL MODELLO DEI WEB SERVICES Gestione di dati binari: SOAP Messages with Attachments Gestione di workflow distribuito tra processi: ebxml REFERENZE ED APPROFONDIMENTI PROPOSTE DI SPERIMENTAZIONI OBIETTIVO IL CASO PIEMONTE Le caratteristiche generali del contesto Le aree di sperimentazione Inquadramento sulle sperimentazioni Censimenti delle basi dati e sistemi di catalogazione Esperienze esistenti Le proposte di sperimentazione Sportello Semplificazione Amministrativa Cataloghi dati e procedure Popolazione Esperienze esistenti Studio per riprogettazione anagrafe Comune di Torino Le proposte di sperimentazione Interscambio telematico sicuro delle informazioni con Stato Civile ed Anagrafi

6 Progetto interscambio in ambito sanitario su certificati medici ed eventi di infortunio Anagrafe open Accesso ai dati della Rilevazione Scolastica Curriculum scolastico Catasto e dati territoriali Esperienze esistenti L'esperienza della Città di Torino nell'utilizzo delle banche dati catastali Il Protocollo d'intesa fra Provincia di Torino e Ministero delle Finanze Le esperienze dei piccoli comuni Le proposte di sperimentazione Anagrafe immobiliare regionale e interscambio informativo Catasto-Comuni Attività economiche, lavoro Esperienze esistenti Lavoro, formazione professionale ed obbligo formativo Le proposte di sperimentazione Anagrafe Attività economiche e produttive Interscambio dati INAIL Centri per l Impiego SIL - SISTEMA INFORMATIVO LAVORO Opere pubbliche Esperienze esistenti Informazioni sui lavori pubblici appaltati nella Regione Piemonte La proposta di sperimentazione Informazioni sui lavori pubblici appaltati a scopo di osservatorio regionale Ambiente Esperienze esistenti Progetto IDA (Interscambio dati ambientali) Le proposte di sperimentazione Evoluzione progetto IDA L ESTENDIBILITÀ DELLE SPERIMENTAZIONI PROPOSTE LE OPERAZIONI NECESSARIE PER L'AVVIO DELLA SPERIMENTAZIONE DEFINIZIONE DEI CRITERI DI MONITORAGGIO E VALUTAZIONE DEGLI EFFETTI ALLEGATO ALLEGATO LINEE STRATEGICHE PER IL TRIENNIO MIGLIORARE LA QUALITÀ DEI DATI DELOCALIZZARE, GRAZIE ALL ICT, LA FORNITURA DI SERVIZI ALLEGATO ALLEGATO PREMESSA L esigenza, espressa in termini sempre più pressanti dai cittadini e dalle imprese, di nuovi e più funzionali servizi, impone una radicale trasformazione della Pubblica Amministrazione. Il quadro normativo, sul quale costruire l innovazione, anche a seguito della recente emanazione del Testo Unico sulla documentazione amministrativa, comprende oggi sia leggi miranti alla semplificazione e razionalizzazione delle strutture pubbliche, sia norme inerenti i processi amministrativi. Sotto la spinta di queste esigenze, ed a seguito delle iniziative intraprese a livello europeo (Piano Prodi per l e-europe), il Governo Italiano ha approvato il 23 Giugno 2000 il Piano d azione del Governo per l e-government. 6

7 Uno dei punti fondamentali su cui si basa il Piano e-government è la diffusione e la facilitazione dell accesso ai dati delle Pubbliche Amministrazioni e l attuazione di una effettiva interazione tra le amministrazioni stesse. Il presente documento individua i contenuti generali, le linee guida, le modalità operative per la stesura di uno studio di fattibilità e di un relativo progetto esecutivo, volti a realizzare un primo esempio di interscambio informativo tra enti pubblici, secondo le indicazioni emerse in sede di Comitato degli Esperti costituito presso il Dipartimento della Funzione Pubblica, e recepite dal Comitato di Indirizzo. Lo Studio in oggetto è in attuazione di quanto deciso dal Comitato di Indirizzo per la realizzazione del Piano di e-government., istituito presso il Dipartimento della Funzione Pubblica che, il 18dicembre 2000, ha approvato il documento di riferimento Prime proposte per migliorare la disponibilità dei dati pubblici. Tale documento individua una prima azione, consistente nell avvio di sperimentazioni, limitate a parte del territorio e delle amministrazioni, sui temi della popolazione, del catasto e dei dati territoriali, delle imprese e delle attività economiche, delle opere pubbliche. 7

8 8.

9 1.IL PIANO D AZIONE NAZIONALE PER L E-GOVERNMENT A seguito delle iniziative intraprese a livello europeo (Piano Prodi per l e-europe), il Governo Italiano ha approvato il 23 Giugno 2000 il Piano d azione del Governo per l egovernment. Si riportano, in sintesi, i principali contenuti e lo stato di attuazione del Piano. 1.1Obiettivi e finalità del piano Il Piano d azione del Governo per l e-government intende indirizzare un insieme di iniziative che riguardano le infrastrutture, gli strumenti di servizio, i sistemi di erogazione, i contenuti, la gestione del cambiamento e l adeguamento del quadro normativo, finalizzate a favorire il cambiamento in atto della Pubblica Amministrazione, attraverso l utilizzo delle moderne tecnologie ICT. Finalità delle azioni previste dal Piano: azioni dirette ad informatizzare la erogazione dei servizi ai cittadini e alle imprese che spesso implicano una integrazione tra i servizi di diverse amministrazioni; azioni dirette a consentire l'accesso telematico degli utilizzatori finali ai servizi della Pubblica Amministrazione e alle sue informazioni. In conseguenza e a supporto delle azioni sopra indicate : azioni di informatizzazione dirette a migliorare la efficienza operativa interna delle singole amministrazioni Il Piano, in un ottica in cui tutte le Amministrazioni Centrali e Locali sono abilitate per una cooperazione informatica paritetica, assegna un ruolo particolare alle Amministrazioni Locali, le quali assumono nel modello decentrato e federale dello Stato sempre più il ruolo operativo di front-office del servizio pubblico, mentre le Amministrazioni Centrali sono destinate a svolgere un ruolo di back-office. In questo disegno il cittadino/impresa potrà ottenere ogni servizio pubblico, cui ha titolo, rivolgendosi ad una qualsiasi amministrazione di front-office abilitata al servizio, indipendentemente da ogni vincolo di competenza territoriale o di residenza. Per la realizzazione del Piano di e-government si considerano necessarie alcune condizioni, tra cui: che tutte le amministrazioni e gli enti siano dotati di un sistema informativo progettato non solo per l'automazione delle funzioni e delle procedure interne della amministrazione e per l'erogazione di servizi ai propri utenti, ma anche per l'erogazione di servizi direttamente ai sistemi informatici delle altre amministrazioni; che tutti i sistemi informativi di tutte le amministrazioni siano connessi tramite una rete tra pari, senza gerarchie; 9

10 che tutte le amministrazioni che svolgono un ruolo di back-office, rendano accessibili senza oneri i propri servizi sulla rete a tutte le amministrazioni che svolgono un ruolo di front-office; che le amministrazioni di front-office realizzino una integrazione dei servizi delle amministrazioni di back-office per fornire servizi integrati secondo le esigenze del cittadino e non secondo l'organizzazione delle amministrazioni eroganti; che l'identificazione (autenticazione) del richiedente il servizio, cittadino o impresa, e la verifica delle sue autorizzazioni, avvengano secondo una modalità uniforme su tutto il territorio nazionale A questo fine verrà utilizzata la carta di identità elettronica come strumento privilegiato di accesso a tutti i servizi della pubblica amministrazione. 1.2Gli strumenti e le azioni del piano Il Piano di azione del Governo per l e-government è incentrato su azioni/progetti che comportano la partecipazione di più Amministrazioni Centrali e Locali. Sostanzialmente sono previste tre tipologie di azioni: Azioni infrastrutturali (la rete nazionale) Azioni delle Ammministrazioni Centrali (I Portali) Azioni delle Regioni e degli Enti locali Più lo sviluppo di alcuni importanti Progetti: L'integrazione delle anagrafi Sistema di interscambio Catasto-Comuni La carta d'identità elettronica Promozione della firma digitale La gestione elettronica dei flussi documentali e-procurement Azioni di formazione 10

11 Per l attuazione delle azioni e dei progetti previsti, il Piano identifica tre strumenti fondamentali. La rete nazionale, cioè la rete che connette tra loro tutte le reti centrali, regionali, locali, di categoria e di settore amministrativo, quelle già esistenti e quelle in via di attivazione. La carta d identità elettronica, come sistema unificato di accesso alle rete e che darà al cittadino il diritto all accesso a tutti i servizi della Pubblica Amministrazione erogati on-line. La firma digitale, che servirà per dare validità giuridica a tutti quei rapporti tra le pubbliche amministrazioni e i privati che la richiedono 1.2.1Le azioni infrastrutturali La infrastruttura tecnologica di base per realizzare il Piano di azione è rappresentata da una rete telematica di copertura nazionale (Rete Nazionale), che sia in grado di interconnettere, con canali di comunicazione sicuri, tutti a tutti i sistemi informatici delle amministrazioni locali e centrali. Tecnicamente la rete è costituita da una Extranet sicura che interconnetterà tutte le Amministrazioni locali tra loro e con quelle Centrali, secondo un modello architetturale peer to peer Principali caratteristiche della Rete Nazionale Sarà possibile connettersi alla Rete Nazionale anche tramite servizi di connettività e di trasporto IP forniti da operatori privati ISP (Internet Service Provider), purché questi si conformino ai suoi requisiti tecnici. Le amministrazioni locali operanti in zone non servite da reti di area o di categoria potranno quindi connettersi alla Rete Nazionale direttamente tramite operatori commerciali. Sia i gestori delle reti federate che gli ISP sono vincolati agli standard di servizio che qualificano la Rete Nazionale come la extranet sicura della Pubblica Amministrazione del Paese. Le amministrazioni centrali verranno automaticamente connesse alla Rete Nazionale tramite RUPA. Le Amministrazioni Locali disporranno di varie opzioni, in funzione dei servizi disponibili nel territorio di appartenenza: - connettersi tramite una rete di area, regionale o sub-regionale. Questa soluzione appare preferibile ovunque disponibile; - connettersi tramite una rete di settore o di categoria; 11

12 - connettersi tramite un ISP privato. Per i servizi di trasporto IP le Amministrazioni Locali potranno in ogni caso scegliere in autonomia tra tutte le opzioni disponibili. Le modalità di erogazione dei Servizi L erogazione a cittadini ed imprese di servizi (Servizi B2C), di natura sia interattiva che transazionale, delle amministrazioni avverrà in Internet secondo strategie e piani autonomi di responsabilità di ciascuna. Il Piano di e-government prevede che, per l accesso telematico ai servizi, tutte le amministrazioni facciano riferimento, a regime, ad un unico sistema nazionale di identificazione e di autenticazione basato sulla carta di identità elettronica, mentre per lo scambio di documenti si dovrà utilizzare in ogni caso la firma digitale, strumento già oggi disponibile. L interoperabilità tra i sistemi informativi delle amministrazioni (Servizi B2B) dovrà avvenire esclusivamente sulla Rete Nazionale e sulla base di standard definiti a livello nazionale che: identifichino i servizi ed i dati che ogni amministrazione dovrà rendere disponibili sulla rete; specifichino per ogni servizio esposto i livelli di sicurezza, le modalità tecniche di accesso e relativi protocolli. Le amministrazioni dovranno realizzare sistemi informatici capaci di esporre i propri dati e servizi sulla Rete Nazionale Le azioni delle amministrazioni centrali Le azioni previste per le Amministrazioni Centrali si concretizzano, sostanzialmente, nella realizzazione di un SISTEMA DI PORTALI. I portali vengono proposti come il mezzo per rendere fruibili, e soprattutto associati a servizi a valore aggiunto, quegli strumenti come la firma digitale e la carta di identità elettronica, già introdotti a livello normativo, che altrimenti sarebbero difficilmente percepiti dai cittadini, e dalle imprese, come concreti ed utili. I portali previsti dal Piano e-government si suddividono in : portali informativi; portali per l'erogazione di servizi. 12

13 I Portali informativi Portale unificato delle norme Attualmente esistono un centinaio di banche dati giuridiche principali e un elevatissimo numero di banche dati secondarie con accessi diversificati e senza alcuna modalità di integrazione. A partire dal prototipo sperimentale "Norma in Rete" (vedi cap. su PAC), già operativo, verrà realizzato il Portale unificato delle norme per facilitare ed unificare l'accesso alla documentazione di interesse normativo e giuridico già disponibile sui numerosi siti istituzionali, attraverso una standardizzazione nella identificazione dei documenti, e la realizzazione di un motore di ricerca. Banca dati della Cassazione La Corte di Cassazione dispone di una banca dati giuridica centralizzata, che contiene documenti di natura normativa, giurisprudenziale e di dottrina fornite da varie fonti. Il sistema di ricerca è molto ricco di funzionalità, ma tecnologicamente datato. L architettura del sistema sarà adeguata alle tecnologie Internet per favorire l accessibilità, rendere il servizio gratuito e consentire l indicizzazione dei documenti tramite il motore di ricerca del Portale unificato delle norme Portali per l'erogazione di servizi I portali per l'erogazione servizi consentono, oltre all'accesso alle informazioni, anche la formulazione interattiva di richieste di servizio o la esecuzione di transazioni. L accesso ai portali di servizi richiederà anche l uso della firma digitale come meccanismo di convalida legale delle dichiarazioni trasmesse e la carta di identità elettronica, come mezzo di identificazione per l accesso ai servizi dei portali. Il portale per i servizi integrati al cittadino La realizzazione di un portale che possa consentire l erogazione dei servizi integrati al cittadino, rappresenta il punto di arrivo del Piano di azione di e-government e comporta un progetto di grande complessità organizzativa e tecnica ed il superamento di numerosi vincoli normativi. Per realizzare questo portale sarà necessario innanzitutto completare la Rete Nazionale di interconnessione tra tutte le amministrazioni e completare il sistema integrato delle anagrafi. Si tratta perciò di un obiettivo di lungo periodo. 13

14 Il portale per i servizi di certificazione Questa azione ha l obiettivo di coinvolgere le amministrazioni e gli enti che detengono le banche dati più rilevanti ai fini del controllo delle autocertificazioni. Nella prima fase verrà realizzato un portale unificato delle amministrazioni partecipanti, con accesso riservato ai dipendenti autorizzati delle amministrazioni procedenti, che consenta loro, sia di verificare immediatamente le informazioni di natura certificatoria. Nella seconda fase del progetto il portale evolverà per offrire anche servizi accessibili direttamente alle procedure informatiche delle amministrazioni procedenti, in modo da rendere completamente automatico l'accesso alle amministrazioni certificanti. Il portale per i servizi all'impiego Il portale dei servizi all impiego consente l incontro tra domanda ed offerta di lavoro per via telematica. Le Regioni o le Province potranno attivare e gestire un portale territoriale e successivamente attivare il servizio a livello interregionale tra Regioni adiacenti, quindi in cooperazione con il Ministero del Lavoro offrire un servizio a copertura nazionale. Il portale per i servizi alle imprese Il progetto realizza una stretta interoperabilità di INPS ed INAIL con il Registro delle Imprese. I sistemi informatici dei tre enti manterranno sempre coerenti tra loro le informazioni relative alle imprese che ciascun ente conserva nel proprio archivio. Le imprese, utilizzando una modulistica unificata, potranno trasmettere tramite un unico portale ai vari enti tutti i moduli e le comunicazioni previste per legge Le azioni delle amministrazioni locali Il ruolo delle Regioni nel Piano d'azione Lo sviluppo delle azioni di e-government vede nelle Regioni un fondamentale punto di riferimento per diversi ordini di motivi. Le amministrazioni regionali assumono un ruolo cruciale nella effettiva attuazione del decentramento amministrativo in settori strategici del servizio pubblico (Lavoro, Trasporti, Finanze, Sanità ecc.). Le Regioni possono svolgere a livello nazionale ed europeo un ruolo, sempre più evidente, per lo sviluppo della società dell informazione a livello locale mediante lo sviluppo di infrastrutture e di servizi. Le Regioni possono svolgere nei confronti degli enti locali del territorio (Comuni, Province, Comunità Montane, ecc.) una azione per favorire la cooperazione amministrativa e l integrazione nella erogazione di servizi. 14

15 Condizione necessaria e propedeutica, perché le Regioni possano svolgere questo ruolo, è la presenza di un piano di e-government a livello regionale elaborato con la partecipazione e la condivisione degli enti locali del territorio Interoperabilità delle reti regionali Le Regioni sono chiamate a svolgere un ruolo essenziale nella realizzazione delle principali infrastrutture e dei servizi necessari alla realizzazione del sistema informativo integrato del Paese. Numerose regioni hanno promosso ed in parte già realizzato reti a copertura regionale allo scopo di interconnettere gli enti locali del proprio territorio. Le Regioni che dispongono, o disporranno a breve, di una rete regionale sono Basilicata, Emilia Romagna, Friuli V.G., Liguria, Lombardia, Marche, Toscana, Piemonte. È necessario promuovere una azione mirata alla interconnessione ed alla interoperabilità di tutte queste reti e della rete unitaria, allo scopo di realizzare, secondo un modello architetturale federato, una rete a copertura nazionale, che consenta a tutte le amministrazioni locali e centrali di interoperare alla pari e di scambiarsi i propri servizi applicativi. Servizi sussidiari e di supporto al decentramento I gestori delle reti federate dovranno realizzare ciascuno sulla propria rete tutti quei servizi applicativi sussidiari e di supporto al decentramento che consentano un'armonica cooperazione applicativa tra le amministrazioni locali e centrali, indipendentemente dalla rete cui sono connesse. Tra questi appaiono prioritari i servizi di supporto al decentramento di competenze in campo di lavoro (Portale per i servizi all impiego), finanze, sanità ecc. e quelli legati alla integrazione delle anagrafi L'informatizzazione degli Enti locali Gli Enti locali, in particolare i comuni, rappresentano gli attori principali della strategia di e-government del Paese, in quanto destinati a realizzare gli sportelli di front-office per la erogazione dei servizi integrati al cittadino. È necessario favorire ed accelerare non solo la completa informatizzazione di tutti gli Enti locali, ma anche la loro connessione ad una delle reti di area accessibili sul loro territorio e, soprattutto e contestualmente, la esposizione in rete dei servizi, con particolare riferimento ai servizi anagrafici e di stato civile. È necessario altresì sostenere lo sviluppo delle reti civiche da parte delle amministrazioni comunali per l erogazione dei servizi pubblici. Questo punto del Piano e-government si concretizza nelle seguenti azioni: 15

16 dotazione per le aggregazione di comuni di infrastrutture informatiche e telematiche che consentano l interconnessione con la rete nazionale; contributo alla realizzazione di porte applicative sulle quali siano esposti i servizi necessari agli altri enti interconnessi; realizzazione di reti civiche per l erogazione di servizi pubblici (portali territoriali); realizzazione dell accesso ai servizi anagrafici; realizzazione dell indice anagrafico La realizzazione dei progetti intersettoriali Unitamente alle azioni infrastrutturali e delle Amministrazioni (Centrali e Locali) il Piano prevede lo sviluppo di alcuni importanti Progetti intersettoriali che possono considerarsi orizzontali alle Amministrazioni e che costituiscono un nucleo applicativo di fondamentale importanza per lo sviluppo del Piano stesso L'integrazione delle anagrafi Questo importante progetto, fondamentale nella visione del Piano si propone di superare la frammentazione dell'attuale sistema degli archivi delle anagrafi. Per fornire servizi integrati ai cittadini. Il Progetto si può considerare diviso in tre specifiche azioni: a) Interazioni tra amministrazioni centrali e comuni Premessa organizzativa del Progetto è la rimozione delle restrizioni normative o autorizzative che attualmente limitano lo scambio diretto di informazioni per via telematica tra i comuni ed ogni altra Amministrazione Locale e Centrale. Dovrà essere, pertanto realizzato l accesso ai servizi di certificazione delle anagrafi. I comuni dovranno, sempre in condizioni di sicurezza e di garanzia della privacy, esporre sulla rete i servizi di accesso a tutte le informazioni certificatorie di cui sono titolari, per consentire la realizzazione della piena funzionalità del Portale per i servizi di certificazione. b) L'indice delle anagrafi La realizzazione di un sistema integrato delle anagrafi presuppone la creazione e la gestione di un indice dei cittadini residenti, o indice delle anagrafi, necessario sia ai fini del reperimento, sia ai fini della verifica e del mantenimento della coerenza delle informazioni anagrafiche a livello nazionale. L'indice è collegato ad un codice unico di identificazione del cittadino, attualmente individuato nel codice fiscale. L'indice delle anagrafi sarà realizzato e gestito dal Ministero dell'interno come un servizio accessibile in rete a tutti i comuni, i quali saranno tenuti a partecipare alla creazione dell'indice nazionale ed al suo aggiornamento. 16

17 L indice potrà consentire la realizzazione di servizi per il cittadino che richiedono una visione integrata delle anagrafi come i servizi elettorali, la carta di identità elettronica ed altri servizi collegati alla residenza. c) Notifica delle variazioni anagrafiche Le notifiche delle variazioni anagrafiche saranno comunicate dai comuni al gestore dell'indice o direttamente o per mezzo di un servizio di notifica eventi e con le stesse modalità con cui vengono comunicate alle altre amministrazioni eventualmente interessate. Un servizio di notifica eventi sarà realizzato come servizio a valore aggiunto della rete nazionale e, data la sua natura infrastrutturale, sarà gestito in modo cooperativo dai centri di gestione di ciascuna delle reti federate che la compongono Sistema di interscambio Catasto-Comuni Questa azione prevede il completamento del sistema di interscambio Catasto-Comuni di cui è stata realizzata, ad oggi, una soluzione funzionalmente completa accessibile attraverso il sito del Ministero delle Finanze (SISTER: Sistema Interscambio Territorio). Gli obiettivi del progetto sono: rendere facilmente accessibili i servizi degli Uffici del Territorio, quali visure e certificazioni catastali, visure ipotecarie, pratiche di accatastamento, di variazione catastali, sia ai comuni che ai cittadini; realizzare un servizio a valenza nazionale, di supporto alla predisposizione, validazione ed aggiornamento delle posizioni ICI, fruibile da comuni, cittadini, imprese, notai, professionisti, ecc.; rendere disponibile, su tutto il territorio nazionale, le banche dati geografiche di derivazione catastale, come base informativa condivisa per lo sviluppo di attività di pianificazione e valutazione sul territorio. Le azioni previste comportano: il potenziamento del sistema SISTER del Ministero delle Finanze, estendendone il collegamento a tutti i Comuni; la realizzazione di un servizio nazionale di supporto alla predisposizione, validazione ed aggiornamento di posizioni ICI, esteso, oltre che agli Enti locali, ai cittadini ed ai professionisti La carta d'identità elettronica La carta di identità elettronica sarà utilizzata non solo come documento di riconoscimento personale, ma anche come unica carta multifunzionale di accesso a tutti quei servizi, erogati per via telematica dalla pubblica amministrazione, che richiedono la identificazione certa dell utilizzatore. La firma digitale integrata all interno della carta di identità elettronica, costituirà la principale modalità di accesso sicuro alle informazioni ed ai servizi on line erogati da 17

18 soggetti pubblici e privati, e potrà garantire la validità legale dei documenti trasmessi per via telematica. A conclusione dello studio di fattibilità condotto da AIPA, il Ministero dell Interno attiverà, in collaborazione con alcuni comuni, un progetto finalizzato alla sperimentazione del circuito di emissione della carta d identità elettronica Promozione della firma digitale Questa azione è rivolta a promuovere la diffusione e l uso della firma digitale. Essendo già stato costituito l albo dei certificatori e garantita la interoperabilità degli stessi, la firma digitale rappresenta ormai una realtà completamente fruibile, sia da parte dei cittadini e delle imprese, ma soprattutto da parte dei dipendenti pubblici cui è attribuito potere di firma La gestione elettronica dei flussi documentali Il D.P.R. n.428/98, la Direttiva del Presidente del Consiglio dei Ministri del 28 ottobre 1999 sulla gestione informatica dei flussi documentali nelle Pubbliche Amministrazioni e le regole tecniche, forniscono un fondamentale impulso alle Amministrazioni centrali, regionali e locali nella concreta attuazione del quadro normativo ora esistente. L azione prevede la realizzazione dei sistemi di protocollo nelle più importanti Pubbliche Amministrazioni Locali (Regioni e principali Comuni), per tutti i moduli previsti dal progetto: registrazione di protocollo, gestione documentale, archiviazione. È, inoltre, previsto il collegamento di tali sistemi via rete nazionale con i sistemi di protocollo delle Amministrazioni Centrali creando così la rete documentale, e realizzando progetti pilota di trasmissione delle principali informazioni in forma strutturata attraverso l utilizzo degli standard di mercato e-procurement Attraverso questo nuovo strumento si vogliono raggiungere i seguenti obiettivi: ridurre la spesa per le forniture di beni e servizi nella Pubblica Amministrazione; rendere le procedure più snelle e più rapide; garantire la massima trasparenza nelle operazioni di gara; aprire il mercato delle forniture e renderlo più competitivo. Le norme di riferimento sono contenute nell art. 24 della Legge 340/2000. Tali disposizioni, permettono, anche con riferimento alla nuova disciplina introdotta dall art. 26 della Legge n. 488 del 1999 di attivare aste telematiche ove si potranno incontrare offerta e domanda, in tempo reale, garantendo sempre all amministrazione le migliori condizioni di mercato. La pubblicazione dei bandi di gara potrà avvenire in via telematica e verranno emanate delle norme regolamentari per rendere compatibile tale nuovo sistema con la disciplina attuale della contabilità generale dello Stato. 18

19 Azioni di formazione Il Piano prevede due tipologie di azioni sul fondamentale tema della formazione. a) Formazione di base Questa azione è focalizzata alla formazione dei pubblici dipendenti come utilizzatori delle tecnologie informatiche. Il Piano si propone di: fornire una alfabetizzazione informatica a tutti i dipendenti; fornire una migliore conoscenza a coloro che abbiano già delle nozioni di base. È prevista l erogazione di 30 ore di corso per ogni dipendente, sia per chi segue il percorso di alfabetizzazione, che per chi segue il percorso avanzato. Inizialmente sarà interessata una popolazione di circa dipendenti pubblici. b) Formazione specialistica L azione si propone di accrescere e aggiornare le conoscenze specialistiche di coloro che gestiscono le infrastrutture informatiche, in particolare dei gestori delle infrastrutture di rete e degli operatori di protocollo e degli operatori degli uffici per le relazioni con il pubblico per recepire i nuovi servizi forniti dalla innovazione normativa e procedurale. 1.3Lo stato di attuazione del Piano 1.3.1La gestione del piano Il Piano di azione di e-government è stato approvato il 23 giugno 2000 dal Comitato dei Ministri per la Società dell Informazione e il 20 luglio dalla Conferenza Unificata La gestione del Piano è affidata a due specifici organismi : L Unità Strategica, costituita il 25 settembre 2000 presso il Dipartimento della Funzione Pubblica, ha il compito di: formulare la visione; elaborare gli indirizzi strategici del programma di e-government; assicurare il coinvolgimento di tutte le amministrazioni. Il Centro tecnico della RUPA, operante dal 9 dicembre 2000 presso la Presidenza del Consiglio dei Ministri come struttura di gestione operativa del piano di e-government, ha compiti di: pianificazione e gestione del Programma di Lavoro di e-government; realizzazione dei servizi infrastrutturali; direzione lavori dei progetti che coinvolgono più amministrazioni. 19

20 1.3.2I finanziamenti previsti In termini tecnici, organizzativi e soprattutto finanziari, il piano si aggiunge, e non si sostituisce, ai piani di informatizzazione che ogni singola amministrazione ha elaborato e gestisce autonomamente ed è principalmente finalizzato ad indirizzarli verso obiettivi sinergici e verso la erogazione di servizi integrati da parte di più amministrazioni. Pertanto i finanziamenti previsti dal Piano devono essere considerati aggiuntivi rispetto a quanto già previsto dalle singole amministrazioni. L attuale stato dei finanziamenti prevede una spesa nell arco dei prossimi due anni di 800 mld (ridotti rispetto ai 1335 mld del piano originale), destinati al raggiungimento, in tempi definiti, di obiettivi precisi: 500 mld per i progetti delle Amministrazioni Locali: Regioni, Province, Comuni, Comunità Montane, ecc.; 113 mld per realizzare i servizi infrastrutturali della Rete Nazionale (68 mld) e per i portali per servizi nazionali (45 mld); 115 mdl per progetti di interesse generale: carta d identità, firma elettronica, e- procurement, indice delle anagrafi, ecc.; 72 mld per la formazione di base dei dipendenti pubblici La realizzazione delle infrastrutture la rete nazionale L architettura tecnica della Rete Nazionale è stata definita dall Unità Strategica. Il documento che ne riassume i principi, di cui l architettura tecnica costituisce un allegato, è stato approvato dalla Conferenza Unificata il 18 gennaio 2001 e rappresenta un accordo vincolante per tutte le amministrazioni. La Rete Nazionale è configurata come una federazione di tutte le reti di area geografica esistenti, cioè delle reti regionali (RUPAR), o sub-regionali, di tutte le reti di settore o categoria e della Rete della Pubblica Amministrazione Centrale (RUPA). Dovrà essere emanata a breve la direttiva che definisce le clausole contrattuali ed i livelli di servizio che le amministrazioni locali dovranno richiedere ai fornitori di servizi di trasporto IP per essere selezionati come provider della Rete Nazionale. Con la direttiva verrà raggiunto l obiettivo di rendere disponibile l infrastruttura abilitante per il sistema di connettività nazionale. Il Piano prevede che ogni amministrazione si doti entro il 2002 della connessione a Internet per erogare i servizi B2C a cittadini ed imprese, e della connessione alla Rete Nazionale per erogare servizi B2B alle altre amministrazioni I progetti delle Regioni e degli Enti locali Il Piano, come visto, assegna un ruolo fondamentale alle Regioni ed agli Enti locali. 20

21 Anche in termini di finanziamenti la parte più cospicua è relativa a tali strutture. Il Piano, però, definisce una serie di condizioni abilitanti allo sviluppo dei progetti ed all assegnazione dei conseguenti fondi. Le Amministrazioni Locali, preferibilmente in forma associata, potranno proporre per il finanziamento progetti coerenti con la visione, le finalità e le priorità del Piano di e- government. Essi avranno come prerequisito: il collegamento alla Rete Nazionale e la realizzazione di sistemi informatici per consentire alle altre amministrazioni le visure e l accesso ai propri servizi interattivi (servizi B2B); il collegamento a Internet per rendere possibile a cittadini ed imprese la compilazione e l invio telematico di moduli per le richieste di servizio (servizi B2C) Ripartizione dei fondi per i Progetti delle Regioni ed Enti Locali Nell ambito dell assegnazione di fondi sopra indicata, gli stanziamenti sono così ripartiti: Servizi delle Regioni 150 mld Informatizzazione Enti locali 300 mld Accesso ai servizi anagrafici 20 mld Indice anagrafico 15 mld Servizio notifica eventi 15 mld Totale Enti locali 500 mld Modalità di assegnazione dei fondi Le risorse finanziarie previste dalle misure del piano di azione saranno trasferite alle Regioni e agli Enti locali sulla base di modalità e criteri generali. (In allegato il documento del Comitato di Indirizzo con le indicazioni per l assegnazione dei fondi Allegato1) Si ricapitolano i criteri generali di assegnazione delle risorse e di valutazione dei progetti: concentrare le risorse assegnandole selettivamente a specifici progetti di attuazione (evitare finanziamenti a pioggia ) in grado di promuovere l integrazione dell Amministrazione Pubblica anche a livello locale; garantire l interconnessione dell intera PA (Centrale e Locale) in tempi brevi; finanziare ed organizzare la diffusione di soluzioni trasferibili ed in fase di avanzata realizzazione, in grado di essere adottati a condizioni vantaggiose da altre amministrazioni; valorizzare le realizzazioni già operative; favorire l aggregazione dei Comuni di piccole dimensioni; 21

22 promuovere il partenariato tra amministrazioni e la partecipazione dei privati; monitorare l utilizzo delle risorse e ridistribuire quelle non utilizzate; consentire risparmi ed economie nell impianto e nell esercizio dei sistemi informativi, informatici e telematici La valutazione dei progetti presentati avverrà sulla base di criteri verificabili, tra i quali: possibilità di valutare nel tempo i risultati del progetto sulla base di indicatori predeterminati; effettiva fruibilità del risultato da parte dell utente; valorizzazione del territorio, sviluppo del sistema produttivo, sostegno all attività delle comunità locali (cittadini, gruppi di interesse); presenza di accordi specifici con il sistema produttivo locale; eventuali esperienze già realizzate o in corso di realizzazione; affidabilità della soluzione tecnico-organizzativa per la realizzazione del progetto; qualità del modello di gestione dei servizi realizzati. 22

23 2.OBIETTIVI DELLO STUDIO SPECIFICI ED IN RELAZIONE AL PIANO DI E- GOVERNMENT 2.1Obiettivi e contenuti generali degli SDF in relazione alle diverse disposizioni vigenti nella PA. Obiettivo degli Studi di Fattibilità è quello di fornire all'amministrazione l insieme delle informazioni necessarie per valutare la realizzabilità dell idea progettuale e stimare il conseguente investimento. Le informazioni chiave per valutare il progetto riguardano la fattibilità tecnica e organizzativa, i benefici, i costi, i rischi, le scadenze temporali. In termini generali, secondo quanto anche indicato dall AIPA, per rispondere a questo obiettivo, gli SDF devono indirizzare i seguenti temi: Rendere esplicite le condizioni che rendono conveniente l effettuazione di progetti per la realizzazione di sistemi informativi automatizzati e l erogazione di servizi informatici tesi al miglioramento dei processi di servizio delle amministrazioni, alla risoluzione di problematiche rilevanti e alla soddisfazione delle esigenze degli utenti. In particolare è fondamentale chiarire i benefici attesi dal progetto in termini di efficacia, efficienza e risparmi economici, e come essi rispondono agli obiettivi di miglioramento individuati, stimare i costi di impianto e di esercizio, individuare e valutare i rischi del progetto e correlare tutti questi elementi. Dare concretezza all ipotesi progettuale, delineando il processo di passaggio dallo stato attuale allo stato finale corrispondente alle attese. In particolare è fondamentale verificare l esistenza di una adeguata soluzione tecnico-organizzativa situata all interno dei vincoli economici e temporali dati, anche attraverso il confronto tra soluzioni diverse e la scelta tra di esse sulla base di criteri esplicitati e predefiniti, nonché fornire elementi oggettivi per la definizione dell eventuale ricorso al mercato ed alle sue modalità. Dal punto di vista tecnico, negli studi di fattibilità si troveranno, quindi, le indicazioni relative a: requisiti funzionali, di sicurezza e di qualità del sistema informativo da realizzare; specifiche globali del sistema informativo da realizzare; segmentazione del progetto; riepilogo delle acquisizioni e realizzazioni previste (configurazione del progetto); piano di massima del progetto (piano dei rilasci, punti di controllo, scadenze temporali); 23

24 criteri per la determinazione della tipologia delle forniture, sulla base delle specifiche funzionali del Progetto; definizione di eventuali vincoli inerenti le modalità di approvvigionamento sulla base delle specifiche funzionali del Progetto; stima dei costi. 2.2Obiettivi specifici dello SDF in relazione al Piano di e-government Con riferimento a quanto indicato nel capitolo1, il presente SDF si pone l obiettivo specifico di favorire l accessibilità ai dati delle pubbliche amministrazioni ed attuare la necessaria interconnessione tra le stesse. Nello specifico il presente studio di fattibilità ha l obiettivo di individuare, con riferimento agli ambiti indicati e ad uno specifico contesto territoriale, delle concrete possibilità di attivazione di flussi informativi tra enti diversi, per un sottoinsieme di funzioni per le quali si ravvisi la possibilità di raggiungere, in tempi brevi, risultati significativi e generalizzabili. Uno dei punti fondamentali dello SDF è quello riguardante le azioni per il miglioramento della qualità e dell accessibilità dei dati pubblici, in attuazione, anche delle Linee strategiche emanate dall AIPA per il triennio che, nello specifico, prevedono: MIGLIORARE LA QUALITÀ DEI DATI Qualità dei dati significa, in particolare: a) correttezza: ossia non solo predefinizione degli standard informativi da rispettare in sede di prima acquisizione, ma anche l esistenza di una fase sistematica di controllo e di validazione dei dati acquisiti; b) coerenza e completezza: ossia l idoneità dei dati di corrispondere all obiettivo informativo da soddisfare. Occorre, a questo scopo, evitare di tenere in vita più basi dati (o anche a supporti cartacei) che si riferiscono ad argomenti simili e che si differenziano tra loro per aspetti marginali; c) tempestività di aggiornamento; d) censire, anche con l ausilio di supporti informatici oggi disponibili, le carenze riscontrabili nelle basi dati di propria pertinenza; e) separare nettamente le responsabilità attinenti alle applicazioni da quelle relative alle basi dati; f) attivare i necessari interventi migliorativi delle basi dati. 24

25 Il problema della qualità ed accessibilità ai dati delle PA è stato ripreso dall Autorità per l informatica anche nelle nuove Linee strategiche che riaffrontano il problema con particolare riferimento agli aspetti della gestione dei dati, della sicurezza e della tutela della privacy (nell allegato 2 si fornisce una sintesi delle linee strategiche dell AIPA e ). In relazione a quanto sopra lo studio di fattibilità individuerà i seguenti elementi: Dal punto di vista metodologico ed architetturale: architetture di riferimento per l interscambio dei dati; analisi per la definizione di standard per assicurare la piena fruibilità e la condivisione dei dati pubblici (interscambio). Dal punto di vista dei contenuti del progetto: la matrice dati/materie/fornitori/fruitori per gli argomenti individuati, ad un primo livello macro ; il sottoinsieme di informazioni di più stretto interesse, sul quale avviare la sperimentazione. Su questo sottoinsieme l analisi della matrice sarà sviluppata ad livello di dettaglio maggiore; gli enti e le funzioni interessate; l ambito territoriale di riferimento. Dal punto di vista della pianificazione del progetto: le operazioni necessarie per l avvio della sperimentazione (analisi organizzativa, individuazione delle funzionalità e dell'architettura del sistema di interscambio, piano generale dei tempi di realizzazione del sistema); la definizione dei criteri di monitoraggio e valutazione degli effetti. Nello sviluppo dello SDF si è cercato di porre una specifica attenzione a due aspetti fondamentali che possono condizionare in modo determinante lo sviluppo del Piano di e- government sia a livello regionale che nazionale: La immediata realizzabilità di quanto progettato ed indicato. Specifici capitoli dello SDF indirizzano le possibili sperimentazioni per l implementazione di quanto proposto La possibilità di riutilizzabilita delle soluzioni proposte. Sulla base di quanto previsto dal Piano di e-government e delle indicazioni fornite dall Unità Strategica di sviluppo del Piano, nello sviluppo del progetto si è tenuta in particolare evidenza la necessità di fornire indicazioni che, pur applicabili al contesto territoriale di riferimento, fossero valide anche in termini più generali. 25

26 3.IL CONTESTO LEGISLATIVO E NORMATIVO DI RIFERIMENTO Vario e diversificato è il contesto legislativo e normativo di riferimento per l attuazione di un processo di ammodernamento della PA e per lo sviluppo di servizi in rete. 26

27 Non è possibile, in questa sede, affrontare in termini completi tutto il panorama di riferimento; si desiderano, però, fornire alcuni elementi di indirizzo per una maggiore completezza ed applicabilità dello SDF in oggetto. Il contesto normativo di riferimento si può ricondurre, a nostro avviso, a tre linee tematiche principali: 3.1Norme inerenti il processo di decentramento e semplificazione della PA 3.1.1Leggi Bassanini sul decentramento e la semplificazione della Pubblica Amministrazione. Legge delega n.59 del 15/3/1997 (Delega al Governo per il conferimento di funzioni e compiti alle Regioni ed Enti locali, per la riforma della PA e per la semplificazione amministrativa). Legge n.127 del 15/5/1995 (Misure inerenti lo snellimento delle attività amministrative e dei procedimenti di decisione e di controllo). Legge n.191 del 16/6/1998 (Modifiche ed integrazioni delle precedenti leggi). Legge n.50 del 8/3/1999 (Delegificazione e Testi Unici di norme concernenti procedimenti amministrativi Legge di semplificazione 1998). Legge n.340 del 24/11/2000 (Disposizioni per la delegificazione di norme e per la semplificazione di procedimenti amministrativi Legge di semplificazione 1999 In particolare, per quest ultima legge, si ricorda l art. 25 (Accesso alle banche dati pubbliche): 1. Le pubbliche amministrazioni di cui all articolo 1, comma 2, del decreto legislativo 3 febbraio 1993, n. 29, che siano titolari di programmi applicativi realizzati su specifiche indicazioni del committente pubblico, hanno facoltà di darli in uso gratuito ad altre amministrazioni pubbliche, che li adattano alle proprie esigenze. 2. Le pubbliche amministrazioni di cui all articolo 1, comma 2, del decreto legislativo n. 29 del 1993 hanno accesso gratuito ai dati contenuti in pubblici registri, elenchi, atti o documenti da chiunque conoscibili Il TU sulla documentazione amministrativa DPR 28 dicembre 2000 n.445 (Decreto del Presidente della Repubblica recante il Testo Unico delle disposizioni legislative e regolamentari in materia di documentazione amministrativa). Il Testo Unico, frutto del lavoro del Nucleo per la semplificazione delle norme e delle procedure e del Progetto "semplifichiamo" del Dipartimento della Funzione Pubblica, istituito dalla legge n.50 del 1999, è una normativa di fondamentale riferimento per tutte le attività delle PA. 27

28 Infatti con il Testo Unico si sono raccolte e sistemate in un unico testo, che ha valore "misto" di legge e di regolamento, tutte le norme che riguardano la materia della documentazione amministrativa (dai certificati alla firma digitale). Il Piano d'azione di e-government contiene numerose misure finalizzate all'eliminazione dei flussi cartacei nei rapporti sia tra utenti e Pubblica Amministrazione, sia tra amministrazioni stesse. L'interconnessione tra gli enti viene vista come condizione essenziale per il miglioramento dei servizi a cittadini e imprese, e come fattore di sviluppo di nuovi servizi basati sulle moderne tecnologie. Il Piano d'azione ha infatti come suo fondamento la stretta interazione telematica tra backoffice e front-office, e cioè la messa a disposizione dei dati da parte di tutte le amministrazioni che li detengono nei loro archivi informatici a quelle che erogano servizi all'utente finale, spesso basandosi proprio sui dati detenuti da altre amministrazioni. È evidente pertanto l'impatto del Piano d'azione sull'intera tematica della documentazione amministrativa, ed in particolare sull'autocertificazione e sull'acquisizione d'ufficio dei dati riguardanti il cittadino. Il Piano auspica infatti che l'acquisizione d'ufficio per via telematica diventi in prospettiva un normale e facile strumento di lavoro delle amministrazioni, arrivando così ad una totale "decertificazione" nei rapporti con gli utenti. In tale visione: il cittadino potrà ottenere ogni servizio pubblico, cui ha titolo, rivolgendosi ad una qualsiasi amministrazione di front-office abilitata al servizio, indipendentemente da ogni vincolo di competenza territoriale o di residenza; all'atto della richiesta di un servizio, il cittadino, oltre agli strumenti di identificazione personale, non dovrà fornire alcuna informazione che lo riguarda e che sia già in possesso di una qualsiasi amministrazione dello Stato; il cittadino non dovrà conoscere come lo Stato è organizzato per la erogazione dei servizi o a quali amministrazioni si deve rivolgere, ma potrà richiedere servizi esclusivamente in base alle proprie esigenze, non in base alla conoscenza di quale amministrazione fa che cosa; il cittadino dovrà poter comunicare solo una volta all'amministrazione, nel momento in cui si verificano, le variazioni che corrispondono ad eventi della vita propria o, quando ne ha titolo, della vita di terzi. Questa comunicazione produrrà automaticamente tutti gli effetti conseguenti. In tale contesto il TU stabilisce una serie di disposizioni di fondamentale importanza per lo sviluppo del Piano, di cui si riassumono le principali: Art. 9 (Documenti informatici nelle pubbliche amministrazioni). Le Pubbliche Amministrazioni provvedono a definire e a rendere disponibili per via telematica moduli e formulari elettronici validi ad ogni effetto di legge. Art. 10 (Forma ed efficacia del documento informatico). 28

29 Il documento informatico sottoscritto con firma digitale soddisfa il requisito legale della forma scritta e ha efficacia probatoria. Art. 14 (Trasmissione del documento informatico) Il documento informatico trasmesso per via telematica si intende inviato e pervenuto al destinatario, se trasmesso all'indirizzo elettronico da questi dichiarato. La trasmissione del documento informatico per via telematica, con modalità che assicurino la avvenuta consegna, equivale alla notificazione per mezzo della posta nei casi consentiti dalla legge. Art. 20 (Copie di atti e documenti informatici) Gli obblighi di esibizione di documenti sono soddisfatti a mezzo di documenti informatici. Art. 23 (Firma digitale) La firma digitale sul documento informatico equivale alla firma apposta sul documento cartaceo. Art. 24 (Firma digitale autenticata) La presentazione di un documento informatico con firma digitale e marca temporale è valida a tutti gli effetti di legge. Art. 25 (Firma di documenti informatici delle pubbliche amministrazioni) In tutti i documenti informatici della pubblica amministrazione la firma digitale sostituisce la firma autografa. Art. 38 (Modalità di invio e sottoscrizione delle istanze) Tutte le istanze e le dichiarazioni da presentare alla pubblica amministrazione possono essere inviate anche per fax e via telematica. Le istanze e le dichiarazioni inviate per via telematica sono valide se sottoscritte mediante la firma digitale o quando il sottoscrittore è identificato dal sistema informatico con l uso della carta di identità elettronica. Art. 43 (Accertamenti d'ufficio) Le amministrazioni pubbliche non possono richiedere atti o certificati concernenti stati, qualità personali e fatti che siano attestati in documenti già in loro possesso o che comunque esse siano tenute a certificare. In luogo di tali atti o certificati sono tenute ad acquisire d ufficio le relative informazioni. Quando l amministrazione procedente opera l acquisizione d ufficio può procedere anche per fax o per via telematica. Si considera operata per finalità di rilevante interesse pubblico la consultazione diretta, da parte di una pubblica amministrazione, degli archivi dell amministrazione certificante finalizzata all accertamento d ufficio di stati qualità e fatti ovvero al controllo sulle dichiarazioni sostitutive presentate dai cittadini. 29

30 Le amministrazioni certificanti sono tenute a consentire alle amministrazioni procedenti, senza oneri, la consultazione per via telematica dei loro archivi informatici. I documenti trasmessi da chiunque ad una pubblica amministrazione tramite fax, o con altro mezzo telematico o informatico idoneo ad accertarne la fonte di provenienza, soddisfano il requisito della forma scritta e la loro trasmissione non deve essere seguita da quella del documento originale. Art. 50 (Attuazione dei sistemi) Le pubbliche amministrazioni provvedono ad introdurre nei piani di sviluppo dei sistemi informativi automatizzati progetti per la realizzazione di sistemi di protocollo informatico in attuazione delle disposizioni del presente testo unico. Le pubbliche amministrazioni provvedono entro il 1 gennaio 2004 a realizzare sistemi informativi automatizzati finalizzati alla gestione del protocollo informatico in conformità alle disposizioni del presente Testo Unico Le norme che regolano ed indirizzano specifici aspetti della semplificazione amministrativa Tali norme, che sono state di fatto unificate ed armonizzate nel TU sopra indicato, si riportano a titolo di completezza del quadro normativo. Rimangono, comunque validi i regolamenti tecnici definiti a seguito ed a completamento di tali norme ed indicati nel seguito.. Firma digitale DPR n.513 del 10/11/1997 (Regolamento per la formazione, l archiviazione e la trasmissione di documenti con strumenti informatici e telematici) e successivo DPCM dell 8/2/1999 (Regole tecniche per la formazione, la trasmissione, la conservazione, la duplicazione, la riproduzione, la validazione dei documenti informatici) elaborato dall AIPA. Circolare AIPA del 19/6/2000 (Linee guida per la interoperabilità tra i certificatori iscritti nell elenco pubblico di cui all art.8 del DPR n.513) 30

31 Protocollo informatico DPR n.428 del 20/10/1998 (Regolamento per la gestione del protocollo informatico da parte della PA) Carta di identità elettronica Legge 127/1997 (art.2) e Legge 191/98 (art.2) DPCM n.437 del 22/10/1999 (Regolamento recante caratteristiche e modalità per il rilascio della Carta di identità elettronica e del documento di identità elettronico) Telelavoro DPR n.70 del 8\3\1999 (Regolamento recante disciplina del telelavoro nelle Pubbliche Amministrazioni a norma dell art. 4 della legge 191/98). 3.2Norme inerenti lo sviluppo dell informatica nella PA e l acquisizione di forniture informatiche A tale categoria appartengono tutte le normative, a carattere sia europeo che nazionale che regolano l acquisizione di beni e servizi informatici da parte delle pubbliche amministrazioni, nonché tutte le deliberazioni emanate dall AIPA ed inerenti sia aspetti tecnici che contrattuali. In allegato (allegato 3) al presente SDF si riporta l elenco delle principali normative in materia suddivise tra : Normativa Comunitaria Normativa Nazionale Circolari dell'autorità per l'informatica nella Pubblica Amministrazione 3.3Norme inerenti la sicurezza dei sistemi informativi e la tutela della privacy La legislazione italiana relativa alla sicurezza informatica ed alla tutela della privacy poggia, oltre il contesto legislativo in precedenza ricordato, su tre specifiche leggi fondamentali, che possono costituire la griglia di riferimento normativo: D. Lgs. n.518 del 1992 che modifica il Regio Decreto n.633 del 1941, relativo al diritto d autore, integrandolo con norme relative alla tutela giuridica dei programmi per elaboratore. Legge n.547 del 1993 che modifica il codice penale italiano introducendo i cosiddetti computers crimes. Legge n.675 del 1996 che disciplina il trattamento dei dati personali. A queste è opportuno aggiungere una delle principali leggi in materia di trasparenza amministrativa e di diritto d accesso: 31

32 Legge 7 agosto 1990 n.241, Nuove norme in materia di procedimento amministrativo e di diritto di accesso ai documenti amministrativi. Inoltre sono da ricordare le precedenti leggi e decreti in materia: Regio Decreto 22 aprile 1941 n.633 Legge 1 aprile 1981 n.121 D.P.C.M. 15 febbraio 1989 Decreto legge 3 maggio 1991 n.143 Decreto legge 13 maggio 1991 n.152 D.P.R. 27 giugno 1992 n.352 Decreto legislativo 29 marzo 1993 n.39 Decreto legislativo 3 febbraio 1993 n.29 32

33 4.INQUADRAMENTO SULLE AZIONI NECESSARIE PER IL MIGLIORAMENTO DELLA DISPONIBILITÀ DI DATI PUBBLICI 4.1Introduzione Ogni Amministrazione Pubblica e/o Ente pubblico gestisce informazioni che possiamo distinguere in maniera molto sintetica in due macro gruppi: informazioni necessarie ad erogare servizi ai cittadini; informazioni necessarie agli Enti/Amministrazioni per i propri processi interni, spesso finalizzati alla propria autogestione. La demarcazione tra processi interni e servizi ai cittadini è talvolta decisamente sfumata, specialmente quando coinvolge un dipendente dell Amministrazione che si rivolge allo stesso Ente per l erogazione di un qualche servizio (ad esempio la propria pratica pensionistica). In questi casi è vero che l Ente e/o Amministrazione gestisce il problema con propri processi interni e quindi con informazioni interne, ma comunque la finalità è orientata a fornire un servizio ad un cittadino. Nel documento circa le linee strategiche per il triennio fornite da AIPA, la definizione di dato pubblico è limitata alle sole informazioni per dare servizi ai cittadini, e sono implicitamente esclusi i dati necessari ai processi di autoamministrazione. Nel resto di questo capitolo ci limiteremo, quindi, a questa tipologia d informazione, che si ritiene comprensiva di quei dati interni che sono comunque orientati al cittadino dipendente dell Amministrazione. 4.2Diverse modalità per i dati In generale le informazioni in possesso alla pubblica amministrazione possono essere gestite e rese disponibili tramite diverse modalità: modalità elettronica/digitale, nel quale rientrano quindi i dati gestiti o gestibili via computer; modalità non elettronica/digitale, ovvero i dati conservati su supporto cartaceo e/o similari. Nei processi che coinvolgono i servizi ai cittadini possono esserci entrambe le tipologie, e spesso il dato cartaceo (ovvero il modulo che il cittadino riempie per richiedere il servizio) è la prima informazione che si colleziona, si riproduce e si archivia. Al fine di erogare servizi in modo efficiente un primo requisito per la Pubblica Amministrazione è la disponibilità dei dati d interesse in modalità digitale. Probabilmente la disponibilità dei dati sensibili in modalità informatica è già una realtà nella maggioranza dei casi, questo perché l Amministrazione aveva l informazione già 33

34 nel modo digitale, oppure ha provveduto/provvede alla digitalizzazione di quanto necessario. La disponibilità dei dati per l erogazione dei servizi ai cittadini in formato digitale è da ritenersi l azione fondamentale per il miglioramento della qualità dei dati pubblici. E da ritenersi un azione necessaria ma non sufficiente: si deve disporre di dati digitali per essere abilitati all erogazione di servizi ai cittadini in modo efficiente, ma avere i dati in formato digitale non garantisce di per sé che i servizi che saranno forniti siano efficienti. Nei prossimi paragrafi si entrerà in maggior dettaglio sul tema sollevato. 4.3Le raccomandazioni dell AIPA Nel documento citato in precedenza (linee strategiche per il triennio e seguenti), si introduce un principio copernicano di straordinaria rilevanza: l Amministrazione Pubblica opera a servizio del cittadino e non viceversa. Il cittadino si rivolge alla Pubblica Amministrazione per l erogazione di servizi (pratiche pensionistiche, richiesta di certificati, notifica di azioni,...). La Pubblica Amministrazione deve poter fornire le prestazioni richieste senza dover chiedere nuovamente informazioni di cui è già in possesso. Non è consentito ribaltare al cittadino la propria inefficienza e quindi la richiesta di ulteriori informazioni (certificati e quanto altro) organizzate e formattate secondo le esigenze della Pubblica Amministrazione stessa. Le conseguenze di questo differente approccio di base sono pervasive in tutti i processi che riguardano l interazione tra il cittadino e la Pubblica Amministrazione nonché tra le diverse Pubbliche Amministrazioni stesse. La nuova filosofia proposta da queste linee strategiche introduce il concetto di unico sistema informativo delle Pubbliche Amministrazioni. In uno degli ultimi censimenti di AIPA circa l informatizzazione della Pubblica Amministrazione (centrale e locale) emerge una penetrazione totale dello strumento informatico. Il 100% della Pubblica Amministrazione Centrale è dotata di strumenti informatici per i propri processi e per i servizi al cittadino. La situazione è altrettanto buona per gli Enti locali, soprattutto se di certe dimensioni. Quello che invece manca è come i diversi sistemi possano colloquiare tra loro. Spesso la comunicazione avviene via carta, utilizzando formati di scambio intermedio. I sistemi informativi sono quindi scollegati e non comunicanti e richiedono l intervento di operatori per creare e compilare i moduli di colloquio. Il modello proposto da AIPA dà una notevole forza agli enti locali. Gli Enti locali sono visti come presidio del territorio e quindi la naturale interfaccia dei cittadini e delle imprese nella richiesta di servizi e/o comunicazione di informazioni. La Pubblica Amministrazione Centrale può essere invece coinvolta come back office, in altre parole si fa carico del processo per l erogazione del servizio, riceve i dati e richieste del cittadino dagli Enti locali o è in grado di procurarseli interagendo con altre entità (locali o centrali), infine eroga il servizio stesso tramite l Ente locale. L operatività descritta ha senso solo se le Pubbliche Amministrazioni sono in grado di scambiarsi i dati dei cittadini. 34

35 Le informazioni possono essere efficacemente condivise e/o scambiate tra diverse organizzazioni pubbliche se e solo se i dati sono organizzati secondo schemi che facilitino lo scambio, ma è altrettanto importante la qualità dei dati stessi. Nel documento citato precedentemente si afferma che La qualità dei dati contenuti nelle basi informative è di fondamentale importanza nel processo di modernizzazione della Pubblica Amministrazione. I dati devono essere condivisi, ma si impone uno standard di qualità per gli stessi. Gli enti e le amministrazioni che sono i proprietari dei dati hanno completa responsabilità circa la loro qualità intrinseca. La qualità dei dati significa in particolare: correttezza; coerenza e completezza; tempestività di aggiornamento; censimento delle carenze; attribuzione di responsabilità; definizione di piani di miglioramento. Nei seguenti paragrafi si entrerà in maggior dettaglio e si identificheranno precise azioni per il conseguimento degli obiettivi presentati. 4.4Correttezza dei dati Con il termine correttezza dei dati si intende: la definizione di standard informativi da rispettare durante la fase di acquisizione delle informazioni; la presenza di una fase sistematica di controllo e validazione dei dati acquisiti. Uno dei problemi principali dei sistemi informativi nelle Pubblica Amministrazione è l evoluzione dei programmi applicativi senza tenere conto di quanto registrato in precedenza. L evoluzione dei sistemi informativi è determinata da: cambiamenti nelle leggi, per cui si richiedono ulteriori informazioni da registrare e/o la definizione di nuovi processi che produrranno informazioni diverse o aggiuntive; adeguamento a nuovi standard tecnologici, per cui il sistema informativo è rivisto alla luce di nuovi paradigmi architetturali software e/o hardware secondo tendenze del mercato informatico; introduzione di standard di sicurezza logica e/o fisica; eventuali ridefinizioni di strutture interne della Pubblica Amministrazione (passaggi di competenze, armonizzazione tra processi, ecc.). 35

36 In tutti questi casi può essere decisa l implementazione di un nuovo programma software per la gestione dei processi che si traduce poi in un diverso modo di acquisire e gestire i dati. Cambiare la struttura, il processo, o semplicemente il supporto tecnologico dei dati pubblici obbliga la Pubblica Amministrazione a migrare le informazioni nei nuovi formati, utilizzando opportuni criteri per il riempimento dei dati mancanti in precedenza. I dati che sono acquisiti tramite un qualunque strumento informatico possono essere soggetti ad errori. Spesso questi errori si traducono in grossi problemi per il cittadino o l impresa che si deve fare carico in prima persona della rimozione dell errore. La definizione di un controllo sistematico sui dati acquisiti e la loro validazione è certamente un valido strumento per: certezza sulla veridicità dei dati di cui si è in possesso; evitare ridondanze nei dati della Pubblica Amministrazione; possibilità di servire meglio i cittadini e le imprese. In generale non è possibile stabilire come condurre un controllo sistematico e validare i dati, ciò dipende di fatto dall applicazione informatica stessa, ovvero dalla natura dei dati. Certo è che occorre aggiungere opportuni programmi che siano in grado di comparare le informazioni tra loro evidenziando opportunamente anomalie e/o incongruenze. Da quanto si è detto fino a questo punto, occorre censire le basi dati orientate ai servizi ai cittadini che si hanno nelle Pubbliche Amministrazioni, elencando possibilmente (azione 1): consistenza (numero di dati/record conservati); tipo di supporto, tecnologia della base di dati informatica; anno d ingresso in esercizi; ufficio/uffici responsabili; censimento degli standard informativi adottati nel corso del tempo e verifica di congruenza degli stessi; censimento delle attività di migrazione dei dati fatte dalle Pubbliche Amministrazioni (se ci sono state) nelle operazioni di adeguamento tecnologico o in generale per ridefinizione di processi; esistenza o meno di procedure di controllo sulla consistenza dei dati e loro validazione. Per quanto riguarda il controllo sulla consistenza dei dati, si devono fare ulteriori approfondimenti (azione 2): censimento, per database, di procedure di validazione dei contenuti, verifica delle seguenti proprietà: 36

37 - periodicità con la quale il test di consistenza è eseguito; - carattere del test (solo su ultimi dati inseriti, totale, altro); - entità coinvolte nelle prove (database esterni, documenti cartacei, altro); - modalità del test (manuale, automatico, misto); - azioni prese conseguentemente ai risultati (correzione manuale, correzione automatica, nessuna correzione, altro); - misura dell efficacia delle procedure di correzione e consistenza, tramite controlli sui dati per campioni statisticamente rappresentativi, o valutando il numero di incidenti con i cittadini e/o imprese. Qualora i database non siano controllati in alcuna maniera, occorrerà identificare le procedure da utilizzare e le modalità. Anche in questo caso è possibile misurare la bontà delle informazioni tramite il numero di casi di correzioni effettuate a seguito di segnalazioni di cittadini e/o imprese. In base ai risultati ottenuti sarà necessario definire attività sistemiche per la correzione e validazione tramite l utilizzo di altri database, o altre informazioni di cui è in possesso l Amministrazione. La definizione esatta delle procedure di test esula dagli scopi di questo documento e sarà possibile solo dopo la conoscenza dei database e del loro contenuto (azione 1). La definizione e la misura della correttezza è da considerarsi prioritario per il miglioramento della qualità dei dati della Pubblica Amministrazione. 4.5Coerenza e completezza Coerenza e completezza sono misure circa l idoneità dei dati a corrispondere all obiettivo informativo per cui sono definiti e raccolti. Processi della Pubblica Amministrazione definiti e/o informatizzati in tempi successivi possono aver determinato database (informatici o anche cartacei) logicamente distinti, ma che di fatto si differenziano per aspetti marginali. In questo caso si ha un evidente spreco di tempo e di risorse per la ricerca, ma è anche molto più facile commettere errori in fase di acquisizione e produzione dei dati. Identificare database e/o archivi con contenuto informativo molto simile è probabilmente un operazione facile. E sufficiente comparare i contenuti (record) e contare le occorrenze uguali o simili (dove simile è un criterio che deve essere opportunamente definito). Non è invece semplice fare in modo che database differenti per aspetti marginali possano essere fisicamente congiunti. Le informazioni sono prodotte o fruite all interno di processi della PA, archivi simili ma logicamente distinti probabilmente sono utilizzati all interno di processi diversi. Tentare di unificare database simili significa rivedere/unificare i processi. 37

38 Lo scenario proposto prevede l analisi dei processi prima ancora dei database, e l identificazione delle modalità di coesistenza dei processi su unica base dati oppure la confluenza di processi distinti in uno unico. Conseguono alcune azioni specifiche per gli enti coinvolti: Riconoscimento di database con differenze marginali: 1. Definizione del concetto simile, ed uguale, per cui due campi in record di database diversi possono essere ritenuti tali; 2. Definizione della percentuale di record uguali e/o simili (tra database distinti) per cui questi possono essere ritenuti con differenze marginali. Nel caso siano riconosciuti database con differenze marginali (ma comunque utilizzati entrambi), occorre comprendere la loro origine: 3. Definiti e/o utilizzati da processi diversi che interessano uffici diversi della PA (o area organizzativa); 4. Definiti e/o utilizzati da processi diversi che interessano lo stesso ufficio della PA (o area organizzativa); 5. Definiti e/o utilizzati dallo stesso processo. Identificazione dei supporti informatici: 6. Stesso tipo di database (stesso produttore software) 7. Diverso tipo di database (diverso produttore di software, oppure stesso produttore ma versioni non compatibili). In base ai risultati del censimento sarà possibile identificare le modalità con cui trattare il problema. Alcune possibilità sono: mantenere i processi distinti, mantenere i database distinti logicamente, ma di fatto unificarli (stesso database fisico) e utilizzare opportune soluzioni software per la gestione; mantenere i processi distinti, ma unificare a tutti gli effetti i database (logicamente e fisicamente) eventualmente ridisegnando le parti di software interessate; unificare i processi, i database, e il software di gestione. Altre possibilità ed azioni specifiche potranno essere esaminate in una fase di studio più approfondita. 4.6Tempestività di aggiornamento La tecnologia attuale consente di inserire dati freschi nelle basi dati pressoché all istante. Non è più giustificabile ritardare l aggiornamento delle informazioni, qualora l Amministrazione sia venuta in possesso di dati nuovi. La tempestività di aggiornamento ricopre un ruolo chiave sia in termini di servizi ai cittadini, sia per quanto riguarda l efficienza della Pubblica Amministrazione. 38

39 E chiaro che se esistono le tecnologie per un rapido inserimento dei dati nuovi, occorre verificare l esistenza o l applicabilità delle stesse nei diversi contesti delle PA. Non è detto che tutti i processi che usano o producono dati siano di fatto informatizzati e quindi in grado di aggiornare le basi dati. Se, ad esempio, esistono flussi di informazioni che un certo processo prevede solo su carta, è evidente che va previsto, in una qualche fase, la traduzione dei dati su opportuno supporto elettronico. Qualora il processo non istituzionalizzi questa funzione, le informazioni nuove ci sono, ma sono su carta e vengono tradotte in forma elettronica una volta alla settimana o una volta al mese ecc. Le azioni a carico delle PA sono le seguenti: censimento della frequenza con cui sono aggiornati i database identificati al punto 4.4; verifica se è registrato in una qualche forma la data dell ultimo aggiornamento; verifica delle modalità di aggiornamento, ovvero: - contestuale - in fasi successive pianificate e previste dal processo - in fasi successive casuali o non pianificate. Un diverso gruppo di azioni sono previste nel caso di processi che non prevedono l aggiornamento contestuale delle informazioni. E probabile che tali processi non abbiano un adeguato supporto informatico, ovvero non siano informatizzati affatto. Occorre verificare se è possibile migliorare il processo introducendo opportune fasi che prevedano la traduzione informatica dei dati (ad esempio l acquisizione tramite scanner del documento, inserimento manuale, ecc.) La modifica dei processi (e quindi dell organizzazione della PA che li presiede e gestisce), è comunque un aspetto decisamente complesso che non si intende risolvere in questo paragrafo. 4.7Censimento delle carenze L AIPA prevede una specifica azione per l identificazione delle carenze dei database di pertinenza delle PA. Esistono diverse applicazioni software in grado di evidenziare carenze nei dati, occorrenze anomale e/o buchi nell informazione. Nei paragrafi precedenti si sono già descritte le azioni specifiche per identificare e censire queste carenze, si puntualizza in questa occasione la necessità di compiere questo controllo con una periodicità definita. Le carenze riscontrate possono originarsi per lacune nel sistema informativo e/o improprio utilizzo dello stesso da parte degli addetti. L attività sistemica di censimento permetterà di definire il grado di affidabilità della base dati, oltre che aiutare nell identificazione e soluzione della causa del problema. 39

40 4.8Definizione delle responsabilità La raccomandazione dell AIPA è di separare nettamente le responsabilità attinenti alle applicazioni da quelle attinenti alle basi di dati. La separazione delle responsabilità permetterebbe un maggior controllo su tutti i punti elencati precedentemente. Un esempio, se l applicazione deve essere modificata per una ragione qualsiasi, il responsabile della base dati dovrà garantire che comunque sia preservata la correttezza, la coerenza e completezza, ecc. In questo scenario, la situazione descritta nel paragrafo 4.5 ha meno probabilità di verificarsi. Anche in questo caso la distinzione delle responsabilità ha impatto sull organizzazione della PA, e sui processi che determinano le modifiche degli applicativi/database. 4.9Piani di miglioramento Una volta compresa la necessità di migliorare la qualità dei dati, e identificati i database sui quali è necessario intervenire, occorre procedere sulla base di piani. La definizione di piani garantisce l organicità degli interventi, la riproducibilità dei risultati, e la sistematicità necessaria. Il piano dovrà contenere anche specifiche attività di controllo delle qualità dei dati ottenute. Il piano deve inoltre considerare le diverse fasi della vita del dato: il contenuto informativo dei dati; il trattamento dei dati, ovvero acquisizione, controllo, e rilascio; la conservazione dei dati, che ha in se aspetti di sicurezza, l accesso in via telematica al dato da parte di utenti abilitati, la gestione delle modifiche e della modificabilità. 4.10Valutazione dei costi e benefici I database in possesso della PA sono decisamente numerosi e contengono milioni e milioni di dati. A questi devono essere aggiunte le informazioni che non sono (ancora) su supporto informatico. Si rimanda ai documenti AIPA sulla RUPA per una stima di questi numeri. Alla domanda se è possibile migliorare tutte le basi dati e fino a che punto, si può rispondere che la tecnologia è di per sé in grado di supportare praticamente ogni tipo di azione, ma certamente non a costi zero e che vi sono anche aspetti di tipo organizzativo che devono essere tenuti in debito conto. Il miglioramento delle basi di dati è necessario per fornire servizi efficienti ed efficaci ai cittadini. Se il cittadino può comunicare i propri dati una sola volta alla PA, la PA deve essere in grado di scambiarsi queste informazioni. Occorre però precisare quali informazioni devono essere scambiate, e quindi identificare le basi dati interessate e/o addirittura i campi nei record. Oltre al criterio della cooperazione occorre esaminare anche quello dell efficienza. Si devono identificare i processi che causano inefficienze nei confronti dei cittadini: 40

41 introducono ritardi nell erogazione dei servizi; costringono il cittadino a riformattare le informazioni in modo da renderle fruibili da parte della PA. 41

42 42.

43 5.ANALISI DELLE ESIGENZE DI DATI PUBBLICI: LA METODOLOGIA 5.1Panoramica delle architetture maggiormente presenti nella PA 5.1.1Introduzione Gli anni trascorsi hanno visto l'avvio di una vasta opera di riforma del sistema amministrativo, intesa ad adeguare agli standard dei paesi più avanzati le prestazioni e i servizi delle pubbliche amministrazioni e la qualità del sistema della regolazione. Di questa opera di riforma è pressoché compiutamente delineato il quadro legislativo, con la legge di riforma del bilancio dello Stato, le quattro cosiddette leggi Bassanini e i conseguenti decreti legislativi e regolamenti. Le tecnologie dell'informazione e della comunicazione, i servizi, i contenuti e quindi i processi di convergenza costituiscono i fattori di maggiore rilievo del grande mercato che è alla base della società dell'informazione L obiettivo fondamentale di migliorare i servizi della Pubblica Amministrazione deve sicuramente essere perseguito attraverso: la diffusione della cultura informatica e digitale: da perseguire attraverso una campagna di sensibilizzazione dell'opinione pubblica e mediante nuove forme di insegnamento che - attraverso l'uso della rete - stimolino anche la didattica a distanza e la promozione di corsi di formazione e riqualificazione professionale; lo sviluppo dell'uso delle tecnologie dell'informazione e della comunicazione: attraverso le quali promuovere la cooperazione tra Pubbliche Amministrazioni ai fini di abbassare il tasso di burocratizzazione; la promozione dei servizi, dei contenuti e della ricerca: attraverso la promozione della ricerca, del commercio elettronico e dei centri servizi on line, dell'industria multimediale ed il sostegno del telelavoro. Su tali fronti l evoluzione della tecnologia può sicuramente dare un altissimo contributo. Nei paragrafi seguenti verrà presentata una panoramica dell evoluzione delle architetture applicative che sono maggiormente presenti nella realtà della Pubblica Amministrazione, facendo riferimento ad alcuni esempi concreti di attuazione. 43

44 5.1.2Tipologia di Architetture Architetture Legacy Il mondo mainframe ha rappresentato la prima grande infrastruttura su cui i principali Enti della Pubblica Amministrazione hanno edificato i loro Sistemi Informativi. Nel modello di computing del Mainframe è il Mainframe stesso che esegue tutte le operazioni sui dati e usa terminali senza capacità propria di processazione come unità di visualizzazione e di inserimento dati. Ad esempio ricercare e visualizzare i dati di un impiegato su un terminale richiede le seguenti operazioni: visualizzazione sul terminale di un modulo su cui l'utente può inserire il nome dell'impiegato; accettazione dell'informazione relativa ai dati inseriti; convalida del formato dei dati; verifica della disponibilità delle informazioni richieste; acquisizione delle informazioni dal database; formattazione dei dati per la visualizzazione sul display dell'utente; visualizzazione delle informazioni richieste. Tutte queste operazioni vengono svolte dal mainframe, mentre il terminale si limita ad effettuare fisicamente le operazioni di I/O. Con l'evoluzione delle tecnologie, la comparsa di nuovi sistemi operativi e l'avvento dei terminali grafici X-Windows, anche l'architettura delle applicazioni mainframe ne ha risentito. Negli anni recenti sono state sviluppate diverse tecnologie che permettono di far migrare i sistemi legacy sulle nuove architetture senza modificare l'interfaccia del sistema quando utilizzato in maniera cooperativa da altre applicazioni esistenti o da nuove applicazioni. Tali tecnologie prendono il nome di: screen scrapers gateways per basi di dati gateway per applicazioni wrappers Ad esempio, nei screen scrapers l'applicazione cliente simula le funzionalità di un terminale, nel senso che accede direttamente all'applicazione legacy per il tramite delle schermate utilizzate dalle transazioni tradizionali; al contrario nei wrappers l'applicazione legacy viene invece incapsulata in oggetti, che vengono attivati dalle nuove applicazioni. 44

45 Architetture Client Server (2 livelli) Il Client Server, che è diventato il modello di riferimento per il networking e le applicazioni di data base a qualunque livello, si contrappone come filosofia e come struttura al Mainframe. La semplicità di realizzazione di una applicazione Client/Server a due livelli, che prevede l implementazione della logica applicativa e dell interfaccia utente insieme nel client, e mantiene sul server solo i dati condivisi, può a prima vista offrire maggiori garanzie in stabilità e prestazioni. La pratica poi dimostra che al crescere della complessità del sistema e della sua distribuzione, separare le componenti di interfaccia da quelle di logica applicativa permette di avere a disposizione tutta una serie di vantaggi quali la manutenibilità del codice, la scalabilità dell applicazione e soprattutto l aggiornamento delle varie versioni su piattaforme diverse. Tali argomenti saranno ripresi nel paragrafo successivo. Per come sono strutturate le applicazioni a due livelli, con l accoppiamento stretto tra logica e interfaccia utente, esse rappresentano la parte più complessa su cui agire per la realizzazione di un sistema di interscambio dati tra applicazioni. La progettazione di una applicazione Client/Server prevede la definizione delle interfacce dei Server, cioè le funzionalità che ogni Server rende disponibili ai suoi Client, con i relativi parametri di ingresso e dati di uscita. Una volta individuato questo insieme di funzionalità occorre definire un formato ed un protocollo per realizzare la comunicazione tra Client e Server e permettere la cooperazione; il formato stabilisce un linguaggio comune, ovvero un insieme di possibili messaggi, ed il protocollo l insieme delle regole per l uso di questi messaggi. Le principali tecniche per la definizione della interfaccia del Server, ovvero del tipo di messaggi che fluiscono tra Client e Server: trasferimento di dati in linea; trasferimento di dati fuori linea (con replicazione); scambio di messaggi in linea; scambio di messaggi fuori linea (code di messaggi); accesso a dati in linea (mediante paradigma ipertestuale). Queste tecniche corrispondono agli strumenti di base disponibili per realizzare le funzionalità principali delle architetture client/server. Sono presenti sul mercato prodotti (Database Gateway Server) che mettono a disposizione, in modo abbastanza integrato, funzionalità che corrispondono a varie di queste tecniche. Inoltre, sono disponibili vari prodotti, relativi alle singole funzionalità, che possono essere utilizzati per realizzare architetture a cooperazione lasca, come quelle relative alle applicazioni dei sistemi informativi locali con dati esterni. 45

46 Architetture Client Server (3 livelli web Orieted) Questo modello, noto anche con il nome di modello basato su servizi o services model, modifica i ruoli tradizionali di client e di server ed aggiunge un nuovo componente architetturale: i business object. Nelle architetture a tre strati, la logica che opera sui dati è isolata dal client e dal server e viene mantenuta in un luogo centralizzato e sicuro. Il modello basato sui servizi consente di vedere le applicazioni come un insieme di caratteristiche (servizi) utilizzate per soddisfare le richieste degli utenti. Incoraggiando lo sviluppatore a progettare un applicazione come un insieme di servizi distinti, è possibile isolare le funzionalità in modo che possano essere riutilizzate, condivise e ridistribuite. L architettura a tre strati consente innanzitutto una maggiore scalabilità. Non è però detto che questa architettura sia appropriata in ogni situazione: è sicuramente spropositata per le piccole realtà ed i piccoli gruppi di lavoro. Analogamente può non essere appropriata per le applicazioni di supporto alle decisioni, caratterizzate da grandi visualizzazioni di dati, ma prive di transazioni. Le applicazioni Client/Server a tre strati sono in continua evoluzione. Non esiste un unico modo corretto per progettare un business object, anche perché spesso la progettazione di queste componenti è influenzata da caratteristiche peculiari dell applicativo da generare, come ad esempio le prestazioni sulla rete. Il reale beneficio derivante dall'utilizzo dei business object risiede nel fatto che questi sono disponibili a diverse applicazioni. Con ciò si intende che, una volta creato un tale oggetto, vi si può accedere con semplicità da un qualunque front-end. Dal punto di vista degli sviluppatori ciò significa che, una volta rese pubbliche le specifiche di un oggetto, chiunque è in grado di sviluppare applicazioni che ne sfruttino l'interfaccia esposta per accedere alla base dati. 46

47 Grazie a questa architettura, se la struttura della base dati viene modificata, l'applicazione non ne risente: soltanto gli oggetti interessati dovranno essere modificati. Su queste basi si è sviluppata l architettura a tre livelli attualmente più diffusa, e cioè quella web-oriented, dove i web server e le loro componenti accessorie (engine, parsificatori, moduli) diventano componenti fondamentali di middleware. Il grosso successo di questa architettura consiste nella semplicità di distribuzione degli applicativi (sul client è presente solo un Browser) e della potente scalabilità che sono in grado di offrire (sistemi a rack, bilanciamento del carico etc). Applicativi distribuiti tramite Broker Un esigenza diffusa è, con termine inglese, la Webization, ovvero la presentazione agli utenti di un unica interfaccia di stile Web per tutte le applicazioni, anche se realizzate con architetture tradizionali (mainframe o Client/Server). Le varianti sono estremamente numerose, ma si riconducono a due classi di architetture: sistemi di accesso ad una risorsa centrale (emulatori di terminali oppure sistemi thin client); sistemi di elaborazione a più livelli (presentazione distribuita, application server, back-end DBMS). I tre principali parametri di costo che intervengono in questa scelta sono: il costo del posto di lavoro transazionale, che può essere molto maggiore nel caso dei sistemi di elaborazione distribuita che devono ospitare l installazione di software applicativo; il costo del deployment delle applicazioni, che è assente nel caso di sistemi centralizzati e invece per i sistemi distribuiti si ripresenta a ogni aggiornamento di ogni applicazione; i costi di trasmissione, da valutare caso per caso in funzione del tipo e della frequenza degli oggetti trasmessi (software applicativo, dati delle applicazioni, copie dei database). A questa categoria di software appartengono i prodotti che vengono definiti application broker. Un application broker rinnova sostanzialmente il modello tradizionale del terminale, in quanto costituisce un servizio lato server in grado di rendere disponibili on demand le applicazioni sui client senza installarle sugli stessi. Affinché ciò sia possibile, lato client è sufficiente che sia disponibile un applicativo di tipo terminale in grado di interloquire con la componente server dell application broker; tale applicativo terminale può essere preinstallato sul sistema client o veicolato, tramite un browser, come estensione dello stesso (Applet Java, ActiveX control o Plug-in). Si noti che non è sempre possibile veicolare un generico applicativo tramite un application broker, in quanto, poiché di fatto le varie istanze dell applicativo stesso girano all interno dello stesso sistema server, questo in generale potrebbe determinare dei conflitti; in alcuni casi pertanto la cosa non risulta fattibile o induce, ove possibile, un adeguato adattamento del software. Queste condizioni in genere comunque non si 47

48 verificano nel caso di applicativi gestionali realizzati sulle piattaforme di maggiore diffusione. Si noti anche che il dimensionamento di un sistema server in grado di fungere da application broker deve essere fatto con particolare attenzione e non può non dipendere da una esatta analisi non solo del numero massimo di client connessi contemporaneamente alle applicazioni, ma anche dalle caratteristiche delle applicazioni stesse. Normalmente infatti i sistemi server dedicati a questa particolare tipologia di architettura centralizzata risultano essere particolarmente equipaggiati dal punto di vista delle risorse di sistema (memoria, cpu, ecc.) e pertanto molto costosi. Questo fattore va quindi tenuto in considerazione quando la scelta di tale architettura è innescata da una analisi dei costi Esempi della realtà della Pubblica Amministrazione Vedremo nei prossimi paragrafi come le varia architetture elencate in precedenza sono state utilizzate per realizzare dei servizi applicativi, e come la tipologia di fruitore abbia influito sulla scelta architetturale utilizzata. In particolare saranno citati alcuni esempi significativi di applicativi presenti nella Pubblica Amministrazione. Applicazioni di sportello [Applicazioni mainframe] La realizzazione di un sistema informativo tramite il quale il cittadino possa venire a conoscenza dei dati relativi a pratiche e documentazione, per esempio, comunale nonché in possesso dei moduli per svolgere le pratiche stesse (validi a tutti gli effetti di legge) e, eventualmente, verificare a che punto sia la propria, attua le disposizioni normative che intendono fornire ai cittadini gli strumenti di conoscenza e comunicazione dell attività delle amministrazioni pubbliche. Tali applicazioni si stanno diffondendo sempre più soprattutto sfruttando le nuove tecnologie Web. Una grossa mole di dati, e le rispettive applicazioni trovano però ancora una largo impiego nel mondo mainframe. Moltissime sono ad esempio le anagrafi gestite con procedure su mondo mainframe. Allo stesso modo diverse città hanno ancor incentrato sul mondo legacy le principali procedure per la gestione dei tributi e delle tasse comunali. [In mondo open] Un significativo esempio di distribuzione di servizi, relativo alla Sanità pubblica e privata è quello dei Centri Unificati di Prenotazione (CUP), dove tipicamente un operatore consulente prenota, da terminale, visite ed esami medici per i cittadini che ne fanno richiesta. L evoluzione dei CUP comprende l integrazione con Internet, la costruzione di reti di CUP, la fornitura di servizi al cittadino non solo in campo sanitario. Nel caso specifico l'applicativo CUP realizzato in Piemonte è costituito da architetture a tre livelli in tecnologia Object Oriented. Un esempio interessante di cooperazione tra applicazioni è stato realizzato estendendo le funzionalità del CUP, ai centri di prenotazione presso le farmacie comunali, utilizzando lo standard CORBA, per l'interazione e la garanzia delle transazioni. Applicazioni rivolte direttamente al cittadino 48

49 Gli interventi di informatizzazione nella Pubblica Amministrazione, così come erano concepiti fino a qualche anno fa, avevano come obiettivo principale la realizzazione di sistemi che tendevano all'incremento dell'efficienza, all'integrazione delle informazioni ed alla semplificazione dei procedimenti attraverso l'introduzione massiccia dell'automazione. In quest'ottica il cittadino assumeva un ruolo marginale. L'uso degli strumenti tecnologici, pur comportando un incremento complessivo dell'efficienza e, quindi, una maggiore rapidità nell'espletamento dei servizi, rimaneva prerogativa del personale amministrativo. Un simile modello ed i conseguenti obiettivi, seppure ancora validi, costituiscono, oggi, un requisito minimo e scontato. L'evoluzione tecnologica dei media, sempre più finalizzata alla massima interazione tra utente fruitore delle informazioni e le informazioni stesse, parallelamente alla rapidità ed alla capillarità con la quale tali tecnologie si diffondono, richiede una completa rivoluzione del tradizionale approccio al problema dell'automazione nella Pubblica Amministrazione. Il cittadino, non va più considerato semplice utente, ma parte integrante del progetto di informatizzazione. L'accesso ai servizi offerti dalla macchina amministrativa deve, oggi, avvenire in maniera il più possibile autonoma, attraverso l'uso dei media tecnologici disponibili. Sono stati attivati alcuni progetti a livello nazionale ed europeo che mirano a distribuire attraverso le reti telematiche la più vasta gamma possibile di servizi ai cittadini e alle imprese in punti di accesso che comprendono chioschi informativi, uffici pubblici e uffici privati. I servizi sono accessibili in modalità self-service, da punti presidiati e da abitazioni private e utilizzano carte magnetiche o a microprocessore in grado di fungere anche da borsellino elettronico per gli acquisti di dettaglio nelle città. Elemento indispensabile per la realizzazione di sistemi rivolti al cittadino è l utilizzo di tecnologie ad alta scalabilità e a basso costo. Le architetture web oriented hanno rappresentato una risposta a questo tipo di necessità. [Ici On line] Nel 2000 sono state avviate anche le prime sperimentazioni di Commercio Elettronico; per il Comune di Torino la nuova forma di pagamento è stata utilizzata per la realizzazione del servizio ICI on line, in architettura Web, che ha consentito ai cittadini di calcolare e pagare via Internet l Imposta Comunale sugli Immobili. A questo fine, sono 49

50 stati siglati accordi con alcune banche ed i concessionari per consentire l utilizzo in rete non solo delle carte di credito, ma anche dei meccanismi di addebito in conto, superando così problemi legati ai costi di commissione. Nel 2001 proseguirà l attività volta a garantire sistemi di pagamento in condizioni di sicurezza e le funzionalità del commercio elettronico verranno arricchite con il coinvolgimento di altri possibili partner nel mondo bancario e con l introduzione di nuove modalità di pagamento. Applicazioni rivolte ad aziende La riforma della Pubblica Amministrazione in atto ha fra i suoi principali obiettivi la semplificazione e l'accelerazione delle procedure amministrative, a vantaggio dei cittadini e degli operatori economici. Anche in questo caso fondamentale è riuscire a realizzare architetture applicative facilmente distribuibili e scalabili, caratteristiche che ben si ritrovano negli approcci weboriented. [Sportello Unico] Un esempio di applicativo realizzato con quest ottica è lo SPORTELLO UNICO PER LE ATTIVITÀ PRODUTTIVE che si propone come strumento di sviluppo economico del territorio attraverso un'attività amministrativa fondata sulla certezza dei tempi e delle procedure, nonché sulla promozione delle potenzialità di sviluppo delle diverse comunità locali. La Regione Piemonte si è impegnata a favorire l'attivazione ed il funzionamento degli sportelli unici comunali, in collaborazione con le altre Amministrazioni pubbliche e con le parti economiche e sociali. L'architettura utilizzata è in questo caso Web-oriented con interfaccia HTML. Via HTTP si interagisce con la parte di application server realizzata in Java servlet. L'interazione con il DB avviene via RMI per ottimizzare i tempi di accesso ai dati. Applicazioni Gestionali e di WorkFlow [Protocollo] L'attività di protocollazione, archiviazione e gestione del flusso dei documenti costituisce l'asse portante dei procedimenti amministrativi svolti all'interno della Pubblica Amministrazione. Tale attività é centrale nella esecuzione dei processi operativi svolti nelle Amministrazioni e tra le Amministrazioni, e può trovare nelle tecnologie della informazione un importante aiuto ai fini del miglioramento della efficienza ed efficacia. In realtà fino ad oggi si è provveduto soltanto alla parziale automazione di questo adempimento. Si stima che nella Pubblica Amministrazione centrale siano oltre le unità organizzative interessate a processi di protocollazione e archiviazione, con un grado di informatizzazione di questi processi pari, approssimativamente, ad appena il 10%. In realtà, questi processi possono essere utilmente collocati tra quelli in cui l intervento dell informatica procura i più ampi margini di utilità e, quindi, di miglioramento, dei servizi che ci si attende dall azione amministrativa

51 Alla base del processo di gestione documentale in una qualunque unità organizzativa di una Amministrazione è il concetto di documento. Un documento può essere definito come qualsiasi atto scritto utilizzato a fini di comunicazione tra operatori della PA, allo scopo di eseguire un procedimento amministrativo, preordinato all emanazione di un atto finale o di un servizio. Le attività connesse alla trattazione dei documenti sono regolate da una procedura prestabilita (detta processo di gestione dei documenti) che determina le azioni e le decisioni da compiere a seguito di particolari eventi, come la ricezione di un nuovo documento o l'apposizione di una firma di visto. Nel caso della Regione Piemonte il protocollo, precedentemente pensato in architettura client/server due livelli, è stato riprogettato in ambiente object oriented tre livelli. [Guarini] Promosso dalla Regione Piemonte, il progetto Guarini ha come obiettivo la diffusione e la valorizzazione del patrimonio culturale piemontese. Guarini mette a disposizione di istituzioni culturali, enti pubblici e privati gli strumenti informatici per la gestione del proprio patrimonio culturale e per la costituzione di banche dati e immagini. Il progetto, in architettura client/server rivolto ai soggetti pubblici che svolgono compiti istituzionali di gestione del patrimonio culturale ed alle associazioni qualificate, include le tipologie di schede definite dall'istituto Centrale per il Catalogo e la Documentazione (ICCD) del Ministero per i Beni e le Attività Culturali e ne propone di nuove, secondo metodi rigorosamente scientifici. Grazie ai finanziamenti previsti dalla Legge Regionale 35/95, i Comuni piemontesi possono provvedere alla catalogazione dei propri beni culturali architettonici, utilizzando una versione semplificata della procedura Guarini. [Sanità] Il Sistema Informativo Sanitario regionale (SIS) rappresenta lo strumento informatico con cui l'assessorato alla Sanità della Regione Piemonte governa l'erogazione dei servizi sanitari ai cittadini piemontesi, grazie alla gestione integrata delle Basi Dati disponibili sulla Rete Unitaria della Pubblica Amministrazione Regionale (RUPAR). Fanno parte del SIS applicativi di tipo amministrativo e contabile (per la regolamentazione dell'attività svolta); epidemiologico e clinico (per il controllo dell'efficacia dei servizi erogati) e statistico (come supporto ai processi decisionali e strategici). Figurano come utenti principali del SIS sia i diversi uffici dell'assessorato regionale alla Sanità che le Aziende Sanitarie Locali e Ospedaliere Le applicazioni sanitarie rappresentano una tipologia di applicazioni che più necessita di movimentazioni massicce di dati (i cosiddetti flussi), soprattutto per le operazioni di controllo o di processo. Per questo motivi è importante individuare soluzioni architetturali che possano garantire sia aspetti di sicurezza che di stabilità e robustezza a sollecitazioni di transazioni massicce. Applicativi di DataWarehouse Il Data Warehouse rappresenta un nuovo approccio per fornire accesso alle informazioni con lo scopo di trovare risposta alle richieste degli utenti di maggiore livello. L approccio 51

52 tradizionale di analisi dei dati si fonda sull uso di strumenti semplici, basati su un linguaggio naturale o formale come SQL, per effettuare interrogazioni (query). Questo approccio tuttavia diventa inefficiente su grandi quantità di dati. Un approccio più moderno è quello denominato On Line Analytical Processing (OLAP), che si basa sulla predisposizione di una vasta gamma di strumenti di analisi che sintetizzano i dati in base alle regole aziendali. Olap è più rapido perché si basa su dati precedentemente sommati e pertanto più vicini alle richieste degli utenti. È opportuno valutare il livello di disaggregazione dei dati da inserire nei Data Warehouse al fine di evitare di scartare dati di dettaglio di eventuale interesse. Un altra tipologia di strumento di analisi su grosse moli di dati è il Data Mining, che consente analisi approfondite sulle correlazioni nascoste nelle basi dati, sfruttando tecniche sviluppate nei campi della statistica e delle macchine learning, per esempio le reti neurali. Tutti questi moderni approcci all analisi e modellazione si basano sull esistenza di un magazzino dati capiente e ben fornito, il Data Warehouse. Per sfruttare a pieno il valore dei dati in possesso delle aziende è necessario che questi siano modellati nel modo più semplice possibile per l utilizzo da parte dell utente. Come è noto la maggior parte delle informazioni entra in azienda attraverso procedure operative, che raramente sono state concepite per organizzare i dati come base di conoscenza e supporto decisionale. Per questo motivo i principi alla base dei sistemi di Data Warehouse sono rivolti alla forte interazione col dato da parte dell utente sia in sintesi che in dettaglio, la disponibilità di serie storiche dei dati, elevate prestazioni per ogni tipo di interrogazioni estemporanea e una visione univoca del significato dei dati presenti nel Data Warehouse. 52

53 Nell ambito della Pubblica Amministrazione piemontese, sono stati realizzati numerosi esempi di Data Warehouse. Nella prima fase sono state realizzate componenti di carattere settoriale (assimilabili a Data Mart singoli), successivamente si è passati ad esperienze di tipo intersettoriale (ad esempio la Banca Dati Demografica Evolutiva della Regione Piemonte, che integra diversi punti di vista inerenti la popolazione, dagli aspetti demografici e a quelli sanitari); è nata perciò l esigenza di definire progetti trasversali a livello di un intero ente, che fungessero da infrastruttura portante per tutti i sistemi di tipo settoriale, da far crescere in modo integrato e federato (ad esempio progetti di DW trasversale di Regione Piemonte e Comune di Torino); infine si stanno avviando esperienze progettuali di tipo inter-ente, che favoriscano la condivisione di basi dati decisionali tra enti diversi e la costruzione di servizi di accesso segmentati per profilo di accesso (ad esempio il progetto di Accesso alle informazioni scolastica tra Regione Piemonte, numerose province piemontesi, comuni, scuole, ecc.). Quest ultimo tipo di progetti si basa sulla definizione di un architettura decisionale di riferimento per i diversi enti, rispetto alla quale le basi dati di interesse per più di un ente, vengono rese disponibili per la costruzione di servizi centralizzati erogabili via web, eventualmente differenziabili per gruppi di utenza: si può perciò parlare di un progetto di Data Warehouse federato per il Sistema Piemonte. Applicativi Territoriali [Applicativi GIS] I Sistemi Informativi Geografici sono nati con la Pubblica Amministrazione. Questa affermazione trova facile riscontro nelle tre nazioni dove ha preso vita il GIS: Stati Uniti, Canada e Gran Bretagna. Anche in Italia Amministrazioni Centrali e Locali dello Stato e Istituti Cartografici sono stati i primi utilizzatori di sistemi GIS. Il GIS approda in Italia negli anni ottanta, quando le più importanti esperienze straniere si consolidano e le principali aziende produttrici di software per il trattamento e la gestione di dati territoriali aprono filiali sul nostro territorio o affidano la distribuzione dei loro prodotti a società italiane. I primi ad interessarsi di GIS sono gli uffici cartografici delle regioni del nord Italia che avviano il processo di informatizzazione della Cartografia Tecnica Regionale e parallelamente iniziano a sperimentare modelli geografici di ausilio alla pianificazione degli interventi sul territorio. Anche alcuni Enti Centrali dello Stato partono con grandi progetti quali: l informatizzazione della cartografia del Servizio Geologico Nazionale, il Sistema Informativo Nazionale Ambientale, il Sistema Informativo Territoriale dei Vincoli Culturali e Ambientali, ecc. Le Università e gli Enti di Ricerca a loro volta promuovono prototipi e progetti pilota sui GIS. Quando s'intende descrivere un applicativo GIS normalmente si fa riferimento a tre componenti: un modello dati orientato, un insieme di algoritmi e un'interfaccia utente. I concetti di interfaccia utente e di algoritmo sono abbastanza intuitivi, mentre per modello dati orientato si intende un modello dati che tenga conto di come i dati debbano essere organizzati per rispondere alle domande che si vorranno fare al sistema. Un semplice esempio può essere quello di come memorizzare le strade: se la domanda riguarda la rete viaria, intesa come insieme sul quale calcolare ad esempio le distanze, i percorsi ottimali, i bacini d'utenza, il traffico, la domanda di trasporto, ecc., allora le strade andranno memorizzate sotto forma di linee e di nodi a formare un grafo, se la 53

54 domanda riguarda la manutenzione del manto stradale, di reti tecnologiche, ecc. andranno invece memorizzate come superfici. Ciò con tutte le varianti possibili: i parametri che consentono di calcolare l'iscrizione in curva degli autobus, il numero di corsie o i sensi di percorrenza potranno essere resi geometricamente, ovvero utilizzando appositi attributi sempre a seconda delle domande che porremo al sistema a supporto delle decisioni che siamo chiamati a prendere (scenari, simulazioni, analisi). Il fatto che ciascuna applicazione abbia bisogno oltre che di programmi ed interfacce anche di un modello dati ad essa orientato non significa che venga meno il grande contributo che il GIS può dare nel coordinamento tra utenti diversi che intervengono sullo stesso territorio. 54

55 Un esempio di configurazione architetturali delle soluzioni GIS usate in Piemonte. Client t(windows 95 o NT) (Applicativi t client GIS Dati Geografici (File System) Componenti GIS Dati Alfanumerici (DB Relazionale) Figura 1 : Configurazione per ambiti client/server su rete locale Nel caso di soluzioni su rete locale in ambito client/server, gli applicativi che vengono consegnati agli utenti sono realizzati prevalentemente utilizzando software GIS commerciali, personalizzandoli o mediante linguaggi proprietari o ambienti di sviluppo tradizionali. Per la gestione della parte alfanumerica vengono adottate diverse soluzioni, prevalentemente viene utilizzata come interfaccia alfanumerica un applicativo realizzato in tecnologia Object Oriented. 5.2Richiami sulla RUPA La Rete Unitaria delle Pubbliche Amministrazioni (RUPA) è un progetto in corso di realizzazione e non riguarda soltanto l'interconnessione delle Pubbliche Amministrazioni Centrali. È un progetto che ha come obiettivo quello di rendere possibile l'interoperabilità delle diverse Pubbliche Amministrazioni e Enti pubblici centrali, per sviluppare una infrastruttura che possa favorire lo scambio di dati e automatizzare i processi interamministrazione. Il modello adottato per lo sviluppo della RUPA è basato su due principi, quello dell'autonomia e quello della cooperazione. Ogni amministrazione pubblica centrale è considerata come un dominio autonomo; all interno del proprio dominio ogni amministrazione opera in totale autonomia operando le scelte che ritiene più giuste per lo sviluppo del suo Sistema Informatico. La RUPA non entra all interno del dominio di una singola amministrazione, ma cerca di definire le interfacce applicative che ogni amministrazione deve esporre verso l esterno per poter cooperante con le altre amministrazioni. 55

56 5.2.1Architettura della Rete Unitaria Lo scenario di cooperazione prevede che le pubbliche amministrazioni, dotate di sistemi informativi dalla struttura eterogenea e cresciuti in maniera completamente indipendente, possano cooperare secondo le regole stabilite dalla Rete Nazionale. In questo contesto ciascuna PA può usufruire dei servizi messi a disposizione dalle altre organizzazioni, anche esterne alla Rete Nazionale, integrandoli con i propri. Le strutture informatiche delle varie PA collegate alla Rete Nazionale sono definite come Domini. All'interno di ogni dominio ciascuna PA utilizza criteri e modelli di cooperazione e sicurezza arbitrari: la connessione tra i vari domini è garantita dalla rete di trasmissione chiamata Rete Nazionale. Il modello della Rete Nazionale, si configura come una internetwork di reti paritetiche, su dorsale TCP/IP, appartenenti ai diversi soggetti della Pubblica amministrazione locale o centrale. In particolare sono presenti la RUPA (Rete Unitaria per la Pubblica Amministrazione) per le Amministrazioni centrali dello Stato, le RUPAR per quelle regioni che hanno adottato il modello RUPA, scegliendo una modalità di interconnessione diretta con quest ultima, le Community Network che raggruppano sia le reti di categoria che le reti territoriali, ed infine gli Enti locali. Tutte le reti che usufruiscono direttamente del sistema di interconnessione della RN sono connesse tra loro attraverso i cosiddetti Exchange Point Operator (RN-EPO) cui sono assegnate diverse funzioni. Al fine di garantire la massima copertura territoriale e prestazionale sono state previste due categorie di EPO: Nazionali e Locali, con differenti requisiti di accesso da parte dei Provider (SP) e con funzionalità particolari. 56

57 L affidabilità del sistema di interconnessione è garantita dai requisiti richiesti ai provider della RN. In figura viene rappresentato uno schema della rete nazionale comprendente le amministrazioni centrali (PAC), quelle locali (PAL) e le Community Network (CN). L accesso alla Rete Nazionale da parte dei diversi soggetti avverrà mediante una opportuna porta di rete che dovrà garantire la connettività con un adeguato livello di sicurezza, secondo modalità e parametri definiti. Dal punto di vista delle strutture organizzative, la Rete Nazionale si innesta in un contesto nazionale che vede, alla fine del 2000, una parziale strutturazione dei servizi di rete della Pubblica Amministrazione italiana, con tecnologie ed esperienze da mantenere, e la forte presenza sul mercato di operatori (italiani ed esteri) specializzati nella fornitura di servizi Internet con esperienza pluriennale. In tale panorama la RN dovrà garantire la disponibilità di accesso ad una infrastruttura omogenea con servizi altamente scalabili integrando e razionalizzando l esistente. In particolare l Internet italiana vede l esistenza di due NAP (Neutral Access Point) che garantiscono un punto di scambio del traffico tra fornitori che operano sul territorio nazionale: MIX (Milan Internet Exchange Point di Milano) e NAUTILUS di Roma, con il primo che coinvolge di gran lunga il maggior numero di operatori (nazionali ed esteri) e rappresenta il principale polo italiano ed uno dei maggiori poli europei per Internet. Si sta affermando inoltre una tendenza che vede i maggiori operatori concludere accordi di peering privato (senza interoperare tra i Nap esistenti) in funzione di interessi di traffico ritenuti bilateralmente interessanti. 57

58 Nell ambito delle iniziative per l attuazione del Piano di e-government, per il corretto funzionamento della Rete Nazionale il Centro Tecnico del Dipartimento della Funzione Pubblica svolge le seguenti attività: Monitoraggio e controllo della Rete Unitaria delle Pubbliche Amministrazioni tramite l attivazione di un centro di controllo; politica di sicurezza globale per le pubbliche amministrazioni; politica unitaria dei prezzi, rendendo le PA nel loro complesso un unico soggetto operante sul mercato telematico; estensione dell utilizzo della rete unitaria ai soggetti esterni rispetto alle PA. 5.3Metodologia per i dati Riprendendo in dettaglio quanto esposto nel capitolo 4 e distinguendo tra : A1.Azione a breve termine e di tipo transitorio A2.Azioni a medio-lungo termine e di tipo stabile, è possibile approfondire in questo capitolo le differenti metodologie da associare alle due fasi. Nella prima fase (A1), legata alle azioni a breve termine, la linea strategica è pubblicizzare e rendere accessibile l esistente. La metodologia di lavoro sarà perciò centrata sul censimento delle basi dati disponibili. Nella seconda fase (A2), legata alle azioni a medio-lungo termine, la linea strategica è integrare le informazioni pubbliche e migliorarne la qualità. La metodologia sarà perciò centrata sul censimento dei dati di interesse al fine della razionalizzazione e miglioramento della qualità delle basi dati. Nei prossimi paragrafi dettaglieremo meglio le metodologie di lavoro relative alle due fasi Metodologia per le azioni a breve termine L azione principale di questa fase è quella di conoscere e rendere disponibili informazioni contenute nelle basi dati, così come sono disponibili attualmente. Per conoscere è perciò opportuno censire quanto è disponibile. La prima fase di censimento delle basi dati e di raccolta delle esigenze informative (una sintetica matrice dati/materie/fornitori/fruitori) deve essere costruita con il coinvolgimento di tutti i livelli territoriali e di competenza. Un esempio è mostrato nell allegato 4, in cui sono riportate due tipologie di matrici: 58

59 una prima matrice individua le principali banche dati di interesse per la Pubblica Amministrazione, rapportate alle materie di intervento (in questo caso è stata utilizzata la classificazione per aree tematiche / di dominio ai sensi del D.Lgs. 112/98); una seconda matrice individua invece, rispetto alle principali basi dati, gli enti fornitori e quelli fruitori In questa prima fase di censimento delle esigenze, è altresì opportuno censire le principali caratteristiche delle basi dati pubbliche, quali ad esempio: l ente proprietario della banca dati, lo scopo della banca dati, struttura della banca dati, caratteristiche della banca dati (centralizzata, distribuita, ), sistema informativo che ospita la banca dati, eventualmente i processi che insistono su questa banca dati Metodologia per le azioni a medio- lungo termine In questa seconda fase l azione diventa più incisiva ed interviene al cuore del problema, ovvero la razionalizzazione di un patrimonio informativo sparso e spesso incongruente. Il punto di vista sinora usato deve essere perciò ribaltato: non è più sufficiente conoscere le basi dati esistenti come entità informatica a sé, ma occorre entrare nel merito delle informazioni che le banche dati contengono e come le contengono. Si dovrà partire da un macroesame di quali sono le principali informazioni di interesse per la Pubblica Amministrazione, classificandole opportunamente (entità); quindi si cercherà di capire dove tali informazioni sono attualmente memorizzate, presso quali amministrazioni e in quali banche dati, e chi è interessato al loro utilizzo in funzione delle competenze attribuite. Questa fase corrisponde a rivedere in modo più organico le matrici materie/dati/fornitori/fruitori, delineando un metamodello. Si dovrà poi entrare più nel dettaglio per vedere come, informazioni che attualmente sono localizzate su basi dati diverse, possono essere integrate per poter ricostruire un profilo complessivo di una certa entità. Facendo un esempio, in relazione ad una persona fisica, in questo momento le caratteristiche del suo profilo sono sparse in molti punti: l anagrafe di un comune ha dettagli sulla nascita, residenza, ecc.; le scuole dispongono dei livelli di istruzione progressivamente raggiunti; i centri per l impiego conoscono gli stati occupazionali; l INPS i contributi versati; 59

60 ecc. Il problema attuale è che queste informazioni sono disponibili in sistemi informativi diversi e non è possibile ricostruire Persona fisica Nascita Istruzione Lavoro Epidemiologia Il possibile filo che può legare in un unico profilo queste informazioni è l identificazione univoca del soggetto (ad es codice fiscale) nelle diverse banche dati; affinché tale identificazione sia univoca, deve perciò essere definito un responsabile unico dell identificazione; tale responsabile deve poi rendere disponibile questa informazione alle diverse PA. Ogni ente che, in relazione al proprio ambito di competenze, è responsabile di un processo amministrativo inerente una caratteristica specifica (istruzione, nascita, ecc.) avrà la responsabilità dell aggiornamento di alcune informazioni relative al profilo. Una parte delle informazioni correlate al processo amministrativo saranno di tipo interno, in quanto legate alle fasi intermedie del processo amministrativo, altre saranno di tipo esterno, in quanto relative allo status finale del processo amministrativo. I dati di tipo interno sono di interesse per la sola amministrazione competente su quel processo amministrativo, mentre quelli di tipo esterno sono di interesse per altre amministrazioni. Per queste ultime tipologie è perciò necessario predisporre dei servizi di pubblicazione delle informazioni, siano essi di tipo a richiesta che di tipo a notifica. Quindi i dati essenziali da pubblicare sulla rete attraverso appositi servizi sono: identificazione univoca delle entità caratteristiche specifiche relative all entità, di cui si è titolari. 60

61 Identificazione della persona fisica Servizi di accesso RUPA Servizi di accesso Dati esterni Nascita, Stato Civile, Dati interni Informazioni intermedie sul processo amministrativo Comune Servizi di accesso Dati esterni Condizione lavorativa Dati interni Informazioni intermedie sul processo amministrativo 5.4Architetture di riferimento per l'interoperabilità basata sull'interscambio dei dati 2 Il problema affrontato dalle tecnologie cooperative per basi di dati è quello di permettere forme di cooperazione tra utenti ed applicazioni che operano inizialmente su distinte basi di dati, gestite da distinti sistemi di gestione di basi di dati (DBMS, o Data Base Management system nel seguito). La forma più stretta di cooperazione tra basi di dati si ottiene mediante la loro integrazione in una unica base dati. Questa soluzione ha il vantaggio concettuale di portare ad una integrazione anche di natura semantica tra le diverse basi di dati, e facilita perciò la comprensione tra gli utenti e la correttezza delle elaborazioni. Questa forma di integrazione è in realtà molto difficile da attuare, per la grande rapidità con cui dati e basi di dati evolvono nelle organizzazioni, e spesso inopportuna o non 2 Testo tratto dai seguenti documenti : Sistemi informativi per la Pubblica Amministrazione:Metodologie e Tecnologie (paragrafo Linguaggi per la modellazione dei dati aziendali di Carlo Batini, Daniele Tatti), documento della Scuola Superiore della Pubblica Amministrazione e Studio di prefattibilità per la individuazione delle infrastrutture necessarie a favorire lo sviluppo della cooperazione applicativa tra Amministrazioni (documento approvato dall Adunanza dell Autorità il 1 ottobre 1998) 61

62 realizzabile, per l autonomia che utenti e gruppi di utenti intendono mantenere sulle basi di dati da essi create e aggiornate. Una variante della precedente scelta è quella delle basi dati distribuite in cui la base dati è ancora gestita da un unico DBMS, ma può essere frammentata in tante basi di dati locali. Ciò in genere migliora l efficienza per accessi locali, ma rende più complessi problemi di aggiornamento su diverse basi di dati. In questa soluzione, usualmente, continua a sussistere una integrazione forte tra la basi di dati locali, che adottano una unica rappresentazione delle informazioni. Tutte le soluzioni successivamente esposte indeboliscono progressivamente il legame concettuale tra le diverse basi di dati del sistema cooperativo. In una base dati federata ad accoppiamento forte le diverse basi di dati vengono gestite autonomamente da diversi DBMS, ma esiste un nuovo componente software che ha la possibilità di accedere omogeneamente alle diverse basi di dati, coordinandone le operazioni. In una base dati federata ad accoppiamento debole, rispetto alla precedente, il nuovo componente garantisce soltanto una visione virtuale integrata, ma non ha potere di intervento gestionale sui sistemi che rimangono fortemente autonomi. Le tecnologie a gateway (traduttori o filtri tecnologici) permettono di tradurre richieste formulate in un linguaggio per un DBMS A in termini di richieste per il linguaggio adottato dal DBMS B. Hanno il vantaggio di non richiedere nessuno o un limitato sviluppo di software aggiuntivo, ma richiedono componenti ad hoc per ogni singola relazione tra sistemi distinti, e fanno perdere la trasparenza resa possibile dalle soluzioni precedenti. Il meccanismo più debole di cooperazione tra basi di dati è quello della estrazione e trasferimento dati, con aggiornamento periodico della base dati locale a partire dalla base dati remota che offre la cooperazione. Questo meccanismo ricade nelle modalità di cooperazione asincrona che riprenderemo più avanti. In tutte le precedenti forme di cooperazione, questa viene instaurata operando sulle basi di esistenti con nuovi componenti architetturali. Nei Data Warehouse (magazzini o depositi di dati) viene creata (periodicamente) una nuova base dati, che nasce dall integrazione stretta delle basi di dati esistenti, e tale nuova base dati viene resa accessibile con potenti linguaggi per l analisi e l estrazione di informazioni rilevanti a fini decisionali. Il vantaggio di questa soluzione, come vedremo meglio anche nel seguito, è nel tenere separati i dati operativi da quelli su cui vengono fatte interrogazioni ed analisi, senza perdere i benefici dell integrazione; lo svantaggio è nell aggravio gestionale derivante dalla necessità di creare una nuova base dati. 62

63 5.5Architetture di riferimento per la cooperazione applicativa Nell ambito della Rete Nazionale, l interazione tra applicazioni non co-residenti avviene sempre attraverso lo scambio di messaggi e comunque utilizzando opportuni protocolli, quindi con modalità asincrona. Tuttavia dal punto di vista concettuale e semantico, indipendentemente dai protocolli usati e dagli standard di rappresentazione dei messaggi, i paradigmi applicativi della cooperazione sono comunque riconducibili a poche forme funzionali primitive, in particolare alle due seguenti: richiesta di servizio e notifica di evento. Per precisare la definizione di queste funzioni è utile introdurre la generica nozione di oggetto applicativo definito come una struttura dati persistente di un dominio, dotata di valore modificabile e controllata da applicazioni del dominio direttamente o tramite un insieme di procedure predefinite. Si può pensare in pratica ad una qualsiasi struttura dati gestita da una applicazione direttamente o tramite un sistema di gestione dati, o anche ad un oggetto, nel senso informatico del termine, dotato di propri metodi. La richiesta di servizio è un messaggio, prodotto da una applicazione di un dominio cliente e diretto ad una applicazione di un dominio servente. Il messaggio determina la esecuzione di una applicazione del dominio servente che, in base alle informazioni contenute nel messaggio, esegue una procedura ed invia una risposta destinata alla applicazione cliente. La risposta è una indicazione certa che la applicazione servente ha attuato la richiesta, anche se eventualmente con un esito negativo. La richiesta di servizio è sempre sincrona nel senso che prima o poi la applicazione cliente si dovrà sincronizzare sulla risposta, perché dovrà utilizzarne le informazioni applicative. 63

64 La richiesta di servizio può essere di due tipi, interrogazione oppure transazione: l interrogazione è una richiesta di servizio che ritorna una informazione del dominio servente senza modificare alcun oggetto applicativo dello stesso dominio; la transazione è una richiesta di servizio che è destinata a produrre una variazione permanente in un qualche oggetto applicativo del dominio servente. La transazione può interessare anche oggetti di più domini. La transazione comporta sempre anche il supporto del paradigma informatico della transazione, nel senso tecnico del termine, perché la modifica permanente di un oggetto applicativo di un altro dominio deve essere garantita atomica e consistente e quindi, se non portata a compimento, deve essere reversibile. La risposta non contiene necessariamente una informazione applicativa, ma può anche ridursi alla semplice segnalazione che la transazione è stata completata oppure no. In teoria si potrebbe avere un terzo tipo di richiesta di servizio, che non modifica alcun oggetto del dominio ma attiva una procedura di elaborazione pura del dominio servente e riceve una risposta che ritorna i relativi risultati. Si tratta di un caso assimilabile alla interrogazione e privo di pratica utilità nel contesto di questa trattazione. 5.6Cooperazione basata su eventi Nella realtà amministrativa e normativa italiana esiste un grande numero di processi di scambio dei dati tra diverse PA, e quindi tra istanze differenti di quelli che vengono chiamati domini applicativi, in cui gli stessi dati sono riconducibili alla tipologia di notifiche di evento. Si tratta cioè dello scambio di un messaggio asincrono, che non richiede una risposta, ma al più una ricevuta di notifica che attesta la consegna. La notifica di evento è tuttavia una funzione sincrona rispetto alla ricevuta di consegna al servizio di notifica eventi (equivalente alla ricevuta di attestazione). La tipologia di scambio dati a notifica di evento può essere realizzata con un servizio di publish and subscribe in cui: il dominio pubblicante fa uso dei servizi di amministrazione per registrarsi e comunicare l intenzione di notificare eventi ai domini sottoscrittori; il dominio sottoscrittore usa i servizi di amministrazione per registrarsi comunicando cioè il suo interesse a ricevere tutti gli eventi di una certa classe e tipo; il gestore del servizio è responsabile del corretto funzionamento del sistema stesso, sia dal punto di vista tecnico che organizzativo, garantendo le caratteristiche di sicurezza, affidabilità e disponibilità richieste. Si noti che in un servizio di Publish and Subscribe non si presuppone alcun carattere di transazionalità degli scambi di messaggi: non vi sono cioè caratteristiche di tipo ACID (Atomicity, Consistency, Isolation, Durability) degli scambi né vi è, almeno ad un primo livello, la necessità di mantenere un concetto di stato della transazione, se non con la consegna completa, da parte del dominio pubblicante, di tutti gli eventi. 64

65 Dal punto di vista architetturale, un tale servizio di P&S può essere realizzato, nel contesto della RUPA, utilizzando schemi basati su contesto dei servizi Internet, oppure basati sull utilizzo di tecnologie middleware. Un sistema tipico è composto delle seguenti parti: Porta di sottoscrizione/pubblicazione: espone al dominio le interfacce di pubblicazione, sottoscrizione, notifica; Servizio di P&S: espone al dominio il repository degli schemi degli eventi, controlla e valida gli eventi stessi, prevede funzioni di gestione e di logging; Servizio di directory: servizio infrastrutturale che mantiene le informazioni su: directory dei domini, elenchi di pubblicanti e sottoscrittori, directory degli eventi pubblicati; Proxy di P&S: garantisce l accesso al servizio di P&S ai domini esterni alla RUPA. 5.7Cooperazione basata su transazioni Le architetture esposte nel par. Precedente fanno riferimento a scambi di messaggi in cui non è prevista una esplicita gestione delle transazioni né dello stato dell elaborazione o di un processo all interno della porta di dominio. Nei casi in cui si renda invece necessario realizzare un sistema che effettui elaborazioni condizionate da una sequenza precisa di scambi dati con altre applicazioni, dati necessari alla prosecuzione stessa della elaborazione, va considerato uno schema architetturale differente. Va infatti presa in considerazione la necessità di realizzare, nella porta di dominio, un motore di logica applicativa che, interagendo con il sistema informativo esistente all interno del dominio e con le richieste/notifiche di eventi provenienti dal altri domini, gestisca l elaborazione delle informazioni di entrambi. La necessità di realizzazione di siti e portali Internet con precise esigenze di scalabilità, robustezza e modularità hanno permesso di delineare uno schema architetturale di massima formato da: Interfaccia verso la rete: in cui un componente di ascolto (es. Web server), replicato per esigenze di affidabilità, accetta richieste di servizio e notifiche di evento e ne invia la risposta Motore logico: in cui un componente di elaborazione (es. Application server), anch esso replicato, consente caratteristiche di scalabilità e modularità nel comunicare con il sistema informativo di dominio Sistema di coda di messaggi: servizio di supporto alle due componeti sopra descritte necessario per garantire l interazione con sistemi informativi esistenti anche di tipo batch. 65

66 5.8Modalità di integrazione e sviluppo Sulla base di quanto indicato nel paragrafo 5.3, sono individuabili due macrofiloni di azioni. A1. Azioni a breve termine e di tipo transitorio finalizzate a: rendere pubbliche le informazioni raccolte attraverso l attività di censimento (catalogo delle informazioni disponibili e dei servizi di accesso disponibili) favorire la costruzione di servizi di accesso alle basi dati pubbliche destinate a supportare le esigenze immediate di chi opera nella pubblica amministrazione (ad esempio per aspetti legati all autocertificazione) A2. Azioni a medio-lungo termine e di tipo stabile: razionalizzare le informazioni migliorare la qualità dei dati costruire servizi di accesso alle informazioni utilizzabili da parte di applicazioni (pubblicazione dei servizi) Le azioni di dettaglio correlate ai macrofiloni sono: A1.MicroAzioni a breve termine e di tipo transitorio : A21. Sperimentazioni su aree territoriali limitate e filoni tematici specifici: censimenti delle basi dati disponibili costruzione di servizi di accesso alle informazioni utilizzabili da parte di operatori A22. Estensione delle sperimentazioni su altre aree territoriali e su altri filoni tematici A2. MicroAzioni a medio-lungo termine e di tipo stabile A23. Sperimentazioni su aree territoriali limitate e filoni tematici specifici: Definizione di un metamodello per il censimento dei dati Popolamento del metamodello su alcuni filoni tematici Integrazione di basi dati tra enti Bonifica massiva di basi dati Pubblicazione di servizi di accesso a tali basi dati integrate e validate accessibili da parte di applicazioni A24. Estensione delle sperimentazioni su altre aree territoriali e su altri filoni 66

67 Nella pagina seguente è riportato un piano di massima delle azioni, in cui vengono evidenziate le sequenzialità. 67

68 Piano di massima delle azioni. ID Nome attività 1 Azioni a breve termine Anno 1 Anno 2 Anno 3 Anno 4 Tri 1 Tri 2 Tri 3 Tri 4 Tri 1 Tri 2 Tri 3 Tri 4 Tri 1 Tri 2 Tri 3 Tri 4 Tri 1 Tri 2 Tri 3 Tri 4 2 Sperimentazioni progetti su ambiti territoriali e tematici limitati 3 Censimenti delle basi dati disponibili 4 Censimenti delle esigenze di informazioni 5 Pubblicazione di servizi di accesso alle informazioni destinate ad operatori 6 Estensione della sperimentazione ad altri ambiti territoriali e ad altre aree tematiche 7 Azioni a medio-lungo termine 8 Matrici materie/dati/enti 9 Sperimentazioni progetti su ambiti territoriali e tematici limitati 10 Razionalizzazione delle basi dati 11 Miglioramento della qualità dei dati 12 Pubblicazione di servizi di accesso alle informazioni destinate alle applicazioni 13 Estensione della sperimentazione ad altri ambiti territoriali e ad altre aree tematiche 68

69 5.9Impatto dell'integrazione Questo paragrafo analizza l'entità dell'impatto (rischi, costi) delle iniziative enunciate nel paragrafo precedente e profila le possibili scelte a livello operativo per minimizzare tale impatto. Si può notare infatti che tali iniziative sono essenzialmente di due tipi: interne al dominio e alla amministrazione ed esterne ad essa. Nella prima classificazione rientrano tutte le operazioni volte al censimento dei dati e al miglioramento della loro disponibilità. Nella seconda rientrano invece le iniziative, necessariamente più complesse e più critiche, volte a pubblicare tali informazioni mediante servizi di rete. Si parla di criticità maggiore in quanto il coinvolgimento non è più soltanto limitato ad un dominio di una amministrazione esportatrice, ma anche a tutte quelle utilizzatrici dei servizi e dei dati, che devono necessariamente allinearsi per quanto riguarda i formati di pubblicazione e di scambio. Per cooperare e condividere informazioni servono infatti degli standard di strutturazione delle informazioni che, al di là della loro qualità intrinseca, consentano il supporto da parte del numero più ampio possibile delle entità amministrative e non, coinvolte negli scambi. In passato si è utilizzata ad esempio l'architettura Corba nelle Intranet che risultava interessante per le caratteristiche di apertura e completezza. Ora serve uno standard per Internet, che, a differenza di Corba consenta l'utilizzo di infrastrutture di sicurezza, quali firewall e altro, senza appesantirne la gestione. Come si vedrà più diffusamente nel capitolo 8, una architettura molto interessante da impiegare in ambito PA per la condivisione di servizi e informazioni si sta di recente sviluppando con l'accordo progressivo di tutte le maggiori industrie informatiche mondiali. Risulta utile ora esaminare brevemente questo approccio, denominato "Web Services", per esemplificare la limitatezza dei rischi legati all'adozione delle nuove tecnologie. I Web Services sono interfacce basate sul formato XML per pubblicare servizi commerciali, amministrativi o applicativi sulla rete. All'interno del modello Web Services, uno standard molto interessante è rappresentato da SOAP, il formato XML utilizzato per lo scambio di informazioni su Internet. SOAP e stato inizialmente ideato da un raggruppamento di aziende e soltanto successivamente sottoposto al consorzio per la standardizzazione di Internet, il World Wide Web Consortium (W3C), che lo sta infatti utilizzando come punto di partenza per la formulazione dello standard per il messaging basato su XML, chiamato "XML Protocol". SOAP si è affermato in breve tempo e può tranquillamente essere considerato uno standard industriale. Inoltre, i maggiori operatori dell offerta di I.T. stanno ulteriormente compiendo una intensa attività tendente ad assicurare la più diffusa disponibilità di implementazioni dello standard su uno spettro ampio di piattaforme di sistemi. Questo fatto è significativo in quanto dimostra come tutti i produttori dell industria informatica mondiale stiano riuscendo a produrre in tempi decisamente rapidi un quadro armonico di standard per la condivisione di servizi sul Web. 69

70 SOAP costituisce un primo passo, ma fondamentale. Sia per l interesse che ha richiamato sulla architettura Web Services, sia per le successive iniziative di standardizzazione che ha stimolato. Se da una parte si tratta infatti di un formato sufficiente soltanto per web services di tipo semplice, dall altra proprio questa sua evidente semplicità ha fornito lo spunto per iniziative quali XML-Protocol (del W3C) o ebxml (delle Nazioni Unite) volte a fornirne estensioni compatibili e non proprietarie. Dal punto di vista della Pubblica Amministrazione Italiana, l accordo delle industrie informatiche mondiali e la standardizzazione dei protocolli rappresentano una grandissima opportunità. Dotarsi di sistemi informatici basati sulle architetture e sugli standard aperti è il passo fondamentale da intraprendere per il miglioramento della disponibilità dei dati pubblici. Tuttavia questo non è sufficiente: questi nuovi standard tecnologici, per poter essere efficacemente impiegati, devono essere accompagnati da una standardizzazione interna alla Pubblica Amministrazione dei processi e delle modalità dell interazione, in un ottica di apertura. L utilizzo di XML o di SOAP, per fare un esempio, da solo non basta e deve essere accompagnato dalla formalizzazione del documento o del processo amministrativo, per consentire a più amministrazioni di completare un provvedimento. In sostanza quindi, solo un approccio alle nuove tecnologie accompagnato da un programma di standardizzazione istituzionale può consentire alla Pubblica amministrazione di porsi al riparo da soluzioni proprietarie e di porre le basi per la condivisione efficace dei dati pubblici. 70

71 6.APPROFONDIMENTO DELL ANALISI SU ALCUNI FILONI 71

72 6.1Obiettivo Obiettivo di questo capitolo è quello di approfondire l analisi funzionale all interno di alcuni ambiti individuati. In particolare il contesto nel quale si intende operare è la costruzione di una matrice che evidenzi per materie le informazioni della Pubblica Amministrazione e per ciascuna informazione ed entità coinvolta gli enti fornitori ed i potenziali fruitori delle stesse in un ottica di interscambio. 6.2Inquadramento sulla matrice materie/dati/fornitori/fruitori Come si è detto nel capitolo 5, al paragrafo 5.2 relativo alla metodologia per i dati, sono individuabili due fasi di lavoro. Nella prima fase di lavoro le azioni si avviano con un censimento delle basi dati esistenti, nella seconda fase con un censimento dei dati esistenti. La differenza non è lieve, in quanto attualmente ogni ente della Pubblica Amministrazione dispone di proprie basi dati costruite in funzione degli ambiti delle proprie competenze. Ha perciò organizzato i dati in funzione della fetta di competenze attribuitagli per legge. Come viene detto nelle linee strategiche dell AIPA, le riforme in atto prefigurano ora un nuovo scenario, che vede in enti locali e agenzie il principale frontoffice nei confronti dei cittadini e assegna alle Amministrazioni Centrali un ruolo principalmente di indirizzo e coordinamento. Il punto di vista necessario è perciò quello di definire in primis i dati di interesse per la pubblica amministrazione, vista nel suo complesso, ricostruire il quadro di chi dispone di quei dati, verificare la qualità dei dati attuali, integrarli e infine farli circolare tra tutti coloro che ne necessitano in funzione delle diverse competenze. Questo garantisce la disponibilità dei dati pubblici in diversi punti della rete e la possibilità di avere un quadro completo delle informazioni presso le diverse amministrazioni (di front-office e di backoffice). Sono distinguibili due macrotipologie di informazioni di interesse per la Pubblica Amministrazione: quelle legate al funzionamento interno di un ente, alle funzioni politiche e di coordinamento; quelle legate ai beni e servizi erogati al pubblico ed alle imprese. I dati della prima tipologia circolano in genere all interno dell ente stesso, ma per lo più non vengono scambiate tra amministrazioni diverse. I dati della seconda tipologia invece, specie in relazione ai processi di decentramento in atto, tendono ad essere oggetto di scambio tra amministrazioni diverse. 72

73 Se si utilizza come base di classificazione delle funzioni organizzativo-gestionali degli enti pubblici (in particolar modo relative al comparto dei Ministeri e degli enti locali), la classificazione Istat-RGS, sono individuabili quattro macro-aree: Coordinamento: comprende tutte le attività finalizzate al coordinamento delle Amministrazioni Pubbliche; Funzionamento: comprende tutte le attività riguardanti il funzionamento interno delle Amministrazioni Pubbliche; sono comprese quindi la gestione del personale ed amministrativo/ finanziaria, l organizzazione, i servizi al personale; Istituzionale: comprende tutte le attività di produzione di beni e servizi erogati al pubblico ed alle imprese; Indirizzo Politico: comprende tutte le attività di indirizzo politico delle Amministrazioni Pubbliche. Per trattare quindi il tema dell interscambio di dati nella pubblica amministrazione, è opportuno prendere in considerazione soprattutto le funzioni che ricadono nella macroarea Istituzionale. Su tali funzioni, si approfondisce la possibilità di classificare le informazioni di interesse per la Pubblica Amministrazione attraverso una matrice materie/dati/fornitori/fruitori Lo schema di massima è il seguente Materie Dati Ente fornitore Ente fruitore Enti La materia è un insieme di funzioni e compiti esercitati da un ente della Pubblica Amministrazione. I dati sono le tipologie di informazioni trattate dall organizzazione Pubblica Amministrazione intesa in senso lato, ovvero le macroaggregazioni di informazioni elementari utilizzate nella organizzazione. Gli enti sono gli organi della Pubblica Amministrazione sia centrale che locale: essi si possono configurare come fornitori o come fruitori di informazioni. Il legame fra Enti Fornitori e Fruitori e i Dati avviene tramite i Servizi. Il legame fra Enti e Materie avviene tramite le Competenze. 73

74 I servizi sono i processi attraverso i quali ciascun ente fornisce e/o richiede delle informazioni. Possono rivestire un carattere più o meno formale, presentandosi come richieste di verifica o consultazioni di dati specifici (Visure) o come richieste di certificati. La competenza è l insieme di funzioni (amministrative e organizzative) attribuite ad un ente in base alla normativa di riferimento. Dettagliando lo schema in uno schema concettuale, definibile come metamodello, si può ottenere quanto mostrato nella pagina seguente. 74

75 75.

76 72.

77 6.2.1Materia La materia è un insieme di funzioni e compiti esercitati da un ente della pubblica amministrazione. Si specializza gerarchicamente in questo modo Settore/Ambito della materia Materia L ambito/settore è un agglomerato di funzioni e compiti esercitati da un ente della pubblica amministrazione. La materia è un agglomerato minore di funzioni e compiti esercitati da un ente della pubblica amministrazione. La scelta delle materie viene effettuata sulla base di classificazioni esistenti. Ad esempio, se si prendono come riferimento le funzioni ed i compiti amministrativi conferiti alle regioni, alle province, ai comuni, alle comunità montane o ad altri enti locali dalle leggi Bassanini, si possono fare i seguenti esempi di Ambito e materia: Settore/Ambito (dalle Leggi Bassanini) Sviluppo economico e attività produttive Materia Artigianato Industria Energia Miniere e risorse geotermiche Ordinamento delle camere di commercio, industria, artigianato e agricoltura Fiere e mercati e commercio Turismo ed industria alberghiera 6.2.2Dati I dati sono le tipologie di informazioni trattate dall organizzazione pubblica amministrazione intesa in senso ampio, ovvero le macroaggregazioni di informazioni elementari utilizzate nella organizzazione. Essi si specializzano come segue: macroentità entità microentità attributi delle microentità 77

78 Riportiamo in figura lo schema più astratto, in cui compaiono le macroentità, tratto dal testo B1 della bibliografia e la successiva definizione delle macroentità 3 : Soggetto, cui corrispondono i soggetti fisici e giuridici che chiedono servizi alla Pubblica amministrazione. Bene, che corrisponde all insieme dei Beni mobili e Immobili su cui la Pubblica Amministrazione ha responsabilità ed eroga servizi. Documento, che corrisponde all insieme dei documenti che la Pubblica Amministrazione utilizza e produce nei processi amministrativi. Riferimento Territoriale, costituito dall insieme di tutte le modalità amministrative e geografiche con cui è possibile descrivere il territorio (es, comune, provincia, particella catastale, ecc.). Unità Organizzativa, che descrive tutte le suddivisioni organizzative in cui si articola la Pubblica Amministrazione centrale (ministeri, direzioni generali, divisioni, uffici, unità periferiche). 3 B1: "Sistemi informativi per la Pubblica Amministrazione: Metodologie e Tecnologie" realizzato a cura di Carlo Batini e Gaetano Santucci. Scuola Superiore della Pubblica Amministrazione 78

79 Ecco alcuni esempi di gerarchia Macroentità Entità Microentità Attributi Soggetto Persona fisica Identificazione Nascita Residenza Identificazione tributaria Identif. sanitaria Fruizione serv. Sanitari Malattie e stati sanitari Nome Cognome Comune nascita Data nascita Comune di residenza Indirizzo Data di inizio residenza Codice Fiscale Tessera sanitaria ASL di iscrizione Medico di base Diabete Tossicodipendenze Persona giuridica Anagrafica soggetto Localizzazione Sede Nascita impresa Denominazione Codice fiscale Partita IVA Comune della sede Indirizzo Data di inizio localizz. Data di inizio attività 6.2.3Enti Essi si specializzano come segue: Tipologia ente Ente Unità organizzativa Nella tabella seguente viene dato un esempio di specializzazione di ente Tipologia ente Ente Unità organizzativa Pubblica Comune Ufficio Anagrafe Amministrazione Ufficio Stato Civile Locale.. ASL Ufficio Igiene.. 79

80 6.2.4Servizi Il servizio è il prodotto di un processo elaborativo, talvolta complesso, operante sui dati che si rende necessario per soddisfare le esigenze informative degli uffici della PA. Nel caso in cui il servizio sia di tipo informatizzato, esso è il prodotto di un processo elaborativo realizzato direttamente dal sistema informativo. I servizi necessari per un ente della Pubblica Amministrazione sono strettamente correlati con le sue competenze (compiti gestionali, di programmazione, di pianificazione). Possono rivestire un carattere più o meno formale, presentandosi come richieste di verifica o consultazioni di dati specifici (Visure, liste) o come richieste di certificati. Le esigenze informative degli uffici della PA relative ai dati, vengono soddisfatte per mezzo di richieste indirizzate ad uffici interni all ente oppure ad uffici di altri enti. Le richieste possono essere presentate per mezzo di comunicazioni telefoniche, via fax o per mezzo di richieste scritte con gradi diversi di formalità; oppure attraverso richieste telematiche. Nel caso si tratti di dati riservati, è necessario accertare l origine della richiesta e verificare se il richiedente è autorizzato ad ottenere le informazioni richieste. Le richieste riguardano informazioni contenute in archivi cartacei o informatizzati. Per alcune tipologie di richieste è necessario svolgere complesse attività di ricerca negli archivi; nel caso di archivi automatizzati è possibile ottenere in modo automatico, per mezzo di funzioni informatiche, le informazioni richieste Competenze La competenza è l insieme di funzioni (amministrative e organizzative) attribuite ad un ente in base alla normativa di riferimento. Un esempio di classificazione di competenze è il COFOG delle Nazioni Unite Possibili utilizzi Lo schema sopradescritto, come anticipato, si configura come un metamodello. Esso è uno schema generale (che chiameremo modello generale ) indipendente dagli enti cui si riferisce: infatti l informazione Ente presente nel metamodello si riferisce all ente generico (ad esempio ente Comune). Affinché sia possibile istanziare il metamodello, in modo da poter effettivamente raccogliere le informazioni, è necessario inserire il riferimento allo specifico ente (ad esempio Comune di Torino ). Per questo motivo bisogna adeguare il metamodello aggiungendo le informazioni relative all ente specifico come segue (chiameremo questo metamodello modello specifico ), come evidenziato nella figura della pagina seguente: Il modello generale può essere utilizzato per mettere in evidenza gli obiettivi da raggiungere da parte delle Pubbliche Amministrazioni per migliorare la disponibilità dei 80

81 dati. In particolare i servizi forniti devono tendere ad un alto livello di qualità dei dati, ad una fornitura tempestiva, e devono prevedere l utilizzo di strumenti informatici sia come mezzo trasmissivo che come tipologia di supporto. I servizi richiesti devono poter essere fruiti attraverso l utilizzo di un meccanismo informatizzato. Nello schema riportato tra due pagine vengono pertanto impostati i valori ottimali con cui potranno essere confrontati i valori effettivi rilevati negli schemi specifici. Il modello specifico istanziato, risulta essere uno strumento utile a diversi scopi; in funzione del livello di dettaglio con cui viene popolato esso può consentire di: 1. verificare le disponibilità dei dati e le necessità di accesso a tali dati da parte dei diversi enti rispetto alle attuali competenze degli enti (fase di analisi preliminare); 2. verificare ipotesi di razionalizzazione ed ottimizzazione di flussi (fase di analisi organizzativa), sulla base delle anomalie di flusso evidenziabili attraverso la matrice stessa; tali ipotesi potenzialmente possono anche suggerire azioni da intraprendere in relazione alla distribuzione delle competenze; 3. costituire la base per il catalogo dei servizi di accesso ai dati pubblici (fase di analisi dei metadati); accessibile alle Pubbliche Amministrazioni. In relazione al primo punto, attraverso il popolamento del modello è possibile verificare la completezza delle informazioni; produrre report di sintesi (ad esempio tabelle Materie/Dati e Enti/ Dati, ecc). In relazione al secondo punto è possibile evidenziare nella matrice sopraindicata potenziali miglioramenti nei flussi attuali. Un esempio di razionalizzazione possibile potrebbe essere l obbligo di comunicazione di cambiamento di stato di un oggetto (notifica di eventi) da parte dell ente che rileva tale cambiamento a tutti gli altri enti che necessitano di tale informazione. Ad esempio uno studente si laurea; l ente accademico rileva l evento e comunica il cambiamento di stato agli enti interessati: il comune per l anagrafe, i centri per l impiego per l incontro domanda/offerta di lavoro, ecc. In relazione al terzo punto l ipotesi è quella di astrarre dalla matrice un metodo per accedere facilmente all elenco dei dati pubblici ed ai relativi servizi di accesso; ciascun dato e ciascun servizio verrebbe descritto in un catalogo attraverso un certo modello (modello dei metadati); la matrice diventa pertanto il canale di navigazione nel catalogo. 81

82 82.

83 83

84 84.

85

86 6.3Filoni individuati Al fine di approfondire e verificare su casi reali l impostazione metodologica esposta in precedenza, sono stati individuati i seguenti filoni: Popolazione, inteso non solo come anagrafe dei comuni, ma anche come anagrafe per l erogazione di nuovi servizi in materia sanitaria e tributaria; Catasto e dati territoriali, per andare incontro alle esigenze specifiche dei diversi enti territoriali; Imprese ad attività economiche, in collegamento con i servizi orientati ai temi del lavoro e alla sperimentazione a livello regionale del SIL; Opere pubbliche, per la ricomposizione di una visione unitaria della spesa pubblica ad ogni livello. Gli esempi di seguito individuati fanno riferimento al territorio piemontese (Comune di Torino, Regione, Province piemontesi). Ovviamente essi possono essere resi oggetto di verifica del livello di generalità attraverso un confronto con enti di altre aree del territorio nazionale Popolazione I nuovi sviluppi della Pubblica Amministrazione richiedono un sistema informativo anagrafico basato sia su una riprogettazione dell informazione (il cittadino fruitore di servizi) sia sulla realizzazione di un sistema tecnologico che permetta una facile evoluzione e il rilascio di nuovi servizi cioè la realizzazione di sportelli virtuali sul Web. Le soluzioni sono finalizzate a: costruzione del nucleo informativo anagrafico del cittadino; soluzioni efficaci ed automatiche per tutti i legami funzionali verso Sistemi Informativi Esterni (per esempio Tasse, comunali o regionali, Aziende Sanitarie); apertura del sistema, in modo controllato e sicuro, alle esigenze di interscambio ed interoperabilità sempre più emergenti ed evidenti (vedi carta d identità elettronica); gestione dell iter demografico e archiviazione dei documenti integrando le operazioni di sportello con quelle di back-office (es. lettera ad altro comune per richiesta d informazione) Premessa In tale contesto si analizzano, nell ambito delle persone fisiche (popolazione), i dati, gli enti coinvolti (fornitori/fruitori). 84

87 Dati Informazioni anagrafiche della persona fisica di interesse per: scuola (livelli di istruzione, obbligo formativo) sanità (certificati medici, eventi di infortunio) tributi autocertificazioni lavoro (denunce nuove assunzioni) Enti Coinvolti Regione Comuni Province ASL Aziende ospedaliere Scuole Atenei Ministero finanze Prefetture INPS INAIL 85

88 Matrice dati/materie/fornitori/fruitori Nella figura seguente viene dato un esempio di popolamento del modello specifico con alcune informazioni correlate alle persone fisiche. Tali informazioni sono state, in parte, ricavate dal materiale del progetto Nuova Anagrafe Open del CSI-Piemonte e del progetto finalizzato A9 del Dipartimento della Funzione Pubblica (interscambio flussi tra anagrafi). 86

89 6.3.2Catasto e dati territoriali Premessa Per conto del Comune di Torino è stata organizzata la nuova banca dati catastale, scaricando i dati provenienti dalle forniture per enti locali del Ministero delle Finanze, su un database Oracle. Nel presente contesto si è analizzata la realizzazione dell anagrafe delle Unità Immobiliari Urbane al fine di permettere l interscambio dei dati e delle informazioni fra il Ministero delle Finanze e il Comune di Torino. Materie: Settore/ambito Sviluppo economico e attività produttive Tutte Materia Dati I dati trattati sono quelli rilasciati dal Ministero delle Finanze secondo lo schema di estrazione da esso specificato nell ottica dell interscambio catasto/comuni, e comprendono sia informazioni relative al catasto fabbricati sia al catasto terreni. Attualmente i dati presenti nella banca dati sono relativi alle Unità Immobiliari Urbane e sono aggiornati al 17/1/2001. DATI Macroentità Entità Microentità Attributi Bene Bene immobile (Unità Immobiliare Urbana) Identificazione Codice amministrativo comune Sezione Foglio Numero Subalterno Localizzazione Ubicazione Classamento Catastale Toponimo Via Numero civico Cod. via Lotto Edificio Scala Interno Piano Zona Categoria Classe 87

90 Soggetto Terreni Persona fisica/giuridica Consistenza Dimensionamento Superficie Rendita Rendita in lire Rendita in Euro Identificativo Partita catastale pratiche Data registrazione Identificativo Codice amministrativo comune particella Sezione Foglio Numero Subalterno Edificialità Classamento Qualità catastale Classe Dimensionamento Ettari Are Centiare Reddito Dominicale in lire Agrario in lire Dominicale in Euro Agrario in Euro Identificativo Partita catastale pratiche Data registrazione.. Identificativo Cognome/denominazione soggetto Nome Sesso Nascita Data di nascita Luogo di nascita Identificativo fiscaleccodice fiscale/partita IVA Titolarietà Codice di diritto Quota di titolo Regime Identificativo Partita catastale pratiche Data registrazione Data di validità Tipo nota. 88

91 Enti Coinvolti Gli enti che collaborano ai processi di interscambio sono: Il Ministero delle Finanze che, attraverso l Agenzia del territorio provinciale, annualmente dovrebbe fornire lo scarico dei dati catastali aggiornati attraverso l Ufficio Provinciale del Territorio; Il Comune (di Torino) con i suoi diversi uffici quali: - Ufficio Tributi - Ufficio Urbanistica - Ufficio Pratiche edilizie - Ufficio Toponomastica. 89

92 Matrice dati/materie/fornitori/fruitori Nella matrice, riportata alla pagina seguente, si dettaglia a titolo di caso studio, il servizio di visura catastale (finalizzata alla verifica della rendita dell immobile) collegata a funzioni amministrative quali ad esempio il calcolo della tassa ICI, il riscontro delle dichiarazioni dei contribuenti ecc. 90

93 6.3.3Attività economiche e tributi Premessa Le leggi Bassanini, nelle parti che riguardano le funzioni dello Stato in rapporto alle Regioni e agli Enti Locali, definiscono una profonda trasformazione nel quadro di riferimento normativo e di funzionamento dell amministrazione decentrata. Questo mutamento avrà, come prima e immediata conseguenza, un impatto rilevante sia sulla direzione sia sulle caratteristiche dei flussi finanziari e decisionali che collegano le diverse unità amministrative ad iniziare da quelle più centrali a quelle che si collocano nell estrema periferia. Se prendiamo in considerazione l aspetto gerarchico dei flussi, noteremo uno spostamento della dimensione verticale dall asse Stato-Regioni all asse Regioni-Province, in quanto l attribuzione di funzioni di governo alle Regioni, mentre da un lato allenta i legami fra queste ultime e lo Stato, dall altro enfatizza la relazione fra il neo-governo regionale e le sue Province. La dimensione orizzontale, tra le Regioni e tra le Province, è prevista, genericamente, in sensibile aumento a causa del decentramento amministrativo e della conseguente distribuzione delle competenze ad un livello territoriale che da centrale diventa locale: qui l asse di collegamento che va a consolidarsi (o a crearsi laddove è assente) può essere sia quello che intercorre fra gli enti locali, che si trovano sullo stesso livello gerarchico (per uno scambio necessario di dati), sia, in un quadro di crescente necessità di aumento dell interdisciplinarietà, quello che unisce i diversi Assessorati all interno della Regione. In questo contesto, la Pubblica Amministrazione ha necessità di disporre di informazioni aggiornate e dettagliate sulle imprese piemontesi. Nel corso degli anni, all interno del S.I.Re, si sono creati vari archivi anagrafici delle aziende finalizzati a gestioni specifiche (Wirp, Ambiente, Protocollo, Agricoltura, Formazione Professionale) e quindi incompleti e con vari livelli di aggiornamento che le rendono ad oggi non integrabili e comunque non coprirebbero l universo delle attività produttive piemontesi. Oggi la maturità tecnologica e l esistenza di una infrastruttura di rete regionale rendono realizzabile il progetto di costituzione di una unica Anagrafe delle Attività Economiche e Produttive (AAEP), alla quale potranno far riferimento tutte le altre realtà che la utilizzano per le proprie esigenze. In tale contesto si analizza la realizzazione di una anagrafe delle attività economiche e produttive piemontesi (AAEP) nell ottica di un suo utilizzo da parte della Direzione Regionale Tributi. La materia di interesse è la seguente: Settore/Ambito (dalle Leggi Bassanini) Sviluppo economico e attività produttive Materia Tutte 91

94 Dati Macroentità Entità Microentità Attributi Soggetto Persona giuridica identificazione Denominazione Cognome e nome (per ditte individuali) Codice fiscale Partita IVA Costituzione Localizzazione sedi Dimensione Attività economica Data inizio attività Data fine attività Motivo cessazione Tipo sede Comune della sede Indirizzo Data inizio attività Data cessazione Motivo cessazione Numero dipendenti informazioni sulle persone giuridiche di interesse per: - l incontro domanda offerta di lavoro - i tributi - infortuni sul lavoro - l emersione del lavoro nero Enti Coinvolti Tipologia ente Ente Unità organizzativa Pubblica Amministrazione Locale Provincia Comune Tutti i settori Tutti i settori Regione Tutti i settori 92

95 Matrice dati/materie/fornitori/fruitori Nella matrice presentata in questa pagina si dettagliano, come esempio, i servizi di visura o estrazioni massive collegate all espletamento di tutte le mansioni amministrative degli enti coinvolti, collegabili sia alle competenze sul lavoro sia a quelle di tipo tributario. 93

96 6.3.4Lavoro Premessa La L.R. n.41 del 14/12/98 ha definito le modalità di costituzione, gestione e riorganizzazione del Centri pubblici per l impiego, la cui efficienza è l obiettivo primario perseguito in tema di politica europea per l occupazione, in quanto costituisce uno strumento basilare per la promozione dell occupabilità a vantaggio sia delle persone in cerca di occupazione sia delle imprese in cerca di personale. Il passaggio graduale di competenze e risorse alle Regioni è stato avviato tramite la soppressione degli uffici periferici del Ministero deputati alle politiche per l impiego (Agenzie per l Impiego e SCICA) e l organizzazione di uffici analoghi che prendono rispettivamente il nome di Agenzie regionali del lavoro e Centri per l impiego. In Piemonte la riorganizzazione del sistema pubblico per l impiego ha portato alla definizione di 30 bacini provinciali del lavoro, intesi come ambiti territoriali che individuano la realtà dei flussi di mobilità tra residenze e luoghi di lavoro. L avvio dei nuovi Centri per l impiego prevede una profonda transizione tra il vecchio ed il nuovo sistema che comporta, oltre alla riorganizzazione delle metodologie operative, al miglioramento delle strutture e alla riqualificazione degli operatori, la definizione di nuovi e importanti obiettivi: dotare il sistema economico e i cittadini piemontesi di efficienti servizi per l incontro tra la domanda e l offerta di lavoro, per l orientamento personalizzato e per il sostegno ai soggetti deboli; accrescere le domande e le offerte lavorative relative a formule particolari (part-time, telelavoro); favorire lo sviluppo dell imprenditorialità e la creazione e lo sviluppo di imprese innovative. Si prospetta quindi un arricchimento del SIL Piemontese nell ottica dell utilizzo da parte dei Centri per l impiego di funzionalità di interscambio informativo con INPS - INAIL in quanto potenziali utilizzatori di servizi anagrafici, propedeutici alla gestione dell incontro tra domanda e l offerta di lavoro. In tale contesto si è quindi analizzata la realizzazione di un protocollo unico di comunicazione che consenta alle Imprese la comunicazione simultanea all INAIL e ai Centri per l Impiego, degli avviamenti e delle cessazioni di lavoro. Materie: Settore/Ambito (dalle Leggi Bassanini) Sviluppo economico e attività produttive Materia Mercato del lavoro 94

97 Dati Macroentità Entità Microentità Attributi Soggetto Persona fisica Identificazione Anagrafica Nome Cognome Sesso Comune nascita Data nascita. Identificazione Tributaria Localizzazione Attività lavorativa Posizione assicurativa Codice Fiscale Comune di residenza Indirizzo Sede di lavoro (identificazione persona giuridica) Data inizio rapporto Livello assunzione Qualifica assunzione Contratto applicato Tipo rapporto (tempo pieno, parziale) Ore settimanali Data fine rapporto Motivo cessazione attributi DNA INAIL. Soggetto Persona giuridica identificazione Costituzione Localizzazione sedi Dimensione Denominazione Cognome e nome (per ditte individuali) Codice fiscale Partita IVA Attività economica Data inizio attività Data fine attività Motivo cessazione Tipo sede Comune della sede Indirizzo Data inizio attività Data cessazione Motivo cessazione Numero dipendenti Enti Coinvolti 95

98 Tipologia ente Ente Unità organizzativa Pubblica Amministrazione Regione Direzione Lavoro Locale Provincia Centro per l Impiego Comune Sportello Unico INAIL INPS Attività relative alla competenza Lavoro : Ente Regione (Direzione Lavoro) Provincia (Centro per l Impiego) Attività Monitoraggio delle mobilità lavorative Rilevazione delle assunzioni e dei licenziamenti lavoratori; supporto tecnico alle imprese per l espletamento degli adempimenti normative relativi al mercato del lavoro Comune (Sportello Unico) INAIL INPS Sostegno e orientamento alle imprese Assicurazione Lavoratori Previdenza sociale 96

99 Matrice dati/materie/fornitori/fruitori Nella matrice, presentata nella pagina seguente, si dettaglia, come esempio, il servizio di comunicazione degli assicurati collegato all attività di monitoraggio delle mobilità lavorative da parte degli enti interessati. 97

100 6.3.5Opere pubbliche Premessa L'Osservatorio dei LL. PP. è stato istituito nel maggio del 1999 presso il Settore Opere Pubbliche della Regione Piemonte, allo scopo di sperimentare procedure informatizzate di raccolta dati sui lavori pubblici avviati sul territorio piemontese. La nascita dell'osservatorio ha rafforzato la possibilità di realizzare la Banca Dati sui Lavori Pubblici, segnalata all'art. 31 della Legge Regionale 18/84, ovvero la Legge generale in materia di opere e lavori pubblici, poiché ha istituito una struttura di riferimento riconoscibile per tutti gli enti piemontesi. L'Osservatorio ha iniziato un'operazione di coinvolgimento di tutti gli enti localizzati sul territorio piemontese, attraverso la divulgazione dei nuovi adempimenti in materia di lavori pubblici, e successivamente attraverso manifestazioni e incontri. I primi dati pervenuti sono stati archiviati su un database Oracle, attraverso il caricamento manuale di schede cartacee, procedimento che ha subito rivelato i limiti in termini di efficienza e di disponibilità di risorse. Questo riscontro, insieme all'esiguità delle risposte in termini numerici da parte degli Enti, ha comunque rivelato la necessità di intervenire con maggiore efficacia sulla diffusione delle informazioni sulle attività in corso e soprattutto sulla disponibilità delle nuove tecnologie, in grado di semplificare l'attività amministrativa e di facilitare la trasmissione e la circolazione delle informazioni. Le successive evoluzioni della Legge Quadro sui Lavori pubblici, dal 1994 al 1998, fino agli ultimi provvedimenti in materia, risalenti al 2000, hanno modificato sostanzialmente la cultura all'interno delle Amministrazioni pubbliche, rivoluzionando il sistema di gestione di un'opera pubblica. Per realizzare questo obiettivo, è stato richiesto l'impegno di Autorità per la Vigilanza sui LL. PP., Regioni, Enti locali e altre Amministrazioni aggiudicatrici. Le Regioni entrano in questo processo come organi di supporto e assistenza alle stazioni appaltanti presenti sul loro territorio, e allo stesso tempo raccolgono e archiviano i dati sugli appalti. Il sistema si afferma quindi con l'individuazione, per ciascuna regione, di una Sezione Regionale dell'osservatorio, che raccoglie i dati, ne verifica la regolarità e li trasmette all'osservatorio centrale di Roma, il quale svolge le elaborazioni utili a supportare l'attività di vigilanza. Questa azione coordinata ha portato all'oggettivo risultato attuale per cui è oramai garantito un flusso costante di dati riguardanti i lavori pubblici, in Piemonte come in tutte le altri regioni di Italia, dalle stazioni appaltanti verso la Regione, e dalla Regione verso l'autorità a Roma. 98

101 Dati In adempimento a quanto previsto dalla Legge 109/94 e s.m.i., del suo regolamento di attuazione - il D.P.R. 554/99 - in ottemperanza anche del D.M. del 21 giugno 2000, e del D.P.R sulla Qualificazione delle imprese, l'osservatorio dei Lavori Pubblici della Regione Piemonte raccoglie dati sui lavori pubblici trasmessi dalle Stazioni appaltanti piemontesi. L'attività di raccolta era già stata preceduta, in base alla L.R. 18/84, da un monitoraggio sugli appalti di Ecu, che sono confluiti nella banca dati 97/98/99. Le schede proposte alle amministrazioni contenevano pochi dati, ma servivano soprattutto per avviare un dialogo con le amministrazioni periferiche, in vista dello stabilizzarsi delle procedure. Dopo l'istituzione della Sezione regionale dell'osservatorio dei LL. PP., i dati che per legge vengono raccolti e acquisiti mediante procedure informatiche sono soggetti a un regime di forte controllo, che garantisce: informazioni sui lavori pubblici appaltati o affidati, a partire dal 1 gennaio del 2001; programmi triennali dei LL. PP. a partire dal triennio ; informazioni anagrafiche su soggetti e imprese Enti Coinvolti Gli enti che collaborano e intervengono direttamente nei processi di interscambio dati allo stato attuale sono: Stazioni appaltanti come indicate dall'art. 2 comma 2 della L. 109/94 e s.m.i.; Sezioni Regionali dell'osservatorio; Osservatorio Nazionale; Autorità per la Vigilanza sui LL.PP. A questi organismi si aggiungono tutti quegli enti che sono coinvolti nel processo, nella definizione delle metodologie esposte, a cui l'autorità è legata attraverso protocolli di intesa: Ministero dei LL. PP. Ministero dell'interno Inps Inail Istat In seguito si individuano enti che potrebbero esser coinvolti attraverso la stipula di convenzioni con l'osservatorio regionale e nella ricezione dei dati possono essere: Prefettura Camera di Commercio Ispettorato del Lavoro Cassa edile 99

102 Ordini professionali Ance Anci Upi Matrice dati/materie/fornitori/fruitori Si rappresenta nel modello il caso di un Ente pubblico per descrivere il flusso di informazioni che passa dall'ente all'osservatorio regionale dei LL. PP. Il caso esaminato riguarda il Comune di Torino, il quale, per sua natura, non è l'unità organizzativa minima del flusso in questione, poiché il Comune è suddiviso in diverse aree ciascuna delle quali assume un competenza specifica per appalti gestiti. Quindi si è scelto, a titolo esemplificativo, il Settore Verde Pubblico, il quale cura le manutenzioni e le realizzazioni in ambito urbano delle aree verdi pubbliche e delle infrastrutture funzionali. Del flusso informativo che coinvolge le Stazioni appaltanti piemontesi e l'osservatorio si è preso in esame la comunicazione periodica di dati riguardanti gli appalti di importo superiore ai Euro, che vengono trasmessi al momento dell'aggiudicazione del lavoro e attestano l'inizio effettivo di realizzazione di un'opera pubblica. Il processo documenta l'inizio di un'attività "produttiva" e garantisce un flusso di dati che sarà continuo fino alla conclusione dell'opera stessa. Il processo coinvolge attualmente solo i due soggetti Regione Piemonte e Stazione appaltante (qui citati come Osservatorio regionale dei LL. PP. e Comune di Torino), ma alcuni dei dati trasmessi sono oggetto di ulteriori comunicazioni ad altri enti e organismi, e provengono da altri enti e organismi. Questo dimostra come spesso negli enti pubblici si accavallano le informazioni poiché sono richieste da più ambiti: nell'esempio riportato risulta evidente l'importanza delle anagrafiche dei soggetti, ma vi sono poi le comunicazioni di dati INPS, di dati ISTAT, di dati INAIL, e di altri dati che sono da trasmettere in adempimento a leggi o normative, ma che sono tuttavia dati soggetti a comunicazioni di natura divulgativa. 100

103 101.

104 6.3.6Ambiente Premessa Il progetto Interscambio Dati Ambientali (IDA) rappresenta una soluzione organizzativa e tecnologica che consente agli enti coinvolti l interscambio di dati ed informazioni Dati Il progetto di cui al precedente paragrafo è basata su un catalogo dei metadati e sull accesso ai dati tramite una lista di viste predefinite (i servizi informativi). Il Sistema, che opera nella Intranet regionale piemontese (PIR-PiemonteInRete) consente ai soggetti operanti all interno della rete di cooperazione l accesso diretto agli archivi presenti presso gli altri soggetti delle rete, minimizzando l impatto organizzativo e tecnico sui diversi sistemi locali, e garantendo ai fornitori il pieno controllo delle informazioni in uscita. Gli enti coinvolti sono la Regione Piemonte - Direzione Tutela e risanamento ambientale programmazione gestione rifiuti progetto, le Province piemontesi ed i Dipartimenti provinciali ed interprovinciali dell'arpa. Le basi dati che costituiscono il patrimonio conoscitivo del sistema di interscambio sono relative ai comparti rifiuti, emissioni in atmosfera e censimento dei corpi idrici, presenti nei sistemi informativi della Regione, dell ARPA, delle Province. Le basi dati utilizzate sono state individuate dai partner del Progetto IDA, sia per il loro interesse nell esame delle problematiche ambientali che per le loro caratteristiche specifiche, ai fini della sperimentazione dell efficienza della soluzione tecnologica, quali la struttura relazionale del database e la presenza di grosse moli di dati, in particolare di natura anagrafica, in modo da sperimentare in modo significativo le prestazioni del sistema. I dati sono gestiti in basi dati relazionali differenti (Oracle, Access, DBF, MS SQL Server...) Enti Coinvolti Regione Piemonte Dipartimenti dell ARPA Province piemontesi Matrice dati/materie/fornitori/fruitori Il caso descritto nella figura seguente esemplifica l'interazione dei diversi soggetti pubblici coinvolti nel sistema IDA nel caso particolare di scambio di dati in materia di rifiuti. La Regione dispone della base dati del MUD: modello unico di dichiarazione in materia di rifiuti. Tali dati provengono dalle Camere di Commercio. Il contenuto della base dati è di interesse per le province, competenti in materia. Attraverso interscambio dati, la Regione, che gestisce il db (data provider) crea delle viste sulla sua base dati e le collega al profilo-utente di ciascuna provincia. In tal modo ogni provincia (data user) può, collegandosi via Intranet ad IDA leggere il set di dati che è abilitata a vedere. Nello schema sono indicate le competenze della regione a mettere a disposizione i dati e della provincia ad acquisirli. Il servizio fornito è appunto l'accesso alla base dati del MUD. 102

105 Il settore è Territorio, Ambiente, Infrastrutture. La materia è Gestione Rifiuti. La caratteristica del sistema di interscambio è che il dato viene letto là dove esso è gestito ed aggiornato. 103

106 104.

107 7.LA QUALITÀ DEI DATI PUBBLICI: REQUISITI, ANALISI DELLA SITUAZIONE ATTUALE ED IPOTESI DI MIGLIORAMENTO 6.4Introduzione Diversi eventi, tra cui spicca il piano di e-government, ma anche altri non meno importanti, come la continua evoluzione delle tecnologie per il data-processing, l avvento di Internet, il continuo processo di decentralizzazione e la diffusa informatizzazione di strati sempre più grandi della popolazione, stanno spingendo le amministrazioni verso la necessità di condividere e migliorare i dati a loro disposizione, onde renderli fruibili ad altre amministrazioni e/o direttamente ai cittadini stessi. In questo contesto, il problema della Qualità dei Dati di cui si dispone, si pone immediatamente come elemento facilitante e/o inibente ai fini della fruibilità dei dati stessi da parte degli interessati (cittadini, Amministrazioni Pubbliche) oltre che ai fini dell integrazione dei sistemi, della condivisione dei dati stessi, e in definitiva dell interoperabilità delle amministrazioni. Il presente capitolo si pone l obiettivo di definire il contesto del problema, dare una definizione del concetto di qualità applicato ai dati, e delineare alcune linee guida nella definizione dei processi che porteranno ad un miglioramento della Qualità dei Dati. 6.5Le basi dati come modello del mondo reale Le Basi di Dati, soprattutto nel contesto della Pubblica Amministrazione, possono essere considerate come un modello della realtà, al limite molto specifica. Ovviamente, parlando di modelli, è implicita una semplificazione della realtà stessa, ma tale semplificazione non deve inficiare le caratteristiche salienti della realtà che si vuole modellare. La Qualità dei Dati è la misura dell accordo che esiste tra quanto rappresentato in un sistema informativo, e lo stesso dato nel mondo reale. Una Qualità dei Dati del 100% indica che esiste un perfetto allineamento dei dati presenti nel nostro sistema informativo, con quanto presente nel mondo reale. Data la natura di continua evoluzione caratteristica 105

108 del mondo reale, nessun sistema informativo di una dimensione significativa può avere una Qualità dei Dati del 100%. L obiettivo da perseguire è quello di avere dei dati sufficientemente aggiornati accurati consistenti tempestivi in modo che possano essere utilizzati efficacemente. Una caratteristica implicita nel concetto di dati aggiornati che però non traspare in modo evidente e non sottolinea a sufficienza le difficoltà sottese per avere dati aggiornati è la tempestività. La tempestività dell aggiornamento della informazione è vitale: significa che al termine della fase di acquisizione dei dati che rendono consistente le informazioni, queste devono essere incamerate nelle corrispondenti basi dati e devono essere rese disponibili a tutti gli interessati, siano essi Amministrazioni Pubbliche o cittadini. La mancanza di tempestività rende inutilizzabile una base dati: la qualità dei dati non abbinata alla tempestività rende la base dati (e l ente che la gestisce) non conforme alla realtà, fino a rendere poco credibile l intero sistema. Come si può immaginare la tempestività è una conseguenza: solo se sono state rispettate tutte le precedenti caratteristiche allora si deve perseguire anche la tempestività. In caso contrario la tempestività non abbinata ad altre caratteristiche rende comunque inutilizzabili i dati e non fa aumentare la qualità dell intero sistema. Pertanto i sistemi che si progettano dovrebbero poter garantire tutte le caratteristiche sopra descritte. I concetti anzi esposti portano a definire il concetto di contesto ovvero a definire quali realtà, processi e dati devono essere gestiti dalla Pubblica Amministrazione, quali siano le fonti che originano i dati (e/o le variazioni agli stessi), chi è il responsabile del trattamento degli stessi, quali sono le condizioni di qualità, chi sono i fruitori, quali sono i sistemi e le Amministrazioni a cui vanno resi disponibili. Sempre nell ambito del contesto rientra la individuazione delle fonti delle informazioni. In questo modo si stabilisce chi origina il dato, se la generazione è interna al proprio 106

109 sistema informativo o se proviene da fonti esterne al proprio sistema informativo: la distinzione è importante perché nel primo caso vi è una precisa responsabilità sulla qualità, tempestività, integrità ed univocità della informazione da parte del proprio sistema informativo mentre nel caso di origine esterna il nostro sistema è passivo. 6.6Motivazioni per migliorare la Qualità dei Dati Esistono sostanzialmente due ragioni che spingono al miglioramento della Qualità dei Dati: una crescita dell efficienza per sé, e il rinnovato contesto di condivisione delle informazioni tra le pubbliche amministrazioni. Un miglioramento della Qualità dei Dati comporta che, in caduta, anche i processi amministrativi che si basano su quei dati migliorano, riducendo l entità delle risorse impegnate in termini di denaro e tempo uomo. Alcuni esempi, tratti da fonti pubbliche, possono essere chiarificatori: i dati di residenza dei contribuenti possono non essere corretti una frazione significativa dei contribuenti non può essere raggiunta per comunicazioni via posta; gli uffici amministrativi possono forzare l inserimento di valori che violano i requisiti, oppure possono omettere la compilazione di certi campi non obbligatori; alcuni contribuenti hanno assegnato più di un SSN, risultando essere più persone fisiche ai fini fiscali; alcuni contribuenti non vengono identificati correttamente nei DB, perché i loro dati sono incorretti. Il contesto di condivisione delle informazioni introduce un ulteriore elemento di difficoltà, dal momento in cui i dati vengono resi disponibili ad entità terze. I requisiti di qualità, allorché i dati vengono resi disponibili anche al di fuori dell amministrazione originaria, potrebbero risultare non più sufficienti. È quindi importante definire la configurazione minima di presenza di dati garantita la quale possiamo accettare le informazioni fornite e registrarle nella nostra base dati e/o renderla disponibile a terzi. Se è il nostro sistema informativo a fornire dati per altri sistemi remoti, è opportuno e necessario che i processi gestionali tengano in considerazione i fabbisogni di tali sistemi remoti. In caso contrario il nostro sistema renderebbe disponibile una informazione che rischia di rendere inconsistente il sistema ricevete: il nostro non sarebbe quindi un dato qualitativamente accettabile. Una peculiarità da sottolineare relativamente ai nuovi sistemi informativi basati ampiamente sul concetto di gestione on line: il dato deve essere catturato là ove questo viene generato. Questa caratteristica non è sinonimo di garanzia di qualità dei dati ma certamente l entità preposta alla nascita del dato ha molti più elementi (se non tutti e comunque ha molti più elementi di un gestore off line) per poter generare un dato qualitativamente valido. Una seconda particolarità è la propagazione dei dati una volta che questi sono stati inseriti nel sistema informativo che li ospita: la propagazione è il processo di notifica ai sistemi che dipendono dal sistema che genera i dati. Questa deve essere automatica e il più vicino possibile al verificarsi dell evento che ha generato il nuovo dato o la modifica del 107

110 preesistente. Queste due particolarità sono anche le principali caratteristiche che devono avere i nuovi sistemi informativi. Le propagazioni di dati possono avvenire in diverse modalità, tra cui le tecniche push : al termine della registrazione i dati vengono notificati ai sistemi dipendenti. Non c è quindi tempo di attesa per la sincronizzazione tra le basi dati. Altro concetto importante è quello del ruolo attivo da parte del sistema generatore : il sistema che deve ricevere i dati non deve essere parte attiva nel reperirsi i dati ma questi vengono resi disponibili dal sistema che per primo ha acquisito la nuova informazione o ne ha gestito la variazione. In questo caso può essere assicurata miglior tempestività di comunicazione che come già accennato è una componente fondamentale della qualità dei dati. In ambienti tecnicamente eterogenei possono coesistere nuove applicazioni e vecchi sistemi. Pertanto il vantaggio reso possibile da questi automatismi può essere inficiato dai dati gestiti dai vecchi sistemi. Le azioni globali per migliorare la qualità dei dati vanno quindi considerate in questo contesto e allo scopo saranno trattate opportunamente nei capitoli successivi. 6.7Inconsistenze Il problema dell integrazione dei dati è di facile soluzione, a meno che le sorgenti delle informazioni siano inconsistenti, cioè che una stessa porzione del mondo reale sia descritta in modo diverso da più di una sorgente dati. Queste inconsistenze possono essere divise in due categorie: inconsistenze intensionali e inconsistenze estensionali. Strettamente legato ai concetti di inconsistenza dei dati e di sorgente di dati, si presenta quello di responsabile del dato. Dando per scontata l esistenza di un ridondanza dei dati, sia a livello di istanza, sia a livello di schema/modello, all istante t 0 pre-integrazione, occorre individuare un entità responsabile per ogni singolo dato, che all istante t 1, postintegrazione, possa dirimere ogni dubbio e che renda la scelta univoca. Tale entità ha il compito di 1) fornire il dato a chi lo richiede, se autorizzato e 2) fornirlo con un livello di qualità sufficiente per i processi elaborativi del richiedente. Il concetto di responsabile del dato peraltro è presente anche nel documento Linee Strategiche per il triennio , laddove si scrive... per ogni materia e tipologia dei dati di interesse amministrativo, un unica amministrazione responsabile della certificazione di qualità del dato, creando, per ogni tipologia di dati, un unica base dati di riferimento le cui informazioni siano poi propagate e rese accessibili a tutti i fruitori Intensionali Le inconsistenze intensionali, spesso riferite nella letteratura anche come eterogeneicità semantiche, appaiono quando un informazione è rappresentata differentemente in sorgenti diverse, e sono le più complesse da gestire. Alcuni esempi sono: conflitti sui nomi degli attributi - p.e. DDN e Data_di_Nascita; 108

111 l uso di differenti unità di misura chilometri contro miglia; livelli di generalizzazione in conflitto per esempio l entità Persona con un attributo Genere contro entità Maschio e Femmina separate; quando le sorgenti impiegano differenti modelli per esempio una rappresentazione dati basata su un modello object-oriented contro un modello relazionale. Le soluzioni a questo problema si sono in genere orientate nel senso delle intergrazioni delle viste della base dati, come parte del processo di progetto della base dati risultante, oppure nel senso di sistemi che effettuano un merge virtuale di basi di dati indipendenti Estensionali Le inconsistenze estensionali compaiono solo dopo che le inconsistenze intensionali sono state risolte, al momento in cui i sistemi che partecipano ad una specifica transazione, si suppone abbiano la stessa rappresentazione intensionale per una stessa entità del mondo reale. A questo punto è possibile che due sorgenti diverse, in teoria con lo stesso significato, ad una stessa interrogazione rispondono con risultati diversi. Esistono in letteratura diverse soluzioni per ovviare a questo tipo di inconsistenze. A titolo di esempio si riporta la seguente soluzione, in cui si introduce il concetto di bontà dell informazione. Per bontà dell informazione si intende la distanza che l informazione presente nella base dati ha dal mondo reale, per esempio in termini di quanti caratteri, per una stringa che rappresenta un codice fiscale, sono errati. Altri criteri di distanza sono definibili, caso per caso. Pertanto si ha: Fase 1 - Procedura Preparatoria Stabilire una misura per la qualità dell informazione Per ogni base dati, definire un insieme di viste, la cui struttura sia utile per inferire la bontà complessiva della base dati Stimare la bontà di ogni vista (campionamento della base dati). Fase 2 - Procedura di Integrazione Data una interrogazione, decomporla nelle relative interrogazioni alle basi di dati individuali, e ottenere le risposte Per ogni gruppo di interrogazioni relative, controllare se le risposte sono consistenti. In caso contrario utilizzare la procedura di armonizzazione (vedere fase 3) Consolidare le risposte in un unica risposta all interrogazione originaria. Fase 3 - Procedura di Armonizzazione Stimare la bontà di ogni risposta Combinare le risposte, in un unica risposta dalla più alta bontà possibile. 109

112 6.7.3Correttezza Sintattica Oltre a quanto detto circa le inconsistenze dei dati, occorre anche considerare la condizione in cui il dato è sintatticamente non corretto. In alcuni casi è possibile definire una sintassi del dato, cioè un insieme di regole che un dato deve soddisfare. Tale insieme di regole può essere semplice, per esempio l età di una persona fisica deve variare tra 0 e 140, oppure più complesso, come nel caso del codice fiscale, ove occorre un controllo incrociato con nome, cognome, data di nascita, sesso, luogo di nascita. Ove possibile si devono applicare già in fase di origine (e di gestione) del dato tutte le precauzioni possibili per evitare queste malformazioni. Pertanto sarà possibile sottoporre al controllo di una routine idonea la correttezza del codice fiscale, controllare tramite apposita routine la correttezza formale e logica di alcune date (data di nascita con il codice fiscale), controllando in maniera incrociata due o più informazioni (correttezza logica). 6.8Requisiti di Qualità dei Dati Dal punto di vista della qualità, il dato, sia esso amministrativo che statistico, può utilmente essere considerato alla stregua di un qualsiasi bene o servizio in modo da potervi applicare i concetti sviluppati nel settore della qualità dei beni e servizi prodotti in ambito industriale o terziario. In tale contesto si può adottare la definizione di qualità proposta nelle norme ISO per un bene o servizio: "Il possesso della totalità delle caratteristiche che portano al soddisfacimento delle esigenze, esplicite o implicite, dell'utente". Questa definizione, ai nostri fini certamente non operativa, evidenzia due punti molto importanti: il soggetto fruitore della qualità è l'utente al quale è rivolto il bene o il servizio; la qualità del bene o servizio consiste nel possesso di determinate caratteristiche. È inoltre opportuno introdurre un'ulteriore distinzione tra il bene o servizio prodotti e il processo di produzione che porta alla loro creazione. Questa distinzione ci serve per evidenziare che le caratteristiche di qualità di un prodotto possono essere in buona parte ottenute migliorando il processo di produzione del bene o servizio in questione. È per questo che nel seguito si farà spesso menzione della qualità di processo e della qualità del prodotto, sempre con l'obiettivo del conseguimento della "soddisfazione dell'utente". A partire da questi concetti generali si possono definire quali sono le dimensioni che caratterizzano la qualità nel caso in cui il bene (e servizio) in questione sia rappresentato dall'informazione statistica su un collettivo di interesse. Le caratteristiche di qualità che i dati devono avere, e qui si richiamano le caratteristiche elencate nel documento Linee Strategiche per il triennio , laddove si scrive... Nel campo specifico della qualità dei dati, da intendersi principalmente come correttezza, tempestività di aggiornamento, completezza e coerenza,... sono pertanto, estendendo quanto sopra espresso : Requisito Descrizione Caratteristiche Metrica d esempio Accuratezza Essere privo di errori Percentuale dei valori che sono 110

113 Completezza Consistenza Aggiornatezza Unicità Validità Rilevanza Accessibilità È il grado con cui i valori sono presenti negli attributi che li richiedono È una misura del grado in cui un insieme di dati soddisfa un insieme di requisiti È il grado con cui i valori sono aggiornati Essere l unico del suo tipo. Non avere eguali. La caratteristica del dato che si basa su un sistema di classificazione sufficientemente rigoroso da validarne la conformità La caratteristica del dato di essere attinente all argomento a cui si riferisce È il grado di facilità con cui un dato è utilizzabile corretti quando comparati con il valore reale. Per esempio m=maschio quando il soggetto è maschio Percentuale dei campi dati contenenti valori Percentuale dei valori che soddisfano i requisiti Percentuale dei dati disponibili al di sotto di una certa soglia temporale (giorni, ore, minuti) Percentuale dei record con chiave primaria Percentuale dei dati aventi valori che ricadono all interno dei loro domini dei valori Percentuale di utilizzo del dato Percentuale di hit al dato falliti Accuratezza: i dati dovranno essere il più possibile privi di errori; non sarà possibile garantire il 100% della accuratezza, sia che il nostro sistema informativo gestisca basi dati primarie, sia che riceva basi dati da altri sistemi informativi. Nel primo caso pur prevedendo tutte le regole per la gestione di dati accurati e consistenti, se la generazione del dato proviene da input manuale da parte di un operatore o proviene da input manuale da parte di un cittadino (fruitore, base dati autoalimentante ), non si può garantire la accuratezza dei dati. Per esempio si potranno prevedere verifiche sulla correttezza di dati quali il nome della via, il numero di CAP, il nome della località, il nome della persona, e così via, ma certamente più difficile è garantire la validità del cognome. Completezza: si dovranno stabilire i dati obbligatori e i dati facoltativi. Tale definizione è legata ai processi gestionali che li utilizzeranno. I dati obbligatori dovranno essere validi nell ambito dei valori gestionali ammessi (per esempio la validità del dominio dei dati come M per maschio, F per femmina, e dunque non sono validi spazio oppure N ). I dati facoltativi possono non essere presenti: qualora presenti il loro controllo di validità ricade nelle regole di controllo dei dati obbligatori. Aggiornatezza: è importante sempre indicare oltre il grado di profondità con cui i dati sono aggiornati, anche la data dell ultimo aggiornamento. Poiché si può essere in presenza di basi dati aggiornate on line da input manuali, piuttosto che in presenza di basi date aggiornate su input ricevuti da sistemi remoti, è importante conoscere lo stato di aggiornamento a quando risale. In caso contrario si può definire una base dati obsoleta o non attendibile. 111

114 Unicità: come per il controllo dei singoli dati anche in questo caso devono essere definite le regole che garantiscano la univocità del dato. Per esempio, possono esistere due persone fisiche con lo stesso nome, cognome, data di nascita, ma non possono esistere due persone fisiche che oltre ai dati precedenti abbiano anche lo stesso codice fiscale. Possono esistere due ricorrenze della stessa persona fisica (per esempio un cambio di residenza, tracciato storicamente), ma questo caso deve essere previsto e gestito dai processi funzionali del nostro sistema informativo. Alcune caratteristiche descritte sono garantite da controlli automatici effettuati dai RDBMS, mentre altri necessitano certamente di controlli logici e formali dal punto di vista applicativo. Poiché possono coesistere basi dati relazionali e basi dati non relazionali la garanzia globale va ricercata e garantita tramite opportune applicazioni: saranno ridondanti laddove ci si trova in presenza di RDBMS. Validità: per alcune tipologie di dati, come età, indirizzo, codice fiscale, e così via, è possibile definire un dominio dei valori validi tale che, dati non appartenenti a tale dominio, sono sicuramente errati. Cosa ancora più importante, la definizione di tali domini consente la realizzazione di procedure che consentono un automazione della validazione, vale a dire che l applicazione di tale procedura consente l immissione di soli dati validi. Naturalmente anche se un dato risulta valido, non è detto che sia anche corretto, per esempio un età che pur assumendo un valore numerico, ha valore 1000, il che ci porta a concluderne la sue incorrettezza. Rilevanza: capacità dell'informazione di soddisfare le esigenze conoscitive degli utenti. Nell'accezione di utente si deve intendere anche i committenti preposti ad organi di governo centrali o locali. È appena il caso di precisare che la caratteristica di rilevanza è strettamente collegata con gli obiettivi di indagine considerati in fase di progettazione. Accessibilità: nota anche col nome di "trasparenza", questa caratteristica corrisponde alla semplicità per l'utente di reperire, acquisire e comprendere l'informazione disponibile in relazione alle proprie finalità. Queste caratteristiche sono influenzate dal formato e dai mezzi di diffusione dell'informazione rilasciata nonché dalla disponibilità di meta-informazioni a suo corredo. 6.9Azioni per migliorare la Qualità dei Dati Le azioni da intraprendere variano in funzione dell obiettivo e della situazione in essere dei sistemi, ma in generale vale il principio che a fronte di uno sforzo più intenso, in termini di risorse spese, si ottengono risultati proporzionalmente migliori. La prima azione da considerare, pur nel suo costo, è l analisi dei processi coinvolti nella produzione del dato, chiamata anche data flow analysis. Infatti, anche se il miglioramento del dato è possibile, in un ottica di processo dinamico, cioè sempre in divenire, tale miglioramento verrebbe vanificato nei successivi cicli di vita del dato. Così come scritto nel già citato documento Linee Strategiche per il triennio ,... i principi generali da seguire sono la chiarezza delle responsabilità nelle diverse fasi di acquisizione trattamento e conservazione dei dati. In generale le azioni possono essere classificate secondo due filoni, in accordo alla loro natura: azioni che impattano sui processi che producono i dati (Process Analisys), e azioni 112

115 che impattano sui dati già prodotti (Data Cleaning). Nell'affrontare il problema della qualità del dato bisogna distinguere due casi: l'ente/azienda genera i dati nei propri sistemi informativi interni; l'ente/azienda acquisisce i dati da fonti esterne (sistemi informativi di altri enti). Considerando a parte il caso in cui si possa intervenire sin dall inizio, generando un corretto processo di acquisizione delle informazioni, esaminiamo più approfonditamente i casi di miglioramento di basi dati già esistenti. Il primo passo da affrontare nel miglioramento della qualità del dato è comune sia che i dati vengano acquisiti esternamente, sia che siano generati all interno di un sistema informativo direttamente gestito: è necessario infatti in prima battuta ispezionare la qualità della base dati ed intervenire massivamente su di essa per migliorarne la qualità. Dopo la prima bonifica massiva si distingueranno le azioni da intraprendere. Se l'ente che utilizza il dato è responsabile della creazione del dato stesso, dopo un primo intervento massivo sui dati, dovranno essere implementati i meccanismi di miglioramento del processo di creazione del dato stesso. Nel caso in cui il dato viene acquisito dall'esterno, non potendo intervenire all'origine, può essere però migliorato il processo di acquisizione del dato. 113

116 Fase 1 Analisi preliminare della qualità di dati e definizione degli obiettivi di qualità da raggiungere Fase 2 Definizione regole di qualità dati Fase 3 Bonifica massiva Fase 4a Cablatura regole nel processo di acquisizione e aggiornamento Fase 4b Cablatura regole nel processo di generazione del dato (Process Analysis) Caso 1 Non esistono dati e genero ex novo il processo (S.i. operazionali interni ad un ente) (Data cleaning) Caso 2 Acquisisco i dati e non posso intervenire su processo (fonti dati esterne) (Data cleaning e Process Analysis) Caso 3 Esistono dati e posso intervenire su processo (Business Process Reengineering) 6.9.1Analisi dei processi Mondo Reale Processi con Interazione Umana Processi Automatici Residenza Nuova Residenza P.A. Atti Ufficiali Residenza Nuova Residenza Residenza Nuova Residenza 114

117 Lo schema raffigurato illustra un tipico evento di cambio di valore di un informazione del mondo reale nel caso in esame un cambio di anagrafe - e la sua propagazione nei diversi strati che compongono il processo. Le frecce tratteggiate indicano dei trigger, di natura qualsiasi. Un cambio di residenza nel mondo reale viene comunicato, dal cittadino, alla PA locale. Questo innesca un processo (basato su processori umani) che prevede diverse attività, tra cui l interazione con il locale sistema informatico. Tuttavia altre attività sono ipotizzabili, come per esempio la comunicazione dell avvenuto cambio di residenza ad un altra amministrazione, per esempio via fax, o con interazione diretta dei sistemi informatici. Lo schema vuole evidenziare che un processo è un attività complessa che interagisce e si interseca con entità del mondo fisico, oltre che con entità informatiche. Pertanto, quando si riflette su come migliorare la qualità dei dati generati da un processo, occorre considerare il processo nella sua interezza, anche e soprattutto in termini di automazione delle attività manuali. Per loro natura le azioni di analisi e controllo non apportano modifiche ai contenuti della base dati: si limitano a scorrere il contenuto, a sottoporre ad analisi mirate e molte volte incrociate (con l ausilio di altre basi dati) i dati disponibili e a segnalare le anomalie riscontrate. Sarà la successiva azione di un operatore o la esecuzione di processi informatici mirati (o da individuare e quindi da realizzare ad hoc) ad apportare le modifiche necessarie alle basi dati per migliorane il contenuto in termini qualitativi. Le azioni di aggiornamento (manuali o automatiche) provvedono a correggere il contenuto delle basi dati garantendo un recupero di qualità dei dati in maniera significativa, portando la qualità della base dati al massimo livello raggiungibile. In termini generali qualsiasi azione di aggiornamento venga eseguita per poter migliorare la qualità dei dati, deve sottoporre i dati presenti nelle basi dati in analisi al controllo di consistenza, di integrità, di rispetto dei domini, di semantica, noti alla data di esecuzione del lavoro e atti a garantire il massimo livello qualitativo delle informazioni. Da questa panoramica generale se ne deduce che le azioni correttive possono essere molto variegate, richiedere molto tempo per poter essere messe in pratica e possono richiedere investimenti economici non indifferenti. In alcuni casi estremi le azioni correttive che possono essere necessarie possono indurre costi e tempi da far ritenere meno onerosa la definizione di un nuovo sistema informativo. Pertanto risulta evidente che le azioni di miglioramento della qualità dei dati sono sempre una conseguenza ovvero fanno parte di un piano di implementazione di un progetto. Trattandosi di un piano realizzativo, tipicamente verranno eseguite le seguenti attività: verrà effettuata l analisi del contesto in cui si inserisce e agisce il nuovo (o vecchio, da aggiornare) sistema informativo, sia come contesto interno alla nostra Amministrazione Pubblica sia per quelle che condividono le nostre basi dati; verranno definiti i ruoli, le responsabilità dei partecipanti ai processi gestionali; verranno definiti i processi gestionali necessari; verrà effettuata una macro valutazione delle basi dati necessarie; verrà effettuato il censimento delle basi dati in essere; verranno identificate le fonti (se esistono) che originano i dati; verranno valutate le fonti (se esistono) che gestiscono e/o forniscono le variazioni dei dati; 115

118 verranno stabiliti i tempi e le modalità di aggiornamento della base dati; verrà stabilita la profondità temporale della base dati; verrà stabilita la traccia abilità della base dati. Disponendo dei macro elementi anzi citati si può procedere con una valutazione dei tempi e relativi costi entro cui la base dati (se già esistente) può essere ricondotta in termini qualitativi e quantitativi ai livelli definiti ed attesi Correzione dei dati esistenti data cleaning Il data cleaning è il processo di correzione degli errori nei dati. Il punto cruciale nella fase di data cleaning è il riconoscimento dei record che devono considerarsi equivalenti, o Record Matching. Questa attività viene generalmente effettuata in tre passi: preparazione dei dati, dove i valori dei dati vengono normalizzati; ricerca di potenziali corrispondenze di record equivalenti; identificazione dei record effettivamente equivalenti per mezzo dell algoritmo di record matching implementato. Le azioni di data cleaning tendono a snellire il contenuto delle basi dati eliminando i dati non più utilizzati (e obsoleti in termini di significato) o eliminando le occorrenze (profondità) storiche non più significative secondo le regole di gestione dei processi/business identificate. Le azioni di eliminazione dei dati non più utilizzati si possono riferire anche a intere occorrenze : il progettista del processo dovrà prestare massima attenzione nell eliminare i dati interessati e a completamento del processo, eventualmente eliminare tutti i dati correlati non più significativi/necessari. Anche in questo l operare in ambiente RDBMS viene in aiuto al progettista garantendo controlli impliciti (automatici) sulla consistenza dei dati rimanenti mentre in ambiente non RDBMS detti controlli ricadono nelle regole di aggiornamento che il progettista dell intervento deve tenere in considerazione. Molto spesso lo snellimento delle basi dati avviene per contesti di business e con diverse tecniche: per poter spiegare il concetto ci si avvale di un esempio. È possibile eliminare tutte transazioni economiche relative ad un cittadino presenti sul database a patto che siano trascorso almeno x anni, poniamo tre. Poiché ci possono essere casi di transazioni economiche pendenti dovute a contestazioni in essere (casi di mora o altro), non tutte le transazioni economiche che soddisfano il requisito temporale automaticamente possono essere eliminate ma si dovrà porre attenzione anche ad altri dati. Così se il cittadino è deceduto nonostante si sia in presenza di casi di transazione economica pendente queste risultano eliminabili in quanto non ci sarà la opportunità materiale che detta condizione venga superata. Si può proseguire dicendo che la eliminazione delle ricorrenze temporali dal database possono avere luogo solo a patto che tutte le ricorrenze siano eliminabili: se esiste un solo caso in cui non si può procedere alla eliminazione delle ricorrenze queste vengono lasciate. Questa condizione può essere giustificata con la osservazione della informazione da dare all utilizzatore che la base dati è aggiornata al (data di fine periodo) a partire da (data inizio periodo), cosa non più sostenibile globalmente nel caso di eliminazione 116

119 caso per caso delle ricorrenze. Infine, per completare l esempio, non si potrà eliminare la anagrafica del cittadino preso (deceduto) se prima non si è proceduto alla eliminazione delle transazioni economiche Record Matching L obiettivo del Record Matching è l identificazione di records nella stessa o in differenti sorgenti dati, che si riferiscono ad una stessa entità del mondo reale, anche se i record non si equivalgono. Le operazioni di normalizzazione dei valori possono avvenire sulle basi dati esistenti tramite azioni di aggiornamento (o correttive) che in virtù delle regole di business (nuove o modificate) provvedano ad uniformare il contenuto dei vari campi soggetti ad aggiornamento, introducendo valori prestabiliti. Per esempio: mentre ognuno è libero di indicare l ubicazione Piazza in diversi modi (P.za., Piazza, Pza, etc..) una routine di normalizzazione può riportare sul database il solo ed unico valore P.za. Esistono prodotti specializzati per il controllo e la segnalazione di similitudine di nomi di persone, vie, città senza aver trovato il valore corrispondente: l azione definitiva può essere richiesta al personale operativo. Lo stesso, esistono prodotti che ricercano doppioni, similitudini: sono prodotti che possono supportare sia le attività di correzione sia quelle di normalizzazione. Infatti in alcuni casi a fronte di una unica anagrafica cittadino possono essere state aperte due o più occorrenze nel database gestionale. Alcuni prodotti sono idonei a supportare queste attività analizzando l intera base dati e fornendo indicazioni di potenziali doppioni, segnalando tutti i casi ipotizzati. La decisione se proseguire nella razionalizzazione in automatico o meno è demandata al responsabile della base dati. 6.10Una metodologia per il miglioramento della qualità di basi dati esistenti Nel caso 3 della tabella di cui al paragrafo 7.6, che riporta una casistica completa di miglioramento della qualità di una base dati di cui si controlla il processo di generazione dei dati operazionali, esaminiamo in dettaglio una possibile metodologia da adottare. 117

120 6.10.1Le caratteristiche della metodologia Il progetto di miglioramento di una base dati esistente di cui si controlla il processo di generazione dei dati avrà due macro fasi: intervento massivo sugli archivi in cui sono presenti anomalie sia in termini di dati testuali (qualità sintattico-semantica) che in termini di dati codificati (integrità referenziale); intervento di tipo funzionale, finalizzato ad incorporare stabilmente ( cablare ) il controllo della qualità dei dati negli applicativi stessi per il mantenimento della qualità raggiunta tramite il precedente intervento massivo. Dal punto di vista metodologico e progettuale, ogni progetto per il miglioramento della qualità dei dati contempla, in generale, le fasi riportate di seguito. Fase 1: Analisi preliminare degli archivi e definizione delle regole. Analisi degli archivi esistenti e delle tabelle di riferimento. Definizione delle regole (in termini di qualità stretta deve essere effettuata per gli archivi esistenti, in termini di eventuale integrità referenziale e di consistenza dei dati deve essere effettuata per il data base finale). Bonifica/Normalizzazione vocabolari/tabelle di riferimento. Progettazione del software da predisporre per il trattamento degli archivi campione ed elaborazione. Stesura report statistico ed analisi dei risultati sui campioni. Fase 2: archivi. Sviluppo degli impianti software specifici per il trattamento massivo degli Fase 3: Attività di Bonifica/Normalizzazione. Bonifica/normalizzazione massiva degli archivi. Riconduzione delle eventuali ambiguità. Recupero degli eventuali scarti. Fase 4: Deduplicazione archivio per l eliminazione logica o fisica delle eventuali ridondanze sintattico-semantiche. 118

121 Fase 5: Riprogettazione del processo gestionale: Progettazione e sviluppo delle componenti software da inserire a regime nel processo gestionale di generazione della base dati. Identificazione dei parametri di input e di output necessari per il richiamo dalle diverse applicazioni delle singole funzioni. Fase 6: Cablaggio della qualità negli applicativi gestionali: per il mantenimento ovvero supporto per la progettazione delle applicazioni (intervento di cablaggio della qualità all interno degli applicativi). Fase 7: Manutenzione qualità. Monitoraggio della struttura del data base finale (eventuali controlli di integrità referenziale e consistenza dati). Manutenzione delle librerie e dei dati di riferimento per la qualità dei dati. L approccio metodologico generale adottato, per realizzare un intervento massivo, si può definire di tipo iterativo. Al fine di raggiungere l obiettivo di qualità richiesto per i dati oggetto di trattamento, la tecnica consiste nel procedere per passi di raffinamento successivo attraverso un processo iterativo che si conclude quando il livello di qualità raggiunto è coerente con l obiettivo: durante ogni ciclo del processo viene isolato e accantonato il sottoinsieme dei dati che hanno raggiunto il livello di qualità richiesto dai dati che non lo hanno raggiunto. In particolare la metodologia è articolabile come segue: definizione con il committente dei requisiti di qualità; analisi preliminare dei dati, sull intera base dati qualora sia di dimensioni non consistenti, attraverso un campione significativo (circa il 6%) nel caso di basi dati di grandi dimensioni: pre-analisi delle anomalie e delle disomogeneità contenute negli archivi, valutazione statistica della incidenza delle anomalie ed individuazione delle principali regole sulle quali basare il controllo di qualità; analisi ed individuazione delle regole di dettaglio da applicare; sviluppo di funzioni software che implementano le regole individuate; applicazione del software alla base dati per rendere operativi gli interventi in base alle regole definite; analisi dei risultati ottenuti dall applicazione del software alla base dati; analisi degli scarti (differenza tra base dati iniziale e base dati bonificata); eventuali cicli iterativi; rilascio finale di archivi, regole, statistiche e documentazione. 119

122 Riportiamo di seguito il flusso metodologico generale. Base dati prima dell intervento Definizione requisiti di qualità Analisi preliminare dei dati Individuazione Regole da applicare Sviluppo funzioni software Realizzazione interventi Analisi risultati Indice qualità complessiv accettabile Non accettabile Sottinsieme dei dati con qualità accettabile Sottinsieme dei dati con qualità NON accettabile Nuova analisi dei dati Rilascio finale Archivi, Regole, Statistiche, Documentazione Nuove regole di dettaglio Archivi finali con dati di qualità accettabile Archivi con dati scartati Regole qualità Statistiche e indici di qualità Documentazione processo di miglioramento della qualità 120

123 6.10.2Tipologie di interventi di bonifica Si riportano di seguito i possibili interventi di qualità dati. Pattern Recognition Processo di riconoscimento semantico di strutture elementari all interno dell informazione stessa attraverso l analisi: degli elementi discriminanti; delle sottostrutture componenti; delle classi in funzione di elementi distintivi individuati da un analisi preliminare sui dati. L attività è necessaria per individuare stringhe omogenee (dal punto di vista sintatticosemantico) all interno di campi descrittivi Data Re-engineering Processo di Reingegnerizzazione dei dati e della loro struttura in funzione delle componenti elementari individuate all interno dell informazione trattata. L attività è necessaria qualora si individuino dati non pertinenti sia al campo in esame che agli altri campi esistenti ma che occorre ugualmente preservare e classificare (es. presenza di un indicazione di località nel campo Descrizione Via o presenza di un titolo nel campo Cognome, etc.). Inoltre essa è propedeutica alla generazione di un ambiente relazionale e/o di Data Warehouse. Bonifica Eliminazione di errori: Ortografici Lessicografici di Formato di Coerenza - tra il valore di un campo e il suo dominio - tra il valore di due o più campi Semantici. Normalizzazione Riconduzione a: - Valori o Formati Standard - Valori o Formati Convenzionali L attività è necessaria qualora si desideri ricondurre informazioni semanticamente equivalenti ma sintatticamente diverse ad un unica rappresentazione Certificazione 121

124 Processo per la validazione dei dati secondo una fonte di riferimento e per l eliminazione di eventuali errori di obsolescenza dei dati stessi. Correlazione Processo di: Abbinamento sintattico-semantico tra archivi di diversa provenienza finalizzato alla certificazione del dato. Abbinamento sintattico-semantico tra archivi di diversa provenienza finalizzato all arricchimento e alla fusione di informazioni. Abbinamento sintattico-semantico di un archivio con se stesso finalizzato al riconoscimento e, eventualmente, all eliminazione logica/fisica delle ridondanze semantiche (Deduplicazione o Doblonatura). L attività è necessaria qualora si desideri recuperare informazioni assenti (ad esempio, il Codice Fiscale) o realizzare associazioni sintattico-semantiche tra diverse informazioni Misura dei risultati La fase di misura dei risultati è fondamentale nell ottica del continuo miglioramento della qualità dei dati. Poiché il raggiungimento della qualità totale, nelle basi dati che modellano realtà di una certa complessità, è un processo asintotico, la fase di misura consente delle correzioni nei processi migliorativi adottati, di modo che i raffinamenti nei processi siano continui. Il concetto di misura è possibile nel contesto di una metrica: è cioè necessario definire un sistema di riferimento per le misure che si andranno ad effettuare. Per esempio, supponendo di applicare una procedura di controllo incrociato ad una base dati che, forniti gli opportuni parametri, verifica la validità di un codice fiscale, si potrebbe misurare il numero di istanze con codice fiscale errato, prima e dopo il l applicazione dei processi di miglioramento della qualità alla base dati medesima. Tale esempio mostra anche l importanza dell effettuazione delle misure prima e dopo l applicazione dei processi di miglioramento della qualità. Come informazione generale i processi devono sempre indicare la origine della richiesta (chi l ha effettuata), i parametri forniti, la base dati interessata, le regole di filtro/individuazione dei dati, il numero di record presenti nella base dati, il numero di casi identificati e nel caso di aggiornamento definitivo il numero di casi aggiornati/eliminati, il numero di record rimasti nel data base. Ogni azione eseguita sulle basi dati dovrebbe sempre permettere la esecuzione in due condizioni, esecuzione in simulazione e una esecuzione in effettivo e almeno in due passi. Un primo passo di lettura di dati e di informazione sulle casistiche individuate (estrazione) e un secondo passo, condizionato alla corretta esecuzione del primo, e all eventuale consenso da parte di un operatore per la fase di vero e proprio aggiornamento della base dati. 122

125 6.10.4Indice di Qualità L indice di qualità, la cui necessità è espressa nel documento Linee strategiche per il triennio capoverso d), rappresenta la qualità di un archivio in termini di congruenza, coerenza, correttezza e completezza dei dati. Esso viene calcolato utilizzando, come parametro di riferimento, la totalità dei dati che non richiedono un ulteriore intervento; tale dato viene rapportato al numero totale delle informazioni in input. Sulla base di questa definizione, l indice di qualità di un archivio viene calcolato in due momenti diversi del processo di bonifica e normalizzazione: all inizio viene calcolato l indice di qualità di partenza dell archivio, e al termine viene calcolato l indice di qualità raggiunto. Viene inoltre dato, come parametro di riferimento, anche l indice di qualità raggiungibile, calcolato come il rapporto fra le informazioni riconducibili e il numero totale di informazioni in input. Siano, cioè, C il numero totale di record per i quali non è stato necessario un intervento di bonifica e normalizzazione, M il numero di record sui quali è stato effettuato un intervento, K il numero di record scartati dal processo di bonifica e normalizzazione ma riconducibili in seguito all introduzione di regole o di ulteriori elaborazioni e T il numero totale di record. Indice di qualità iniziale I = C/T, Indice di qualità raggiunto R = (C+M)/T, Indice di qualità raggiungibile r = (C+M+K)/T. Sulla base di queste definizioni, viene inoltre calcolato l indice di qualità complessivo dell intervento effettuato: Q = (α+β)/2, dove α=r/r e β=(r-i)/(r-i) (α e β sono uguali a 0 se r è 0) Nella tabella seguente vengono posti in relazione alcuni criteri applicabili ad un archivio sottoposto ad un processo di controllo di qualità dei dati con le eventuali anomalie riscontrabili. CRITERIO COMPLETEZZA CORRETTEZZA COERENZA CONGRUENZA ANOMALIA Campo vuoto (a livello di campo singolo) Errore ortografico Errore di formato Errore lessicografico (a livello di campo singolo) Errore di struttura (nome nel campo con struttura cognome e viceversa) (a livello di campo singolo) Errore di congruenza tra valore del campo nome e valore del campo sesso (tra due o più campi) 123

126 6.11Conclusioni Nel corso del capitolo abbiamo sviluppato il tema della Qualità dei Dati, introducendone il concetto. È stato spiegato come rendere misurabile la qualità, per far si che essa sia una grandezza, appunto, misurabile e verificabile. Sono stati illustrati i razionali che spingono al miglioramento della qualità, e sono state delineate le linee guida nella ambito delle azioni da intraprendere per ottenere dei dati di migliore qualità. Un analisi puntuale della situazione attuale delle basi dati esistenti nella Pubblica Amministrazione è al di là del contesto di questo documento, ma sono comunque forniti gli strumenti concettuali di base per procedere, caso per caso, nell analisi stessa. Sono individuabili in sintesi le seguenti azioni generali da condurre per apportare un miglioramento dei dati nella PA: Promuovere analisi della qualità basi dati esistenti. Promuovere bonifiche massive con regole predefinite (fornitura di regole generali e archivi standard per i controlli). Definire i principali controlli applicabili per tipo di campo (es. su codice comune, su indirizzo). Fornitura di archivi standard da utilizzare (es. ISTAT potrebbe favorire la diffusione di codifiche standard quali codici Comuni, codici professioni) nello sviluppo di procedure. Porre come precondizione per nuovi sviluppi di s.i. operazionali della PA regole generali da rispettare e favorire l'utilizzo di archivi standard di controllo (linee guida per tutti coloro che sviluppano software per la PA che se rispettate danno la "certificazione di qualità" e l'etichetta di "software per l'interscambio" con qualità de dati garantita. Favorire la costruzione di basi dati integrate per le componenti identificate come entità nel capitolo 6. Identificare sempre, per ogni entità, il responsabile dell identificazione (gestore della componente identificativa) e la chiave di identificazione univoca dell entità da utilizzare per ogni incrocio e per agganciare le microentità. Costruire servizi di accesso standardizzati alle basi dati delle entità fruibili sulla RUPA/RUPAR (basati sui campi identificativi standardizzati). Vincolare all utilizzo dei campi identificativi standardizzati delle entità per ogni base dati contenente le microentità e favorire la costruzione di servizi di accesso standardizzati ai dati di interesse pubblico contenute nelle basi dati delle microentità, fruibili sulla RUPA/RUPAR. L obiettivo della qualità diventa quindi un obiettivo non solo perseguibile, ma anche desiderabile e, per quanto detto nell introduzione, anche prioritario. Le amministrazioni sono, per loro natura, una delle pietre angolari del sistema Italia, e se è vero che una qualità dei dati migliore porta ad un incremento della velocità di interazione tra le amministrazioni e/o tra le amministrazioni e i cittadini, tale aumento di ritmo sarà una ricaduta positiva per l intero paese. 124

127 7.ANALISI PER LA DEFINIZIONE DI STANDARD PER ASSICURARE LA PIENA FRUIBILITÀ E LA CONDIVISIONE DEI DATI PUBBLICI 7.1La cooperazione tra le Amministrazioni negli scenari e-government La cooperazione tra applicazioni di amministrazioni differenti, sviluppate su sistemi eterogenei, collegate tramite una rete è una problematica piuttosto complessa, che nell ambito della Pubblica Amministrazione è stata già ampiamente affrontata nel recente passato dall AIPA e dalla Funzione Pubblica. Se questo tema pertanto è lungi dal costituire una novità, nel recente periodo si è assistito a due fenomeni molto importanti che ne stanno influenzando l evoluzione: Il primo fenomeno è puramente tecnologico, ed è legato alla maturità, alla diffusione ed alla standardizzazione dei protocolli e dei linguaggi legati al modo Internet, in particolare il protocollo HTTP ed il linguaggio XML. Il secondo fenomeno è legato ai fattori di business della Pubblica Amministrazione, essendo costituito dalle nuove esigenze evidenziate dal piano di E-government e dai progetti ad esso correlati. In risposta ai due fenomeni evidenziati, in questo capitolo viene presentata una proposta di un nuovo modello architetturale, che possa garantire alla Pubblica Amministrazione un adeguato livello di interoperabilità e di cooperazione applicativa. Tale proposta deve rispondere ad una serie di requisiti fondamentali che vengono di seguito elencati: Supporto a diversi scenari; l architettura deve essere in grado di supportare i seguenti scenari di business: Government-to-Citizen (G2C): interazione tra cittadino ed amministrazioni Government-to-Government (G2G) : interazione tra due o più amministrazioni Government-to-Business (G2B): interazione tra amministrazioni ed imprese Supporto a diversi paradigmi di interoperabilità: Sincrono/Asincrono: lo scambio di messaggi applicative può avvenire, a seconda delle esigenze, in tempo reale o differito Point-to-point: l interazione tra gli interlocutori (ad esempio due amministrazioni) avviene in modo diretto, senza alcun intermediario Notifica Eventi: l interazione tra gli interlocutori (ad esempio due amministrazioni) avviene in modo indiretto, intermediata da una infrastruttura di servizio (infrastruttura di Publish and Subscribe) che fornisce servizi per la pubblicazione di un evento e di sottoscrizione agli eventi stessi. In questo paradigma ad esempio un Comune, a fronte della richiesta di cambio residenza da parte di un cittadino, pubblica l evento Cambio Residenza, insieme a tutti i dati ad esso relativi, sul sistema di Publish and Subscribe; in seguito a questa pubblicazione, il sistema di Publish and Subscribe notifica in modo opportuno tutte le amministrazioni che hanno preventivamente sottoscritto quell evento specifico, che nell esempio potrebbero essere l ASL, INPS, Finanze, il Ministero dell Interno, ecc. Gestione di workflow tra processi eterogenei: molto spesso oggi il cittadino o le imprese sono soliti interfacciare la Pubblica Amministrazione facendosi carico loro 125

128 della gestione del complessità del workflow che un certo evento ha determinato, il che implica che sono spesso più di una le interazioni che sono costretti ad avere con le varie amministrazioni per completare il processo, caricandosi anche dei vari flussi documentali. Uno dei requisiti di una architettura di interoperabilità deve pertanto essere quello di poter garantire la possibilità di realizzare sistemi in cui la gestione del workflow tra i diversi processi possa essere automatizzata e pertanto la sua complessità nascosta all attore esterno che ha determinato la richiesta. Si è soliti dire a tal proposto che il cittadino o l impresa devono poter vedere la Pubblica Amministrazione nella sua globalità come un unico interlocutore. Portali come integratori/orchestratori di servizi: nella logica evidenziata nel punto precedente il Portale diventa automaticamente il punto di accesso preferenziale coloro i quali hanno necessità di interfacciare la Pubblica Amministrazione come un unico interlocutore. Implementazione del modello a Porte di Dominio: l architettura deve essere assimilabile al modello basato sul concetto di Porta Applicativa e Porta Delegata già in uso presso la Pubblica Amministrazione. I requisiti tecnologici della proposta devono essere i seguenti: Supporto all architettura della Rete Nazionale della Pubblica Amministrazione, che è una Extranet federata basata sull utilizzo dei protocolli standard Internet. L interoperabilità deve essere assicurata indipendentemente dalle piattaforme su cui sono realizzati i servizi. Adozione di meccanismi standard Internet anche per quanto riguarda strumenti e policy di sicurezza. Un altro requisito fondamentale di una proposta architetturale che risulti facilmente applicabile in questo contesto è quella di poter permettere di preservare gli investimenti che le varie amministrazioni hanno già fatto nel loro patrimonio di Sistema Informativi; pertanto l architettura proposta deve poter permettere una integrazione semplice e possibilmente a basso costo con i sistemi preesistenti all interno delle Porte di Dominio. Può essere utile, in questo paragrafo introduttivo, approfittare per richiamare alcune nozioni generiche relative alla cooperazione applicativa: Un oggetto applicativo è definito come una struttura dati persistente di un dominio, dotata di valore modificabile e controllata da applicazioni del dominio direttamente o tramite un insieme di procedure predefinite. Si può pensare in pratica ad una qualsiasi struttura dati gestita da una applicazione direttamente o tramite un sistema di gestione dati, o anche ad un oggetto, nel senso informatico del termine, dotato di propri metodi. Una richiesta di servizio è un messaggio, prodotto da una applicazione di un dominio cliente e diretto ad una applicazione di un dominio servente. Il messaggio determina la esecuzione di una applicazione del dominio servente che, in base alle informazioni contenute nel messaggio, esegue una procedura ed invia una risposta destinata alla applicazione cliente. La risposta è una indicazione certa che la applicazione servente ha attuato la richiesta, anche se eventualmente con un esito negativo. La richiesta di servizio è sempre sincrona nel senso che prima o poi la applicazione cliente si dovrà sincronizzare sulla risposta, perché dovrà utilizzarne le informazioni 126

129 applicative. La richiesta di servizio può essere di due tipi, interrogazione oppure transazione: L interrogazione è una richiesta di servizio che ritorna una informazione del dominio servente senza modificare alcun oggetto applicativo dello stesso dominio. La transazione è una richiesta di servizio che è destinata a produrre una variazione permanente in un qualche oggetto applicativo del dominio servente. La transazione può interessare anche oggetti di più domini. La transazione comporta sempre anche il supporto del paradigma informatico della transazione, nel senso tecnico del termine, perché la modifica permanente di un oggetto applicativo di un altro dominio deve essere garantita atomica e consistente e quindi, se non portata a compimento, deve essere reversibile. La risposta non contiene necessariamente una informazione applicativa, ma può anche ridursi alla semplice segnalazione che la transazione è stata completata o meno. 7.2Architetture Web-based Come accennato nel paragrafo precedente, la proposta architetturale descritta un questo capitolo è basata sugli standard Web. Le architetture Web-based hanno infatti raggiunto negli ultimi anni un livello di evoluzione e diffusione tali da poter rispondere a tutti i requisiti evidenziati. Si è infatti assistito molto velocemente alla trasformazione di Internet in tre fasi successive: Una prima fase, quella della Connettività, che ha visto l affermarsi del protocollo TCP/IP, in cui si sono cominciati a diffondere l uso della posta elettronica e di semplici protocolli per lo scambio di documenti, quali FTP e Gopher. Una seconda fase, quella della Presentazione, che ha visto l affermarsi del protocollo HTTP e del linguaggio HTML, in cui si sono cominciati a diffondere la consultazione tramite Browser delle pagine Web, inizialmente soltanto statiche, poi sempre più dinamiche e collegate al business ed alle applicazioni reali dei fornitori di servizi Una terza fase, quella attuale, dell Interoperabilità tra applicazioni, che sta vedendo l affermarsi del linguaggio XML, in cui si sta cominciando ad affermare i Web Services, ovvero componenti applicative accessibili tramite i protocolli ed i linguaggi di Internet. Dal punto di vista tecnologico una implementazione basata sulle tecnologie Web assicura una evoluzione dell architettura sia in termini di soluzione ad uno scenario altamente distribuito e necessariamente scalabile (quale quello della Extranet federata che costituisce la Rete Nazionale della Pubblica Amministrazione), sia in termini di strumenti e tecnologie sempre in evoluzione ed all avanguardia. Un vantaggio macroscopico è quello di essere svincolati dai fornitori e di avere la possibilità, in qualsiasi momento, di scegliere fra molteplici alternative sia in termini di strumenti di sviluppo, di amministrazione e gestione, in termini di servizi ed implementazioni È anche possibile realizzare il sistema utilizzando un insieme misto di prodotti e soluzioni fornite dai diversi fornitori ottenendo, in modo trasparente, lo stesso livello di servizio. Nel caso in cui un componente non dovesse soddisfare alcuni requisiti funzionali potrebbe essere sostituito senza necessità di rivedere l intera architettura ma soprattutto 127

130 senza impattare su problematiche di integrazione tra i diversi componenti del sistema stesso. L enorme domanda di servizi Internet molto avanzati e mission-critical a cui si è assistito nell ultimo periodo, nel campo del commercio elettronico B2C e B2B, dei sistemi di Finanza Online, ma anche nel campo della Pubblica Amministrazione (per es. pagamento tributi) hanno spinto l evoluzione delle diverse piattaforme applicative. Oggi sono disponibili molteplici prodotti sulle diverse piattaforme che realizzano complessi sistemi di Web Application Server in grado di supportare scenari complessi e di integrarsi con i sistemi esistenti. Pertanto si ritiene che una architettura Web-based sia in grado di soddisfare tutti i requisiti richiesti dai diversi scenari di cooperazione applicativa nel contesto del piano di E-government e della Rete Nazionale, compresa l interoperabilità tra diverse piattaforme e l integrazione con il mondo legacy. 7.3Criteri per la sicurezza Le problematiche di sicurezza in una architettura di cooperazione applicativa basata sull utilizzo di standard Internet, possono essere rimandate in generale a quelle dei servizi offerti online su Internet e quindi possono essere adottati i meccanismi standard di ampia diffusione e generale accettazione in contesti, quali ad esempio quelli del mondo bancario o finanziario in generale, in cui certi requisiti sono estremamente stringenti. L accesso ai servizi offerti, sincroni o asincroni, da una Porta Applicativa in questo scenario può essere ristretto a utenti autorizzati allo stesso modo con cui può essere riservato l accesso ai siti Web. Oltre alla restrizione d accesso, il servizio offerto potrebbe avere il requisito di assicurare la riservatezza dei dati scambiati, così come pure la protezione della logica interna e dei dati sulla base dei quali viene implementato il servizio stesso. In sostanza quindi, rendere sicuro l accesso ad un servizio di questo tipo è perfettamente analogo al rendere sicuro l accesso ad un sito Web; invece di autorizzare l accesso agli utenti finali, si autorizzano computer specifici e/o amministrazioni (Porte Delegate) ad accedere al servizio offerto (Porta Applicativa) Se è noto a priori quali computer hanno bisogno di accedere ad un certo servizio, è possibile usare l'internet Protocol Security (IPSec) o sistemi firewall per restringere accesso a computer di indirizzi di IP conosciuti ed autorizzati. Nel caso in cui non possano essere noti a priori gli indirizzi di IP di tutti i sistemi client, l'approccio migliore per implementare l'autenticazione è quello di sfruttare le funzionalità di autenticazione del protocollo utilizzato per scambiare i messaggi. Per esempio, se si sta spedendo e ricevendo messaggi codificati in XML su protocollo HTTP, è possibile sfruttare le caratteristiche di autenticazione disponibile per l HTTP. Normalmente i vari Web Server disponibili sulle diverse piattaforme supportano diversi meccanismi di autenticazione per HTTP: 128

131 Basic Authentication: utilizzato per l identificazione dei client in modalità non sicura o semi-sicura, in quanto il nome utente e la parola chiave sono inviate sotto forma di testo in chiaro. Basic Authentication over SSL: come per l autenticazione Basic, tranne per il fatto che il nome di utente e la parola chiave sono spedite sulla rete con la cifratura Secure Sockets Layer (SSL), piuttosto che in chiaro. Si tratta di una buona scelta per gli scenari Internet-based, anche se l uso di SSL ha un impatto negativo sulle performance. Per attivare SSL è necessario installare sul Web Server un certificato server (SGC) emesso da una Certification Authority. Autenticazione integrata con il sistema operativo ospitante: utile solamente per scenari Intranet. Non può essere usato attraverso sistemi Proxy o Firewall. Certificati Client: richiede che ogni client abbia ottenuto un certificato. I certificati sono mappati sulle account utente che sono utilizzati dal server per autorizzare accesso ai servizi. Se risulta inaccettabile che i dati codificati in XML che compongono i messaggi applicativi siano inviati sul protocollo HTTP come testo in chiaro è consigliato l utilizzo dello standard SSL. Si noti che SSL è significativamente più lento del HTTP da solo, pertanto è necessario pesare attentamente i tradeoff tra la sicurezza e le performance. È possibile usare SSL per alcune specifiche funzionalità per cui il livello di sicurezza richiesto è più elevato, e tecniche più leggere per operazioni dove la sicurezza è meno critica. Dal punto di vista della sicurezza è utile evidenziare un ulteriore vantaggio offerto dall adozione di una architettura basata sull utilizzo di standard Internet: infatti l adozione dei protocolli Internet per la cooperazione applicativa in alternativa ad uno stack RPC (Remote Procedure Call) tradizionale, permette di garantire un adeguato livello di protezione dagli attacchi esterni, in quanto garantisce che sistemi firewall possono essere frapposti a difesa delle porte di dominio, senza per questo rischiare di inibire il traffico di cooperazione; detto in altri termini, si evita che per far funzionare il meccanismo di cooperazione applicativa prescelto, si scenda a pericolosi compromessi di sicurezza quali configurazioni eccessivamente aperte dei sistemi firewall, che possono aprire ad attacchi indesiderati. È utile inoltre notare che la Pubblica Amministrazione Italiana, grazie alle recenti azioni, normative ed esecutive, effettuate al fine di standardizzare l utilizzo della Firma Digitale, si trova in una posizione abbastanza vantaggiosa dal punto di vista della gestione della sicurezza negli scenari di cooperazione, potendo contare sulla potenziale diffusione di certificati digitali standard X.509v3 emessi dalle varie Autorità di Certificazione nel rispetto della normativa AIPA. A tal proposito è doveroso però segnalare che tale opera di standardizzazione nella gestione della sicurezza ha degli impatti non trascurabili dal punto di vista organizzativo ed è quindi facile prevedere un periodo transitorio, durante il quale l utilizzo dei Certificati Digitali dovrà avere la necessaria diffusione, le varie amministrazioni potranno migrare le loro architetture di sicurezza verso soluzioni più omogenee, ed infine anche le relative infrastrutture (sistemi/soluzioni forniti dalle varie Autorità di Certificazione e la relativa interoperabilità tra gli stessi) potranno maturare in modo tale da poter fornire un servizio adeguato ed efficiente. 129

132 7.4Il linguaggio XML L evoluzione e la diffusione del commercio elettronico Business-to-Business (B2B) ha eletto lo standard XML come metalinguaggio in grado di standardizzare i messaggi utilizzati per l attivazione di procedure remote. L utilizzazione di dati strutturati facilita la gestione e l elaborazione automatizzata dei dati e la creazione di ambienti di cooperazione applicativa. XML consente di creare una sintassi standard, ben organizzata, facile ed intuitiva, che può trarre vantaggio dalla disponibilità di tanti parser commerciali pronti da utilizzare, che consentono agli utenti, con investimenti contenuti, di descrivere e trattare dati specifici, qualunque sia la loro natura e il loro uso. XML è strutturato in modo tale da contenere al suo interno sia i dati che si vogliono rappresentare sia la loro descrizione in termini di struttura. Una delle caratteristiche più importanti di XML è infatti la possibilità di definire la struttura del documento tramite il formalismo di base Document Type Definition (DTD) o quello più evoluto costituito da XMLSchema. DTD e XMLSchema costituiscono insiemi di regole di sintassi per i TAG XML. Attraverso di essi si stabilisce infatti quali TAG, con relativi attributi, vadano usati, in quale ordine debbano apparire e quali siano annidati all'interno di altri. Un altro vantaggio in questo contesto è quello di poter validare la correttezza di un file XML, prima che questo venga elaborato o spedito. XML è un linguaggio per rappresentare i dati in modo indipendente dall architettura hardware e software del sistema e dai linguaggi applicativi utilizzati. Questo consente di trasferire dati ad una applicazione residente su un sistema diverso e che siano da questi correttamente interpretati, evitando di dover utilizzare dei formati record proprietari specificamente disegnati per far interoperare le applicazioni. Questo consente di separare le applicazioni legacy dalla rappresentazione dei dati. Uno scenario di utilizzo di XML di grande interesse è quello della cooperazione applicativa. In questi ultimi anni sono stati fatti molti sforzi per definire un modello che permettesse l elaborazione distribuita e per soddisfare le esigenze di integrazione di sistemi eterogenei su rete pubblica. L arrivo di XML e con esso la possibilità di strutturare un documento di testo per contenere informazioni semanticamente valide, unitamente alla generale accettazione, da parte di tutte le organizzazioni di HTTP e FTP come protocolli di distribuzione delle informazioni, ha aperto una nuova opportunità di sviluppo per l interoperazione tra organizzazioni diverse. Definendo la struttura della stringa dei dati (tracciato record) in XML, che può utilizzare come protocollo per il trasporto l HTTP è possibile far dialogare due applicazioni anche su rete pubblica Internet. L applicazione, in questo caso, è esposta su una Porta Applicativa e viene invocata da un altra applicazione che opera su una Porta Delegata. Questo consente all applicazione che opera sulla porta delegata di invocare l applicazione che eroga il servizio residente sulla porta applicativa, passando la stringa dei dati prevista e concordata fra le parti per il colloquio, e di ricevere da questa le informazioni richieste in risposta. In pratica si realizza un livello di trasformazione dei dati, che dal lato interno, dialoga con le applicazioni legacy nelle modalità tradizionali, ed esporta all esterno, attraverso il Web Server, le informazioni nel formato XML previsto. 130

133 Come già accennato in precedenza XML consente di utilizzare il protocollo HTTP per il trasporto dei dati, quindi, non richiede l apertura di porte di servizio specifiche sui firewall per consentire il passaggio dei dati da Internet ai sistemi interni. 8.4 Tecnologie middleware alternative per interscambio dati e cooperazione applicativa Sono fondamentalmente tre le principali problematiche che fino ad oggi hanno reso difficoltosa la realizzazione dei vari modelli di cooperazione applicativa nell ambito della Pubblica Amministrazione: interoperabilità tra piattaforme diverse; interoperabilità tra middleware diversi; interoperabilità tra modelli di sicurezza. Queste problematiche hanno impattato fortemente l effettiva interoperabilità tra le tecnologie middleware a componenti distribuiti diffusesi negli ultimi anni, soprattutto quando questa interoperabilità veniva richiesta in uno scenario Internet o Internet-like. Nella seguente tabella vengono richiamate queste tecnologie ed i relativi meccanismi per l invocazione remota delle componenti. Tecnologie a componenti COM/COM+ CORBA EJB Meccanismi di invocazione remota DCOM IIOP RMI Nel seguito si elencano alcune dei limiti che queste tecnologie hanno concretamente evidenziato: Non funzionano in modo efficiente attraverso i Firewall, quando questi ultimi sono configurati per veicolare traffico HTTP (porte 80, 443), in quanto, essendo basate su meccanismi ti tipo RPC tradizionale, richiedono l apertura di un numero aggiuntivo di porte TCP, in range abbastanza estesi. Sono tecnologie concepite per la realizzazione di componenti tipicamente stateful e connection oriented, che poco si sposano con la natura stateless e connectionless del mondo Internet. Normalmente si dice che si tratta di tecnologie ad accoppiamento forte (tightly-coupled) in contrapposizione con le tecnologie Internet che sono tipicamente ad accoppiamento debole (loosely-coupled). COM ha una diffusione molto ampia ma è limitato di fatto alla piattaforma Windows. EJB presuppone l utilizzo esclusivo di Java come linguaggio di programmazione. CORBA è molto meno diffuso delle altre due tecnologie. In aggiunta a questo l esperienza sul campo ha dimostrato che è molto complicato non solo far parlare tra loro tecnologie ad oggetti eterogenee (COM <-> CORBA, COM 131

134 <-> EJB, CORBA <-> EJB), ma addirittura la stessa tecnologia implementata su piattaforme diverse, molto spesso per motivi legati alle policy di sicurezza implementate in modo diverso. La situazione non è molto diversa se, in alternativa alle classe delle tecnologie evidenziate, si utilizza per fare interoperare le applicazioni un Message-Oriented Middleware (MOM) allo scopo di implementare un paradigma di cooperazione asincrono. L architettura proposta, come si vedrà nei paragrafi immediatamente successivi, è nata per superare le limitazioni dei modelli tradizionali facendo uso degli standard Internet Il concetto di Web Service La nuova architettura proposta per la cooperazione applicativa tra Amministrazioni è basata sul concetto, di sempre maggiore successo e diffusione, dei Web Services. Basato su XML, il paradigma dei Web Services rappresenta infatti la nuova architettura di riferimento per l interoperabilità e la distribuzione dei servizi applicativi in uno scenario Internet. Il termine Web Services indica funzionalità operative esposte da una azienda, attraverso la connessione ad una rete basata su protocolli Internet, verso altre aziende o programmi software automatici, allo scopo di fornire pubblicamente le modalità di utilizzo di un proprio servizio. Un Web Service sfrutta gli aspetti positivi sia dei componenti che del web, in quanto: racchiude le funzionalità in una black-box; interagisce con altri servizi con una interfaccia ben definita; necessita del supporto dei protocolli Internet; è stateless; si basa su di una interfaccia basata sui messaggi, definiti da un contratto. Il modello dei Web Services è completamente indipendente dal linguaggio di programmazione, dalla piattaforma e dal modello ad oggetti eventualmente utilizzato, pertanto: è possibile creare un Web Service con qualsiasi linguaggio su qualsiasi piattaforma; è possibile usufruire di un Web Service con qualsiasi linguaggio su qualsiasi piattaforma. I requisiti fondamentali per l implementazione del modello dei Web Services sono: uno standard per la rappresentazione dei dati: XML (Extensible Markup Language); un formato messaggi che sia comune ed estensibile: SOAP (Simple Object Access Protocol); 132

135 un linguaggio di definizione delle interfacce di invocazione (contratti) che sia comune ed estensibile: WSDL (Web Service Description Language); un modello di registro delle interfacce/contratti: UDDI (Universal Description, Discovery and Integration). Si tratta per certi aspetti di un modello incrementale : infatti SOAP e WSDL come si vedrà sono a loro volta basati su XML, mentre UDDI è a sua volta un Web Service che espone una interfaccia SOAP. Come si può notare c è una sostanziale analogia tra le diverse elementi che costituiscono questo modello ed una tecnologia a componenti più tradizionale: SOAP è un meccanismo di invocazione remota come DCOM, IIOP, RMI, mentre il WSDL ha nel modello proposto un ruolo simile ad esempio a quello di IDL in un contesto CORBA. Il grosso vantaggio è però che tutto è completamente basato su XML e HTTP, e pertanto tutto intrinsecamente indipendente dalla piattaforma e dal linguaggio di programmazione. Come evidenziato nella Figura 1, le tre principali componenti dell Architettura Web Services sono: Fornitore del Servizio: è il proprietario del servizio. Dal punto di vista architetturale è la piattaforma che fornisce l accesso al servizio; in termini di Cooperazione Applicativa è la Porta Applicativa dell Amministrazione che espone il servizio. Richiedente il Servizio: è il soggetto che richiede che una certa funzione sia svolta. Dal punto di vista architetturale, è l applicazione o l utente che cerca ed invoca un dato servizio; in termini di Cooperazione Applicativa è la Porta Delegata dell Amministrazione che richiede servizio. Registro dei Servizi: è un elenco consultabile di descrizioni di servizi in cui i Fornitori di Servizi pubblicano i loro servizi ed i richiedenti il servizio individuano il servizio stesso ottenendo le informazioni necessarie ad ottenere il servizio. In termini di Cooperazione Applicativa sarà una Directory dei Servizi, che è possibile immaginare ospitato presso il Centro Tecnico della Rete Nazionale. 133

136 Descrizione del Servizio Registro dei Servizi WSDL, UDDI WSDL, UDDI Richiedente il Servizio SOAP Fornitore del Servizio Descrizione del Servizio Servizio Fig.1- Schema dell architettura Web Services L architettura dei Web Services suggerisce un modello di business nel quale possono essere identificate le seguenti fasi distinte: Realizzazione del Servizio (Build): il servizio in oggetto viene implementato utilizzando eventualmente tecnologie e piattaforme consolidate. Ad esempio, il servizio potrebbe essere implementato utilizzando un modello a componenti/ oggetti esistente, demandando a questo livello la risoluzione delle problematiche di integrazione con eventuali piattaforme legacy (sistemi OLTP, sistemi ERP, DBMS, ecc.). Esposizione del servizio in architettura Web Services (Expose): la realizzazione del Web Service vero e proprio presuppone che le componenti applicative realizzate nella fase precedente siano accedibili tramite una infrastruttura Web standard tramite il protocollo HTTP ed il linguaggio XML. In questa fase si utilizzano strumenti di produttività in grado di generare in modo automatico l interfaccia WSDL e le componenti server necessarie per produrre questo livello di wrapping. Pubblicazione del Servizio (Publish): l interfaccia WSDL viene opportunamente pubblicata su un registro UDDI, in modo tale che sia accedibile da interlocutori esterni; in questa fase, in un contesto più ristretto, in alternativa ad una infrastruttura UDDI, è sufficiente che l interfaccia WSDL sia resa disponibile in lettura sul sito del fornitore del servizio oppure su eventuali altre forme alternative di repository. Nella fase di pubblicazione vanno ovviamente definite anche le eventuali policy di sicurezza per l accesso al servizio ed informazioni sul modello di business proposto (es. costi del servizio, logiche di registrazione, ecc.) 134

137 Ricerca del servizio (Find): Il richiedente il servizio, che ha necessità di accedere al servizio in una logica B2B, ricerca nel registro UDDI le informazioni necessarie, costituite in ultima analisi dall interfaccia WSDL; analogamente a quanto detto per la fase precedente, anche in questa fase, in un contesto più ristretto, in alternativa ad una infrastruttura UDDI, è sufficiente che il richiedente possieda le informazioni (URL) su dove andare a recuperare l interfaccia WSDL, nel caso sia resa disponibile in lettura sul sito del fornitore del servizio oppure su eventuali altre forme alternative di repository. Invocazione del servizio (Bind/Invoke): il richiedente il servizio possiede tutte le informazioni potenziali per essere in grado a questo punto di invocare il servizio offerto dal fornitore tramite chiamate SOAP, nel rispetto non solo dell interfaccia WSDL esposta, ma anche delle policy di sicurezza e del modello di business definito. Nel flusso applicativo si possono identificare diverse componenti. Le componenti della Porta Delegata sono: Applicazione richiedente: Il modello proposto è sostanzialmente un modello di implementazione di applicazioni. L accesso ad un Servizio avviene infatti attraverso l uso di elementi applicativi che gestiscono le richieste di servizio. Questi elementi applicativi possono essere delle interazioni pure del tipo machine-to-machine (es. applicazioni B2B) oppure delle applicazioni web che utilizzano un Web Application Server per interfacciare una applicazione con un utente dotato di browser. L applicazione richiedente può essere scritta in qualsiasi linguaggio capace di utilizzare il protocollo SOAP. In pratica, è richiesto un XML parser ed una implementazione SOAP richiamabile da tale linguaggio. In genere l applicazione richiedente non accederà ai servizi componendo direttamente un messaggio SOAP, ma si avvarrà di intermediari forniti dal Services runtime e degli strumenti di sviluppo. Runtime del richiedente: Il runtime del richiedente (la Porta Delegata) é costituito da un insieme di linee di codice che supporta l accesso di un applicazione ad uno specifico servizio. Il Runtime del richiedente fornisce i seguenti servizi di base: 135

138 1. Supporto al processo di chiamata dei pacchetti all interno di messaggi SOAP e trattamento dei messaggi SOAP di risposta. 2. Supporto completo per tutti i diversi protocolli di trasporto utilizzati per la trasmissione dei messaggi SOAP. 3. Runtime configurabile per le politiche di decisioni comuni. Ogni azione di runtime deve svolgersi all interno di un modello di sicurezza. In fase di design i tools devono generare le limitazioni di configurazione che diverranno poi inputs per l applicazione di runtime. Il Runtime richiedente può inoltre fornire i seguenti servizi addizionali: 1. Accesso in ricerca per le informazioni contenute nel registro. 2. Estrazione di informazioni aggregate partendo da informazioni semplici contenute nel registro di descrizione dei servizi. 3. Creazione di servizi di proxy (di seguito definiti) partendo da informazioni aggregate di tipo WSDL. Le componenti della Porta Applicativa sono: Interfaccia SOAP: un servizio é un componente che gira sotto la supervisione del Web Application Server (WAS). Poiché la richiesta di uno specifico servizio utilizza SOAP come protocollo sottostante, si assume che lo stesso servizio sia invocato utilizzando l infrastruttura SOAP. Il router SOAP gestisce l analisi dei messaggi SOAP ed instrada le richieste verso l oggetto di destinazione, che può essere implementato utilizzando diverse tecnologie e/o linguaggi, in funzione della specifica piattaforma, di componenti applicative preesistenti o di eventuali altri vincoli. Lo strumento di sviluppo proposto può esaminare le classi esposte dall oggetto di destinazione usando processi di introspezione e quindi generare un interfaccia di definizione di tipo WSDL per la classe in questione e anche gli appropriati descrittori di erogazione per erogare il servizio all interno di uno specifico ambiente. Contenitori di Servizio: per tutte le applicazioni che non possiedono già un interfaccia Web standard, il codice del Servizio richiesto può utilizzare un adattatore generato dallo strumento in grado di gestire la transizione verso il modello richiesto dal codice di destinazione. Questi adattatori personalizzati dovrebbero essere generati automaticamente dallo stesso strumento che crea il WSDL che definisce la fornitura del Servizio. 136

139 8.4.2 Simple Object Access Protocol Lo standard SOAP è il diretto discendente della proposta denominata XML-RPC. Come XML-RPC, il SOAP mappa direttamente le chiamate RPC su HTTP. Il protocollo SOAP nasce come lightweight protocol (intento dichiarato: essere possibile implementarlo in 2-3 giorni) in quanto tale, prevede solo un semplice meccanismo di Request/Response. Nella figura seguente viene illustrata la struttura del protocollo SOAP. Lo standard SOAP si basa sui seguenti elementi: HTTP (incluse anche le HTTP-extensions). È l unico protocollo supportato attualmente dalle specifiche SOAP, benché SOAP sia indipendente dal protocollo di trasporto sottostante e siano disponibili anche implementazioni su SMTP. Per l invio dei messaggi viene usata una HTTP POST. La Response alla POST è usata per comunicare il risultato dell invocazione remota. 137

140 POST /Supplier HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnn SOAPAction: "Some-URI" Figura 1: Esempio di POST SOAP HTTP/ OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn Figura 2: Esempio di Response SOAP XML L Envelope ed il Body sono elementi la cui presenza è obbligatoria. Nel Body viaggia la specifica XML del metodo richiamato. L Header è un elemento opzionale attraverso cui è possibile specificare delle estensioni del protocollo. ENVELOPE <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" HEADER) <SOAP-ENV:Header> <t:transaction xmlns:t="some-uri" SOAP-ENV:mustUnderstand="1 SOAP_ENV:actor= some-uri> 5 </t:transaction> </SOAP-ENV:Header> BODY <SOAP-ENV:Body> <m:getlasttradepriceresponse xmlns:m="some-uri"> <Price>34.5</Price> </m:getlasttradepriceresponse> Figura 3: Esempio di Messaggio SOAP In questo caso i parametri actor e mustunderstand indicano il sistema target e l obbligatorietà o meno della estensione (nell esempio una Transaction con identificativo 5 ). 138

141 Encoding L uso del SOAP Encodng Style è incoraggiato ma non required. Schema alternativi possono essere usati, fornendo nell envelope o nel body il namespace corrispondente. Il SOAP Encoding Style definisce: - Simple Types: int, float, negativeinteger,string - Compound Types: Arrays, Structs <element name="age" type="int"/> <element name="height" type="float"/> <element name="displacement" type="negativeinteger"/> <element name="color"> <simpletype base="xsd:string"> <enumeration value="green"/> <enumeration value="blue"/> </simpletype> </element> <age>45</age> <height>5.9</height> <displacement>-450</displacement> <color>blue</color> Figura 4: Esempi di Simple Types Il SOAP permette alle applicazioni di invocare dei metodi o funzioni che risiedono su server remoti. Una applicazione SOAP genera una richiesta contenuta in una stringa XML, fornendo tutti i dati richiesti dal metodo remoto e l indirizzo di questo. Il SOAP server trasmette la richiesta all oggetto specificato nell indirizzo, tipicamente utilizzando il protocollo HTTP, per il trasporto della richiesta e della stringa dei dati. Quando la richiesta è stata soddisfatta e l esecuzione remota è completata, la risposta del metodo viene formattata in XML e viene restituita all applicazione. 139

142 8.5 Linguaggi per la descrizione delle interfacce ed indici dei servizi In questo paragrafo vengono illustrati con maggiore dettaglio le caratteristiche del linguaggio di descrizione WSDL e dell iniziativa di registry UDDI; entrambi, come è stato evidenziato in precedenza, ricoprono un ruolo molto importante nell architettura dei Web Services: WDSL è infatti il meccanismo di definizione delle interfacce dei Web Services, mentre UDDI rappresenta un modello di indice dei servizi implementati in tale architettura Web Service Description Language La tecnologia WSDL si pone a metà tra SOAP (il wire protocol ) e le funzionalità offerte dal registro UDDI e consente di definire la semantica dei servizi scomponendo i metadati in elementi più o meno astratti. Le informazioni contenute in un documento WSDL sono rappresentate in XML e permettono di definire i messaggi di input ed output di un determinato servizio (codificati in XML Schema), la relazione tra questi (le operazioni) ed il collegamento fisico ad un determinato endpoint che costituisce il punto di fornitura fisico del servizio web. Il WSDL è un documento XML e quindi può essere contenuto nel filesystem locale oppure caricato dinamicamente da un web server. Quello che conta nelle specifiche non è la posizione fisica dell informazione XML ma la semantica e la struttura dei contenuti. Le specifiche WSDL definiscono un insieme di informazioni relative alla definizione dei servizi ed al collegamento di questi a SOAP, HTTP e MIME. Gli elementi basilari che compongono una definizione WSDL sono: - Tipi - Messaggi - Operazioni - Collegamenti (binding) - Definizione del servizio La combinazione di più definizioni di questi elementi definiscono un Web Service. Al fine di comprendere meglio il ruolo dei vari elementi che compongono un documento WSDL è utile fornire un esempio pratico, che illustra la definizione di un Web Service che fornisce un servizio di informazione circa il valore di titoli di borsa: 140

143 <?xml version="1.0"?> <definitions name="stockquote" targetnamespace=" xmlns:tns=" xmlns:xsd1=" xmlns:soap=" xmlns=" <types> <schema targetnamespace=" xmlns=" <element name="tradepricerequest"> <complextype> <all> <element name="tickersymbol" type="string"/> </all> </complextype> </element> <element name="tradeprice"> <complextype> <all> <element name="price" type="float"/> </all> </complextype> </element> </schema> </types> <message name="getlasttradepriceinput"> <part name="body" element="xsd1:tradepricerequest"/> </message> <message name="getlasttradepriceoutput"> <part name="body" element="xsd1:tradeprice"/> </message> <porttype name="stockquoteporttype"> <operation name="getlasttradeprice"> <input message="tns:getlasttradepriceinput"/> <output message="tns:getlasttradepriceoutput"/> </operation> </porttype> <binding name="stockquotesoapbinding" type="tns:stockquoteporttype"> <soap:binding style="document" transport=" <operation name="getlasttradeprice"> <soap:operation soapaction=" <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="stockquoteservice"> <documentation>my first service</documentation> <port name="stockquoteport" binding="tns:stockquotebinding"> <soap:address location=" </port> </service> </definitions> 141

144 Nel documento si possono evincere le diverse sezioni citate sopra. In dettaglio: la sezione types definisce i tipi utilizzati all interno dei messaggi del servizio. L utilizzo del Tag <schema> permette di scegliere quale tipo di encoding utilizzare (nell esempio si usa proprio XML Schema). I tipi corrispondono più o meno a strutture dati tipo struct del linguaggio C; le sezioni message contengono le definizioni dei messaggi di scambio del servizio e fanno uso di parti definite come tipi nelle sezioni Types. Possiamo pensare ai messaggi come aggregati di tipi; la sezione porttype definisce le operazioni esposte dal Web Service (sostanzialmente i metodi dell oggetto remoto che costituisce il servizio web). Per ogni metodo viene definito il messaggio di input ed il messaggio di output; la sezione binding contiene il collegamento tra il porttype (cioè la definizione astratta del servizio) all endpoint fisico. Queste sono le informazioni che indicano il protocollo da utilizzare e come ricondurre i messaggi di input ed output al protocollo utilizzato; la sezione service contiene la definizione del servizio in termini della sua descrizione e della posizione fisica del servizio (tipicamente il suo URL) definiti endpoint. Le operazioni possibili (porttype) possono essere di diverso tipo e costituiscono le primitive che un endpoint può supportare. Sono sostanzialmente le quattro combinazioni ottenute dall invio e la ricezione di un messaggio da parte di un endpoint. Queste sono: one-way: l endpoint riceve un messaggio inviato dal client. È una sorta di fire&forget dove il Web Service riceve una notifica; request-response: in questo caso l endpoint riceve un messaggio di richiesta, esegue le operazioni relative e fornisce al client una risposta inviando un messaggio correlato alla richiesta ricevuta; solicit-response: è l opposto del precedente; qui è l endpoint che invia una notifica al client ed in seguito attende da questo una risposta correlata; notification: la notifica prevede l invio da parte dell end-point di un messaggio. È l opposto dell one-way e può essere utile per implementare sistemi di push. Le specifiche WSDL, come accennato, definiscono alcuni collegamenti (bindings) con altre tecnologie, quali SOAP, HTTP e MIME. Il binding con SOAP è relativo agli endpoint e cioè alle specifiche di invio dei messaggi di input ed output tramite SOAP. Senza entrare troppo nel dettaglio possiamo dire che tramite una grammatica semplice ma espandibile, le informazioni relative ai messaggi vengono veicolate nella struttura SOAP utilizzando i blocchi Header e Body. Per quanto riguarda HTTP, invece, le specifiche WSDL definiscono collegamenti per i verbi GET e POST in modo da consentire ad una applicazione sviluppata per WSDL di accedere ad un Web Server come se fosse un Web Service. Un altro collegamento interessante è quello con alcuni tipi di encoding MIME, tra cui l application/x-www-form-urlencoded che viene utilizzato per eseguire l invio di una FORM in HTML ed il text/xml utilizzato per indicare testi XML. Anche la grammatica relativa al collegamento a MIME è espandibile e potrà essere sviluppata in futuro con altre tipologie di collegamenti. 142

145 8.5.2 L'iniziativa Universal Description, Discovery and Integration UDDI, acronimo di Universal Discovery Description and Integration, è una specifica di un registry web-based distribuito che contenga informazioni su Web Services. I registries UDDI possono essere utilizzati per promuovere ed individuare i Web Services In questa sezione di intende fornire le informazioni basilari su UDDI, al fine di permettere di comprendere che cosa è UDDI, quali attori lo dovrebbero utilizzare, e soprattutto come un registry distribuito permetta potenzialmente ad applicativi di una certa organizzazione di individuare ed interagire con i Web services esposti sulla rete da altre organizzazioni. La specifica UDDI fornisce una serie di servizi ed una interfaccia programmatica che definiscono un semplice framework per descrivere qualunque tipo di Web Service. La specifica consiste in parecchi documenti ed un XMLSchema che definisce un protocollo di programmazione, basato su SOAP, specifico per le operazioni di discovery dei servizi. Queste specifiche sono state inizialmente definite grazie al lavoro di un gruppo di aziende, le quali hanno implementato i primi servizi UDDI su Internet in logica di partnership multi-sito. Utilizzando i servizi web offerti da un registry UDDI, una organizzazione può individualmente registrare le informazioni circa i web services che è in grado di esporre e offrire ad altre organizzazioni. Queste informazioni possono essere aggiunte al registry sia tramite le pagine di un sito Internet, sia utilizzando degli strumenti che facciano uso diretto delle interfacce programmatiche UDDI. Una volta che la registrazione è stata effettuata, I dati forniti dall organizzazione vengono automaticamente condivisi con le eventuali altre istanze del registro distribuito, e diventano immediatamente disponibili a quanti abbiano necessità di individuare quali servizi siano esposti da quell organizzazione. Come accennato in precedenza, la specifica UDDI consiste in un XMLSchema per messaggi SOAP ed in una descrizione di API. L XML Schema di UDDI definisce tre tipologie fondamentali di informazione, necessarie dal un punto di vista tecnico per poter utilizzare un Web Service offerto da un altra organizzazione. Queste tipologie sono: - informazioni di business; - informazioni sul servizio (o informazioni di binding); - informazioni specifiche dei servizi. Nella figura seguente sono illustrate sia la gerarchia delle informazioni, che gli elementi XML chiave che sono utilizzati per descrivere ed individuare le informazioni circa i Web Services. 143

146 <businessentity> name, contacts, description, indentifiers, categories <businessservice> (1..n) name description, categories <bindingtemplate> (1..n) technical information <tmodel> name description URL pointers to specificaitons Nel seguito vengono forniti maggiori dettagli circa le tipologie di informazioni definite: Informazioni di Business: l elemento businessentity Gli elementi XML di base che supportano la pubblicazione e l individuazione delle informazioni di business sono contenute un una struttura denominata businessentity, che fornisce una informazione di alto livello. L informazione completa relativa all elemento businessentity può essere categorizzata, in modo tale che sia possibile effettuare ricerche al fine di individuare le organizzazioni che appartengono ad una particolare industria o categoria, oppure che sono localizzate in una specifica area geografica. Le descrizioni tecniche e di business dei Web Service sono definite all interno delle sottostrutture dell elemento businessentity, in particolare nelle strutture denominate businessservice e bindingtemplate, illustrate nei punti successivi. Informazioni di Servizio: l elemento businessservice La struttura businessservice è un contenitore descrittivo che viene utilizzato per raggruppare una serie di Web Services correlati ad un processo di business o ad una categoria di servizi. Le informazioni contenute in businessservice possono essere ulteriormente categorizzate, permettendo alla descrizione del Web Service di essere segmentati in relazione all industria, al prodotto, al servizio o ai confini geografici. All interno di ogni businessservice sono presenti uno o più descrizioni tecniche del Web Service, che contengono le informazioni che sono rilevanti per le applicazioni che hanno necessità di connettersi con il servizio remoto. Queste informazioni includono l indirizzo a cui connettersi, come pure il supporto ad eventuale informazioni opzionali. È possibile definire anche funzionalità addizionali che permettano di supportare opzioni complesse di routing come ad esempio per gestire problematiche di bilanciamento di carico. Informazioni specifiche dei servizi: l elemento bindingtemplate 144

147 L informazione necessaria per invocare effettivamente un servizio è contenuta nell elemento denominato bindingtemplate. Conoscere solo l indirizzo al quale contattare un determinato Web Service potrebbe non essere sufficiente; ad esempio, se una certa organizzazione offre un Web Service che permette di inviare un ordine di acquisto, la conoscenza dell URL del servizio può non essere di per se utile se non sono conosciute altre informazioni vitali affinché l ordine possa essere effettivamente inviato con successo, come ad esempio quali protocolli vanno utilizzati, quali sono i requisiti di sicurezza e quale forma di risposta è lecito attendersi dal servizio come conferma dell invio dell ordine. Proprio per questi motivi, ogni elemento di tipo bindingtemplate contiene uno speciale elemento che costituisce una liste di riferimenti alle informazioni specifiche. Questi riferimenti, che costituiscono le chiavi per poter accedere alle informazioni, sono chiamati tmodels, che non sono altro che metadati relativi ad una specifica, e che includono il suo nome, l organizzazione che la pubblica, ed i puntatori alle URL relative. Nell esempio precedente, il riferimento tmodel è un puntatore all informazione circa le specifiche dell ordine d acquisto. In questo modo il modello UDDI supporta anche il concetto di compatibilità tra Web Services. Utilizzando lo stesso tmodel per un determinato tipo di servizi, organizzazioni diverse possono fornire Web Services che risultano compatibili. Le specifiche UDDI includono la definizione delle interfacce (API) del Web Service che permette l accesso alle informazioni contenute nel registry. Le API si dividono in due categorie: API di Inquiry: vengono utilizzate per realizzare programmi in grado di ricercare e scorrere informazioni presenti nel registry; in questa categoria ricadono anche le chiamate che permettono di gestire la fase di recovery nel caso che una chiamata ad un Web Service fallisca, garantendo pertanto una gestione del concetto di qualità di servizio. API di Publishing: vengono utilizzate da chi intende implementare strumenti evoluti per interagire con il registry e per permettere ad esperti tecnici di gestire le informazioni pubblicate sotto forma di strutture businessentity e tmodel. Le API di UDDI sono tutte a loro volta implementate come chiamate SOAP. Ovviamente un principio importante delle API di Publishing e del registry UDDI in generale, riguarda la gestione della sicurezza: solo gli utenti autorizzati sono in grado di pubblicare, modificare e/o cancellare le informazioni di loro proprietà all interno del registry. 8.6 L'integrazione di applicazioni Legacy L integrazione tra Web Services e applicazioni esistenti dal lato del richiedente si basa su due componenti fondamentali: Proxy di Servizio: Un proxy di servizio rappresenta un applicazione di aggregazione per l implementazione di uno specifico servizio. Il proxy viene creato dal runtime richiedente 145

148 partendo da una definizione di tipo WSDL e contiene sia tutte le informazioni per l implementazione dell aggregazione, sia l interfaccia di definizione necessaria a produrre il messaggio SOAP inviato al servizio. Una volta che il proxy dei servizi è stato creato, può invocare il metodo del Servizio utilizzando la funzione di invoke() che produrrà il nome del metodo e un set di argomenti da utilizzare nel messaggio SOAP per il servizio. Di risposta, il proxy dei servizi fornirà supporto per restituire informazioni dettagliate sui risultati e quelle di gestione degli errori. Per molte applicazioni richiedenti, la presenza del proxy di servizi sarà mascherata attraverso un adeguato wrapping del codice generato dai tools di sviluppo. I proxies di servizio verrebbero utilizzati direttamente solamente se l applicazione richiedesse un informazione di invocazione di servizio che non è stato possibile determinare in fase di sviluppo dell applicazione. Questo meccanismo é molto simile a quello di accesso di tipo riflesso di Java. Poiché la creazione di un proxy di runtime è di tipo dinamico, la generazione dei proxy di servizio potrebbe risultare limitata dal livello di sicurezza del proxy. Wrapper di Servizio: un wrapper di servizio é un codice che accede ad un Servizio su richiesta di un applicazione. I wrappers di servizio vengono generati da un tool di sviluppo dell applicazione richiedente partendo da un appropriata definizione di Servizio Web. La definizione può essere sia un entry di un registro di tipo UDDI sia un documento WSDL. I wrappers di servizio creano un interfaccia più semplice verso il servizio, nascondendo quanti più dettagli possibile del servizio stesso (aggregazione, chiamata, ordinamento). L obiettivo dei wrappers di servizio generati è quello di permettere al codice richiedente di accedere ad un servizio tramite il Web proprio come se il codice si trovasse ad operare all interno dello stesso processo. Per quanto riguarda il lato del fornitore di servizi, l integrazione con applicazioni esistenti può seguire tre scenari : Wrapping di servizi transazionali legacy host: l integrazione è ottenuta esportando il servizio transazionale tramite un connettore che poi viene wrappato da un oggetto che rappresenta il servizio sulla porta applicativa. Wrapping di servizi con interfaccia testuale: un secondo caso di integrazione con servizi legacy è quello in cui il servizio è erogato da una applicazione monolitica in cui la presentation logic (a caratteri) è strettamente interconnessa alla business logic. In questo caso gli strumenti cosiddetti di screen scraping possono eseguire il recording di una sequenza di interazioni con l applicazione, ed esporne poi gli input e gli output come argomenti di metodi di set/get di un oggetto o componente. Tale oggetto sarà l immagine del servizio sulla porta applicativa, mentre l interazione con l applicazione legacy vera e propria sarà attraverso un emulatore di terminale o tecnologia equivalente. Wrapping di servizi XA: questa tipologia dimostra il caso di un codice sviluppato ad hoc per esporre un servizio sulla porta applicativa. Essendo il servizio sviluppato specificamente per interagire con il SOAP, non è necessario un adapter. 146

149 8.7 Estensioni del modello dei Web Services L architettura dei Web Services descritta nei paragrafi precedenti rappresenta un modello di interoperabilità molto semplice ed efficace. Questi attributi ne stanno determinando una accettazione del mercato estremamente ampia, al punto che è possibile affermare che la globalità dei fornitori nel settore IT hanno adottato e/o stanno lavorando su soluzioni che implementano questa architettura. L architettura dei Web Service fornisce un modello di interoperabilità di base, sul quale è possibile implementare modelli più complessi ed esaustivi, sfruttando la caratteristica tipica dell XML di prestarsi alla costruzione di modelli incrementali. In questa sezione si vuole fornire una indicazione di quelle che sono alcune delle iniziative più importanti in corso per la definizione di estensioni del modello basilare dei Web Services, al fine di indirizzare alcune problematiche più complesse di interoperabilità, quali lo scambio di dati in forma binaria ed il supporto a workflow tra processi in uno scenario di cooperazione complesso, il supporto alle transazioni distribuite. Queste sono infatti alcuni esempi di problematiche di cooperazione che il modello di base dei Web Services da solo, senza le dovute estensioni, non è in grado di supportare. Nonostante ciò è utile ricordare che una eventuale futura ampia diffusione del modello basilare proposto nel contesto della Pubblica Amministrazione, rappresenterebbe comunque un enorme passo avanti nell implementazione delle architetture di interoperabilità negli scenari e-government, in quanto è facile ipotizzare che le attuali primarie esigenze di interscambio dati tra Amministrazioni diverse possano essere ampiamente soddisfatte dal modello dei Web Services. 147

150 8.7.1 Gestione di dati binari: SOAP Messages with Attachments La specifica SOAP 1.1 da sola non è in grado di supportare l invio di documenti complessi e/o in forma binaria. Il modello dei Web Services, per poter essere adottato in uno scenario più ampio ed esaustivo, necessita che i messaggi A SOAP possano essere trasmessi insieme a documenti collegati (attachments) di vario tipo, come immagini fax, documenti legali, schemi e disegni, ecc. Questi dati sono spesso rappresentati in forma binaria; per esempio, la gran parte delle immagini su Internet vengono trasmesse utilizzando i formati GIF e JPEG. Grazie alla semplice estensibilità del modello dei Web Services, è stata proposta al W3C una estensione di SOAP, denominata SOAP Messages with Attachments, attualmente allo stato di Nota, con l obiettivo di definire un meccanismo standard per realizzare un forma di binding tra un messaggio SOAP 1.1 ed un messaggio MIME multipart/related, in modo tale che le regole di elaborazione del messaggio SOAP 1.1 vengano comunque preservate. Il meccanismo MIME multipart per l incapsulamento di documenti elettronici generici può essere utilizzato per collegare tali documenti come attachments al messaggio SOAP. Nella proposta vengono specificate le regole per l utilizzo di riferimenti URI per le entità definite nel package MIME. In questo documento non si intende esaminare i dettagli della specifica SOAP Message with Attachments, per il cui approfondimento si rimanda alle referenze indicate alla fine di questo capitolo. È importante comunque evidenziare che il meccanismo proposto è esclusivamente basato sulle caratteristiche già esistenti di SOAP e sul meccanismo standard MIME mechanisms, al fine di trasportare e referenziare gli attachments. In altre parole, viene proposto un approccio semplice ma efficace che utilizza standard già esistenti, senza necessità di inventare nuovi protocolli. 148

151 Al fine di fornire un esempio esplicativo, nel seguito viene illustrato un messaggio SOAP 1.1 che contiene una immagine in formato TIFF di un fax (file claim061400a.tiff): MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=mime_boundary; type=text/xml; Content-Description: This is the optional message description. --MIME_boundary Content-Type: text/xml; charset=utf-8 Content-Transfer-Encoding: 8bit Content-ID: <?xml version='1.0'?> <SOAP-ENV:Envelope xmlns:soap-env=" <SOAP-ENV:Body>.. <thesignedform </SOAP-ENV:Body> </SOAP-ENV:Envelope> --MIME_boundary Content-Type: image/tiff Content-Transfer-Encoding: binary Content-ID: TIFF image... --MIME_boundary-- È utile sottolineare come questo modello di estensione di SOAP possa permettere l adozione del modello dei Web Services anche in scenari di automazione della gestione documentale ed in generale si presta all implementazione di modelli più complessi, come ad esempio quello definito nella specifica ebxml, descritto nel paragrafo successivo, che utilizza SOAP Messages with Attachments come Message Service Specification Gestione di workflow distribuito tra processi: ebxml Il termine ebxml è l acronimo di electronic business XML e si riferisce ad una iniziativa internazionale dell' UN/CEFACT (United Nations Centre for Trade Facilitation and electronic business), nell ambito delle Nazioni Unite. Tale iniziativa ha lo scopo di ricercare e identificare le basi tecnologiche su cui sia possibile standardizzare l'implementazione di XML a livello globale, in particolare con l intento di facilitare e rendere meno complessa e onerosa l implementazione di flussi basati su transazioni che intercorrano nell ambito di segmenti verticali di attività. L'obiettivo di ebxml è di fornire una infrastruttura tecnica aperta per permettere l'uso di XML in maniera coerente ed uniforme nello scambio di dati elettronici in contesti applicazione-applicazione e applicazione-uomo, in quei casi in cui esistano scambi complessi che richiedano una strutturazione concordata delle transazioni, siano esse a richiesta singola o multipla, oppure schemi e flussi documentali. Questi particolari requisiti applicativi comportano la necessita di modelli di implementazione estensivi rispetto a quello ottenibili con il modello di base dei Web Services. 149

152 In tal senso ebxml, una suite di specifiche XML e di processi ad esse correlati progettati per fornire una infrastruttura per la collaborazione e l integrazione, costituisce una estensione del modello dei Web Services: da una parte riutilizza SOAP per il trasporto delle informazioni, dall altra aggiunge le strutture dati necessarie per specificare la coreografia delle transazioni e del workflow, con meccanismi quindi piu articolati rispetto a quello semplice richiesta/risposta disciplinato per scelta progettuale da SOAP. La strutturazione che è stata data ad ebxml è tale da renderne l'utilizzo adatto anche per gli scenari di cooperazione applicativa nella pubblica amministrazione, anche alla luce del fatto che ebxml fornisce un percorso di transizione dagli standard EDI verso XML. Alcuni tra i principi generali che guidano lo sviluppo di ebxml sono: permettere lo scambio di dati elettronici in modo semplice utilizzando le specifiche tecniche di XML; definire uno standard, evitando soluzioni proprietarie che costringano gli utenti di ebxml all'uso o al supporto di singoli prodotti software; supportare specifici segmenti economici verticali (finanza, telecomunicazioni, industria, commercio, pubblica amministrazione), con l obiettivo di minimizzare i costi delle transazioni elettroniche economiche o amministrative. Lo sviluppo dei documenti contenenti le specifiche di ebxml è portato avanti da diversi gruppi di lavoro, più precisamente il progetto e le specifiche sono suddivise nei seguenti gruppi: ebxml Requirements: requisiti generali che guidano l evoluzione di ebxml; Technical Architecture: architettura tecnica e normative di appoggio; Registry & Repository: specifica per l architettura ed il funzionamento dei servizi forniti dal registry/repository e relazioni con l iniziativa UDDI; Business Process Specification Schema: specifica per la redazione di un processo di business in XML; Collaboration-Protocol Profile and Agreement: specifica per la redazione di un accordo di cooperazione in XML e la relativa elaborazione; Message Service Specification: specifica di un formato XML per la strutturazione, il trasporto e instradamento dei messaggi. Basato su SOAP 1.1 with Attachments e MIME Protocol; Core components: specifiche relative all individuazione, all utilizzo e alla catalogazione di elementi riusabili da impiegare nella formalizzazione di processi di business. Le varie specifiche sono tra loro indipendenti, pertanto è possibile implementare/aderire solo ad una parte di esse. Tuttavia, considerate nel loro insieme, esse coprono tutti gli aspetti riguardanti la cooperazione di soggetti nella rete, cooperazione finalizzata allo scambio di informazioni principalmente, ma non limitatamente, ad un contesto di commercio elettronico. Di particolare interesse sono tre ambiti in cui le specifiche ebxml forniscono un approccio completo e innovativo. Essi sono: il livello di trasporto del messaggio, il supporto al registry e l utilizzo del processo di Business Process. 150

153 A livello di trasporto del messaggio, ebxml, con la specifica TRP (Transport Routing and Messaging), comprende il supporto dell'enveloping dei messaggi, con caratteristiche di sicurezza quali: identificazione, autenticazione, controllo di accesso, crittografia, controllo di integrità del messaggio, non ripudio e registrazione degli eventi (logging). ebxml consente il riutilizzo di protocolli esistenti: es MIME per l'aggregazione di più messaggi in uno, SMTP e FTP e HTTP per il trasporto vero e proprio. Lo scambio di messaggi si appoggia infatti alle specifiche SOAP 1.1 with attachments, opportunamente estese e generalizzate, nei modi appena esposti. L'instradamento dei messaggi viene gestito cosi' come le varie modalità di consegna: best effort, once and only once, messaggistica sincrona e asincrona, fire and forget, consegna multiparty. Ai fini della cooperazione applicativa nella pubblica amministrazione risulta di particolare interesse il supporto garantito da parte di ebxml per le strutture dette registry e repository, atte a mantenere le informazioni e i formati di scambio dati di ciascuna delle entità interessate a cooperare e comunicare. Viene qui riassunto un esempio di possibile funzionamento del registry/repository: nella figura è visibile la sequenza di operazioni eseguite da Company A e Company B, due entità che desiderano cooperare in uno scenario ebxml. Dapprima (fasi da 1 a 5) Company A pubblica, per mezzo del repository, le specifiche del suo servizio e i dettagli della sua implementazione a partire da un Business Process codificato dal legislatore o da associazioni di categoria (Industry nella figura). In seguito Company B, desiderosa di cooperare con Company A, ricava dal repository le informazioni di cui necessita e stipula con Company A un accordo di cooperazione TPA (Trading Partner Agreement) contenente i dettagli dell'interazione(fasi da 6 a 11). Le transazioni tra le due entità sono in seguito possibili autonomamente (fase 12). 151