Una strategia trentina per la realizzazione dell`interoperabilità e

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
Marco Pistore
Paolo Traverso
Informatica Trentina
[email protected]
ITC-IRST – Trento
[pistore, [email protected]]
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
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.
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.
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.
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”.
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
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
L’interoperabilità come innovazione di sistema: il
“tripolo” istituzioni-centri di ricerca-imprese
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 ICARPAT, 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
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
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
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
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
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.