Una strategia trentina per la realizzazione dell'interoperabilità e della cooperazione applicativa fra amministrazioni

Transcript

1 Una strategia trentina per la realizzazione dell'interoperabilità e della cooperazione applicativa fra amministrazioni Sergio Bettotti Italo Della Noce Nicola Prantil SOI-PAT [sergio.bettotti, italo.dellanoce, nicola.prantil]@provincia.tn.it Giuliano Muzio Informatica Trentina giuliano.muzio@infotn.it Marco Pistore Paolo Traverso ITC-IRST Trento [pistore, traverso@itc.it] Sommario Obiettivo della presente nota e' descrivere la strategia adottata dalla Provincia Autonoma di Trento per favorire la realizzazione di una piena interoperabilità e cooperazione applicativa fra le amministrazioni. Si descrivono in particolare due pilastri di questa strategia, ovvero la realizzazione di un sistema di collaborazioni sul territorio che coinvolga amministrazioni pubbliche locali, aziende e centri di ricerca attivi sul territorio e l'adozione di un insieme di strumenti per l'interoperabilità, basati su sistemi e formati open source, che adottano e evolvono i modelli SPC/SPCoop. Introduzione E' ampiamente riconosciuto il ruolo fondamentale che la realizzazione di una piena interoperabilità e cooperazione applicativa fra le amministrazioni può giocare per favorire la semplificazione e l'efficientizzazione della PA: basti considerare a tal proposito le indicazioni che in tal senso compaiono nelle recenti linee strategiche per la realizzazione del Sistema nazionale di e-government predisposte dal Ministro Luigi Nicolais. Sono però altrettanto ampiamente riconosciute le difficoltà nella realizzazione di questa piena interoperabilità e cooperazione, che richiede un ripensamento complessivo dei processi interni di lavoro delle PA e del loro modo di relazionarsi con gli utenti. E' quindi evidente l'importanza di non sommare, per quanto possibile, a queste difficoltà di natura organizzativa altre difficoltà di natura tecnologica. L'esistenza di un sistema pubblico di connettività e cooperazione applicativa (SPC/SPCoop) che propone modelli e specifiche tecniche basati su standard aperti e consolidati e' sicuramente un buon punto di partenza, ma non e' in grado da solo di rispondere alle esigenze tecnologiche che emergeranno da un'adozione sempre più diffusa e generalizzata delle infrastrutture di cooperazione applicativa. L'adozione dei modelli e delle specifiche SPC/SPCoop deve quindi accompagnarsi con una progressiva estensione di SPC/SPCoop con nuovi modelli e metodologie, nuove tecnologie e standard, casi di successo e soluzioni riutilizzabili che arricchiscano gli strumenti informatici utilizzabili a supporto della realizzazione della cooperazione applicativa. In Trentino, il processo sopra descritto e' supportato con un insieme di azioni strategiche che si pongono due obiettivi fortemente sinergici: (1) la realizzazione di un sistema di collaborazioni sul territorio che coinvolga amministrazioni pubbliche locali, aziende e centri di ricerca attivi sul territorio; (2) l'adozione da parte del sistema appena descritto di un insieme di strumenti per l'interoperabilità, basati su strumenti e formati open source, che adottano e evolvono i modelli SPC/SPCoop. La realizzazione della rete di collaborazioni sul territorio ha la funzione di favorire una collaborazione sistematica e continuativa fra tutti gli attori necessari ad una corretta evoluzione delle tecnologie di interoperabilità. In questo modo, e' possibile realizzare un incontro e un bilanciamento naturale fra problemi e requisiti dei domini applicativi (pubbliche amministrazioni), soluzioni e prodotti tecnologici assestati (aziende) e soluzioni innovative e di ricerca (centri di ricerca). Si può ad esempio dosare l'utilizzo di soluzioni di ricerca in un progetto di interoperabilità, limitandolo agli aspetti più innovativi, e garantendo comunque la soluzione complessiva del problema con l'adozione di tecnologie assestate. In questo modo, si favorisce un trasferimento più efficace di soluzioni di ricerca in soluzioni funzionanti e in pratiche industriali e di permette, in senso inverso, di indirizzare l'evoluzione delle soluzioni di ricerca verso i problemi applicativi e tecnologici reali. Azione necessaria al successo di questa collaborazione

2 a livello di sistema e' l'adozione da tutti gli attori di una piattaforma condivisa e basata su strumenti aperti per l'interoperabilità applicativa. Per strumenti aperti intendiamo non solo soluzioni open source e formati aperti, ma anche architetture aperte, che permettano cioè l'aggiunta, l'evoluzione o l'utilizzo selettivo delle specifiche funzionalità di interesse in uno specifico ambito applicativo. L'utilizzo di strumenti aperti e' indispensabile all'interno del sistema trentino per favorire la condivisione e il trasferimento di soluzioni e tecnologie fra i diversi attori. E' fondamentale inoltre in ottica evolutiva, per garantire una continua aderenza allo standard SPC/SPCoop, sia per favorire l'adozione eventuale di soluzioni risultate efficaci da parte dello standard SPC/SPCoop, sia in ottica inversa, ovvero di adeguamento della piattaforma trentina alle evoluzioni dello standard SPC/SPCoop. Nel seguito della nota verranno descritte in maggiore dettaglio le azioni che si stanno compiendo in Trentino per creare il sistema di collaborazioni e per sviluppare la piattaforma di strumenti aperti sopra descritti. Si presenteranno inoltre alcuni risultati che si intendono conseguire in queste azioni, in termini di estensione di standard e di modelli. Il fuoco sarà in particolare sul significato e sull'importanza dell'adozione di standard e strumenti aperti per supportare una evoluzione e un'adozione più rapida e meno invasiva delle soluzioni sviluppate. L interoperabilità come innovazione di sistema: il tripolo istituzioni-centri di ricerca-imprese Realizzare compiutamente l interoperabilità tra applicazioni sviluppate e gestite da una pluralità di attori che lavorano in un dato territorio significa anche individuare quali possano essere i migliori modelli organizzativi in grado di supportare tale interoperabilità. In altre parole, accanto agli standard e alle specifiche tecniche necessari a garantire il funzionamento dei sistemi interoperanti è opportuno introdurre altri strumenti di gestione del cambiamento, che permettano di mettere a sistema quanto realizzato da un punto di vista applicativo. Vista in questo contesto, l interoperabilità e la cooperazione applicativa presuppongono una nuova modalità di interazione tra pubbliche amministrazioni, che le renda capaci di aprire verso l esterno (e in primo luogo verso le istituzioni e le realtà che lavorano nell ambito dello stesso territorio) e rendere chiaramente leggibili le pratiche e i processi amministrativi e funzionali che le caratterizzano. Questa apertura risponde a un duplice obiettivo: da un lato mettere a disposizione di altre amministrazioni pratiche virtuose sviluppate all interno del proprio contesto organizzativo, dall altro realizzare una sorta di benchmarking che permetta di adeguare il proprio funzionamento a quello delle migliori pratiche altrui. Tale confronto biunivoco non preclude alcun punto di arrivo del processo cooperativo, che può sfociare nell adozione di un processo preesistente o nella reingegnerizzazione dei processi dei cooperanti. L adozione di tecnologie che abilitano l interoperabilità e la cooperazione applicativa implica quindi la necessità di generare un innovazione di sistema, che raccordi tra loro gli attori del territorio. Proprio nel rispetto di questo assunto, è stata immaginata la modalità di realizzazione dei progetti di interoperabilità in Trentino. La restante parte di questo capitolo sarà dedicata a illustrare e analizzare in dettaglio, in un ottica prettamente organizzativa, due casi specifici che si riferiscono a progetti avviati sul territorio trentino con la finalità di realizzare sistemi informativi che implementino il concetto di interoperabilità e cooperazione applicativa. Per analizzare al meglio i casi di studio citati nel paragrafo precedente è opportuno premettere alcuni concetti cardine del ragionamento, che servano nel contempo a chiarire come il percorso descritto affondi le sue radici in un lavoro iniziato già da alcuni anni. Il primo concetto è l importanza della creazione di reti di relazioni sul territorio. Infatti, la cooperazione non è abilitata soltanto dalla presenza di reti telematiche (seppur molto importanti), ma anche dalla reale esistenza di contatti e occasioni di lavoro comune che consentano alle realtà del territorio e agli individui che le rappresentano di trovare momenti di incontro, di scambio, di reciproca influenza culturale. Il valore di queste relazioni è inoltre indubbiamente aumentato dalla capacità di costruire team eterogenei, assegnando loro obiettivi e traguardi comuni e condivisi. Va detto che da questo punto di vista il Trentino è avvantaggiato dall avere un estensione territoriale relativamente ridotta, anche se la conformazione orografica dello stesso può generare fenomeni di digital divide. Sembra importante a questo punto chiedersi quali debbano essere in concreto i componenti di questa rete di relazioni, oltre ovviamente alle componenti istituzionali che, dato il loro ruolo, devono fungere da coordinamento e da collante del sistema. In Trentino questa riflessione ha portato alla conclusione che, per portare a termine un percorso di innovazione di sistema, che abbiamo visto essere una precondizione per la realizzazione dell interoperabilità, non si possa

3 prescindere da altri due attori fondamentali: i centri di ricerca ICT e le imprese innovative del territorio. Nasce in questo modo il concetto di tripolo dell innovazione, come modello organizzativo di riferimento per la realizzazione di reti aperte interoperanti. L ulteriore ricaduta positiva del coinvolgimento dei centri di ricerca e delle imprese nella realizzazione dell interoperabilità è data dalla familiarità che questi soggetti hanno (forse in misura addirittura maggiore di quanto non abbiano le stesse istituzioni) con il concetto di reti di relazioni. Coinvolgere questi attori significa quindi anche, in una certa misura, poter disporre di altre reti, collegate a quella primaria, che possono avere un ulteriore effetto positivo sui progetti. Il secondo concetto cardine è la necessità di individuare strutture organizzative e/o centri di competenza dedicati alla ideazione, progettazione e gestione dei progetti innovativi di interoperabilità. Data l estrema complessità di tale attività non sembra infatti opportuno considerare i progetti che la riguardano come ordinari progetti di sviluppo ICT, ma è piuttosto il caso di creare un nucleo di competenze ad hoc, dotato della necessaria autonomia per affrontare situazioni particolarmente delicate. In questo senso due aspetti vanno sottolineati: i progetti di interoperabilità mal si prestano alla creazione di strutture gerarchiche tipiche dei progetti interni a una singola organizzazione e la comunicazione tra attori eterogenei implica la capacità di comprendere e utilizzare linguaggi diversi, tra loro a volte anche contradditori. Il centro di competenza dedicato deve quindi avere la capacità di rapportarsi a realtà diversificate e multiformi. In Trentino, la risposta a questa esigenza è stata data individuando (o creando, laddove necessario) in tre realtà del territorio i nuclei di competenze in grado di affrontare la sfida delineata nel paragrafo precedente: il Servizio Organizzazione e Informatica della Provincia Autonoma di Trento (PAT), un gruppo di Innovation Management in Informatica Trentina (di recente creazione), azienda della PAT che sviluppa e gestisce in Insourcing i sistemi provinciali e il gruppo di ricerca sull E-government (anch esso di recente creazione) all interno dell ITC-IRST, Ente di ricerca della PAT. Veniamo ora ai casi di studio, con una piccola premessa che riguarda il territorio trentino. Gli aspetti che è importante sottolineare ai nostri fini sono due: da un lato l elevato numero di ricercatori ICT presenti in Trentino rispetto alla popolazione (circa 800), dall altro la dimensione relativamente ridotta delle imprese trentine (la media è di 1,2 addetti per impresa). Questi due aspetti hanno importanti influenze sull implementazione del tripolo precedentemente citato: intanto perché sorge l opportunità di sfruttare al meglio, a vantaggio delle istituzioni del territorio, le competenze dei ricercatori ICT, eventualmente incrementando il contenuto innovativo dei progetti di interoperabilità (questi aspetti saranno trattati più esaurientemente nel prossimo capitolo). La dimensione ridotta dell impresa facilita invece la flessibilità delle relazioni che si generano, obbligando tuttavia le istituzioni a un faticoso lavoro di raccordo tra una pluralità di aziende, ciascuna delle quali può tipicamente essere utilizzata per applicazioni di nicchia o specializzate verticalmente in un determinato dominio. Il primo caso di studio è costituito dal progetto ICAR- PAT, componente provinciale del più ampio progetto ICAR (Interoperabilità e Cooperazione Applicativa fra le Regioni), che ha come obiettivo una serie di realizzazioni infrastrutturali e applicative, che dovrebbero fornire un dispiegamento sul territorio e un'adozione in ambiti di competenza regionale degli standard SPC/SPCoop. Il secondo progetto è il progetto CASALPINA, progetto locale che ha l obiettivo di sperimentare un infrastruttura di interoperabilità che permetta la cooperazione applicativa in ambito socio-assistenziale. Questa cooperazione deve in prospettiva riguardare i vari enti che, a vario titolo, operano per fornire servizi socioassistenziali. Caratteristica specifica del progetto e' che alla progettazione e realizzazione della soluzione contribuiscono in maniera determinante aziende e centri di ricerca del territorio, con l'obiettivo di applicare e sperimentare in ambito industriale idee innovative di ricerca. Segnaliamo per punti quelli che ci sembrano essere gli aspetti maggiormente importanti che scaturiscono dall analisi di questi progetti, sottolineando che i progetto sono ancora in corso e che hanno orizzonte temporali assai diversi: il primo di lungo periodo (fine prevista 2009), il secondo di breve periodo (fine prevista aprile 2007). a) Condivisione degli obiettivi da parte degli attori. La prima sfida che un progetto di interoperabilità si trova concretamente ad affrontare è la capacità di gestire e superare comportamenti opportunistici da parte degli attori di progetto, per i quali gli obiettivi di sistema devono essere armonizzati con gli obiettivi che le singole istituzioni e/o strutture organizzative hanno assegnato loro. Mettere a

4 disposizione di altri i propri sistemi è non solo percepito come rischioso in virtù di elementi culturali, ma anche come inutile in rapporto al soddisfacimento dei propri obiettivi di performance (individuali e di gruppo). Si tratta quindi di accettare il rischio di condividere infrastrutture e applicazioni, ma anche di saper percepire l obiettivo istituzionale che è sotteso ai progetti e che ha come unica contropartita a lungo termine la crescita culturale complessiva del territorio (che sfocerà auspicabilmente in una crescita anche economica). Condividere gli obiettivi di un progetto di interoperabilità significa quindi spogliarsi degli aspetti tattici per investire in un percorso che ha una ricaduta non immediata. In questo senso ci sembra importante sottolineare che i progetti di interoperabilità devono avere una durata congrua con l ambizione che si pongono. Il caso del progetto CASALPINA ci insegna anche che porre una prima data-obiettivo a breve termine può essere pagante solo se si fa percepire agli attori del progetto che questo è un primo passo in un percorso di collaborazione che può continuare a lungo. Una sorta di periodo di prova del team di progetto, che verifica l eventuale sussistenza di forti incompatibilità al proprio interno. Può essere inoltre opportuno che gli obiettivi del progetto (in Trentino questo è avvenuto sia per ICAR-PAT, sia per CASALPINA) siano chiaramente esplicitati con comunicazioni formali ai massimi livelli tra i soggetti istituzionali che partecipano all iniziativa. In altre parole, il solo approccio bottom-up all interoperabilità potrebbe non essere sufficiente, se non adeguatamente accompagnato da un parallelo percorso topdown che lo rafforzi. b) Libertà di sperimentazione. Il ciclo di vita del progetto di interoperabilità non può essere scandito da fasi rigidamente sequenziali quali quelle di un modello waterfall, ma ha bisogno di iterazioni e di flessibilità operativa. Si tratta infatti di superare processi, più o meno esplicitati, appartenenti a singole organizzazioni, per costruire pragmaticamente processi condivisi da una rete di organizzazioni, i cui standard non è detto che siano allineati, condivisi o molto più semplicemente reciprocamente noti. Il risultato di progetto va quindi conseguito per approssimazioni successive, che affinano risultati iniziali realizzati a livello prototipale (con un modello prototipale o a spirale ) e garantiscano a ogni attore la possibilità di sperimentare adeguatamente e di comunicare all interno della propria organizzazione quanto realizzato. È evidente che per garantire che tale libertà di sperimentazione conduca comunque a risultati soddisfacenti è necessaria una forza notevole a livello di governance di progetto, che consenta di fare sintesi laddove si rischierebbe di lasciare eccessivo spazio a comportamenti disarticolati. c) Adeguatezza degli strumenti e delle modalità di comunicazione. La rete di relazioni del progetto di interoperabilità regge bene se adeguatamente supportata da opportuni strumenti di comunicazione. Si tratta quindi di prevedere i necessari momenti di confronto mediante riunioni, workshop, brainstorming, così come è necessario utilizzare in modo sensibile strumenti informatici di collaboration e workgroup. Lo stile di leadership per la gestione dei progetti dovrebbe quindi essere improntato, non solo a criteri che garantiscano la libertà di sperimentazione, ma anche alla massima trasparenza, nella volontà di condividere al massimo all interno del gruppo di lavoro gli oggetti realizzati dal progetto. Ciò non toglie che siano opportuni anche momenti di settorializzazione e specializzazione di competenze. Sia in ICAR-PAT che in CASALPINA si è infatti sempre partiti dal presupposto che all interno del gruppo di lavoro si dovessero utilizzare le migliori competenze a disposizione per realizzare i task di progetto, una cui prima immediata conseguenza è che, se è vero che ogni amministrazione si apre e si mette in rete con altre amministrazioni, è pur vero che ogni amministrazione gestisce in prima persona le evoluzioni dei propri sistemi informativi. d) Presenza di esperti del dominio applicativo di progetto. La scelta del dominio applicativo per il progetto di interoperabilità non è banale. ICAR-PAT (almeno al momento) e CASALPINA, per una precisa scelta dell amministrazione provinciale lavorano entrambi sul dominio socio-sanitario. In particolare CASALPINA coinvolge oltre alla

5 PAT, anche l Azienda Provinciale per i Servizi Sanitari (APSS) e alcune amministrazioni comunali (in particolare il Comune di Trento). Questo dominio garantisce un buon bilanciamento tra la specializzazione necessaria per affrontarlo e la ricchezza applicativa che lo contraddistinguono, ma richiede come è ovvio la presenza di esperti di dominio. Tali esperti non possono essere costituiti soltanto dagli appartenenti alle unità organizzative di riferimento delle istituzioni (APSS e Servizi Socio-Sanitari della PAT), ma devono essere anche affiancati da esperti provenienti da aziende e centri di ricerca che abbiano familiarità con le tecnologie che caratterizzano il dominio stesso. e) Lavoro di mediazione tra interessi contrapposti. La prima difficoltà nell implementare da un punto di vista organizzativo il tripolo dell innovazione è nel mediare tra interessi contrapposti, gestendo i conflitti tipici di ogni progetto complesso. Le tecniche con le quali si risolvono i conflitti che nascono all interno dei progetti di interoperabilità chiamano quasi sempre in causa aspetti relativi alla scelta di particolari strumenti informatici o alle caratteristiche che in un determinato contesto deve assumere una specifica implementazione. Se è vero infatti che per loro natura i progetti di interoperabilità privilegiano la scelta di formati e standard aperti (vedere il prossimo capitolo per gli approfondimenti), è pur vero che all interno di questo ambito ci si deve confrontare con una pluralità di opzioni che spesso devono fare i conti con le scelte del passato e i sistemi legaci presenti all interno delle singole organizzazioni. Il ruolo di chi governa e gestisce i progetti di interoperabilità diventa quindi un ruolo particolarmente delicato, perché esso deve caratterizzarsi come colui che pur utilizzando al meglio le competenze delle imprese e dei centri di ricerca deve evitare meccanismi di lock-in che non tutelano gli interessi delle amministrazioni e dei cittadini e che non sono di per sé fugati dalla scelta di adottare formati e standard aperti. La difficile via d uscita sembra in questo caso essere suggerita dall orientare le proprie scelte massimizzando l apertura e la flessibilità che la generanda infrastruttura di interoperabilità dovrà garantire, senza esasperare tuttavia atteggiamenti che non consentirebbero di massimizzare al contempo le competenze del territorio, comprendendo che per le architetture di interoperabilità sono possibili e necessarie anche scelte tattiche. f) Valorizzazione del risultato del lavoro, anche se effettuato sui back-end dei sistemi. Il lavoro necessario per garantire l interoperabilità e la cooperazione applicativa tra le istituzioni inizia dal back-office e dalle infrastrutture di back-end. Per far adeguatamente percepire a un pubblico vasto di cittadini e di amministratori i benefici dei progetti di interoperabilità è necessario allora individuare strumenti opportuni per divulgare quello che si sta realizzando. Questa individuazione è un processo faticoso che richiede tempi e modalità opportune e non può prescindere dal coinvolgimento attivo di tutti gli attori del progetto. Integrare i vari apporti in uno schema di sintesi che valorizzi le competenze di ciascuno genera quindi un costo aggiuntivo che va previsto se si vuole garantire alla propria iniziativa il successo necessario. Accanto ai temi ricordati nei paragrafi precedenti si sottolineano alcuni aspetti che allo stato attuale non sono stati affrontati, ma che potrebbero costituire materia di successivi approfondimenti. 1) Se l interoperabilità e la cooperazione applicativa non consentono la realizzazione di reti di relazioni reali sul territorio, vanno realizzate reti virtuali (per esempio a livello nazionale o sovranazionale). Rimane da chiarire in che modo le reti virtuali garantiscano un adeguato livello di condivisione degli obiettivi progettuali che abbia ricadute benefiche sui cittadini del territorio 2) Nei paragrafi precedenti è stata abbondantemente chiarita la necessità di sostenere effort adeguati per cementare la rete di relazioni della comunità che realizza l interoperabilità. Tali effort, oltre a costituire un sforzo in termini di costi progettauli, pongono il problema di trovare i giusti indicatori per effettuare una valutazione efficace delle attività di interoperabilità. 3) E' necessario approfondire ulteriormente il discorso che riguarda i diritti di proprietà delle infrastrutture di interoperabilità e delle conoscenze necessarie per realizzarle. Questo approfondimento è da effettuare non solo per chiarire il ruolo che i privati possono avere accanto alle istituzioni in questo contesto, ma

6 anche per stabilire in che modo garantire l esercizio di queste infrastrutture. Strumenti aperti e sperimentazione di soluzioni innovative: un esempio concreto Nel capitolo precedente abbiamo discusso due iniziative progettuali in cui la rete di collaborazioni fra istituzioni, aziende e centri di ricerca presenti sul territorio trentino viene sfruttata per permettere una migliore realizzazione di soluzioni di interoperabilità e cooperazione applicativa. Uno degli obiettivi di questo approccio e' permettere di adottare, in modo selettivo e mirato, soluzioni di avanzate e di ricerca all'interno di questi progetti. Si può, cioè, dosare l'utilizzo di queste soluzioni di ricerca, limitandolo agli aspetti più innovativi, e garantendo comunque la soluzione complessiva del problema con l'adozione di tecnologie assestate. In questo modo, si favorisce un trasferimento più efficace di soluzioni di ricerca in soluzioni funzionanti e in pratiche industriali e di permette, in senso inverso, di indirizzare l'evoluzione delle soluzioni di ricerca verso i problemi applicativi e tecnologici reali. Nel capitolo precedente, abbiamo analizzato i requisiti di natura organizzativa che sono necessari per realizzare questo tipo di approccio all'innovazione. In questo capitolo, analizzeremo un secondo aspetto, altrettanto importante: l'adozione da tutti gli attori di una piattaforma condivisa e basata su strumenti aperti per l'interoperabilità applicativa. Più che ripercorrere i numerosi e ben noti argomenti a favore dell'adozione dell'open source e dei formati aperti, che pure condividiamo e riteniamo fondamentali, vogliamo seguire in questa nota un approccio diverso e mostrare, su un esempio specifico, come l'utilizzo di strumenti aperti si sia dimostrato condizione indispensabile per l'adozione di idee e strumenti sviluppati dalla ricerca nell'ambito del progetto CASALPINA. Nell'ambito dell'interoperabilità e delle architetture orientate ai servizi, un tema di ricerca che sta riscuotendo un crescente interesse sia dall'accademia sia dalle grandi aziende (IBM, Oracle, HP prime fra tutte) e' quello del monitoraggio. L'interesse su questo tema ha due forti spinte, che analizziamo nel seguito. La prima spinta nasce dall'ovvio requisito di specificare, a livello di accordo di servizio, non solo gli aspetti funzionali relativi alla fornitura e all'utilizzo di un servizio, ma anche aspetti nonfunzionali relativi ai livelli di servizio (es. periodo di disponibilità del servizio, tempi di risposta, livello garantito di risposta positiva del servizio...). Questi parametri di Service Level Agreement sono necessari in fase di negoziazione per la definizione dell'accordo di servizio; altrettanto importante e' il monitoraggio di questi parametri a run-time, per rilevare deviazioni nelle modalità e nei livelli di fornitura dei servizi rispetto a quanto negoziato. Evidenza dell'importanza di questo tema sono sia l'attenzione da parte delle grandi aziende alla definizione di linguaggi specifici per la definizione dei requisiti si Service Level Agreement (si veda ad esempio il recente standard ws-agreement), sia lo sviluppo e la progressiva inclusione in piattaforme di supporto all'interoperabilità applicativa di strumenti e tecniche per il monitoraggio e di questi requisiti. Tale necessità di sviluppare strumenti per definire e monitorare Service Level Agreement e' riconosciuta infine anche nel progetto ICAR, dove anzi uno dei principali interventi infrastrutturali riguarda proprio lo sviluppo di questi strumenti. La seconda spinta a supporto dello sviluppo di strumenti avanzati di monitoraggio nasce dal requisito di realizzare anche nell'ambito delle architetture orientate ai servizi funzionalità di data warehouse e di business intelligence. tipiche degli ambiti centralizzati. E' infatti evidente che, se l'esecuzione di un processo e' distribuito e richiede l'accordo e la collaborazione fra più attori, anche un'analisi completa e un'estrazione efficace di informazioni di business intelligence non può che richiedere la collaborazione di questi attori. Pertanto, accordi di servizio e interoperabilità applicativa non devono riguardare solo la messa a disposizione dei servizi necessari ad eseguire un processo distribuito, ma devono normare e permettere anche l'accesso alle informazioni necessarie al data warehouse e di business intelligence. Questo aspetto e' evidente nel progetto CASALPINA, che si pone esplicitamente l'obiettivo di realizzare l'interoperabilità fra enti in ambito socioassistenziale non solo per quel che riguarda l'invocazione di servizi ma anche per quel che riguarda la realizzazione di funzionalità di data warehouse e l'estrazione di indicatori sul funzionamento dei vari enti che partecipano alla fornitura di servizi socioassistenziali. Questi indicatori sono la sorgente prima di informazioni per permettere alla Provincia di Trento di svolgere i suoi compiti di monitoraggio e governance su questi enti. Da un punto di vista tecnologico, le funzionalità per supportare data warehouse messe a disposizione dai singoli attori di un dominio di cooperazione altro non sono che servizi addizionali, che affiancano quelli

7 necessari per realizzare la logica applicativa. Da un punto di vista concettuale, e' però di fondamentale importanza distinguere le due tipologie di servizi : logica applicativa e logica di monitoraggio/dataware house hanno finalità e modalità operative diverse, spesso coinvolgono attori diversi (si pensi ad esempio all'ambito socio-assistenziale, in cui la Provincia di Trento non partecipa alla logica applicativa ma interviene solamente nella logica di monitoraggio per realizzare i suoi compiti di governance) e basandosi su strumenti diversi. E' perciò importante sviluppare soluzioni specifiche per realizzare la logica di monitoraggio/dataware house nell'ambito delle architetture orientate ai servizi: e' cioè importante realizzare uno strato specifico per questa logica che si basi sulle tecnologie base dei servizi, ma che le declini per realizzare le funzionalità specifiche richieste da questa logica. Si tratta, cioè, di sviluppare: (1) standard specifici per definire proprietà e servizi di monitoraggio/dataware house; (2) standard specifici per l'interoperabilità fra piattaforme per quel che riguarda l'invocazione di questi servizi di monitoraggio/dataware house; e (3) strumenti specifici che implementino questi standard. Questo modo di procedere e' prassi consolidata nell'ambito delle architetture orientate ai servizi in cui specifici standard intervengono a normare l'utilizzo dei servizi per realizzare specifiche funzionalità infrastrutturali (si pensi alla discovery basata sullo standard UDDI, oppure allo standard SAML per quel che riguarda autenticazione e autorizzazione). I centri di ricerca trentini coinvolti nel progetto CASALPINA (Università e ITC-IRST) sono attivi da vari anni nella ricerca nell'ambito del monitoraggio nelle architetture orientate ai servizi, sia per quel che riguarda il monitoraggio di Service Level Agreement, sia per quanto concerne il monitoraggio orientato al dataware house e alla business intelligence. In particolare, hanno sviluppato linguaggi e tecniche per supportare queste forme di monitoraggio e hanno realizzato strumenti di supporto che hanno raggiunto un buon livello di maturità. Il progetto CASALPINA e' pertanto l'occasione per applicare queste tecniche e questi strumenti in un dominio reale. Il progetto CASALPINA non si limita tuttavia a voler sperimentare questi strumenti avanzati di monitoraggio, ma vuole fornire una soluzione complessiva al problema dell'interoperabilità in ambito socio-assistenziale. Per questo motivo, gli strumenti di ricerca devono essere combinati con strumenti più assestati, basati su SPC/SPCoop, per supportare una soluzione complessiva del problema. L'adozione di strumenti open si e' dimostrata una precondizione fondamentale e una scelta necessaria per poter realizzare nei tempi del progetto questa integrazione fra strumenti innovativi di ricerca e tecnologie più assestate e permettere uno sviluppo organico e bilanciato dei diversi aspetti del progetto. Ci preme in particolare mettere in evidenza tre aspetti legati agli strumenti che si sono dimostrati fondamentali. 1. L'utilizzo di linguaggi standard aperti e estensibili tipici delle architetture orientate ai servizi da parte di SPC/SPCoop per la definizione dell'accordo di servizio permette una estensione puntuale e localizzate di questi accordi di servizio in modo da supportare i nuovi linguaggi di specifica necessari a descrivere la logica di monitoraggio/dataware house. Questa estensione non pervasiva permette di offrire un supporto specifico per le funzionalità avanzate di monitoraggio, recuperando pienamente l'esistente per quel che riguarda tutti gli altri aspetti relativi all'interoperabilità applicativa. 2. L'utilizzo di una piattaforma open source per la realizzazione delle funzionalità di Porta di Dominio (nel nostro caso, la Porta di Dominio realizzata da Insiel per la Regione Veneto) e' condizione necessaria per permettere l'inclusione degli strumenti sviluppati dalla ricerca a supporto del monitoraggio (anch'essi open source ) nella base di codice della Porta di Dominio. L'adozione di una soluzione non open source, sia per la Porta di Dominio di base, sia per le estensioni, sarebbe ostacolo molto severo alla sperimentazione, richiedendo la definizione di accordi e licenze specifiche. 3. Ancora più importate della licenza open source della Porta di Dominio adottata, e' fondamentale per supportare una sperimentazione efficace l'architettura aperta utilizzata nella realizzazione della Porta stessa. Questa architettura e' stata pensata per permettere un'agevole aggiunta o estensione di una specifica componente, come anche un utilizzo selettivo delle specifiche funzionalità di interesse in uno specifico ambito applicativo. Affianco alla licenza, e' proprio questa architettura a permettere una semplice integrazione dei prototipi di ricerca in un'architettura più ampia e a supportare l'utilizzo selettivo di idee innovative che si

8 vuole realizzare nel progetto. L'esempio presentato e', secondo noi, rappresentativo del ruolo indispensabile dell'utilizzo di strumenti aperti all'interno del sistema trentino per favorire la condivisione e il trasferimento di soluzioni e tecnologie fra i diversi attori coinvolti nei progetti di innovazione. E', dal nostro punto di vista, fondamentale anche in ottica evolutiva, per garantire una continua aderenza allo standard SPC/SPCoop, sia per favorire l'adozione eventuale di soluzioni risultate efficaci da parte dello standard SPC/SPCoop, sia in ottica inversa, ovvero di adeguamento della piattaforma trentina alle evoluzioni dello standard SPC/SPCoop. Conclusioni In questa nota abbiamo descritto la strategia adottata dalla Provincia Autonoma di Trento per favorire la realizzazione di una piena interoperabilità e cooperazione applicativa fra le amministrazioni. Abbiamo descritto in particolare due pilastri di questa strategia. Il primo pilastro consiste nella realizzazione di un sistema di collaborazioni sul territorio che coinvolga amministrazioni pubbliche locali, aziende e centri di ricerca. Questo sistema ha l'obiettivo di realizzare una collaborazione continuativa fra tutti gli attori necessari ad una corretta evoluzione delle tecnologie di interoperabilità, al fine di realizzare un incontro e un bilanciamento naturale fra problemi e requisiti dei domini applicativi (di competenza delle pubbliche amministrazioni), soluzioni e prodotti tecnologici assestati (di competenza delle aziende) e soluzioni innovative e di ricerca (di competenza dei centri di ricerca) Il secondo pilastro e' l'adozione da tutti gli attori di una piattaforma condivisa e basata su strumenti aperti per l'interoperabilità applicativa. Per strumenti aperti abbiamo inteso non solo soluzioni open source e formati aperti, ma anche architetture aperte, che permettano cioè l'aggiunta, l'evoluzione o l'utilizzo selettivo delle specifiche funzionalità di interesse in uno specifico ambito applicativo. L'utilizzo di strumenti aperti e' infatti indispensabile all'interno del sistema trentino per favorire la condivisione e il trasferimento di soluzioni e tecnologie fra i diversi attori. Nella nota abbiamo utilizzato due progetti di innovazione per illustrare e suffragare l'importanza dei due pilastri sopra menzionati. Questi progetti, anche se ancora in corso, hanno dato evidenze degli effetti positivi e dei possibili risultati derivanti dall'adozione della strategia sopra descritta.