Accountability nella cooperazione applicativa interregionale

Accountability nella cooperazione applicativa interregionale

Autore 1

Giulio Siccardi

Regione Liguria – Via Fieschi 15 – Genova

Autore 2

Mauro Giaccardi

Datasiel spa – Via Fieschi 17 - Genova [email protected] [email protected]

SOMMARIO

1. COME FA LA PA AD ESSERE LIBERA E CHE COSA SIGNIFICA CHE SIA LIBERA ? 1 1.1 DIRITTO ALL’ACCESSO E

RISERVATEZZA 1 1.2 DIRITTO DI INFORMAZIONE 2

2. ARCHITETTURA GENERALE E DOMINIO DI RIFERIMENTO 3 3. SPECIFICA DEI LIVELLI DI SERVIZIO (FASE DI PROGETTAZIONE) 4 4. SISTEMA DI TRACCIATURA (FASE DI RENDICONTAZIONE) 5 5. SPECIFICA DI MONITORAGGIO (FASE DI VALUTAZIONE) 5

1. Come fa la PA ad essere Libera e che cosa significa che sia Libera ?

L’attività della Pubblica Amministrazione è volta alla cura concreta degli interessi pubblici che sono individuati dal legislatore secondo le diverse fonti legislative (Costituzione, legislazione nazionale, regionale, …)

I fini dell’agere pubblico sono sempre e necessariamente predeterminati dalla legge e debbono essere perseguiti secondo canoni di doverosità e continuità. Ciò non significa che i contenuti dei provvedimenti e dell’attività amministrativa siano predeterminati dalla legge, rimane infatti un margine di autonomia decisionale (discrezionalità) nella scelta della soluzione migliore cioè nella valutazione imparziale degli interessi secondari in gioco al fine del miglior perseguimento dell’interesse pubblico primario nel rispetto del buon andamento cioè con il minore costo sociale (cioè sacrificando il meno possibile le posizioni giuridiche dei cittadini coinvolti nella fattispecie concreta).

La regole fondamentali sono:

• Trasparenza e pubblicità: rendere accessibili notizie e documenti circa l’operato della PA

• Economicità: riconducibile al principio di buona amministrazione (art. 97 Costituzione Repubblica Italiana ) indica il rapporto tra risorse impiegate e risultati ottenuti;

• Efficacia: riconducibile al principio di buona amministrazione (art. 97 Costituzione Repubblica Italiana ) indica il rapporto tra risultati ottenuti e obiettivi prestabiliti.

1.1 Diritto all’accesso e riservatezza

Il riconoscimento del diritto alla riservatezza come limite al diritto di accesso ?

Le leggi 241/1990, 15/2005 e 80/2005 introducono il principio del giusto procedimento che prevede:

l’obbligo della PA di comunicare agli interessati la notizia relativa all’avvio del procedimento, il diritto di questi ultimi a parteciparvi attivamente, la possibilità che l’amministrazione procedente concluda accordi con gli interessati al fine di determinare il contenuto del provvedimento ovvero in sostituzione di questo.

Occorre ammettere l’accesso ma con modalità ed accorgimenti tali da non frustrare l’esigenza di riservatezza. Per esempio è importante individuare a fronte di una richiesta di accesso eventuali controinteressati e comunicare agli stessi l’avvenuta

richiesta di accesso in modo che questi possano, eventualmente, presentare motivata opposizione alla richiesta di accesso.

Il d. lgs. 267/2000 (TUEL) allarga il diritto all’accesso stabilito dalle suddette leggi anticipando la conoscenza alla fase in cui le informazioni non sono ancora trasfuse in documenti ed estendendo i soggetti titolari del diritto di accesso a tutti i cittadini, singoli o associati, anche se non siano titolari di una posizione giuridica particolarmente qualificata ed agiscano senza ben identificate motivazioni.

1.2 Diritto di Informazione

Il comma 2 dell’art. 10 del d. lgs. 267/2000 (TUEL) prevede che la normativa regolamentare assicuri ai cittadini il diritto di accedere alle informazioni di cui è in possesso l’amministrazione locale

L’utilizzo della tecnologia declina il diritto all’accesso ed all’informazione nella PA mediante il superamento dei confini fisici e temporali degli sportelli.

In questo processo di innovazione della Pubblica Amministrazione governato tra l’altro dalle suddette disposizioni normative si inserisce il cambiamento di ruolo dei sistemi informativi all’interno della Pubblica Amministrazione che non servono più per

“autorizzare/controllare burocraticamente” la gestione delle risorse pubbliche ma debbono diventare la base di un nuovo modo di “rendere conto” alla comunità sul rispetto dei suddetti principi di pubblicità e trasparenza, economicità ed efficacia.

Sulla base di quanto sopra esposto è evidente che una Pubblica Amministrazione aperta e libera significa che la stessa PA si preoccupi di assicurare che l’erogazione di beni e/o servizi pubblici avvenga secondo modalità tali da assicurare l’individuazione delle connesse responsabilità, la trasparenza sulle risorse impiegate, il valore dei servizi prestati e la loro attitudine a soddisfare gli utenti.

La Pubblica Amministrazione deve fornire informazioni e motivazioni sulla propria attività e sui propri risultati a chiunque sia interessato anche in assenza di una specifica e formale relazione contrattuale.

Si è assistito ad una evoluzione del settore pubblico dai principi di “stewardship” alle diverse declinazioni di

“accountability”.

Tradizionalmente nel settore pubblico prevaleva l’idea di “stewardship” cioè la responsabilità della corretta gestione e conservazione di un bene altrui e l’idea di

“accountability” intesa come rispetto ed obbedienza alla norma, come trasparenza dei procedimenti e provvedimenti. Si parla oggi di accountability

“manageriale” cioè di responsabilizzare i manager della Pubblica Amministrazione sui risultati conseguiti e sulle risorse impiegate, di accountability “professionale” cioè di stimolo alla comunicazione dei risultati e delle risorse utilizzate in modo da coinvolgere gli interlocutori sia nella fase di pianificazione sia in quella di rilevazione e consuntivazione.

Il sussistere o meglio il tendere ad una situazione di accountability implica la realizzazione delle 4 fasi di quello che la letteratura definisce il “ciclo virtuoso” di accountability:

fase di programmazione: ove l’accountee (parte che ha delle attese verso l’altra) e l’accountor (parte che è tenuta a rendere conto di come risponde alle stesse) definiscono le attese del primo verso il secondo e l’oggetto del rendere conto

fase di attuazione: l’accountor implementa o non implementa quanto definito nella precedente fase fase di rendicontazione: ove l’accountor produce informazione accessibile e completa comunicandolo all’accountee

fase di valutazione: l’accountee valuta ed eventualmente sanziona l’attività e i risultati dell’accountor.

Regione Liguria da subito si è posta il problema di come tradurre l’accountability, di come dare trasparenza, di come contrattualizzare le responsabilità e soprattutto di quanto le procedure ed i sistemi informatici di ogni singolo ente producono attraverso rapporti di cooperazione applicativa.

Si è da subito ritenuto importante realizzare strumenti e supporti che consentissero a rendere aperta e libera la partecipazione alla cooperazione applicativa attraverso precise responsabilità.

Non è sufficiente cooperare occorre realizzare la leale collaborazione così come previsto dall’articolo 97 della Costituzione Italiana.

Il Progetto ICAR “Interoperabilità e Cooperazione Applicativa in rete tra le Regioni” si inquadra:

- nell’iniziativa “i2010 – Una società europea dell’informazione per la crescita e l’occupazione”

- nelle linee strategiche nazionali per lo sviluppo dell’e-government (Ministro Innovazione)

- nelle linee strategiche Cnipa 2008 - 2010 - nel Codice dell’Amministrazione Digitale (CAD) - nel Sistema Pubblico di Connettività (SPC)

- Il Sistema Pubblico di Cooperazione Applicativa (SPCoop)

ICAR è un progetto che definisce il modello e attiva l’infrastruttura di cooperazione applicativa fra le pubbliche amministrazioni secondo le specifiche SPCoop sperimentandola in 7 aree applicative (compensazione sanitaria, anagrafi,AOO, lavoro, bollo auto, carburanti, banche dati statistiche).

SPCoop e la Cooperazione Applicativa sono diventati lo snodo principale, in quanto tecnologia abilitante, dell’azione di semplificazione e ammodernamento della PA a tutti i livelli: le Regioni attraverso ICAR, concretizzano le linee strategiche nazionali, raccordando i diversi livelli della PA, esaltano la propria centralità amministrativa e permettono il dispiegamento su tutto il territorio di una potente azione innovativa.

Al progetto partecipano 16 Regioni (Valle d’Aosta, Piemonte, Liguria, Lombardia, Veneto, Friuli Venezia Giulia, Emilia-Romagna, Toscana, Marche, Umbria, Lazio, Abruzzo, Campania, Basilicata, Puglia e Sardegna) e 1 provincia Autonoma (Trento). Queste

Amministrazioni attraverso ICAR, oltre a dispiegare l’infrastruttura di base, affrontano e sperimentano i problemi di:

- Definizione del modello e dispiegamento di un sistema per la gestione dei livelli minimi garantiti di servizio (SLA) in logica di cooperazione applicativa

- Definizione del modello e dispiegamento di un sistema federato di identità digitale

- Definizione del modello e dispiegamento della semantica dei dati e dei servizi in cooperazione (annotazioni semantiche e ontologie di dominio).

Il progetto presenta una serie di elementi innovativi:

- La tecnologia: pochissime esperienze (in primis nella PA) di progetti con architetture orientate ai servizi (SOA);

- Gli standard: utilizzo intensivo di standard affermati ma poco utilizzati (XML, WSDL, SAML) e utilizzo di nuovi standard o in corso di standardizzazione (WS-Agreement, SAWSDL, WSBL, ecc.);

- Il modello open: documenti e moduli software tutti distribuiti in logica “pubblica” (open source, gnu, creative commons, ecc.);

- L’aggregazione proponente: 17 enti direttamente e indirettamente oltre 6000 enti;

- Il management: staff centrale di coordinamento dedicato.

In questo scenario si inquadra l’esperienza della Regione Liguria come capofila del Task INF-2

“Gestione Strumenti di SLA a livello interregionale” del progetto ICAR.

La misurazione della qualità del servizio è l’obiettivo principale dell’attività. Infatti, i livelli di qualità del servizio traducono le attese qualitative dei clienti in obiettivi quantitativi misurabili, utilizzabili per verificare i livelli di qualità pattuiti e dedurre un giudizio sull'andamento dei servizi.

INF-2 ha quindi definito i seguenti obiettivi principali :

− la definizione dei parametri “fondamentali” da utilizzare come indicatori nella dichiarazione della qualità del livello di servizio e la loro pubblicazione attraverso la predisposizione dell’accordo di servizio (fase di programmazione)

− integrazione con l’infrastruttura di cooperazione applicativa predisposta dal task INF-1 che realizza l’interscambio fra Enti (fase di attuazione)

− realizzazione di un sistema di tracciatura per ottenere dati completi e accessibili per la misura dei suddetti parametri, a partire dai

valori registrati durante l’esercizio del servizio stesso, la loro archiviazione e messa a disposizione (fase di rendicontazione)

− realizzazione di un sistema di monitoraggio volto alla correlazione fra i risultati attesi, e dichiarati in fase di programmazione, con i risultati effettivamente riscontrati sui singoli parametri di monitoraggio, al fine di consentire il monitoraggio degli SLA (Service Level Agreement) previsti (fase di valutazione).

La soluzione predisposta è costituita da componenti autonome, replicabili in più istanze sia per quello che riguarda la raccolta dei dati, sia per quello che riguarda la loro pubblicazione.

I risultati ottenuti consentono:

− alle amministrazioni regionali di:

• condividere i parametri da dichiarare per qualificare il livello di servizio di ogni singolo servizio

• erogare servizi in maniera consapevole, cioè potendone monitorare e controllare la qualità.

− a livello interregionale:

• il controllo della qualità dei servizi che cooperano a livello interregionale.

Sul piano tecnologico, la soluzione proposta garantisce piena autonomia alle singole amministrazioni per gli aspetti di configurazione, implementazione, gestione dei sistemi informativi locali utilizzando esclusivamente linguaggi, componenti ed infrastruttura open source.

2. Architettura generale e dominio di riferimento

I componenti architetturali di pertinenza del Task infrastrutturale INF-2 si articolano lungo tre linee di intervento: specifica dei livelli di servizio negli accordi di servizio, sistema di tracciatura e sistema di monitoraggio.

Le tre linee di intervento fanno riferimento alle suddette fasi di programmazione, rendicontazione e valutazione e si interfacciano con quanto progettato nel Task INF-1, che ha definito il complesso delle sue realizzazioni come NICA, “Nodo di Interconnessione per la Cooperazione Applicativa” e si può schematizzare l’architettura generale dell’intervento nel seguente modo.

La reference implementation prodotta come deliverable del progetto comprende esempi di tracciatura e monitoraggio di parametri SLA. Questi esempi, elaborati anche secondo le indicazioni raccolte in ambito progettuale, comprendono parametri derivanti da metriche di risorsa “di base”, utili cioè a fondare un sistema di gestione SLA semplice ma significativo ed in grado di evolvere verso forme di monitoraggio più sofisticate.

3. Specifica dei livelli di servizio (fase di progettazione)

La registrazione degli accordi di servizio avviene in modalità off-line, in modo unilaterale o dopo accordi tra soggetto erogatore e soggetto fruitore.

Il framework adottato nel progetto ICAR è WS- Agreement, ideato nell’ambito del OGF (Open Grid Forum). La parte specifica di ogni accordo di servizio riservata alla specifica SLA è occupata dalla struttura XML di un “/wsag:Agreement”, definita dal formalismo WS-Agreement.

Dopo il confronto con altri formalismi esistenti anche su architetture proprietarie, si è riscontrato, in accordo con CNIPA e con gli attori del progetto interregionale, che alcune caratteristiche di WS-Agreement ben si adattavano agli obiettivi progettuali e, attraverso una sua estensione custom, prevista dal framework, è stato definito un linguaggio attraverso il quale poter

dichiarare le metriche ed i parametri oggetto di monitoraggio.

La definizione di parametri SLA relativi ad un servizio applicativo avviene così a partire dall’individuazione di metriche di risorsa aventi attinenza col servizio applicativo medesimo e di algoritmi in grado di costruire, basandosi su tali metriche elementari, il valore complessivo del parametro e, di conseguenza, la rispondenza con quanto pattuito.

WS-Agreement prevede la negoziazione e la conclusione di accordi on-line. Una rilevante parte del formalismo XML proposto è dedicato alla definizione dell’elemento a struttura complessa

“AgreementTemplate”. I soggetti che intendono usufruire di un servizio valutano le caratteristiche offerte all’interno di tale struttura e, eventualmente, viene creato un elemento “Agreement” a immagine del template esaminato.

WS-Agreement non è solo una specifica di linguaggio XML, ma definisce anche protocolli, basati su interfacce astratte, per la creazione di accordi ed il monitoraggio degli stessi on-line.

In particolare WS-Agreement ben corrisponde al principio di adottare standard in un mondo aperto allo sviluppo e diffusione della conoscenza.

E’ stato necessario estendere il formalismo, sfruttando proprio i protocolli all’uopo destinati, per gestire il livello di complessità applicativa emersa dall’analisi condotta a livello interregionale.

Definito questo formalismo, la fase di attuazione prevede l’effettiva implementazione dei servizi applicativi di cooperazione fra gli Enti, attraverso

l’utilizzo dei framework previsti da SPCoop e messi a disposizione dal task INF-1.

4. Sistema di tracciatura (fase di rendicontazione) La realizzazione del repository delle tracciature applicative costituisce parte integrante della reference implementation. Individuata la natura dei dati oggetto di memorizzazione, sono state predisposte le componenti che consentono la registrazione delle metriche di risorsa dichiarate, all’interno dei parametri SLA oggetto degli accordi di servizio.

Le interfacce messe a disposizione dal sistema di tracciatura consentono la registrazione delle singole misure di ogni metrica di risorsa prevista nell’accordo di servizio, fornendo la chiave necessaria per l’univoca identificazione dell’episodio di cooperazione applicativa di riferimento e della misura medesima.

Il disegno del repository delle tracciature tiene conto di due esigenze primarie: l’individuazione dell’episodio di cooperazione applicativa cui si riferisce la misura da registrare e l’identificazione della misura medesima e contiene riferimenti a:

− accordo di servizio;

− fruitore ed erogatore del servizio;

− servizio;

− singola interazione fruitore-erogatore (per correlare metriche di risorsa diverse relative al medesimo episodio)

− misura di metrica di risorsa elementare

5. Specifica di monitoraggio (fase di valutazione)

Le informazioni raccolte nella di tracciatura degli episodi applicativi, vengono, in questa fase, correlati con i valori attesi e dichiarati negli accordi di servizio, ed in particolare nella sezione SLA di tali accordi.

Per giungere a tale correlazione, il sistema di monitoraggio, rispettando la specifica WS-Agreement, sistema permette di ricavare lo stato di un servizio relativo ad una coppia fruitore erogatore e di uno o più parametri SLA..

A tal fine il sistema è costituito da interfacce, esposte anche come repertorio di web services compatibili SPCoop, per il monitoraggio dei parametri SLA basati sulle tracciature depositate nel repository di cui sopra.

Per un efficace monitoraggio dell’efficienza dei servizi applicativi, si è inoltre provveduto a dotare il sistema di un’interfaccia operatore che consiste in una console distribuita che consente di attivare/disattivare il logging delle tracciature del singolo servizio applicativo, di visualizzare e correlare i risultati ottenuti con i livelli di servizio attesi per i singoli parametri oggetto di monitoraggio, relativamente ad una determinata finestra temporale.