Nella scelta degli strumenti da utilizzare per un determinato progetto di dematerializzazione, rientrano anche altre considerazioni che vanno oltre la scelta di quale applicativo utilizzare. A prescindere dalla soluzione o dalle soluzioni tecnologiche, vi sono infatti delle decisioni strategiche che caratterizzeranno in maniera determinante la tipologia di progetto e le modalità con cui esso potrà essere sviluppato e fruito.
Tra le scelte più rilevanti si evidenziano:
• La tipologia di strumenti usati (open source o proprietari), che determinano la flessibilità sia nello sviluppo sia nell’evoluzione del progetto;
• Le modalità di fruizione di tali strumenti (in house o software as a service), che determinano l’impatto di questi strumenti in termini economici e strutturali all’interno dell’organizzazione.
Verranno di seguito analizzate le dinamiche che guidano queste particolari scelte. Tipologia degli strumenti
2.4.1.
La prima scelta riguarda la natura degli strumenti che dovranno essere utilizzati: esiste infatti la possibilità di utilizzare sia prodotti open source che prodotti proprietari. A prima vista la scelta può sembrare banale e confinata al solo aspetto tecnologico, ma in realtà essa incide in modo profondo sulla cultura e sul modo con cui l’organizzazione approccia e gestisce la tecnologia e sui futuri progetti di evoluzione.
Il software open source, chiamato anche “software libero” in una sua accezione più evocativa, è quel software per cui lo sviluppatore rilascia liberamente il codice sorgente che sta alla base del software stesso. Per tali applicazioni è quindi garantito il diritto dell’utente di eseguire liberamente il programma, di studiarne il funzionamento e adattarlo alle proprie esigenze, di copiare e migliorare il programma, e di redistribuire liberamente copie e miglioramenti al pubblico96. Il software libero non viene tipicamente
venduto direttamente, seppur questo sia possibile, ma viene piuttosto usato come vettore gratuito per l’eventuale offerta di una serie di altri servizi accessori al software stesso, come per esempio l’assistenza o pacchetti aggiuntivi esclusivi.
96 Definizione di Software Libero, Free Software Foundation, http://www.gnu.org/philosophy/free-
Capitolo 2 - Dematerializzazione: elementi caratterizzanti e tecnologie
Un software di tale tipo viene rilasciato usando una delle licenze open source definite dal consorzio OSI97, tra le quali le più utilizzate sono la GNU/GPL, in tutte le sue varianti, la
BSD, la Apache e la EUPL, una licenza rilasciata dall’UE appositamente per le PA. Tali licenze pongono determinati vincoli legali sui software licenziati, stabilendo alcune regole per il rispetto della proprietà intellettuale degli autori, tutelandone quindi abusi e appropriazioni illecite, e preservando il funzionamento dell’intero movimento open source, garantendo comunque all’utilizzatore i diritti e i principi precedentemente esposti. Il movimento open source nell’ultimo decennio è stato caratterizzato da una forte crescita e, analizzando il mercato delle soluzioni precedentemente esposte98, non è raro oggi
trovare soluzioni software di successo che seguono questo paradigma anche a livello enterprise, come ad esempio Alfresco (DMS/ECM), Drupal (CMS), Liferay (Web Portal), e altri. Questi software, proprio per la loro natura aperta, si stanno diffondendo anche presso le PA.
I software proprietari invece, seguono solitamente dinamiche commerciali, vendendo direttamente il software attraverso una “licenza d’uso” che non attribuisce all’utente la proprietà del software, ma ne permette l’utilizzo nei modi definiti dagli stessi sviluppatori. Questa tipologia di software è ancora la più diffusa utilizzata in ambito enterprise, soprattutto per una maggiore maturità dei prodotti, presenti sul mercato da più tempo, e per la presenza di servizi di assistenza e garanzia qualificati.
Tra questi due approcci antitetici, vi sono poi una serie di “sfumature” intermedie o di combinazioni che portano spesso alla definizione di un offerta software complessa: per esempio è frequente trovare un determinato applicativo open source disponibile gratuitamente per uso non commerciale, che diventa invece a pagamento per uso aziendale, offrendo alcune funzionalità aggiuntive e supporto qualificato.
Risulta chiaro come, in questo contesto, la Pubblica Amministrazione si trova di fronte ad una scelta non banale, che deve essere attentamente valutata in base a considerazioni non solo tecnologiche ma anche economiche, organizzative e, essendo comunque un servizio pubblico, anche politiche.
Studi del CNIPA99 (ora DigitPA), indicano come l’uso di tecnologie open source in una PA
sia una pratica auspicabile, in particolare in garanzia del riuso di tali tecnologie tra più
97 Elenco completo delle licenze ritenute open source dall’OSI (Open Source Initiative)
http://www.opensource.org/licenses/alphabetical
98 L’analisi del mercato è stata effettuata basandosi sui Magic Quadrant di Gartner, ove disponibili. 99 Rapporto conclusivo gruppo di lavoro “Codice Sorgente Aperto”, CNIPA, 2004
amministrazioni e dell’aderenza a formati aperti. Il nuovo CAD inoltre, stabilisce che, in una gara pubblica di fornitura, il software open source venga equiparato a tutti gli effetti al software proprietario, indirizzando quindi gli Enti verso un atteggiamento che non contrasti queste soluzioni, a differenza di quanto fino ad ora poteva accadere.
Una presa di posizione sulla bontà di una soluzione open source rispetto a una proprietaria è sempre difficile, in quanto i parametri da valutare sono diversi caso per caso e dipendono fortemente dalla situazione organizzativa e tecnologica in cui tali software vengono implementati. Il seguente elenco propone una sintesi delle considerazioni più comuni sui vantaggi e gli svantaggi pratici dell’uso di tecnologia open source rispetto al software proprietario:
Vantaggi
• Risparmio nei costi di licenza;
• Possibilità di personalizzazione e adattamento alle esigenze specifiche (flessibilità); • Attitudine all’aderenza a standard e formati aperti;
• Indipendenza da fornitori specifici;
• Trasparenza, data dalla possibilità di accesso al codice sorgente; Svantaggi
• Generalmente minori garanzie di solidità e innovazione dei vendor;
• Completezza funzionale solitamente di ordine inferiore ai corrispettivi software “best of breed” commerciali;
• Qualità della documentazione e del supporto fornito; • Dipendenza da terze parti e dalla comunità.
In termini assoluti non è possibile dire che un modello è migliore di un altro, ma la scelta deve essere valutata esigenza per esigenza e inserita all’interno di una precisa strategia di evoluzione dei Sistemi Informativi.
Modalità di implementazione e fruizione 2.4.2.
Oltre alla natura degli strumenti tecnologici usati in un progetto, è anche fondamentale stabilire le modalità di implementazione e fruizione degli stessi. La scelta che si pone è quella di definire se implementare tali soluzioni internamente, ovvero nei sistemi informativi interni all’Ente o comunque di sua proprietà, oppure di affidarsi a provider esterni.
Capitolo 2 - Dematerializzazione: elementi caratterizzanti e tecnologie
Sintetizzando tali modelli è quindi possibile definire i due paradigmi alla base delle possibili scelte di un organizzazione:
Paradigma “in house”: l’applicazione viene implementata internamente o integrata nei SI dell’Ente, rappresentando a tutti gli effetti una proprietà dell’amministrazione.
Paradigma “as a service”: si fruisce di un applicazione di proprietà del provider, gestita interamente da esso nel proprio SI ed, erogata verso l’Ente attraverso un interfaccia web- based. Solitamente in questo caso viene proposta una sottoscrizione d’uso, per la quale l’Ente paga un corrispettivo in base ad alcune caratteristiche tecnico-organizzative (es. numero dipendenti, funzionalità, etc.) e/o al consumo effettivo del servizio.
Entrambi i paradigmi hanno sia vantaggi che svantaggi, che anche in questo caso devono rientrare nelle scelte dell’organizzazione, in relazione alla tipologia di progetto da sviluppare.
Con il paradigma in house, l’Ente mantiene il controllo totale sull’applicazione e sui dati in essa contenuti, dovendosi per contro accollare gli oneri di sviluppo, gestione e manutenzione della stessa. Inoltre questa soluzione soffre di rigidità operativa, in quanto le prestazioni dell’applicazione sono fortemente legate all’infrastruttura tecnologica disponibile.
Con il paradigma del software as a service, invece, demandando in outsourcing la completa gestione dell’applicativo e, di conseguenza, dei dati in essa contenuti, l’Ente si assume un rischio intrinseco di sicurezza legato alla fiducia riposta nel provider scelto, che in sistema pubblici che spesso gestiscono informazioni sensibili è un parametro da tenere in forte considerazione. Inoltre le possibilità di personalizzazione dell’applicazione sono ridotte al minimo ed è necessario valutare attentamente l’implicazione di possibili discontinuità nel servizio. Questo modello però, consente forti risparmi e semplificazioni per la gestione IT dell’Ente, che non si deve più occupare internamente di assicurare la disponibilità dell’applicazione o la sua manutenzione, né deve prevedere l’acquisto di nuovi server. Pagando per ciò che effettivamente si consuma, si beneficia inoltre di una maggiore efficienza della spesa e di una trasformazione di costi fissi in costi variabili. Essendo inoltre che tali soluzioni sono realizzate in sistemi cloud, nei quali vi è un disaccoppiamento tra la parte applicativa e l’hardware sottostante, la flessibilità operativa è garantita ed è in questo modo più agevole rispondere a eventuali picchi di domanda. Questi due paradigmi rappresentano gli estremi delle possibili scelte: vi sono però una serie di modelli intermedi che spesso rappresentano la scelta più indicata per determinati tipi di contesti organizzativi e tecnologici. Ad esempio è attualmente diffuso il modello
dell’Infrastructure as a Service (IaaS) nel quale il fornitore non offre all’organizzazione l’applicazione finale, ma un’infrastruttura fruibile da remoto che permette la realizzazione delle applicazione da parte dell’organizzazione stessa o di un altro fornitore. In questo caso è possibile quindi realizzare specifiche applicazioni dedicate, che seguono le evoluzioni stabilite, mantenendo comunque per l’organizzazione il vantaggio di non dover gestire al proprio interno la complessità tecnologica di base necessaria al relativo funzionamento.
Spesso le soluzioni software as a service veicolate sul Sistema Pubblico di Connettività nazionale, vengono utilizzate dalle Pubbliche Amministrazioni Locali più articolate, come le Regioni o le Provincie, per fornire servizi applicativi a Comuni o Enti pubblici che altrimenti non avrebbero i mezzi e le competenze per sviluppare internamente tale soluzione. Un esempio è rappresentato dall‘Albo Pretorio Online, diventato recentemente obbligatorio. Alcune province (ad es. Como) hanno infatti realizzato una piattaforma per offrire un Albo Pretorio sovracomunale, in cui ciascun comune potesse pubblicare, in un’apposita sezione dedicata, i propri Atti, senza dover realizzare internamente una soluzione dedicata. In questo modo, oltre a semplificare il lavoro degli Enti locali più piccoli, è stata garantita anche una certa centralità organizzativa e una unificazione delle piattaforme software utilizzate dalle amministrazioni, che è uno degli annosi problemi che contraddistinguono la PA moderna.
Il modello software as a service sta avendo negli ultimi anni una forte spinta dal mercato, portando d’altronde con sé molti punti di attenzione che le PA devono tenere in debita considerazione. Tra questi il rispetto dei livelli di servizio (SLA) e il trattamento dei dati personali sono certamente i più rilevanti. Saper gestire tali soluzioni e le potenzialità che esse offrono all’interno dei rigidi vincoli normativi che caratterizzano un ambiente come la PA è infatti una sfida da non sottovalutare.