La cooperazione applicativa come scelta strategica per le organizzazioni con finalità pubbliche

Transcript

1 MASTER IN INTEROPERABILITÀ PER LE PUBBLICHE AMMINISTRAZIONI E LE IMPRESE UNIVERSITÀ LA SAPIENZA APRILE 2011 La cooperazione applicativa come scelta strategica per le organizzazioni con finalità pubbliche Macro analisi dei benefici del cambiamento Stefano Pescosolido 27/04/2011 Organizzazioni che desiderano collaborare possono trarre vantaggio dalle opportunità offerte dall'interoperabilità dei sistemi informativi ed, in particolare, dalla cooperazione applicativa. Per le organizzazioni con finalità pubbliche, una simile collaborazione si traduce, di fatto, in vantaggi di tipo economico e sociale. Nella realtà italiana, la cooperazione applicativa non è ancora una capacità affermata in modo diffuso ed uniforme su tutte le pubbliche amministrazioni e le organizzazioni con esse cooperanti. In questo documento si presenta una mappa di tipo Business Dependency Network (BDN) ottenuta analizzando in modo strutturato, nel contesto di riferimento, le motivazioni che possono guidare all'introduzione di questa capacità, nonché le modalità con cui tale introduzione può avere luogo.

2 Indice dei contenuti Lista degli acronimi Introduzione Il concetto di beneficio e l approccio metodologico adottato per l analisi... 6 Modalità di specializzazione della macro-analisi ad un contesto più specifico L analisi dei benefici nel ciclo di vita dei servizi IT L innovazione oggetto dell analisi: la cooperazione applicativa Gli elementi costituenti SPCoop Il dominio applicativo e la Porta di Dominio L Accordo di Servizio L interazione con i SICA L ambito di focalizzazione dell analisi: le organizzazioni con finalità pubbliche Il risultato dell analisi Motivazioni guida Impulso dalla normativa europea ed italiana Affermazione criteri meritocratici nell e-government italiano Crescente richiesta di interoperabilità Affermazione paradigma SOA e Cloud Computing Crescente complessità dei sistemi Crescente responsabilizzazione sugli SLA Crescente richiesta di flessibilità e di efficienza Obiettivi (stato desiderato) Aderenza alla normativa di riferimento Incremento del numero dei servizi erogati in SPCoop Controllo sistematico dei livelli di servizio Disponibilità di linee guida aziendali per la Cooperaz. Applic Benefici attesi Riduzione dei rischi di non aderenza alla normativa Riduzione dei costi legati alla gestione delle procedure Incremento dei finanziamenti legati ai risparmi ottenuti Riduzione dei costi legati al non rispetto degli SLA Riduzione dei tempi di realizzazione di nuovi servizi Riduzione dei costi di gestione della piattaforma servizi

3 Iniziative richieste Predisposizione e registrazione di una PDD per ogni dominio applicativo Migrazione servizi esistenti in SPCoop (ADS + integr. PDD) Creazione di nuovi servizi in SPCoop (ADS + integr. PDD) Predisposizione per la misurazione dei livelli di servizio Adozione strutturata del processo di gestione dei benefici Redazione di regole tecniche aziendali su SOA ed SPCoop Formazione sviluppatori su SOA ed SPCoop Formazione sistemisti sulla gestione della PDD Fattori tecnologici abilitanti Disponibilità PDD certificate Disponibilità dei servizi SICA Ampia disponibilità di esempi e casi d'uso di SPCoop Ampia disponibilità di tecnologie e standard per le SOA Ostacoli noti Costi iniziali di implementazione e migrazione Esistenza di carenze nelle regole tecniche SPCoop Esistenza di standard SOA carenti o concorrenti Incertezze sul futuro dei servizi SICA Riferimenti bibliografici

4 Lista degli acronimi Si presenta di seguito l elenco degli acronimi utilizzati nel presente documento. Acronimo CAD SPC SPCoop SPConn SICA PDD ADS GFID G2G EIF ITIL CSI BDN SOA SLA KPI Significato Codice dell Amministrazione Digitale Sistema Pubblico di Connettività Sistema Pubblico di Connettività Cooperazione Applicativa Sistema Pubblico di Connettività Componente di connettività Servizi Infrastrutturali per la Cooperazione Applicativa Porta di Dominio Accordo di Servizio Gestione Federata delle Identità Digitali Government to government European Interoperability Framework IT Infrastructure Library Continual Service Improvement Benefit Dependency Network Service Oriented Architecture Service Level Agreement Key Performance Indicator 3

5 1. Introduzione Questo documento è stato redatto come lavoro di approfondimento degli argomenti trattati nel corso denominato Strumenti di supporto all interoperabilità e best practices tenuto dal Dott. Francesco Tortorelli e dal Dott. Michele Missikoff, parte del master in Interoperabilità per la pubblica amministrazione e le imprese organizzato dall università La Sapienza di Roma nell anno Il documento è finalizzato alla presentazione di una valutazione dei benefici che si possono ottenere tramite l introduzione della cooperazione applicativa quale asset portante nella strutturazione dei servizi offerti dalle organizzazioni operanti nel settore pubblico. Il lavoro è motivato dalla costatazione dell attuale livello di disomogeneità esistente, presso le pubbliche amministrazioni italiane e le aziende private con esse cooperanti, nel campo dell adozione dei processi e delle tecnologie finalizzate della cooperazione applicativa. Si è scelto, in particolare, di focalizzare quest analisi nell ambito delle organizzazioni con finalità pubbliche in quanto queste sono vincolate e, contemporaneamente, favorite dall esistenza di una normativa di riferimento che fornisce chiare indicazioni sulle modalità con cui mettere in atto la cooperazione applicativa. In questo documento, i contenuti sono organizzati come illustrato di seguito: Figura 1: struttura del presente documento In particolare: si descrive, inizialmente, il concetto di beneficio e l approccio metodologico adottato per impostare l analisi; 4

6 si riportano, quindi, le definizioni dei concetti di interoperabilità e cooperazione applicativa, in quanto innovazione oggetto dell analisi; si specifica, inoltre, il significato di questi termini rispetto alla normativa di riferimento; si definisce, quindi, lo scenario di applicazione dell analisi, al fine di evidenziarne le specificità che hanno impatto nella valutazione dei benefici; sono, infine, presentati i risultati dell analisi. L esposizione dei risultati dell analisi è organizzata per ambiti, in modo coerente con la scomposizione del ragionamento effettuata secondo l approccio metodologico adottato. 5

7 2. Il concetto di beneficio e l approccio metodologico adottato per l analisi Con il termine beneficio ci si riferisce a qualunque risultato positivo relativo ad aspetti economici o noneconomici ma comunque misurabile che ci si attende di ottenere a seguito dell adozione di un cambiamento. Come emerge dalla suddetta definizione, condizione necessaria affinché un beneficio possa essere ottenuto è l adozione di un cambiamento; quest ultimo genericamente consiste nell introduzione di nuovi servizi o nell adozione di una modalità differente di organizzare le attività per i servizi già esistenti. L innovazione è la tipologia di cambiamento che più frequentemente è in grado di generare benefici nell ambito dei servizi di Information Technology *di seguito IT +. L introduzione della cooperazione applicativa quale nuova capacità dei sistemi informativi di un organizzazione di esporre servizi alle organizzazioni cooperanti può essere classificata come cambiamento di tipo innovativo. Le organizzazioni adottano il processo di gestione dei benefici (benefit management) al fine di individuare e gestire i potenziali benefici derivanti dai possibili cambiamenti che possono essere apportati alle proprie modalità operative. Si tratta di un processo ciclico, che prevede una fase di individuazione dei benefici, una fase di pianificazione della modalità di realizzazione, una fase di messa in atto del piano ed una fase di misurazione dei risultati. Nella seguente figura si rappresenta il processo di gestione dei benefici nei suoi elementi essenziali. Figura 2: il processo di gestione dei benefici (benefit management) L attività di identificazione dei benefici o analisi dei benefici consiste nello studio delle motivazioni e delle conseguenze relative all adozione di un possibile cambiamento nel contesto di uno specifico scenario 6

8 di riferimento, finalizzata all individuazione dei possibili benefici derivanti, nonché delle condizioni affinché tali benefici possano essere effettivamente perseguiti. La metodologia di analisi dei benefici adottata in questo documento è ispirata al modello denominato Benefit Dependency Network *di seguito BDN +, sviluppato dalla Cranfield School of Management [rif. 1]. Si tratta di un modello adottato frequentemente dalle aziende e dalle società di consulenza [rif. 2] come strumento decisionale a supporto dell attività di identificazione dei benefici. Il modello di BDN consiste nella rappresentazione grafica, sotto forma di mappa, dei principali fattori che motivano e consentono il perseguimento di un beneficio, nonché delle relazioni che legano questi fattori. La seguente figura mostra un esempio di struttura per una generica BDN: Figura 3: la tipica struttura di una mappa BDN Gli elementi presenti in una mappa BDN sono classificati secondo le seguenti tipologie: Tipologia di elemento Drivers Investments Objectives Business Benefits Business Changes Enabling Changes IS/IT Enablers Significato Fattori guida, che stimolano la definizione di obiettivi legati al perseguimento di benefici. Obiettivi effettivamente perseguibili; possono essere definiti come lo stato desiderato. Benefici attesi da uno specifico cambiamento. Cambiamenti messi in atto per il perseguimento dei benefici desiderati. Progetti e programmi necessari per la messa in atto dei cambiamenti. Servizi e tecnologie abilitanti l esecuzione dei progetti e dei programmi. Come si nota, in una mappa BDN, sono messi in relazione: I contenuti del cambiamento proposto (per rispondere alla domanda sul cosa lo realizzi) 7

9 Le modalità di attuazione del cambiamento proposto (per rispondere alla domanda sul come si realizzi) I benefici attesi (per rispondere alla domanda sul quanto valgono) I motivi del cambiamento (per rispondere alla domanda perché lo si prende in considerazione) Una mappa di questo tipo può essere letta in due direzioni distinte, con finalità differenti: se letta da destra verso sinistra, la mappa consente di individuare i cambiamenti necessari al perseguimento degli obiettivi di riferimento; se letta da sinistra verso destra, consente di giustificare i cambiamenti rispetto agli obiettivi di riferimento. La seguente figura illustra graficamente quali informazioni possano essere ricavate da una mappa di tipo BDN. Figura 4: le informazioni ricavabili da una mappa di tipo BDN Tra le attività proprie della fase di analisi dei benefici, vi è anche l associazione di una probabilità e di un impatto per ciascuno dei benefici riportati nella mappa di tipo BDN. Questa classificazione consente di stabilire la priorità da dare a ciascun beneficio, ovvero alle iniziative che ne consentono il perseguimento. 8

10 Figura 5: la classificazione dei benefici in base alla priorità ed all'impatto L analisi condotta in questo documento è ispirata al suddetto modello BDN in quanto si propone di definire una rappresentazione grafica delle motivazioni e delle conseguenze legate nel caso specifico esaminato all adozione della cooperazione applicativa per le organizzazioni con finalità pubbliche. Si intende, tuttavia, enfatizzare la lettura della mappa in un solo senso, ovvero dagli elementi che descrivono il perché (cause del cambiamento) agli elementi che descrivono il cosa (contenuti tecnologici del cambiamento), attraverso gli elementi che descrivono il come (modalità di attuazione del cambiamento). Ciò detto, per rendere più intuitiva la lettura della mappa, si è deciso di invertirne il senso di rappresentazione mettendo a sinistra gli elementi che descrivono i perché ed a destra elementi che descrivono il cosa. Poiché, inoltre, non si considera il contesto reale di una specifica organizzazione, ma si ragiona tramite considerazioni generali sul contesto di una generica organizzazione appartenenti al settore pubblico, la mappa BDN qui rappresentata non include indicazioni quantitative sui benefici attesi dal cambiamento (ovvero, non consente di rispondere alla domanda sul quanto valgono i benefici attesi). Nella mappa descritta in questo documento, gli elementi rappresentati sono, quindi, classificati ed organizzati secondo le tipologie rappresentate nella seguente figura. 9

11 Figura 6: la struttura per la mappa BDN proposta in questo documento Il significato di queste tipologie di elementi è descritto nella seguente tabella: Tipologia di elemento Significato Motivazioni guida Asserzioni ed evidenze prodotte dall ambiente esterno o interno all organizzazione, che inducono a considerare l ipotesi di adottare il cambiamento oggetto dell analisi. Obiettivi perseguibili Finalità che l organizzazione può decidere di perseguire nel momento in cui si propone di adottare il cambiamento oggetto dell analisi. Possono essere considerati come rappresentazione dello stato finale che si desidera raggiungere con il cambiamento. Benefici attesi Vantaggi osservabili e misurabili quantitativamente, che sono attesi dal cambiamento oggetto dell analisi. Iniziative abilitanti Azioni di tipo organizzativo o tecnologico, necessarie per la messa in atto del cambiamento oggetto dell analisi. Fattori tecnologici abilitanti Elementi tecnologici che rendono possibile il cambiamento oggetto dell analisi. Ostacoli noti Possibili fattori ostacolanti l adozione del cambiamento oggetto dell analisi. Nella precedente figura, le frecce rappresentano il flusso logico del ragionamento legato all attività di valutazione strategica dei benefici del cambiamento. In particolare, le singole frecce hanno il seguente significato: Freccia Da Motivazioni guida ad Obiettivi perseguibili Da Obiettivi perseguibili a Benefici attesi Da Obiettivi perseguibili ad Iniziative abilitanti Da Fattori tecnologici abilitanti ad Iniziative abilitanti Da Ostacoli noti ad Significato Lo sforzo di definizione degli obiettivi perseguibili con il cambiamento oggetto dell analisi è solitamente giustificato e reso necessario dall evidenza delle motivazioni guida, ovvero dei fattori stimolanti. La definizione quantitativa dei benefici attesi segue la definizione qualitativa degli obiettivi da perseguire. Una volta definiti gli obiettivi, è possibile organizzare le azioni necessarie al raggiungimento degli stessi. Questa freccia è tratteggiata in quanto coerentemente con la struttura del modello BDN nella mappa presentata in questo documento, le relazioni tra i singoli obiettivi e le singole iniziative non sono esplicitate. L organizzazione delle iniziative necessarie al raggiungimento degli obiettivi non può prescindere dalla conoscenza degli aspetti tecnologici che possono avere impatto nella definizione delle iniziative stesse. L organizzazione delle iniziative necessarie al raggiungimento degli obiettivi 10

12 Iniziative abilitanti e viceversa Da Iniziative abilitanti a Benefici attesi non può prescindere dalla conoscenza degli ostacoli che possono avere impatto nell effettivo raggiungimento dei benefici attesi. Ogni singola azione può essere legata direttamente ad uno o più benefici. La seguente figura evidenzia le equivalenze e le differenze tra il modello di mappa presentato in questo documento ed il tradizionale modello di una mappa BDN: Figura 7: le differenze tra la struttura della mappa BDN presentata in questo documento ed una tradizionale mappa BDN La seguente tabella descrive le equivalenze tra le tipologie di elementi esistenti nella mappa presentata in questo documento e le tipologie di elementi in una tradizionale BDN: Tipologia di elementi nella mappa presentata in questo documento Motivazioni guida Obiettivi Benefici attesi Iniziative abilitanti Fattori tecnologici abilitanti Ostacoli noti Equivalente tipologia di elementi in una tradizionale mappa di tipo BDN Drivers Investments Objectives Benefits Business Changes + Enabling Changes IT/IS Enablers La seguente tabella, invece, sintetizza le differenze e le relative motivazioni: Differenza Orientamento opposto Accorpamento di Enabling Changes e Business Motivazione Come già spiegato, si ritiene logicamente più intuitivo disporre, da sinistra verso destra, le motivazioni del cambiamento e da destra verso sinistra gli elementi tecnologici e le azioni organizzative che consentono il raggiungimento dei benefici di interesse. Si è adottato quest accorpamento per semplificare la struttura complessiva della mappa. 11

13 Changes in Azioni necessarie Aggiunta della tipologia di elementi denominata Ostacoli Si ritiene utile mostrare, già nell attività di valutazione dei benefici, quali ostacoli occorre tenere in considerazione nel momento in cui si intende mettere in campo specifiche iniziative. Modalità di specializzazione della macro-analisi ad un contesto più specifico La mappa proposta in questo documento si propone di fornire una valutazione strategica dell adozione della cooperazione applicativa per le organizzazioni con finalità pubbliche, organizzata classificando gli elementi rilevanti secondo la metodologia appena descritta. Tale mappa è prodotta a seguito di un attività di macro-analisi, ovvero di un attività di analisi di tipo macroscopico, in quanto, anziché essere applicata al contesto di una singola specifica organizzazione o ancor più nel dettaglio di uno specifico servizio, è focalizzata su una generica organizzazione di un intero settore economico (nel caso specifico, il settore delle organizzazioni che operano con finalità pubbliche). Figura 8: livello di dettaglio di una mappa BDN Una simile analisi macroscopica si candida, quindi, per essere il punto di partenza di una valutazione strategica più rigorosa e dettagliata circa la possibile adozione di un cambiamento nel contesto di una particolare organizzazione o all interno di un organizzazione nel contesto di uno specifico servizio. Una BDN dettagliata è uno strumento decisionale valido non solo per verificare la coerenza di un iniziativa di cambiamento (programma o progetto) rispetto agli obiettivi aziendali, ma anche per organizzare efficacemente la pianificazione del cambiamento (project/program management), in modo da perseguire prima i benefici più rilevanti (quick wins). I risultati di un analisi strategica sui benefici di un cambiamento sono fortemente legati oltre che all ampiezza dell ambito di focalizzazione (così come appena chiarito) anche alle condizioni tecnologiche ed organizzative esistenti al momento dell esecuzione dell analisi stessa; in particolare, i fattori guida, le tecnologie abilitanti e gli ostacoli possono mutare nel tempo, sia nel numero che nel relativo impatto. La valutazione dei benefici oggetto di questo documento, se ripetuta nel tempo e/o su un ambito di focalizzazione più specifico (un organizzazione o un servizio), può, quindi, fornire risultati diversi da quelli esposti in questo documento. 12

14 La seguente figura rappresenta la modalità di utilizzo di una macro-bdn (prodotta, in un determinato istante, analizzando i benefici di un innovazione per una generica azienda di un determinato settore economico), come punto di partenza per una successiva analisi focalizzata su una singola organizzazione o su un singolo servizio. Figura 9: specializzazione di una mappa BDN di tipo macroscopico, al momento dell'applicazione ad un caso specifico Per quanto appena chiarito, la macro-bdn presentata in questo documento può essere utilizzata come punto di partenza per eseguire un analisi più dettagliata dei benefici derivanti dall adozione strutturata della cooperazione applicativa in una singola specifica organizzazione con finalità pubbliche. L analisi dei benefici nel ciclo di vita dei servizi IT Come appena evidenziato, l ambito di focalizzazione di una BDN può essere anche solo un singolo servizio IT per il quale si sta valutando l opportunità di introdurre un cambiamento. Ad esempio, una pubblica amministrazione già dotata di un infrastruttura e delle metodologie necessarie per la cooperazione applicativa potrebbe realizzare una BDN come strumento decisionale per valutare l impatto della pubblicazione delle ontologie relative ad uno o più servizi applicativi esposti in SPCoop. Nella letteratura di IT Infrastructure Library (versione 3) *di seguito ITILv3 o, più semplicemente, ITIL rif. 3+, il ciclo di vita dei servizi IT erogati da un organizzazione è presentato secondo un modello ciclico che comprende di più fasi e per ciascuna di esse più processi. 13

15 Figura 10: le fasi ed i processi per la gestione del ciclo di vita dei servizi IT (da ITIL v3) In particolare, nella fase di Continual Service Improvement *di seguito CSI +, è previsto che l organizzazione di riferimento proceda a definire la visione per il cambiamento, secondo il modello illustrato nella seguente figura. Figura 11: modello per la fase di CSI È evidente come le stesse domande presenti nel diagramma rappresentato nella precedente figura possano essere la base di partenza per l impostazione di una mappa di tipo BDN. Nella fase di Service Strategy, inoltre, sono gestiti i processi di: 14

16 gestione della domanda (demand management) gestione finanziaria (financial management) Le attività previste in questi processi sono tali da consentire la verifica della sostenibilità di un piano di innovazione rispetto alla previsione della domanda ed al relativo profilo finanziario. Anche queste attività possono avere impatto nella redazione di una mappa BDN, come momento per la rigorosa valutazione numerica dei benefici attesi da riportare nella mappa. Nella seguente figura sono evidenziati gli input per la redazione di una BDN, ricevuti dalle attività eseguite nel contesto delle fasi CSI e Service Strategy. Figura 12: Redazione di una BDN rispetto alle fasi dell'it Service Management (da ITIL v3) La valutazione dei risultati proposti in una BDN consente di prendere decisioni circa l opportunità di proseguire o meno nell intento dell adozione del cambiamento (valutazioni di tipo go/no-go ). 15

17 3. L innovazione oggetto dell analisi: la cooperazione applicativa La cooperazione applicativa consiste nella capacità di applicazioni differenti ed eterogenee, appartenenti ad organizzazioni differenti ed in generale indipendenti, di scambiarsi dati, nel contesto di processi applicativi coordinati, in base alle esigenze proprie dei servizi offerti dalle applicazioni stesse. La cooperazione applicativa riguarda un aspetto particolare della problematica più generale dell interoperabilità dei sistemi informativi. In particolare, una valida definizione di quest ultima capacità è riportata nello European Interoperability Framework *di seguito EIF +: Da Towards interoperability for European public services - Annex 2 EIF [rif. 4]: L interoperabilità, nell ambito dell erogazione di servizi pubblici europei, è l abilità di organizzazioni diverse ed eterogenee di interagire per perseguire obiettivi comuni, condivisi e benefici per entrambe, e riguarda la condivisione delle informazioni tra le organizzazioni, nei processi di business supportati e per mezzo dello scambio di dati tra i loro sistemi ICT. Nello stesso EIF si specifica che il concetto di interoperabilità è applicabile a diversi livelli ; in particolare, una volta definito il contesto politico e normativo di riferimento (come nel caso dell analisi presentata in questo documento), il concetto di livelli di interoperabilità introdotto dall EIF suggerisce di considerare le dimensioni tecnologica, semantica ed organizzativa anche nel momento in cui si considera la problematica dell introduzione della cooperazione applicativa come asset portante nella strutturazione dei servizi offerti da un organizzazione. Per le organizzazioni italiane con finalità pubbliche a cui si applica il Codice dell Amministrazione Digitale [di seguito CAD +, il concetto di cooperazione applicativa viene definito nei termini seguenti: Dal CAD Art. 72; punto E [rif. 5]: «cooperazione applicativa»: la parte del sistema pubblico di connettività finalizzata all'interazione tra i sistemi informatici delle pubbliche amministrazioni per garantire l'integrazione dei metadati, delle informazioni e dei procedimenti amministrativi. Come si nota, tale definizione fa esplicito riferimento al Sistema Pubblico di Connettività [di seguito SPC ], la cui definizione è riportata, nello stesso CAD, nei seguenti termini: Dal CAD Art. 73; comma 2 [rif. 5]: Il SPC è l'insieme di infrastrutture tecnologiche e di regole tecniche, per lo sviluppo, la condivisione, l'integrazione e la diffusione del patrimonio informativo e dei dati della pubblica amministrazione, necessarie per assicurare l'interoperabilità di base ed evoluta e la cooperazione applicativa dei sistemi informatici e dei flussi informativi, garantendo la sicurezza, la riservatezza delle informazioni, nonché la salvaguardia e l'autonomia del patrimonio informativo di ciascuna pubblica amministrazione. In particolare, la componente di cooperazione applicativa di SPC è spesso riferita con l acronimo SPCoop ; viceversa, la componente di SPC relativa alla connettività tra le amministrazioni pubbliche è spesso riferita con l acronimo SPConn. Nelle regole tecniche che descrivono il SPC, è previsto che la componente di 16

18 SPCoop integrata nei servizi applicativi delle singole amministrazioni si avvalga di servizi offerti centralmente dalla componente denominata Servizi Infrastrutturali di Cooperazione Applicativa *di seguito SICA +. La seguente figura mostra gli elementi costituenti il SPC [rif. 7]: Figura 13: la struttura di SPC Per organizzazioni con finalità pubbliche, quindi, la cooperazione applicativa consiste nella capacità del proprio sistema informativo di consentire interazioni di tipo government to government *di seguito G2G +. Nel seguente paragrafo si descrivono gli elementi fondamentali di SPConn, tratti dalle regole tecniche referenziate dalla normativa di riferimento. Gli elementi costituenti SPCoop Il dominio applicativo e la Porta di Dominio Il concetto di dominio applicativo e di Porta di Dominio *di seguito PDD o PdD + è definito nelle Regole tecniche e di sicurezza per il funzionamento del SPC contenute nel Decreto del Presidente del Consiglio dei Ministri del 1 aprile 2008: Dal DPCM 1 aprile 2008 Art. 1 [rif. 6]: «dominio applicativo»: l'insieme dei servizi applicativi erogati sotto la diretta responsabilità di un'amministrazione; «porta di dominio»: unico componente architetturale del SPC attraverso il quale si accede al dominio applicativo dell'amministrazione per l'utilizzo dei servizi applicativi. 17

19 Si riporta di seguito una definizione più ampia della funzione della PDD, tratta da uno dei documenti pubblicati dal progetto ICAR. Nell estratto si definiscono anche i concetti di porta delegata e porta applicativa. Da ICAR-TaskINF1-Specifiche_tecniche_interfaccia [rif. 8]: Nella specifica SPCoop, un dominio è definito come il confine di responsabilità di un ente o soggetto amministrativo e racchiude al suo interno tutte le applicazioni da esso gestite. Il confine applicativo del Dominio è rappresentato dalla Porta di Dominio (PdD), attraverso la quale devono transitare tutte le comunicazioni da e verso il dominio. Le Porte di Dominio si parlano tra di loro scambiandosi richieste e risposte in un formato parte della specifica SPCoop, denominato busta egov. Tuttavia il formato della busta non è parlato nativamente dalle applicazioni, pertanto la Porta di Dominio deve anche occuparsi di convertire le richieste applicative nel formato busta egov. Facendo riferimento a questa problematica, i compiti della Porta di Dominio vengono solitamente classificati in due componenti: il componente di cooperazione, che riguarda la comunicazione tra le Porte di Dominio e quello di integrazione, che riguarda la comunicazione tra i Servizi Applicativi dell Ente e la Porta di Dominio. Il componente di integrazione si differenzia a sua volta in due diversi moduli: la porta delegata e la porta applicativa. In particolare la porta delegata è utilizzata come proxy per l accesso al servizio destinazione, mentre la porta applicativa deve essere in grado di gestire la consegna dei contenuti delle buste egov ricevute al corrispondente servizio applicativo interno al dominio destinazione. La seguente figura, tratta dalle regole tecniche relative ad SPC, mostra il ruolo di proxy applicativo svolto dalle PDD [rif. 9]. Figura 14: il ruolo di proxy applicativo delle PDD L Accordo di Servizio Il concetto di Accordo di Servizio *di seguito ADS o AdS + è definito nelle Regole tecniche e di sicurezza per il funzionamento del SPC contenute nel Decreto del Presidente del Consiglio dei Ministri del 1 aprile 2008: Dal DPCM 1 aprile 2008 Art. 1 [rif. 6] «accordo di servizio»: la convenzione tra erogatore e fruitore del servizio applicativo, redatta in formato XML e resa pubblica attraverso le infrastrutture condivise del SPC, che descrive l'oggetto del servizio e le relative modalità di erogazione e fruizione; 18

20 Una descrizione dettagliata dei contenuti e della struttura richiesta per gli ADS è stata pubblicata dal CNIPA nei documenti che forniscono le specifiche ed i requisiti funzionali di SPCoop. Si riporta di seguito una valida sintesi tratta dalla documentazione pubblicata dal progetto ICAR: Da ICAR - Task Ap4 - specificaadsv1.3 [rif. 8] Un ADS è composto da: una Parte Comune che formalizza gli aspetti riusabili in differenti contesti una Parte Specifica che completa la parte comune, aggiungendo le informazioni specifiche per una particolare coppia di erogatore-fruitore. La Parte Comune di un ADS è composta da: Specifica delle Interfacce: descrive l interfaccia del servizio a livello di scenario di coordinamento e di scambio elementare di messaggi del fruitore e dell erogatore: wsdl concettuale wsdl logico fruitore (da includere sempre anche se vuoto) wsdl logico erogatore; Specifica delle Conversazioni: (opzionale) quando necessaria, descrive le conversazioni supportate dal servizio (sequenza si scambi che il servizio supporta). Viene rappresentata con il WSBL (Web Service Beahviour Language) e consiste in: wsbl concettuale wsbl logico fruitore un wsbl logico erogatore; Riferimento alla semantica: (opzionale) contiene un riferimento all ontologia/schema concettuale (o porzioni di essa) che definisce la semantica dell informazione veicolata dal servizio. La descrizione della semantica viene solo riferita nell ADS e lasciata come elemento esterno. La Parte Specifica di un ADS contiene: Specifica dei Porti di Accesso: descrive gli aspetti implementativi (livello fisico) dei Web Service dell erogatore e fruitore, ovvero l URI dei punti d accesso ed i binding (basati sulla Busta egov) delle varie operazioni. Specifica dei Livelli di Servizio: (opzionale) descrive gli elementi necessari per poter definire i livelli di servizio concordati tra erogatore e fruitore, ed il modo di valutarli e misurarli. Specifica delle Caratteristiche di Sicurezza: (opzionale) descrive le caratteristiche di sicurezza supportate e richieste dal servizio. La seguente figura, tratta dal materiale delle lezioni del Master [Rif. 7], dà una rappresentazione chiara dei contenuti di un ADS. 19

21 Figura 15: la struttura degli ADS Si evidenzia che, al fine di definire i contenuti di un ADS, è opportuno avere chiari i concetti relativi alle seguenti classificazioni: Modalità di scambio dei messaggi. Scenario di coordinamento. Classi di servizio Anche per questi concetti, si riporta la definizione sintetica presente nella documentazione pubblicata dal progetto ICAR: Da ICAR - Task Ap4 - specificaadsv1.3 [rif. 8] La modalità in cui erogatore e fruitore interagiscono è tramite scambio di messaggi. Ne esistono di tre tipi: messaggio senza replica: un sistema mittente invia un messaggio a un sistema destinatario; messaggio/replica sincroni: un sistema richiedente trasmette un messaggio sincrono a un sistema rispondente e si mette in attesa della replica sincrona. Successivamente il rispondente trasmette una replica sincrona al richiedente correlata logicamente con il messaggio; messaggio/replica asincroni: un sistema richiedente trasmette un messaggio asincrono a un sistema rispondente. Il rispondente trasmette in seguito una replica asincrona al richiedente correlata logicamente con il messaggio ricevuto. La correlazione a livello logico tra messaggio e replica asincroni è rappresentata esplicitamente dall inserzione nella replica di un identificatore di correlazione. Lo scambio elementare di messaggi è utilizzato per definire gli scenari di coordinamento. Sono previsti alcuni tipi di scenari elementari di coordinamento dell erogazione/fruizione del servizio: 20

22 Richiesta senza risposta: viene implementato utilizzando il messaggio senza replica. Richiesta/risposta: dal punto di vista del fruitore è possibile avere: o Richiesta/risposta sincrona: utilizza uno scambio elementare di tipo messaggio/replica sincroni. o Richiesta/risposta asincrone: utilizza lo scambio elementare di tipo messaggio/replica asincroni. L identificatore di correlazione messaggio/replica può essere utilizzato come identificatore di correlazione richiesta/risposta. Notificazione senza risposta: utilizza uno scambio elementare di tipo messaggio senza replica. Notificazione/risposta: utilizza lo scambio elementare messaggio/replica sincrono o asincrono. I servizi disponibili su SPCoop si distinguono in 4 classi. Servizi mono-erogatore/mono-fruitore: il servizio è erogato da un solo sistema erogatore e destinato alla fruizione di un unico sistema fruitore. Servizi mono-erogatore/multi-fruitore: il servizio è erogato da un solo sistema erogatore e destinato alla fruizione di M fruitori Servizi multi-erogatore/mono-fruitore: il servizio è erogato da un insieme di N sistemi erogatori e destinato alla fruizione di un unico sistema fruitore. Servizi multi-erogatore/multi-fruitore: il servizio è erogato da un insieme di N sistemi erogatori e destinato alla fruizione di M fruitori. Si specifica, infine, che la documentazione di riferimento per gli ADS prodotta dal CNIPA non include una definizione formale e definitiva circa la struttura fisica di un ADS. Anche in questo caso, a titolo esemplificativo, si presenta la scelta fatta nel contesto del progetto ICAR. Da ICAR - Task Ap4 - specificaadsv1.3 [rif. 8] Nell impacchettamento dei file componenti l ADS, abbiamo ipotizzato e utilizzato, non essendoci ancora una specifica ufficiale in merito, la struttura che segue (per la parte Specifica è analoga). Figura 16: la struttura fisica degli ADS del progetto ICAR L interazione con i SICA I SICA mettono a disposizione servizi centralizzati, fondamentali per consentire la cooperazione applicativa tra le amministrazioni pubbliche. La seguente figura, tratta dalle regole tecniche di SPC, mostra la struttura dei SICA [rif. 9]: 21

23 Figura 17: la struttura dei SICA Come mostrato in figura, l infrastruttura dei SICA è a sua volta dotata di una PDD (colonna di destra) nonché di servizi di monitoraggio, gestione e controllo della sicurezza (colonna di sinistra). Nella parte centrale della figura sono riportati i servizi effettivamente erogati dai SICA alle amministrazioni pubbliche. Tali servizi sono raggruppati per ambito nella seguente tabella: Ambito Nome del servizio Registri Servizio di registro dei SICA generale Anagrafe delle amministrazioni e dei punti di accesso telematici; gazzetta degli ADS Servizio di indice dei soggetti Anagrafe dei dipendenti Servizio di catalogo degli schemi e delle ontologie Enciclopedia delle informazioni trattate e scambiate Sicurezza Servizio di certificazione Rilascio di certificati digitali e delle relative liste di revoca Servizio di Gestione Federata delle Identità Digitali *di seguito GFID + Strutture funzionali per l autenticazione federata, basati sullo standard SAML Qualificazione Servizio di qualificazione PDD Prove di conformità ed interoperabilità per le PDD Servizio di qualificazione SICA secondari Prove di conformità ed interoperabilità per i SICA secondari 22

24 4. L ambito di focalizzazione dell analisi: le organizzazioni con finalità pubbliche In generale, l analisi dei benefici legati all introduzione di un servizio o di una capacità di business porta a considerare assunti diversi e ad articolare ragionamenti diversi a seconda dell ambito specifico di applicazione dell analisi stessa. Ad esempio, è evidente che l adozione della cooperazione applicativa per il Sistema Sanitario Nazionale persegue obiettivi diversi ed attende benefici generalmente diversi rispetto a quelli legati all adozione della stessa nel contesto di aziende manifatturiere. È importante, quindi, focalizzare l ambito di analisi dei benefici, definendo il contesto di riferimento. L analisi a cui si fa riferimento in questo documento riguarda le organizzazioni operati con finalità pubbliche. Si considerano, in particolare, tutte le organizzazioni a cui è applicabile il CAD e che possono usufruire del SPC; tale ambito di applicazione è specificato come segue nello stesso CAD: Dal CAD Art. 2; comma 2 [rif. 5] Le disposizioni del presente codice si applicano alle pubbliche amministrazioni di cui all articolo 1, comma 2, del decreto legislativo 30 marzo 2001, n. 165, nel rispetto del riparto di competenza di cui all articolo 117 della Costituzione, nonché alle società, interamente partecipate da enti pubblici o con prevalente capitale pubblico inserite nel conto economico consolidato della pubblica amministrazione, come individuate dall Istituto nazionale di statistica (ISTAT) ai sensi dell articolo 1, comma 5, della legge 30 dicembre 2004, n Dal CAD Art. 75 [rif. 5] 1. Al SPC partecipano tutte le amministrazioni di cui all'articolo 2, comma Il comma 1 non si applica alle amministrazioni di cui al decreto legislativo 30 marzo 2001, n.165, limitatamente all'esercizio delle sole funzioni di ordine e sicurezza pubblica, difesa nazionale, consultazioni elettorali. 3. Ai sensi dell'articolo 3 del decreto del Presidente della Repubblica 11 novembre 1994, n. 680, nonché dell'articolo 25 del decreto legislativo 30 giugno 2003, n. 196, è comunque garantita la connessione con il SPC dei sistemi informativi degli organismi competenti per l'esercizio delle funzioni di sicurezza e difesa nazionale, nel loro esclusivo interesse e secondo regole tecniche che assicurino riservatezza e sicurezza. È altresì garantita la possibilità di connessione al SPC delle autorità amministrative indipendenti. 3-bis. Il gestore di servizi pubblici e i soggetti che perseguono finalità di pubblico interesse possono usufruire della connessione al SPC e dei relativi servizi, adeguandosi alle vigenti regole tecniche, previa delibera della Commissione di cui all articolo 79. Poiché si tratta di un ambito di applicazione che, per quanto sia specifico, è pur sempre molto ampio, le indicazioni che si possono trarre dall analisi sono alquanto generiche. Ciò nonostante, i risultati di seguito presentati e l approccio metodologico utilizzato possono essere ulteriormente specializzati per contestualizzare l analisi dei benefici in un settore specifico o, addirittura, per una specifica organizzazione. 23

25 5. Il risultato dell analisi La seguente figura rappresenta la mappa di valutazione strategica dei benefici attesi dall introduzione della cooperazione applicativa nel contesto delle organizzazioni con finalità pubbliche che non si sono ancora dotate in modo strutturato di una simile capacità tecnologica. Figura 18: la mappa di tipo BDN risultante dalla macro-analisi Trattandosi del risultato di un analisi macroscopica in quanto applicata su una generica organizzazione di un settore economico non è possibile dare un valore quantitativo ai singoli benefici elencati nella mappa. Ciò nonostante; si è fatto attenzione a riportare come benefici solo elementi quantificabili, ovvero solo elementi per i quali sia possibile assegnare un valore numerico nel momento in cui si intenda specializzare la mappa focalizzando l analisi nel contesto di una specifica organizzazione. Nei seguenti paragrafi si descrivono i singoli elementi presenti nella mappa. In particolare, per ogni elemento, si riporta una tabella contenente le informazioni strutturate così come descritto di qui di seguito. Relazioni Si fornisce una descrizione sommaria dell elemento. Si riporta un estratto della mappa in grado di evidenziare, per l elemento considerato, le sue relazioni con gli altri elementi della mappa. 24

26 Per i benefici, inoltre, la suddetta tabella è estesa per consentire l esposizione di una prima valutazione di impatto e probabilità legate al beneficio stesso. Motivazioni guida In questo paragrafo si descrivono le asserzioni e le evidenze che una generica organizzazione italiana con finalità pubbliche può recepire dall ambiente in cui opera (fattori esterni ) o dalle strutture interne all organizzazione stessa (fattori interni ), tali da indurre a valutare l adozione della cooperazione applicativa come cambiamento capace di produrre benefici. Impulso dalla normativa europea ed italiana Nella Comunità Europa è in atto un forte impulso politico e normativo al potenziamento della capacità di interoperabilità da parte delle pubbliche amministrazioni operanti nei paesi membri. Per la Comunità Europea, questo impulso è realizzato tramite: la pubblicazione di linee guida e di direttive applicabili ai paesi membri; l erogazione di fondi atti a sostenere finanziariamente le attività progettuali che prevedono interventi coerenti con le suddette linee guida. In Italia, il CAD [rif. 5] in quanto normativa di riferimento e guida per l evoluzione informatica delle pubbliche amministrazioni vincola le organizzazioni operanti con finalità pubbliche all adozione del SPC per la connettività e la cooperazione applicativa. In particolare, l Art. 75 del CAD già riportato integralmente in questo documento nel par. 4 stabilisce quanto sintetizzato nella seguente tabella: Soggetto Pubbliche amministrazioni Società, interamente partecipate da enti pubblici o con prevalente capitale pubblico inserite nel conto economico consolidato della pubblica amministrazione Organismi competenti per l'esercizio delle funzioni di sicurezza e difesa nazionale Autorità amministrative indipendenti Gestore di servizi pubblici e i soggetti che perseguono finalità di pubblico interesse Obbligo/Opportunità Obbligo di partecipare al SPC. [Art. 75 Comma 1] È loro garantita la possibilità di connessione al SPC. [Art. 75 Comma 3] Possono partecipare al SPC [Art. 75 Comma 4] Si riportano di seguito alcune affermazioni estratte dal CAD che chiariscono precetti ed opportunità relativi alla cooperazione applicativa; in particolare, si evidenziano le sentenze di maggiore interesse nel contesto di quanto si sta affermando in questo documento. Dal CAD Art. 17; comma 1 [rif. 5] 25

27 1. Le pubbliche amministrazioni centrali garantiscono l'attuazione delle linee strategiche per la riorganizzazione e digitalizzazione dell'amministrazione definite dal Governo. A tale fine, le predette amministrazioni individuano un unico ufficio dirigenziale generale, fermo restando il numero complessivo di tali Uffici, responsabile del coordinamento funzionale. Al predetto Ufficio afferiscono i compiti relativi a: h) progettazione e coordinamento delle iniziative rilevanti ai fini di una più efficace erogazione di servizi in rete a cittadini e imprese mediante gli strumenti della cooperazione applicativa tra pubbliche amministrazioni, ivi inclusa la predisposizione e l'attuazione di accordi di servizio tra amministrazioni per la realizzazione e compartecipazione dei sistemi informativi cooperativi; Dal CAD Art. 41; comma 2-bis [rif. 5] 2-bis. Il fascicolo informatico è realizzato garantendo la possibilità di essere direttamente consultato ed alimentato da tutte le amministrazioni coinvolte nel procedimento. Le regole per la costituzione, l identificazione e l'utilizzo del fascicolo sono conformi ai principi di una corretta gestione documentale ed alla disciplina della formazione, gestione, conservazione e trasmissione del documento informatico, ivi comprese le regole concernenti il protocollo informatico ed il sistema pubblico di connettività, e comunque rispettano i criteri dell'interoperabilità e della cooperazione applicativa; regole tecniche specifiche possono essere dettate ai sensi dell'articolo 71, di concerto con il Ministro della funzione pubblica. Dal CAD Art. 47; comma 1 [rif. 5] 1. Le comunicazioni di documenti tra le pubbliche amministrazioni avvengono mediante l'utilizzo della posta elettronica o in cooperazione applicativa; esse sono valide ai fini del procedimento amministrativo una volta che ne sia verificata la provenienza. [CAD Art. 68; comma 2] 2. Le pubbliche amministrazioni nella predisposizione o nell'acquisizione dei programmi informatici, adottano soluzioni informatiche, quando possibile modulari, basate sui sistemi funzionali resi noti ai sensi dell articolo 70, che assicurino l interoperabilità e la cooperazione applicativa e consentano la rappresentazione dei dati e documenti in più formati, di cui almeno uno di tipo aperto, salvo che ricorrano motivate ed eccezionali esigenze. Dal CAD Art. 76; comma 2 [rif. 5] 1. Gli scambi di documenti informatici tra le pubbliche amministrazioni nell'ambito del SPC, realizzati attraverso la cooperazione applicativa e nel rispetto delle relative procedure e regole tecniche di sicurezza, costituiscono invio documentale valido ad ogni effetto di legge. Dal CAD Art. 78; comma 1 [rif. 5] 1. Le pubbliche amministrazioni nell'ambito della loro autonomia funzionale e gestionale adottano nella progettazione e gestione dei propri sistemi informativi, ivi inclusi gli aspetti organizzativi, soluzioni tecniche compatibili con la cooperazione applicativa con le altre pubbliche amministrazioni, secondo le regole tecniche di cui all articolo 73, comma 3-bis. Le stesse pubbliche amministrazioni, ove venga loro attribuito, per norma, il compito di gestire soluzioni infrastrutturali per l erogazione di servizi comuni a più amministrazioni, 26

28 adottano le medesime regole per garantire la compatibilità con la cooperazione applicativa potendosi avvalere di modalità atte a mantenere distinti gli ambiti di competenza. Relazioni In estrema sintesi, secondo la normativa, la cooperazione applicativa: deve essere perseguita definendo un ufficio che ne sia responsabile; consente scambio di documenti informatici valido agli effetti di legge; deve essere adottata per l accesso al fascicolo informatico; deve essere perseguita realizzando o acquistando sistemi capaci di garantire il rispetto delle relative regole tecniche Figura 19: motivazione Impulso dalla normativa europea ed italiana Affermazione criteri meritocratici nell e-government italiano Nell art. 15 del CAD è stato esplicitamente introdotto un criterio meritocratico per premiare le amministrazioni pubbliche più virtuose nell adozione delle linee guida di riferimento e nella capacità di trarne risparmi. Si riporta di seguito il contenuto di quest articolo, evidenziandone le sentenze di maggiore interesse nel contesto di quanto si sta affermando in questo documento. Dal CAD Art Digitalizzazione e riorganizzazione [rif. 5] 1. La riorganizzazione strutturale e gestionale delle pubbliche amministrazioni volta al perseguimento degli obiettivi di cui all'articolo 12, comma 1, avviene anche attraverso il migliore e più esteso utilizzo delle tecnologie dell'informazione e della comunicazione nell'àmbito di una coordinata strategia che garantisca il coerente sviluppo del processo di digitalizzazione. 2. In attuazione del comma 1, le pubbliche amministrazioni provvedono in particolare a razionalizzare e semplificare i procedimenti amministrativi, le attività gestionali, i documenti, la modulistica, le modalità di accesso e di presentazione delle istanze da parte dei cittadini e delle imprese, assicurando che l'utilizzo delle tecnologie dell'informazione e della comunicazione avvenga in conformità alle prescrizioni tecnologiche definite nelle regole tecniche di cui all'articolo bis. Le Pubbliche amministrazioni nella valutazione dei progetti di investimento in materia di innovazione tecnologica tengono conto degli effettivi risparmi derivanti dalla 27

29 razionalizzazione di cui al comma 2, nonché dei costi e delle economie che ne derivano. 2-ter. Le Pubbliche amministrazioni, quantificano annualmente, ai sensi dell articolo 27, del decreto legislativo 27 ottobre 2009, n.150, i risparmi effettivamente conseguiti in attuazione delle disposizioni di cui ai commi 1 e 2. Tali risparmi sono utilizzati, per due terzi secondo quanto previsto dall articolo 27, comma 1, del citato decreto legislativo n. 150 del 2009 e in misura pari ad un terzo per il finanziamento di ulteriori progetti di innovazione. 3. La digitalizzazione dell'azione amministrativa è attuata dalle pubbliche amministrazioni con modalità idonee a garantire la partecipazione dell'italia alla costruzione di reti transeuropee per lo scambio elettronico di dati e servizi fra le amministrazioni dei Paesi membri dell'unione europea. Come si nota, l articolo non fa riferimento esplicito alla cooperazione applicativa; ciò nonostante, la razionalizzazione dei procedimenti amministrativi e la semplificazione delle modalità di accesso da parte delle imprese (e si intende sottointeso delle altre amministrazioni cooperanti), così come citata nel comma 2, può giustificare l esigenza di adottare la cooperazione applicativa quale capacità strutturale di cooperazione con le altre amministrazioni. Nel citato articolo 15 ed, in particolare, nel comma 3, si specifica che le amministrazioni devono misurare e quantificare i risparmi effettivamente conseguiti, al fine di ottenere i finanziamenti necessari all esecuzione di nuovi progetti di innovazione. È ragionevole prevedere che l adozione di criteri meritocratici di incentivazione all innovazione ed all efficienza sarà presente se non anche potenziata nei futuri aggiornamenti del CAD. Relazioni Figura 20: motivazione Affermazione criteri meritocratici nell e-government italiano Crescente richiesta di interoperabilità Le organizzazioni pubbliche che devono accedere a dati o servizi disponibili presso altre organizzazioni pubbliche sempre più spesso richiedono a queste ultime di adeguarsi ai precetti espressi nel CAD e di esporre tali dati e servizi per mezzo di SPC e della cooperazione applicativa. 28

30 Relazioni Figura 21: motivazione Crescente richiesta di interoperabilità Affermazione paradigma SOA e Cloud Computing Il paradigma della Service Oriented Architecture *di seguito SOA + è ormai da anni consolidato ed affermato, con il supporto di un numero di standard e di prodotti commerciali sempre crescente. Il modello SPCoop per la cooperazione applicativa ha regole tecniche coerenti con i principi delle SOA. In questi ultimi mesi stiamo assistendo all affermarsi anche dal punto di vista commerciale del paradigma del cloud computing, declinato nelle sue diverse capacità di esporre, come servizio, l infrastruttura (Infrastructure as a Service IaaS), la piattaforma applicativa (Platform as a Service PaaS) o le singole applicazioni software (Software as a Service SaaS). Questo paradigma è a sua volta basato sulle potenzialità della virtualizzazione e sulla caratteristica di accoppiamento lasco dei sistemi che interagiscono secondo i principi delle SOA. È ormai prevista una rapida convergenza sul cloud dei servizi che non richiedono per esigenze specifiche un dispiegamento presso il sistema informativo interno all organizzazione. È ragionevole prevedere che, nel medio termine, un numero via via maggiore di servizi esposti in cooperazione applicativa possa includere componenti messe a disposizione sul cloud (macchine virtuali, servizi esposti in modalità SOA, applicazioni), traendo così vantaggio dalla flessibilità intrinseca del cloud computing e dai risparmi da essa derivanti. 29

31 Relazioni Figura 22: motivazione Affermazione paradigma SOA e Cloud Computing Crescente complessità dei sistemi I più recenti sistemi middleware rendono sempre più semplice la realizzazione di applicazioni SOA, a fronte però di una crescente complessità intrinseca dei sistemi stessi. Il dispiegamento dell infrastruttura necessaria per la messa in atto delle regole tecniche relative alla cooperazione applicativa (PDD, eventuali SICA secondari, ) è, a sua volta, causa un ulteriore incremento della complessità dei sistemi informatici da gestire. Tale complessità, se non adeguatamente governata, rischia di diventare causa di inefficienze nella gestione dei sistemi informativi. Relazioni Figura 23: motivazione Crescente complessità dei sistemi Crescente responsabilizzazione sugli SLA La cooperazione applicativa prevede la possibilità di definire in modo esplicito i livelli di servizio garantiti (anche noti come Service Level Agreement o SLA) per un determinato servizio applicativo. Questa definizione può essere, infatti, inclusa nella parte specifica dell ADS; in questo modo, per uno stesso servizio, l organizzazione erogante può garantire prestazioni diverse ad organizzazioni fruitrici diverse. Man mano che l adozione delle tecnologie SOA si diffonde tra le organizzazioni pubbliche tramite la convergenza di queste ultime verso il modello della cooperazione applicativa, cresce la dipendenza dei processi di ciascun organizzazione dalle prestazioni dei servizi erogati dalle organizzazioni partner. Contestualmente, quindi, diventa sempre più pressante la 30

32 richiesta di rispetto dei livelli di servizio concordati. Nei casi in cui l accesso ad un determinato servizio è regolato da un apposito contratto che ne stabilisce tra l altro i relativi costi di fruizione, il rispetto dei livelli di servizio concordati è spesso condizione necessaria perché l organizzazione fruitrice sia tenuta a pagare l intera somma pattuita all organizzazione erogante, ovvero perché non abbia il diritto di applicare penali. Relazioni Figura 24: motivazione Crescente responsabilizzazione sugli SLA Crescente richiesta di flessibilità e di efficienza La richiesta di flessibilità, per un amministrazione pubblica, è la conseguenza interna della crescente richiesta di interoperabilità da parte delle altre amministrazioni pubbliche. In particolare, accade spesso che la dirigenza delle amministrazioni pubbliche sia sollecitata dall esterno a potenziare le capacità dei propri sistemi informativi (ad esempio, introducendo nuovi servizi informatici) e, per questo, richieda al proprio staff di gestione dell IT che tali cambiamenti siano apportati in tempi estremamente rapidi. La predisposizione di strumenti e processi per la pubblicazione di servizi in cooperazione applicativa può essere una risposta adeguata alla richiesta di flessibilità, in quanto consente di garantire un approccio consolidato alla pubblicazione dei servizi, secondo modalità note e sfruttando potenzialmente infrastrutture hardware già predisposte. In condizioni economiche di crescita assente o incerta, inoltre, le organizzazioni sono spesso motivate a perseguire i possibili risparmi derivanti dall incremento dell efficienza ovvero dalla riduzione dei costi interni. L adozione della cooperazione applicativa può portare significativi risparmi nell esecuzione delle procedure amministrative di un organizzazione pubblica, grazie all abbattimento dei costi sempre elevati dovuti alle interazioni non automatizzate con le altre pubbliche amministrazioni. Perché questi risparmi possano essere effettivamente raggiunti, è altresì necessario fare in modo che la piattaforma stessa per la cooperazione applicativa ed i processi definiti per il relativo utilizzo siano ottimizzati e consolidati; solo così, infatti, si possono minimizzare i costi relativi alla loro introduzione. 31

33 Relazioni Figura 25: motivazione Crescente richiesta di flessibilità e di efficienza Obiettivi (stato desiderato) In questo paragrafo si definiscono gli obiettivi che un organizzazione italiana con finalità pubbliche può porsi nel momento in cui intende adottare la cooperazione applicativa come capacità di esporre servizi informatici ad altre organizzazioni pubbliche, ovvero come capacità di automatizzare le interazioni di tipo G2G. In una mappa BDN, gli obiettivi rappresentano lo stato finale desiderato, per il raggiungimento del quale si mette in atto il cambiamento considerato. Tali obiettivi sono derivati dalle motivazioni guida ed influenzano i benefici attesi. Aderenza alla normativa di riferimento Per quanto il CAD, in molti aspetti, sia vincolante verso le politiche di digitalizzazione delle pubbliche amministrazioni, l effettiva aderenza di queste ultime ai precetti organizzativi e tecnologici ivi prescritti è in alcuni casi carente. La generica organizzazione di riferimento può porsi, quindi, come obiettivo, la minimizzazione o ancor meglio l annullamento dello scostamento esistente tra quanto richiesto dalla normativa e quanto effettivamente realizzato nel proprio sistema informativo. 32

34 Relazioni Figura 26: obiettivo "Aderenza alla normativa di riferimento" Incremento del numero dei servizi erogati in SPCoop La generica organizzazione di riferimento può porsi, come obiettivo, l incremento del numero di servizi esposti in cooperazione applicativa, coerentemente con le politiche adottate dalla Comunità Europea e dalla normativa italiana che stimolano e vincolano verso questo tipo di approccio strutturato all interoperabilità. Relazioni Figura 27: obiettivo "Incremento del numero dei servizi erogati in SPCoop" Controllo sistematico dei livelli di servizio L attuazione della capacità di controllo sistematico dei livelli di servizio per i servizi erogati è un obiettivo estremamente virtuoso per qualunque azienda. 33

35 Relazioni Spesso la capacità di misurazione delle effettive prestazioni di un servizio informatico è resa difficile da diverse cause, quali, ad esempio: la mancata definizione dei Key Performance Indicators *di seguito KPI + che maggiormente possono descrivere le effettive prestazioni del servizio; la mancata progettazione del servizio stesso affinché possa dare informazioni sulle relative prestazioni; la difficoltà intrinseca dell attuazioni di misurazioni in grado di non perturbare le prestazioni ed il funzionamento del servizio stesso; la mancata disponibilità nell organizzazione di riferimento di strumenti capaci di facilitare e/o automatizzare l esecuzione dei test sulle prestazioni di un servizio. Nel contesto delle organizzazioni pubbliche, la capacità di misurazione delle prestazioni dei servizi diventa via via più importante man mano che aumenta l adesione alla cooperazione applicativa, ovvero man mano che aumenta il numero di interazioni on-line tra i servizi e man mano che le procedure amministrative di una generica organizzazione diventano dipendenti dai servizi offerti dalle altre organizzazioni. Si è già evidenziato il fatto che, per i servizi cooperanti nelle modalità definite da accordi commerciali, il rispetto dei livelli di servizio è, spesso, condizione necessaria perché l organizzazione fruitrice sia tenuta a pagare in pieno la somma concordata con l organizzazione erogatrice del servizio. Figura 28: obiettivo "Controllo sistematico dei livelli di servizio" Disponibilità di linee guida aziendali per la Cooperaz. Applic. L adozione di un framework interno, capace di descrivere le linee guida aziendali per l utilizzo e la gestione della piattaforma di cooperazione applicativa, nonché la modalità di progettazione dei sistemi in modo coerente con le regole tecniche di SPC è condizione necessaria per fare in modo che l introduzione di questa piattaforma non induca costi operativi non controllati. 34

36 Relazioni Figura 29: obiettivo "Controllo sistematico dei livelli di servizio" Benefici attesi In questo paragrafo si definiscono i benefici che un organizzazione italiana con finalità pubbliche può perseguire decidendo di adottare la cooperazione applicativa come capacità di esporre servizi informatici ad altre organizzazioni pubbliche, ovvero come capacità di automatizzare le interazioni di tipo G2G. Per ciascun beneficio si riporta una prima macro-classificazione del relativo impatto e della relativa probabilità. L impatto di un beneficio è valutato genericamente, con il valore booleano alto o basso, in base ad una stima grossolana relativa agli effettivi vantaggi ottenibili dall organizzazione a seguito del completo perseguimento del beneficio; in particolare: si considera genericamente alto l impatto dei benefici legati al cambiamento delle attività primarie delle organizzazioni di riferimento, quali ad esempio la digitalizzazione dei processi amministrativi; si considera basso l impatto dei benefici legati ad altri fattori, quali i risparmi derivanti dalle ottimizzazioni sulle attività di gestione. Questi ultimi, infatti, impattano un numero di risorse (persone, sistemi, attività) solitamente molto inferiore rispetto ai primi. La probabilità di un beneficio è valutata come probabilità che si verifichino le condizioni tali a garantire il completo perseguimento del beneficio stesso. Nella seguente figura si anticipa il risultato della macro-valutazione di probabilità ed impatto effettuata sui benefici rappresentati nella mappa. 35

37 Figura 30: valutazione della priorità e dell'impatto per i benefici della mappa BDN proposta Come già evidenziato, una simile valutazione di probabilità ed impatto consente di individuare la priorità da associare a ciascun beneficio, ovvero ai cambiamenti (progetti e programmi) finalizzati al perseguimento del beneficio stesso. Riduzione dei rischi di non aderenza alla normativa Come già evidenziato, il CAD in quanto normativa di riferimento pur garantendo alle pubbliche amministrazioni la completa autonomia nell organizzazione dei propri processi amministrativi, è vincolante per queste ultime rispetto ai tempi ed alle modalità di digitalizzazione dei processi stessi. In particolare, come già evidenziato, << la progettazione ed il coordinamento delle iniziative rilevanti ai fini di una più efficace erogazione di servizi in rete a cittadini e imprese mediante gli strumenti della cooperazione applicativa >> è un obbligo per tutte le amministrazioni pubbliche, oltre che essere un opportunità per <<i gestore di servizi pubblici e i soggetti che perseguono finalità di pubblico interesse>>. Difficoltà di varia natura (organizzativa, tecnologica e finanziaria) hanno finora ostacolato le amministrazioni pubbliche nel perseguire il raggiungimento della completa aderenza alla normativa del CAD. Sebbene sia alquanto improbabile, questa situazione potrebbe causare all amministrazione problemi di natura legale. È invece più probabile che la stessa situazione possa causare alla dirigenza dell amministrazione difficoltà di tipo politico, specialmente nei confronti delle altre amministrazioni che possono richiedere accesso ai dati ed ai processi tramite cooperazione 36

38 applicativa. Probabilità Impatto Relazioni Bassa (per quanto sia tecnicamente possibile, al momento si ritiene improbabile che un amministrazione possa essere chiamata a rispondere davanti ad un tribunale circa la mancata completa aderenza rispetto alla normativa del CAD) Basso (si ritiene che gli eventuali costi legati a sanzioni sulla non completa aderenza alla normativa di riferimento siano bassi, se paragonati come ordine di grandezza ai risparmi ottenibili dalla digitalizzazione dei processi amministrativi). Figura 31: beneficio "Riduzione dei rischi di non aderenza alla normativa" Riduzione dei costi legati alla gestione delle procedure Probabilità Impatto È ragionevole prevedere l adozione strutturale della cooperazione applicativa possa incentivare una più completa digitalizzazione dei processi amministrativi propri dell organizzazione, semplificando ed automatizzando le modalità di interazione tra l organizzazione stessa e le altre amministrazioni. È noto che la digitalizzazione dei processi è solitamente causa di significativi risparmi, principalmente perché elimina l esigenza di numerose, ripetitive e costose attività manuali, garantendo nel contempo la minimizzazione del rischio di occorrenza di errori legati a queste ultime e, di conseguenza, la standardizzazione dei livelli di qualità. Alta (si ritiene alta la probabilità che la digitalizzazione dei processi e l automazione della cooperazione con le altre organizzazioni possa generare risparmi) Alto (si ritiene che i risparmi generati dalla digitalizzazione dei processi e dall automazione della cooperazione con le altre organizzazioni possano essere significativi) 37

39 Relazioni Figura 32: beneficio "Riduzione dei costi legati alla gestione delle procedure" Incremento dei finanziamenti legati ai risparmi ottenuti Probabilità Impatto Come già evidenziato, nel CAD sono definiti meccanismi meritocratici per l incentivazione della digitalizzazione delle pubbliche amministrazioni. In particolare, nell Art. 15, si specifica che le pubbliche amministrazioni ottengono finanziamenti per nuovi progetti di innovazione proporzionali ai risparmi ottenuti dai progetti di innovazione già messi in campo. Questa normativa genera, di fatto, un circolo virtuoso, in cui le amministrazioni meritevoli possono vedere premiati e supportati i propri sforzi di innovazione, nonché la propria attenzione al perseguimento dei risparmi legati all innovazione stessa. Bassa (si giudica bassa la probabilità di ottenere questo beneficio in quanto, mediamente, sono poche le pubbliche amministrazioni in grado di misurare e dimostrare i vantaggi già ottenuti con progetti innovativi legati alla cooperazione applicativa) Alto (si considera che l entità di questi finanziamenti possa essere potenzialmente alta rispetto al costo complessivo dei progetti di innovazione) 38

40 Relazioni Figura 33: beneficio "Incremento dei finanziamenti legati ai risparmi ottenuti" Riduzione dei costi legati al non rispetto degli SLA Probabilità Impatto Nel momento in cui le amministrazioni espongono i propri servizi in cooperazione applicativa, aumenta la probabilità che le prestazioni di tali servizi possano impattare le prestazioni dei processi realizzati dalle organizzazioni cooperanti che accedono ai servizi stessi. Negli ADS, un amministrazione può già dare evidenza di quali prestazioni intende garantire alle organizzazioni cooperanti; come già evidenziato, questi parametri sono opzionali e sono inclusi nella parte specifica di un ADS (per uno specifico servizio, una determinata organizzazione erogante può garantire prestazioni diverse ad organizzazioni fruitrici diverse). Come già chiarito, nei casi in cui l accesso ad un determinato servizio è regolato da un apposito contratto che ne stabilisce tra l altro i relativi costi di fruizione, il rispetto dei livelli di servizio concordati è spesso condizione necessaria perché l organizzazione fruitrice sia tenuta a pagare l intera somma pattuita all organizzazione erogante, ovvero perché non abbia il diritto di applicare penali. Per quanto, al momento, sia altamente improbabile che i servizi delle pubbliche amministrazioni esposti in cooperazione applicativa possano essere regolati da contratti di cooperazione che vincolino formalmente il rispetto delle prestazioni garantite, è altresì tecnicamente possibile che nel medio termine con l incremento dei rapporti di cooperazione applicativa, simili vincoli possano essere messi in atto. Bassa (è raro che le organizzazioni pubbliche stipulino tra loro accordi di cooperazione applicativa contenenti clausole penali legate al mancato rispetto dei livelli di servizio) Basso (le eventuali clausole penali legate al mancato rispetto dei livelli di servizio, comportano costi sicuramente bassi se paragonati ai risparmi ottenuti dal processo di 39

41 Relazioni digitalizzazione dei processi amministrativi) Figura 34: beneficio "Riduzione dei costi legati al non rispetto degli SLA" Riduzione dei tempi di realizzazione di nuovi servizi Probabilità Impatto Relazioni La disponibilità di un infrastruttura e di processi rodati per la creazione e l erogazione di servizi in cooperazione applicativa è sicuramente causa di significativi risparmi sui tempi e, quindi, sui costi legati alle attività di progettazione e sviluppo di nuovi servizi. Alta (nelle condizioni citate, si considera molto probabile la possibilità di ridurre i tempi e di abbassare i costi di progettazione e sviluppo di nuovi servizi in cooperazione applicativa). Alto (si considera rilevante l impatto che può avere l abbattimento dei costi di progettazione e sviluppo di servizi di cooperazione applicativa, grazie alla disponibilità di un infrastruttura già qualificata e di processi rodati). Figura 35: beneficio "Riduzione dei tempi di realizzazione di nuovi servizi" 40

42 Riduzione dei costi di gestione della piattaforma servizi Probabilità Impatto Relazioni L adozione, da parte di un organizzazione con finalità pubbliche, della cooperazione applicativa come modalità strutturale di esposizione dei propri servizi informatici alle organizzazioni cooperanti richiede, all organizzazione stessa, la predisposizione di adeguate infrastrutture tecnologiche, nonché l adozione di nuove procedure sia relative all utilizzo di questa piattaforma, sia relative alla gestione di tali infrastrutture. Diventa, quindi, fondamentale fare in modo che queste nuove infrastrutture siano progettate in modo razionale, utilizzate in modo coerente e gestite in modo ottimale. Solo in queste condizioni, è possibile ottenere risparmi relativi ai costi operativi legati a tale piattaforma. Alto (è altamente probabile che un adeguata attenzione alla capacità di gestione dell infrastruttura concretizzata con la redazione di regole tecniche e la formazione del personale incaricato sia fonte di risparmi quantificabili sui costi operativi dell infrastruttura stessa) Basso (questi risparmi sono solitamente di bassa entità se paragonati ai risparmi ottenibili, ad esempio, grazie alla digitalizzazione dei processi amministrativi). Figura 36: beneficio "Riduzione dei costi di gestione della piattaforma servizi" Iniziative richieste In questo paragrafo si elencano le iniziative che un organizzazione italiana con finalità pubbliche deve mettere in campo nel momento in cui intende adottare la cooperazione applicativa come capacità di esporre servizi informatici ad altre organizzazioni pubbliche, ovvero come capacità di automatizzare le interazioni di tipo G2G. Alcune delle iniziative qui descritte hanno natura prettamente progettuale; queste, infatti, si configurano come attività di durata limitata nel tempo, capaci di garantire il perseguimento di determinati obiettivi nel rispetto di vincoli ben definiti. Per questa tipologia di iniziative, è possibile fare previsioni dettagliate circa il tempo ed i costi necessari per la relativa attuazione; è, altresì, opportuno articolare le relative attività in fasi, secondo una suddivisione coerente con la metodologia adottata a livello aziendale per la gestione dei 41

43 progetti. È, possibile, ad esempio, stabilire quali attività devono essere messe in atto per ciascuna delle seguenti fasi progettuali, con i relativi tempi ed i relativi rilasci (deliverables): fase di analisi dei requisiti e vincoli fase di pianificazione delle attività fase di sviluppo della soluzione fase di test della soluzione fase di stabilizzazione della soluzione fase di rilascio della soluzione Altre tipologie di iniziative possono avere una natura più organizzativa che progettuale. Predisposizione e registrazione di una PDD per ogni dominio applicativo Ciascuna pubblica amministrazione è chiamata a predisporre una PDD per ogni dominio applicativo in essa definito, nonché a registrare l esistenza di tali PDD nel registro SICA. L iniziativa si configura chiaramente come di tipo progettuale. Relazioni Figura 37: iniziativa "Predisposizione e registrazione di una PDD per ogni dominio applicativo" Migrazione servizi esistenti in SPCoop (ADS + integr. PDD) Per alcune pubbliche amministrazioni, l interazione con le organizzazioni cooperanti necessaria per lo svolgimento della propria missione è messa in atto con processi altamente manuali e poco ottimizzati. Altre pubbliche amministrazioni, di fatto, già automatizzano 42

44 Relazioni parzialmente o interamente questo tipo di interazioni, pur tuttavia senza garantire il pieno rispetto delle regole tecniche relative alla cooperazione applicativa, bensì adottando accordi eterogenei, stipulati ad-hoc con singole organizzazioni cooperanti. La migrazione dei servizi esistenti in SPCoop riguarda, macroscopicamente, la messa in atto delle seguenti attività (anch esse di natura prettamente progettuale): la creazione dei servizi informatici secondo i principi della SOA (qualora non già esistenti); la definizione e la pubblicazione degli ADS per ciascuno di questi servizi, comprensivi degli elementi comuni e degli elementi opportunamente stipulati con ciascuna delle organizzazioni fruitrici; l integrazione dei servizi con la PDD capace di esporli su SPC. Figura 38: iniziativa "Migrazione servizi esistenti in SPCoop (ADS + integr. PDD)" Creazione di nuovi servizi in SPCoop (ADS + integr. PDD) Una volta predisposta l infrastruttura necessaria per il rispetto delle regole tecniche sulla cooperazione applicativa, ed una volta definite le procedure interne di utilizzo e gestione di quest infrastruttura, la generica organizzazione quando necessario potrà avviare le attività progettuali relative alla creazione di nuovi servizi; questi ultimi dovranno essere adeguatamente progettati per poter essere ospitati da tale infrastruttura. Per ciascuno di questi servizi, dovranno essere messe in atto le seguenti attività: la progettazione e lo sviluppo del servizio secondo i principi della SOA; la definizione e la pubblicazione degli ADS associati al servizio, comprensivi degli 43

45 Relazioni elementi comuni e degli elementi opportunamente stipulati con ciascuna delle organizzazioni fruitrici; l integrazione del servizio con la PDD capace di esporli su SPC. Figura 39: iniziativa "Creazione di nuovi servizi in SPCoop (ADS + integr. PDD)" Predisposizione per la misurazione dei livelli di servizio Relazioni L organizzazione deve adottare tecnologie e processi per fare in modo di avere sempre sotto controllo le prestazioni effettivamente erogate dai servizi esposti in cooperazione applicativa, per adeguato confronto con i livelli di servizio garantiti. In tal senso, è esemplificativo ed interessante lo sforzo fatto nel contesto del progetto ICAR ed, in particolare, nel contesto del task denominato INF-2 ( Gestione di Strumenti di Service Level Agreement a livello interregionale ) per arrivare alla creazione di un infrastruttura ed alla definizione di una metodologia condivisa capace di garantire la misurazione degli scostamenti tra le prestazioni erogate e gli SLA concordati. 44

46 Figura 40: iniziativa "Predisposizione per la misurazione dei livelli di servizio" Adozione strutturata del processo di gestione dei benefici Il processo di gestione dei benefici (benefit management) descritto sommariamente all inizio di questo documento consente alle organizzazioni di tenere sempre sotto controllo la coerenza delle azioni messe in atto rispetto agli obiettivi aziendali, nonché l efficacia delle azioni stesse rispetto ai benefici inizialmente previsti. Nel contesto di riferimento per questo documento, la capacità di misurazione dei benefici ottenuti con la cooperazione applicativa è condizione necessaria secondo quanto prescritto nell art. 15 del CAD per l accesso ai finanziamenti di nuovi progetti innovativi. Relazioni Figura 41: iniziativa "Adozione strutturata del processo di gestione dei benefici" Redazione di regole tecniche aziendali su SOA ed SPCoop Come più volte chiarito, l introduzione di una piattaforma capace di realizzare le regole tecniche stabilite dalla normativa per la cooperazione applicativa deve essere accompagnata dalla redazione di un framework aziendale contenente indicazioni circa l utilizzo e la gestione della piattaforma stessa. È opportuno che queste linee guida contengano almeno le seguenti informazioni: Informazioni tecniche per lo sviluppo ed il testing dei servizi da esporre in cooperazione 45

47 Relazioni applicativa: o modalità di utilizzo delle infrastrutture comuni; o modalità di utilizzo degli standard WS-*; o modalità di redazione e pubblicazione degli ADS; o modalità di integrazione con la/e PDD; o obblighi ed accortezze per garantire la sicurezza del codice; o obblighi ed accortezze per garantire la leggibilità del codice; o modalità di instrumentazione dell applicazione, per facilitare la misurazione dei livelli di servizio; o posizione e caratteristiche degli ambienti di dispiegamento (sviluppo, collaudo, pre-produzione, produzione); o modalità di esecuzione dei test (unit testing, system test; integration test; ecc ) o Informazioni organizzative: o responsabilità, ruoli, assegnatari; o calendario delle attività di gestione schedulate; o modalità di documentazione dei progetti; o requisiti per la presa in carico di nuovi servizi da parte dei responsabili della gestione dei sistemi; o processo di gestione dei cambiamenti (change management) e dei rilasci in produzione (release management); o Figura 42: iniziativa "Redazione di regole tecniche aziendali su SOA ed SPCoop" 46

48 Formazione sviluppatori su SOA ed SPCoop A completamento dell iniziativa di redazione di un framework aziendale sull utilizzo e sulla gestione della piattaforma di gestione applicativa, si suggerisce di mettere in campo attività di formazione mirate alla comprensione dei contenuti del framework da parte degli sviluppatori dei servizi. Relazioni Formazione sistemisti sulla gestione della PDD A completamento dell iniziativa di redazione di un framework aziendale sull utilizzo e sulla gestione della piattaforma di gestione applicativa, si suggerisce di mettere in campo attività di formazione mirate alla comprensione dei contenuti del framework da parte amministratori di sistema. Relazioni Figura 43: iniziativa "Formazione sviluppatori su SOA ed SPCoop" Fattori tecnologici abilitanti 47

49 In questo paragrafo si elencano i fattori tecnologici che rendono possibile, per un organizzazione italiana con finalità pubbliche, l adozione del modello di cooperazione applicativa, inteso come capacità di esporre servizi informatici ad altre organizzazioni pubbliche, ovvero come capacità di automatizzare le interazioni di tipo G2G. Disponibilità PDD certificate Sono disponibili PDD già certificate, ovvero per le quali è garantito un funzionamento completamente coerente con le regole tecniche specificate per la cooperazione applicativa. Relazioni Figura 44: fattore tecnologico abilitante "Disponibilità PDD certificate" Disponibilità dei servizi SICA Sono disponibili servizi SICA capaci di erogare funzionalità coerenti con quelle descritte nella normativa di riferimento. Relazioni Figura 45: fattore tecnologico abilitante "Disponibilità dei servizi SICA" 48

50 Ampia disponibilità di esempi e casi d'uso di SPCoop Relazioni Le regole tecniche relative alla cooperazione applicativa sono ormai stabilizzate da diversi anni e per questo sono già state adottate con successo da diverse organizzazioni. Esistono diverse referenze pubbliche che descrivono le modalità con cui si è proceduto a realizzare infrastrutture coerenti con tali regole tecniche. Tra le fonti di documentazione più complete in tal senso, si citano i documenti relativi ai 3 task infrastrutturali ed ai 7 task applicativi del progetto ICAR. In particolare, quest ampia documentazione contiene dettagliati esempi circa le seguenti problematiche: Modalità di organizzazione degli ADS Modalità di redazione delle componenti obbligatorie presenti negli ADS (modello dei dati scambiati, specifica delle interfacce, specifica delle conversazioni e dei porti di accesso) Modalità di redazione delle componenti opzionali presenti negli ADS (livelli di servizio, ontologie, specifiche di sicurezza) Modalità di funzionamento delle interazioni di cooperazione applicativa Possibili estensioni funzionali alla PDD Architettura per la misurazione del rispetto degli SLA Architettura per la sicurezza federata Figura 46: fattore tecnologico abilitante "Ampia disponibilità di esempi e casi d'uso di SPCoop" Ampia disponibilità di tecnologie e standard per le SOA Il paradigma SOA si è affermato a livello mondiale ormai da diversi anni. Esistono numerosi prodotti commerciali, che realizzano sistemi middleware per lo sviluppo e l erogazione di servizi in ottica SOA. 49

51 Questi prodotti seguono velocemente l evoluzione della tecnologia, ovvero sono frequentemente aggiornati per implementare via via i nuovi standard che si affermano, a livello mondiale, nel contesto delle SOA. Relazioni Figura 47: fattore tecnologico abilitante "Ampia disponibilità di tecnologie e standard per le SOA" Ostacoli noti Costi iniziali di implementazione e migrazione È evidente che iniziative progettuali finalizzate all implementazione di un infrastruttura coerente con le regole tecniche della cooperazione applicativa, nonché alla migrazione dei servizi esistenti su tale infrastruttura comportino un costo iniziale rilevante. L evidenza di un tale costo, se non accompagnata da un adeguata analisi dei benefici, rappresenta un ostacolo certo alla possibilità di ottenere il consenso aziendale necessario per la realizzazione di questo impegnativo programma. 50

52 Relazioni Figura 48: ostacolo "Costi iniziali di implementazione e migrazione" Esistenza di carenze nelle regole tecniche SPCoop Le regole tecniche della cooperazione applicativa lasciano alcuni punti non completamente chiariti. Si fa riferimento, ad esempio, alla struttura fisica dell ADS, già citata in questo documento. Ci sono, inoltre, regole tecniche che non sono supportate da soluzioni tecnologiche commerciali; si fa riferimento, ad esempio, alla struttura SOAP della busta di e-gov ed allo standard WSBL. Quanto appena descritto può rappresentare un ostacolo pratico alla definizione di regole tecniche aziendali per la cooperazione applicativa, nonché all adozione delle stesse nei progetti di migrazione o implementazione dei servizi verso la piattaforma di cooperazione applicativa. 51

53 Relazioni Figura 49: ostacolo "Esistenza di carenze nelle regole tecniche SPCoop" Esistenza di standard SOA carenti o concorrenti In ambito SOA, esistono ancora ambiti non coperti da standard adeguatamente affermati; si fa riferimento, ad esempio, alla mancanza di standard relativi ai pagamenti (billing) per l accesso a servizi commerciali. Analogamente, esistono ancora standard concorrenti che coprono esigenze funzionali analoghe; si fa riferimento, ad esempio, alla concorrenza tra gli standard WS-Notification e WS-Eventing. Esistono, inoltre, standard che pur essendosi affermati, sono adottati solo parzialmente dalla comunità mondiale; si fa riferimento, ad esempio, allo standard UDDI. In alcuni casi, le tecnologie coperte dalla cooperazione applicativa sono poco mature a livello di standard affermati e di prodotti commerciali in grado di supportarli. Si fa riferimento, ad esempio, alle tecnologie per la definizione delle ontologie legate ai servizi pubblicati. Quanto appena descritto può rappresentare un ostacolo pratico alla definizione di regole tecniche aziendali per la cooperazione applicativa, nonché all adozione delle stesse nei progetti di migrazione o implementazione dei servizi verso la piattaforma di cooperazione applicativa. 52

54 Relazioni Figura 50: ostacolo "Esistenza di standard SOA carenti o concorrenti" Incertezze sul futuro dei servizi SICA I recenti tagli ai finanziamenti delle iniziative a supporto dell informatica pubblica hanno impattato anche i contratti di supporto e gestione dell infrastruttura relativa ai servizi SICA. Relazioni Figura 51: ostacolo "Incertezze sul futuro dei servizi SICA" 53