All Around Work
Applicazioni
 

17/09/2015

Share    

Verso un salto di qualità inevitabile

L’open source non è più solo un tema dell’IT e deve parlare al business. Per questo all’interno sia dei sistemi informativi aziendali sia delle società di consulenza bisogna ora puntare a un salto verso la piena maturità di questo tema nel suo complesso. Questa e altre considerazioni sono emerse dal confronto organizzato con sette rappresentanti di aziende ed enti pubblici utilizzatrici di soluzioni open source.

L’open source da tempo ha superato la fase pionieristica e si sta radicando sempre di più in molte imprese italiane sul fronte originario delle infrastrutture ICT, generalmente server, ma anche su quello delle applicazioni. Il fenomeno è in crescita, e questo lo diciamo da anni, ma nonostante questo rispetto alle soluzioni commerciali o al tema ‘antico’ dello sviluppo custom soffre ancora di una certa immaturità. Cosa manca quindi perché le soluzioni open source diventino una componente che possa presentarsi con la stessa autorevolezza delle altre opzioni tecnologiche?
È quanto la redazione di Office Automation ha cercato di capire grazie a una tavola rotonda organizzata su questo argomento a fine giugno che ha visto la partecipazione di sette rappresentanti di aziende utenti che da tempo utilizzano le soluzioni open source in diversi ambiti. Ne è nata una discussione interessante e approfondita che riproponiamo in queste pagine, ma poiché siamo convinti che l’importanza della posta in gioco sia molto alta, il tema verrà affrontato anche il prossimo 24 settembre a Milano in occasione della prossima Open Source Conference organizzata dal nostro editore Soiel International.


Attraverso questo articolo e l’appuntamento di Milano cerchiamo di portare un contributo culturale ricco su un argomento che in realtà viene trattato da pochi nel nostro Paese, pur coinvolgendo ormai decine di migliaia di organizzazioni IT di aziende private e di enti pubblici. Nel nostro piccolo da anni siamo convinti che invece questo fenomeno non vada sottovalutato e cerchiamo di allinearci sempre di più all’evoluzione della domanda del mercato. Perciò a presentazione di questa tavola rotonda diciamo solo che dai diversi interlocutori è emersa la consapevolezza che l’open source è ormai pronto per fare un salto di qualità, che deve essere guidato dall’organizzazione IT interna, in due direzioni fondamentali. Nel rapporto con il business e con il top management della propria realtà, e su un secondo versante nel rapporto con le società di consulenza dove la cultura del servizio è ancora carente. Con le community invece sono le aziende utenti che sentono di dover migliorare il loro approccio a queste relazioni. Ma questi sono solo alcuni dei temi più importanti emersi in occasione della nostra tavola rotonda. Buona lettura.

Quando e perché avete deciso di utilizzare soluzioni open source, i vantaggi riscontrati e quali invece le criticità?

Davide Blanchetti, ICT Manager Responsabile Domanda e Sviluppo Applicativo di Edenred Italia. Edenred Italia, nota per aver inventato i Ticket Restaurant®, è un pure player nel mercato della gestione dei fondi finalizzati per le imprese ed è è tra i principali protagonisti mondiali del mercato delle carte e dei voucher di servizio prepagati. È specializzata nell’ideazione e nella realizzazione di soluzioni innovative per promuovere il benessere delle persone e le performance delle organizzazioni: dai benefit per le risorse umane alle spese professionali, dai programmi di incentivazione e motivazione fino a progetti di welfare aziendale e ai programmi ad hoc per la pubblica amministrazione.
Open source è oggi un tema molto vasto e sotto il suo cappello si raccolgono argomenti diversificati che comprende: sistemi, reti, application server e software di front end che viene esposto verso gli utenti finali attraverso portali.
A seconda delle esigenze utilizziamo software sviluppato da vendor che operano sul mercato, sistemi custom che implementano soluzioni specifiche per la nostra realtà e soluzioni open source. Di volta in volta scegliamo la soluzione ritenuta migliore. La nostra esperienza open source parte nel 2008, quando abbiamo analizzato le soluzioni per l’area portali e uno dei driver è stato naturalmente il risparmio economico. Ma attenzione paragonare questi software alle soluzioni commerciali non è un’attività facile a causa dei costi nascosti dell’open source, dovuti a diversi fattori.
Oltre all’aspetto economico quindi prendiamo in considerazioni altri due elementi. Il primo è la maturità del software in valutazione: partiamo dai quadranti Gartner per valutare il posizionamento dei prodotti della tipologia che ci interessa e cerchiamo di capirne le linee evolutive. Il secondo è la popolarità e la vivacità delle community che sono legate al prodotto open source di riferimento. C’è molta differenza in termini di vivacità tra community da 100.000 persone e community da milioni di persone. Scegliamo sempre soluzioni supportate dalle community più numerose, questo per poter usufruire di una maggiore qualità nel supporto nel momento in cui dovremo affrontare problemi.
Verso business e top management è però più facile esporre i vantaggi di una soluzione open source quando questa ha un elevato livello di maturità e può essere comparata a soluzioni commerciali. Negli altri casi si incontrano sempre resistenze.
Nel caso portali, un altro fattore entrato in gioco è stata la disponibilità del prodotto nelle due versioni open source ed enterprise. Nel 2008 era uno dei primi a mettere a disposizione le due linee; oggi è pratica diffusa. Ci siamo lasciati la ‘porta aperta’: se la versione open source sarebbe risultata stretta, saremmo migrati a quella enterprise usufruendo così anche del supporto del vendor. Ma grazie alla community di riferimento molto attiva abbiamo sempre risolto tutti i problemi incontrati.
Questo è un aspetto interessante che tengo a sottolineare. Quando lavorando su una soluzione open source sorge un problema, si ha sempre la percezione che sia una difficoltà specifica legata al contesto. Nel rapporto con la community invece si scopre spesso che problemi analoghi o uguali sono già stati risolti più di una volta, generando anche evoluzioni del prodotto.
Tornando all’eterogeneità della nostra base applicativa, è importante tener presente come sia necessario disporre di una soluzione infrastrutturale sottostante molto strutturata. Abbiamo quindi implementato tra le altre cose anche un’importante architettura SOA che permette di esporre una buona parte delle nostre funzionalità in ottica multicanale. Una funzionalità open source, custom o di un prodotto di mercato può essere esposta a richiesta sul portale, la volta dopo sul canale mobile oppure verso partner esterni che la integrano nelle loro soluzioni. L’architettura SOA è determinante per abilitare quella piena libertà di scelta sulle diverse soluzioni applicative (custom, vendor e open source) a cui accennavo prima.

Giovanni Grazia, Responsabile Progettazione, Valutazione e Implementazione Open Source presso il Dipartimento IT della Regione Emilia-Romagna. La prima esperienza open source, non vissuta direttamente da me che sono arrivato dopo, della Regione Emilia Romagna è del 1995 e si scontrò all’epoca con il grosso problema della mancanza di un supporto professionale adeguato. Si tornò quindi rapidamente a una piattaforma vendor.
Nel 2005 dopo anni nei quali abbiamo assistito a una grossa crescita di server dipartimentali si è rivalutata l’offerta open source: nello spazio di dieci anni erano infatti cresciute le competenze della community, ma anche quelle dei fornitori ai quali assegniamo la maggior parte del lavoro sistemistico, di sviluppo e di integrazione. Dalle nuove esperienze del 2005 abbiamo aperto delle filiere di sviluppo attive ancora oggi che guardano nello specifico al mondo server.
Primo punto chiave quindi per portare avanti il nostro approccio è lo sviluppo delle competenze sia interne sia esterne. Sicuramente il basso costo iniziale delle soluzioni open è un vantaggio. È un fattore che permette di studiare ed esplorare a fondo la soluzione scelta e che lascia la libertà di decidere in piena consapevolezza se andare avanti o abbandonare l’ipotesi, oppure quando e come adottare la soluzione studiata. Ma la cosa più importante dell’open source è la garanzia di libertà di scelta nel tempo. Ogni soluzione open porta con sè un importante patrimonio di standard aperti supportati. Nel nostro ambiente, per esempio, dal 2005 a oggi abbiamo traghettato soluzioni in tre diverse distribuzioni Linux server, senza grossi impatti. La combinazione tra codice aperto e standard aperto è quello che veramente libera l’IT dal lock in che invece per motivi commerciali si verifica con le soluzioni proprietarie.

Massimo Pessina, ICT Infrastructure, Service Management and ICT Security di Saipem. Saipem è uno dei leader mondiali nei business di Engineering & Construction e Drilling, con un forte orientamento verso attività nel settore Oil&Gas in aree remote e acque profonde. Opera in più di 60 Paesi con circa 50.000 dipendenti di 130 nazionalità diverse. Lato IT, il nostro obbiettivo è assicurare il pieno svolgimento del servizio nei cantieri e nelle filiali attive in questi Paesi e le problematiche da risolvere sono sempre sostanziali. In questo contesto il mio ruolo è quello di referente delle infrastrutture centralizzate, e la mia esperienza open source è consolidata sulle tematiche di infrastruttura, perché questo è l’ambito in cui Saipem ha scelto primariamente di introdurre soluzioni di questo tipo.
Sono d’accordo nel dire che nell’open source ci sono molti costi nascosti che sono comunque controbilanciati da un investimento iniziale limitato che nel tempo crescerà perché le soluzioni in produzione necessitano di continui aggiustamenti. È molto difficile tenere sotto controllo i costi nascosti e ci sono criticità relative alle competenze in Italia su alcune nuove tematiche di nicchia. I temi sistema operativo Linux e application server open source da tempo, come per tutti, sono invece consolidati. Il nostro obiettivo primario è dove possibile ridurre i costi IT per le attività a supporto dell’IT stessa, e molte soluzioni open source sono valide alternative a quelle di mercato. Come esempio posso citare il fatto che da quest’anno abbiamo affidato a una soluzione open source il processo di discovery/ inventory per classificare tutti gli oggetti (server, network device e quant’altro) che dobbiamo tenere sotto controllo in un ambiente dove le operation di Saipem sono dislocate in tutto il mondo: la soluzione open source adottata ci ha permesso di risparmiare svariate migliaia di euro se confrontata con la precedente soluzione commerciale in essere. Nel tempo questo risparmio è destinato ad abbassarsi, ma credo che si manterrà consistente. Preferibilmente utilizziamo le release enterprise delle soluzioni open source per ragioni di supporto, ma poiché in certi casi anche queste si dimostrano essere un po’ chiuse, non disdegnamo l’adozione delle versioni community e sviluppiamo in casa quanto ci serve. Un progetto molto interessante che stiamo affrontando è legato al tema hybrid cloud. Gestendo un’architettura decentralizzata utilizziamo una piattaforma di virtualizzazione commerciale molto spinta, e sempre nella logica del risparmio dei costi dell’IT sull’IT vorremmo costruire in casa l’hybrid cloud utilizzando OpenStack. Sicuramente tecnologia oggi molto in voga, tutte le aziende ne offrono una distribuzione commerciale, ma il prodotto – nato da sviluppatori per rispondere ad esigenze di altri sviluppatori non è facilmente integrabile con realtà enterprise ed il costo di implementazione necessario a supportare le nostre esigenze è attualmente ancora elevato. In ogni caso abbiamo uno studio sul TCO della soluzione che continuiamo a mantenere aggiornato ogni volta che vengono rilasciati nuovi sviluppi.
La piattaforma di virtualizzazione di partenza è il punto critico. Per le soluzioni costruite su Linux il passaggio a OpenStack è più naturale, mentre nel caso di sistemi di virtualizzazione dei principali vendor, una realtà complessa ed eterogenea come la nostra si trova davanti una strada piuttosto complicata.

Oscar Baracchi, Responsabile Servizio Informatico Comunale, Comune di Vigevano. Il comune di Vigevano è una piccola realtà che amministra una cittadina di 64.000 abitanti in provincia di Pavia. I primi approcci all’open source risalgono al 2000, purtroppo a causa di un inconveniente subito dalla nostra architettura che all’epoca integrava ambienti di diversi vendor: cadde una delle due istanze sempre attive del database sul file server portandosi dietro 220 utenti collegati. Verso l’open source in quegli anni avevamo un atteggiamento bivalente, da un lato scetticismo dall’altro curiosità. Avendo però letto diversi articoli su autorevoli quotidiani economici che parlavano ormai di quanto si potesse considerare robusto e stabile l’ambiente Linux, allora abbiamo deciso di provare una soluzione alternativa rispetto a quanto avevamo in produzione fino al giorno dell’incidente. Toccato con mano che l’ambiente Linux si confermava stabile, robusto e assicurava le prestazioni che ci aspettavamo, peraltro su hardware di recupero, abbiamo iniziato sempre a valutare con attenzione le soluzioni del mondo open source alternative a quelle che avevamo in casa. Nel tempo abbiamo esteso l’utilizzo di queste in molteplici ambiti: accesso remoto, firewall e proxy, monitoraggio interno del traffico di rete, statistiche sulla rete civica e sulla intranet del comune e altro ancora. Siamo complessivamente soddisfatti e i costi di implementazione e di messa a punto delle soluzioni tutto sommato sono accettabili. Confermo che la facilità di migrazione da un prodotto a un altro è un fattore determinante nella scelta dell’open source, perchè non si hanno vincoli e non avendo pagato licenze e contratti di manutenzione ci si sente molto più liberi. Abbiamo una struttura interna di sette persone (sei tecnici una amministrativa) e per buona parte dell’open source lato server ci appoggiamo a una società esterna, che può contare su skill più aggiornati dei nostri, relativi alle novità dei prodotti. Anche nel nostro caso ci siamo comunque sempre orientati su prodotti maturi, ove possibile con community molto vaste che forniscono tutte quelle garanzie che per un’organizzazione come la nostra sono necessarie sotto il profilo del supporto. Internamente una persona dello staff IT si occupa anche di sviluppo software web, sempre con strumenti open, e su queste soluzioni possiamo contare su una certa esperienza in fatto di integrazioni anche con ambienti non open. Nel nostro sistema informativo infatti convivono anche applicazioni di vendor/soluzioni verticali e specialistiche per i comuni, non open source. Quando si presenta la necessità di utilizzare dati generati da diverse applicazioni, questi sviluppi sono sempre stati fatti in casa, utilizzando strumenti open. L’esperienza è complessivamente positiva, ma, nel tempo, abbiamo vissuto anche delle criticità su diversi fronti che posso approfondire più tardi.

Luigi Caligiuri, Responsabile Sviluppo e IT Manager parte assicurativa e viaggi del portale Segugio.it. – Gruppo Mutui On Line. Il Gruppo, nato nel 2000 è diviso in due strutture: la parte Broking, nella quale è inserita anche la mia organizzazione, che si occupa della comparazione e della intermediazione dei prodotti su Internet; una seconda struttura focalizzata sul Business Process Outsourcing a supporto di banche, finanziarie, compagnie di assicurazione, società di asset management. Gruppo MOL, quotato in borsa, ha integrato nel tempo numerose società e anche il portale Segugio. it è un grande esempio di integrazione: una serie di servizi e di sezioni del portale sono gestiti in open source, e altri servizi e sezioni sono gestiti con soluzioni tradizionali. È così che nello stesso portale diverse sezioni sono costruite con versioni diverse di diversi linguaggi di programmazione: asp.net, .net, Java, php e altri ancora.
Vista la nostra storia continuiamo a fare molta integrazione poiché più dell’80% degli applicativi sia client sia server sono creati e gestiti da noi. Tutti i giorni affrontiamo problematiche legate al rapporto tra le soluzioni open source e l’ambiente Microsoft. Personalmente la mia professionalità grazie alle esperienze precedenti è cresciuta quasi esclusivamente nel mondo open source e tendo a privilegiare sempre soluzioni di questo mondo. Questo anche perché oggi molte soluzioni proposte da diversi vendor sono in realtà loro customizzazioni di prodotti open source, o loro brandizzazioni.
Quella dei costi nascosti è la problematica più grande con la quale ci scontriamo tutti i giorni. Facendo tutto in house le persone dello staff devono essere continuamente aggiornate su tutte le soluzioni che utilizziamo. Ma quando abbiamo un problema, siamo abbastanza sicuri che riusciamo ad affrontarlo e a risolverlo nel giro di poco tempo, mentre quando altri hanno un problema con un prodotto di mercato, a seconda dei livelli di servizio concordati, la risposta del fornitore può arrivare anche con tempi lunghi.
Il problema di business numero uno è la competitività con gli altri portali, ma soprattutto l’ottimizzazione del sito per Google e quindi dobbiamo stare molto attenti alle mosse di questo importante attore di mercato. Per esempio, ora che Google ha deciso che darà maggior evidenza a siti/pagine che dispongano di una versione mobile dei siti, allora tutti quanti noi dello sviluppo abbiamo come priorità la versione mobile.
Anche sul fronte infrastruttura preferiamo le soluzioni open source e oggi siamo interessati alle soluzioni a supporto del cloud. L’open source è una scelta vincente anche per i prossimi tempi perché permette a un’organizzazione IT di stare sempre sulla breccia.
Infine non si può non notare che anche i grandi vendor proprietari si stanno aprendo perché credo siano positivamente influenzati dalle dinamiche dell’open source.

Andrea Bettoni, Information Technology Manager, Diapath SpA. Diapath SpA è un’azienda italiana affermata a livello internazionale, specializzata nello sviluppo di tecnologie per il settore biomedicale che progetta, produce e distribuisce strumenti, reagenti e consumabili impiegati nelle procedure di analisi dei laboratori di anatomia patologica. Siamo circa in 80 persone, due nello staff IT. Il core business viene gestito da soluzioni proprietarie. Le operation devono sempre andare avanti secondo i piani, non possiamo permetterci di fermare un laboratorio di analisi, e quindi l’ERP è la soluzione di un vendor internazionale. Anche la progettazione è un’attività core e quindi è gestita da sistemi CAD sviluppati da diversi vendor. In questo scenario, gli unici ambiti di intervento dell’open source che l’IT riesce a mettere in campo sono quelli ‘no core’. Lavorando solo su gare d’appalto, tutte le logiche degli acquisti nella PA sono imperniate, per la stragrande maggioranza sul prezzo più basso e non sulla qualità delle funzionalità, quindi la salvaguardia della marginalità è molto importante. Anche l’IT deve contribuire in tal senso cercando di mantenere i costi di infrastruttura i più bassi possibili nonostante vincoli indotti dai sistemi core. Per questo, al momento di selezionare il mio collaboratore, uno dei driver di selezione è stato proprio la dimestichezza con l’open source, non a caso una delle domande principali poste ai diversi candidati è stata “Come te la cavi con l’open source applicato in azienda?” Il vantaggio innegabile dell’open source sta nel fatto che ogni richiesta o problematica che emerge dal nostro cliente interno viene messa in atto con tempi di risposta risibili.
Inoltre, come già detto da altri, l’open source consente di provare le soluzioni che stiamo sviluppando a costo quasi nullo. Se uno sviluppo si rivela non appropriato al nostro obiettivo lo possiamo fermare tranquillamente, non abbiamo speso soldi, abbiamo solo investito il nostro tempo. Ma per l’imprenditore il costo delle nostre ore è comunque fisso. Questo però è anche un limite e con il tempo sto cercando di portare l’azienda a ragionare in altro modo, vista anche la mia esperienza precedente in aziende manufacturing sempre molto attente a definire ogni tipologia di costo.
Se infatti è difficile far risaltare il costo dell’impegno dello staff IT nello sviluppo dell’open source, questo aspetto si ribalta poi negativamente perché è anche difficile far percepire la reale consistenza dei risparmi che si riescono a ottenere. È vero che nell’open source ci sono dei costi nascosti, ma ci sono anche dei vantaggi nascosti difficili da far percepire nelle piccole realtà. Probabilmente nelle realtà più grandi dove esiste una cultura manageriale vengono applicati dei modelli che potrebbero essere mutuati anche su scala più piccola.
Infine, un’altra criticità per staff IT molto piccoli è il fatto che risulta difficile coltivare i rapporti con le community. In questa relazione è anche molto importante la modalità di approccio e di presentazione delle problematiche che chiediamo di affrontare. Quando non ci si pone nel modo giusto, ti rispondono di andare a consultare il manuale. Chi crede che il ruolo della community sia quello di fornire un servizio di assistenza, si sbaglia e se ne accorge in fretta.

Gabriele Colombo, Responsabile Divisione Telecomunicazioni, AGSM Verona. AGSM è la multiutility di proprietà del comune di Verona. Oltre ai servizi ‘core’ quali energia elettrica e gas, AGSM come operatore eroga servizi di telecomunicazione (mainteiner, accesso internet, servizi di videosorveglianza, housing e hosting applicativo e servizi ISP) basati quasi interamente sulle centinaia di km di fibra ottica distribuita sul territorio veronese di cui è proprietaria.
L’approccio all’open source di tipo applicativo risale al 2011. Il driver utilizzato per la scelta, come spesso succede per le soluzioni di tipo open source, è generalmente quello economico. Il vantaggio di queste soluzioni è che partono a costo zero e sono di conseguenza allettanti. L’errore che spesso accompagna la loro valutazione è che a fronte di un costo minimo o inesistente ci si può permettere facilmente di sbagliare. Questo tipo di approccio, radicato anche nelle strutture ICT è sostanzialmente sbagliato in quanto trasmette la sensazione che le soluzioni di tipo open siano di bassa qualità e poco affidabili, mentre il mercato, specialmente nel mondo sistemistico, ci dice esattamente il contrario. Il senso comune che dicevo prima è quindi sicuramente un atteggiamento da combattere.
Il nostro approccio applicativo al mondo open è relativo all’uso di una soluzione di asset management per il mondo IT. Si tratta di CMDbuild, soluzione open realizzata secondo le linee guida ITIL relative al Cmdb (configuration management database) che ci ha consentito di catalogare secondo un modello dati da noi elaborato tutte le informazioni relative agli asset del mondo TLC distribuiti sul territorio. La natura open dell’applicativo basato sugli standard internet (Apache, PostgreSQL, Shark, Liferay, IReport) ci ha consentito l’evoluzione necessaria per integrare il nostro sistema di monitoraggio (anch’esso open) con gli asset registrati in modo tale che ogni allarme ricevuto venga confrontato con le informazioni registrate che indicano quali azioni intraprendere, oltre ad accompagnare la segnalazione con una scheda che consente di percepire in modo immediato la gravità del guasto ed effettuare l’analisi d’impatto sul sistema.
Le evoluzioni successive ci hanno portato a sviluppare il sistema di trouble ticketing sia per il mondo TLC che per i servizi informativi (multi azienda) sulla stessa piattaforma abbiamo così ottenuto diversi vantaggi dall’integrazione e dal censimento dei servizi e degli asset gestiti dalla struttura sistemi informativi e da quella TLC. Oltre a questa particolare rilevanza, la soluzione è stata aperta al processo commerciale che, tramite il workflow gestito da Shark, è sviluppato completamente nella soluzione e consente la distribuzione dell’informazione tra le strutture di pre e post vendita dei servizi abilitando i clienti all’accesso al sistema di trouble ticketing. Come tutti i prodotti, l’inizio è stato incerto ed abbiamo scontato qualche imperfezione che, grazie al supporto del mainteiner sono state superate velocemente. Con il tempo le persone hanno arricchito molto la loro esperienza e oggi sono tecnicamente valide sotto tutti i profili; parallelamente è cresciuto anche il prodotto che oggi è giudicato ottimo dalla community delle aziende che lo utilizzano.
Uno dei problemi delle soluzioni open è che non sempre sono supportate da società in grado di far esprimere il completo potenziale. È necessario trovare partner fortemente orientati al supporto clienti con consulenti che siano allineati alle sempre più stringenti esigenze di business che le aziende sperimentano.
Questa è spesso la ragione che spinge le grandi aziende ad affidarsi ai big della consulenza ovvero perché percepiscono il valore di un supporto molto forte e l’orientamento alla condivisione dei risultati, atteggiamenti in generale pregiati e di valore.

Caligiuri, Segugio.it. Molto spesso nelle mie esperienze precedenti mi sentivo dire: “Se il progetto non è basato sulla soluzione di un vendor non si fa ”; e non sempre nell’open source si riescono a definire degli SLA precisi. Però se il tuo interlocutore è un management che ha propensione verso l’innovazione ed è attento, tra i tanti aspetti, anche ai costi allora riesci a far accettare anche questi compromessi.
Il punto è essere in grado di ‘saper vendere’ la soluzione open source, e qui si sconta il fatto evidenziato dal collega, ovvero che spesso abbiamo dei professionisti tecnicamente molto bravi che però non sono in grado di parlare con il cliente.
Come argomento favorevole all’open source posso aggiungere il fatto che spesso riusciamo a essere nella risposta al business anche più veloci delle altre opzioni. Approntiamo delle soluzioni ‘quick & dirty’ sviluppando rapidamente i requisiti principali, le mandiamo online e poi facciamo tuning e copriamo le aree complementari inizialmente trascurate.

Blanchetti, Edenred Italia. Una breve considerazione sulle modalità di approccio alle community. È vero che molte volte si tende ad abusare del loro supporto. Chi si rivolge a una community senza avere una minima conoscenza dell’open source e della soluzione che si sta utilizzando, non motiva le persone della community a fornirgli il supporto che chiede. Le community non sono Open Source for Dummies e poiché non siamo più nella fase pionieristica queste si aspettano che chi chiede supporto abbia almeno una buona conoscenza dei concetti di base.

Poiché è facilmente prevedibile che la complessità dei vostri ambienti sia destinata a crescere, c’è un problema in generale di gestione delle diverse componenti e in particolare delle soluzioni open source?

Pessina, Saipem. È indubbio che la diffusione dell’open source aumenti la complessità di gestione non solo prettamente per le tematiche IT ma anche, per esempio, nel gestire l’aumento di fornitori di media dimensione con conoscenze di prodotto specifiche e fortemente verticalizzate.
A livello applicativo, è chiaro che nella nostra realtà la componente di gestione corporate continuerà a rivolgersi alle piattaforme di vendor tradizionali. Anche sul fronte delle commesse però, dove l’IT in questi anni è stato chiamato a giocare un ruolo sempre più propositivo, l’open source può diventare un’alternativa ai prodotti commerciali dove sia necessario abbassare il costo relativo all’IT per supportare la marginalità del business. Chiaramente una scelta basata su tecnologia open source necessita del totale coinvolgimento del business poiché l’adozione di tali soluzioni non può prescindere da una condivisione del rischio in caso di problematiche future.
La condivisione del rischio è a mio avviso la condizione per far apprezzare l’open source al di fuori dell’IT. Certo l’aumento delle soluzioni open source in produzione ha un riflesso sui costi di application management e magari anche sulla relazione con i vendor... ma è comunque vincente.

Baracchi, Comune di Vigevano. Uno dei problemi indotti dall’eterogeneità delle nostre applicazioni, a prescindere dall’utilizzo o meno di soluzioni open source, è quello del ‘single sign on’. È un obiettivo che ancora oggi non riusciamo a completare al 100%. Dove possiamo cerchiamo di integrare l’accesso ai sistemi utilizzando come base per l’autenticazione dei nostri applicativi l’Ldap della versione open source di una soluzione molto conosciuta di posta elettronica. In questo modo l’utente può utilizzare la password della posta per autenticarsi e accedere anche a una parte delle applicazioni di suo abituale utilizzo (es: ticketing help-desk). Purtroppo le soluzioni basate su tecnologie proprietarie e gli applicativi verticali sviluppati da aziende commerciali integrano sistemi di autenticazione sviluppati ad hoc così come la gestione dei ruoli e dei profili, perciò non siamo ancora riusciti ad arrivare a un unico single sign on. Adotteremmo sicuramente una soluzione open source che ci consentisse di arrivare a questo risultato.

Blanchetti, Edenred Italia. Il fatto di avere sistemi eterogenei, sicuramente aumenta la complessità, ma di contro porta dei vantaggi che le superano di molto. Dal punto di vista della gestione del nostro ambiente avere tutto lo stack infrastrutturale e/o applicativo affidato a un unico vendor forse ci aiuterebbe molto, ma questo poi genera problemi di costi, di tempi di supporto, di manutibilità. Per alcune problematiche, per esempio, a volte anche i grandi vendor rispondono che non forniscono supporto... Come già detto il nostro è un ambiente applicativo piuttosto eterogeneo, ed è così anche la parte infrastrutturale che non seguo, e abbiamo lavorato molto per organizzare entrambe su diversi livelli architetturali che naturalmente interagiscono tra loro. In ognuno di questi si possono trovare soluzioni sia open source sia custom sia di vendor diversi, che sono integrate, o comunque supportano l’interoperabilità tra loro, in diverse modalità, come già detto principalmente grazie a SOA.
In questo ambiente così eterogeneo quindi la complessità di gestione è più legata alle persone dello staff IT che devono gestire questa ampia varietà. Chi lavora nei vari livelli architetturali del nostro modello deve possedere competenze sui prodotti sia commerciali sia custom sia open source che interagiscono nell’area che deve presidiare. Venendo alla condivisione del rischio. L’open source non è più da tempo un tema solo dell’IT e nella nostra organizzazione la condivisione del rischio è portata a tutti i livelli fino al top management. Una volta il business non entrava nei criteri delle nostre scelte, ma la situazione è cambiata da quando l’IT non viene più considerato un costo trasversale, ma come una componente importante dei costi di ogni singola attività. Dal momento in cui è cambiata questa visione, l’open source è iniziato a essere un argomento condiviso anche al di fuori dell’IT. Ogni progetto open source generalmente oggi si connota sempre per una componente che possiamo identificare con la frase ‘gettare il cuore oltre l’ostacolo’. Nell’area portali abbiamo deciso di implementare questo tipo di soluzioni e quando però si verifica un problema di business (non si riescono a inserire gli ordini o a ricaricare i ticket...) tutti a livello di top management sono consapevoli che la decisione di adottare in questa area soluzioni open source è stata una scelta comune.
La condivisione del rischio dell’open source vuol quindi dire accettare una serie di regole differenti rispetto all’utilizzo di software commercial come, ad esempio, diversa impostazione dei livelli di servizio oppure, in linea generale, diversi tempi di messa in esercizio.
Certamente le soluzioni open source non sono in grado di fornire le garanzie che invece un vendor può mettere sul tavolo. Se succede qualcosa, risponde in prima persona con penali e coperture dei costi subiti dal cliente... Con l’open source questo non succede.

Colombo, AGSM Verona. Il punto relativo alle garanzie fornite dai vendor è da sempre importante. Secondo me è fondamentale che si riesca a definire quanto un’applicazione sia critica o meno per l’organizzazione che la utilizza. Spesso la tipologia dei prodotti scelti dipende dalla risposta alla domanda: quanto tempo posso permettermi di avere l’ambiente di produzione bloccato? Spesso non si affida un ambiente critico a un sistema open source per le radicate errate convinzioni di cui ho parlato in precedenza. Sembra che l’orientamento stia lentamente cambiando. Ci sono soluzioni open che sono tra le migliori del mercato sia in termini di affidabilità che in termini di solidità. La piattaforma WordPress credo sia un esempio evidente di prodotto open estremamente stabile e affidabile tanto che moltissime aziende hanno scelto questa piattaforma come soluzione veloce per la loro vetrina.
A volte la scelta è strettamente legata al fatto che il fornitore garantisce in prima persona il buon funzionamento del sistema. In questi casi quindi, di nuovo la criticità del sistema diventa il driver principale per determinare la scelta e in questi casi oggi l’open source il più delle volte non fornisce lo stesso livello di garanzie.

Focalizziamoci brevemente sulle esperienze di riuso legate al mondo open source vissute nelle pubbliche amministrazioni. I due rappresentanti a questo tavolo che esperienze possono raccontarci?

Baracchi, Comune di Vigevano. Grazie a un progetto cofinanziato dalla Regione Lombardia, il Comune di Vigevano può mettere in atto il riuso su tre linee parallele, e fino a oggi, in ognuna di queste abbiamo fatto una diversa esperienza. Il riuso è quindi un tema che si sviluppa in questo caso attraverso tre modalità diverse.
La prima esperienza è stata il riuso di un software nato da un progetto nazionale: GIT, gestione integrata del territorio (http://www.progettogit.it/area_ riservata/default.html), piattaforma georeferenziata che gestisce dati generati da fonti eterogenee, interne ed esterne all’ente (sviluppo della Regione Umbria). In questa esperienza si è dimostrata valida la logica di mettere a fattor comune i moduli che possono essere condivisi, riadattati e riutilizzati senza grossi oneri e in maniera molto veloce. Giudizio complessivamente positivo.
Una seconda esperienza è stato il riuso di un servizio, quindi una cosa diversa dal riuso di un software. Abbiamo attivato il sistema di erogazione in prossimità dei servizi comunali, ma, in prospettiva, non solo comunali (aziende del comune, ASL), TServe (http://www.comune.vigevano.pv.it/contenuti/pagine/educativo/punti-t-serve), sviluppato dal Comune di Prato. Questo consente al cittadino l’accesso ad alcuni servizi comunali di pagamento multe, rette anche in orari e in giorni in cui non sono aperti gli sportelli comunali, recandosi in tabaccherie, farmacie, edicole, cartolerie e presso altri esercenti sotto casa per compiere determinate operazioni. Il servizio viene gestito dal Comune di Prato per conto del Comune di Vigevano. Giudizio complessivamente positivo anche in questo caso. La terza esperienza è invece stata complessivamente negativa. Abbiamo cercato di riutilizzare un software per la gestione del protocollo web sviluppato da un’altra amministrazione comunale, che si presumeva ampiamente stabile e collaudato. Dopo le iniziali difficoltà di partenza, di personalizzazione ed adeguamento della procedura, sono emersi, durante l’utilizzo a regime, aspetti critici non trascurabili, con anche casi di perdita di dati e in qualche caso problemi di integrazione con altri applicativi non risolti o non risolvibili; un sistema in fin dei conti rivelatosi sostanzialmente non abbastanza stabile. Visti i problemi riscontrati, anche su pressione degli utilizzatori interni siamo dovuti tornare indietro. Abbiamo poi saputo che lo stesso ente cedente ha nel frattempo riscritto l’applicazione, ma a quel punto non eravamo più interessati e disponibili a fare da ‘alfa-tester’ una seconda volta.
Nella pratica del riuso vale anche qui la regola di andare su applicazioni, piattaforme o servizi consolidati e ampiamente già utilizzati da altri, oppure, quanto meno, di aspettare due o tre anni per valutarne bene l’evoluzione e la maturità dal primo rilascio.

Grazia, Regione Emilia-Romagna. Mi ritrovo sostanzialmente nelle esperienze descritte dal collega. Il riuso così come previsto dal CAD (Codice Amministrazione Digitale, ndr) è, se volete, un po’ ingenuo, perché nella realtà è difficile che una soluzione sviluppata magari in modalità custom per una amministrazione una volta installata in un’altra amministrazione funzioni. Il costo di adeguamento di queste soluzioni e la loro manutenzione può risultare anche molto elevato e in alcuni casi può essere paragonabile a quello di uno sviluppo che parte da zero.
Dove ha funzionato bene il riuso è invece quando si è riusciti a intervenire ‘a monte’, ovvero perché sono state ben condivise le logiche di sviluppo nella fase di progettazione. Riteniamo questo l’approccio più valido e infatti come Regione Emilia Romagna abbiamo anche pubblicato un ‘catalogo’ dei software utilizzati nelle amministrazioni locali del nostro territorio, proponendo una visione ampia della condivisione che comprende l’esperienza, la progettazione e, certamente, anche il software. In generale la mia considerazione sul tema del riuso è che nel mondo dell’open source questa pratica è endemica ed è il motivo stesso che spinge la crescita delle community. Proprio in tale senso abbiamo avuto diverse esperienze positive. Una community mondiale molto diffusa (quella legata al CMS Plone) al suo interno ha visto l’organizzarsi di una community di sole pubbliche amministrazioni di tutto il mondo (PloneGov) molto vivace e molto concreta. In questo contesto anche noi abbiamo sviluppato delle componenti messe poi a disposizione di tutti i ‘colleghi’.
Esperienza positiva anche con OpenOffice. Avevamo riscontrato un bug relativo a un problema di integrazione con un’altra applicazione, questa di natura commerciale, la risoluzione del problema era essenziale per evitare di tornare indietro rispetto al programma di migrazione verso la soluzione open source.
Abbiamo quindi incaricato un’azienda di sviluppare la soluzione al problema e abbiamo richiesto che il codice venisse rilasciato alla community, non solo a quella di OpenOffice ma anche a quella di LibreOffice. Lo sviluppo fatto dal partner è già nella beta della soluzione ufficiale che verrà rilasciata prossimamente e per noi non è un problema tenere ferma la migrazione per pochi mesi.
Generare e mantenere nel tempo invece una versione custom di OpenOffice avrebbe voluto dire affrontare in futuro notevoli problemi sul fronte degli aggiornamenti e sulla libertà di migrare un domani con facilità verso soluzioni alternative.
Per avere la certezza che il software sviluppato venisse accettato dalla community ci siamo rivolti quindi a uno dei due specialisti italiani che sanno mettere mano al codice del prodotto seguendo tutte le regole dettate dalla community. Abbiamo dovuto aspettare un po’ di tempo, ma come detto questo non era un problema.

Qualche commento su queste esperienze dai colleghi che lavorano in realtà non della PA?

Caligiuri, Segugio.it. Mi associo a questa ultima considerazione del collega, anche il tema dell’open source customizzato è assolutamente da tenere in considerazione. È sempre meglio rilasciare alla community uno sviluppo che poi lo fa suo, in questo modo ci si mette al riparo dal fatto che gli aggiornamenti futuri del software non avranno più bisogno di quella determinata patch. In Italia siamo ‘fortunati’ perché abbiamo specialisti open source veramente bravi, ma sono sempre uno o due anche per i prodotti più popolari.


Blanchetti, Edenred Italia. Se si usa un software applicativo open source bisogna seguire delle regole di sviluppo e programmazione più ferree di quelle utilizzate per le personalizzazioni del software commercial. Nel software commercial il vendor detta le regole, nel software open source se l’IT aziendale non dà delle regole si rischia l’anarchia.
Le personalizzazioni che stravolgono determinate versioni di software open source legheranno per sempre l’azienda a quella versione. È una scelta che si può perseguire, ma in piena consapevolezza. Dare le regole di sviluppo però non basta, bisogna soprattutto fare in modo che queste vengano rispettate, e non limitarsi a valutare un software unicamente sotto il profilo del rispetto delle specifiche funzionali date.

Bettoni, Diapath. Il problema delle regole è più difficile da incanalare in un contesto composto dai famosi ‘geek’. Perché a uno bravo, sveglio e veloce probabilmente faccio molta fatica a dargli queste regole, e lui farà molto più fatica a rispettarle.
Lo dico per esperienza, perché il firmware sviluppato dalla nostra ricerca e sviluppo per il funzionamento dei macchinari biomedici di nostra realizzazione, ovvero attività core dell’azienda, non è scritto sempre con i crismi che uno si aspetta. Ma qui prevalgono le esigenze del business. Operare senza regole rischia di far perdere molti dei vantaggi dell’open source.

Caligiuri, Segugio.it. Trovo molto difficile controllare che le regole da noi fissate vengano effettivamente rispettate, anche se si utilizzano tool appositi per questo scopo. Il punto vero è che il codice deve essere documentato. È più facile quando si imposta il lavoro sullo sviluppo di microservizi. Per ognuno si può dare una descrizione iniziale per spiegare cosa effettivamente fa e poi si possono mettere delle frasi di commento in diversi punti. Mi è capitato spesso di lavorare con persone che utilizzano linguaggi che non conosco. Per me è impensabile imparare un nuovo linguaggio per vedere cosa c’è nel codice prodotto da questi sviluppatori, mentre invece posso farmi un’idea grazie ai commenti inseriti. Rimane il fatto però che le richieste del business sono sempre urgenti e bisogna produrre rapidamente codice. Quindi a seconda dell’importanza del lavoro scelgo se affidarlo, oppure no, a un programmatore con una certa seniority e che so che cura in modo adeguato la documentazione del codice.

Colombo, AGSM Verona. La formazione culturale del singolo sviluppatore fa la differenza quando un codice deve essere riutilizzato. Alcuni sviluppatori documentano il codice ed altri non lo fanno per niente. Negli anni i linguaggi di programmazione hanno facilitato l’accesso al loro utilizzo, la platea dei programmatori si è estesa di molto e quindi molte regole fondamentali che si seguivano in passato si sono perse.


Grazia, Regione Emilia-Romagna. Anche su questo fronte abbiamo cercato di darci una metodologia e quindi oggi è attivo un sistema di ticketing interno per tracciare proprio le attività di sviluppo. Colleghiamo i commit fatti dagli sviluppatori alle issue aperte includendo la descrizione di quanto è stato fatto. In questo modo quando facciamo un rilascio sappiamo effettivamente cosa stiamo mettendo a disposizione dei nostri utenti. Tutto il ciclo di vita di una soluzione deve essere il più possibile ingegnerizzato, non solo la fase di sviluppo iniziale.

Pessina, Saipem. Quando sento che gli specialisti italiani su alcuni temi open source anche molto popolari sono uno o due penso che questa sia un grossa criticità. C’è un forte problema di lavoro per molte persone, ma quando si cerca di reperire esperti sull’open source è difficile trovarli. Credo che il tema dell’open source dovrebbe trovare maggiore spazio a livello scolastico, specie negli istituti tecnici. Oggi spesso le aziende catapultano il programmatore junior neoassunto a produrre codice e questi lo scrive secondo la formazione con la quale è stato preparato, spesso a discapito della qualità o della leggibilità del codice stesso.

Come organizzate la formazione dello staff IT sulle soluzioni open source da voi utilizzate?


Caligiuri, Segugio.it. La formazione viene generalmente vista come un fermo macchina: formare una persona vuol dire toglierla dalla produzione. Il costo della formazione, tra costi diretti e indiretti, non è quindi poco, perciò è importante riuscire a fare sempre affidamento sulla buona volontà e sulla passione delle persone dello staff che spontaneamente sono spinte ad aggiornarsi per conto proprio.

Baracchi, Comune di Vigevano. Nei comuni i budget per la formazione sono stati centralizzati e ormai è sostanzialmente finalizzata a tematiche non ICT (sicurezza del lavoro, anticorruzione...). Riusciamo a ritagliare delle mezze giornate di formazione includendo questa attività all’interno di iniziative di altro genere (progetti specifici o adesione a reti di comuni). L’autoformazione tecnica volontaria è abbastanza praticata, anche grazie alla buona qualità dei materiali oggi disponibili in rete.

Blanchetti, Edenred Italia. Al di là dell’open source, abbiamo fatto la scelta di razionalizzare i linguaggi utilizzati all’interno dell’azienda, oggi supportiamo per la gran parte degli sviluppi Java J2EE. Una razionalizzazione che porta vantaggi anche sotto il profilo della formazione che si focalizza su questo strumento con corsi verticali istituzionali e attività di affiancamento e coaching. Certamente poi anche i nostri sviluppatori fanno molta autoformazione. La razionalizzazione ha comunque portato a una migliore condivisione della conoscenza tra le persone dell’azienda.

Colombo, AGSM Verona. Quando abbiamo scelto la soluzione in area Cmdb, abbiamo deciso di non fare formazione sugli aspetti IT del prodotto, ma su tutto quello che ci consente di poterlo utilizzare al meglio. Ritengo meno utile, vista la cronica carenza di risorse, che ci si concentri sugli aspetti estremamente tecnici del prodotto. Credo sia invece necessario che si conosca bene la modalità di lavoro del prodotto e le potenzialità per essere autonomi nelle configurazioni di base. È fondamentale conoscere il modello dati implementato che ci consente di ottenere le informazioni registrate in modo veloce e puntuale. Abbiamo comunque acquisito un’esperienza che ci consente di realizzare delle modifiche al prodotto o piccoli workflow per soluzioni di tipo win-win.

Conclusioni
La consapevolezza che l’open source sia ormai diventato un tema centrale per molte organizzazioni IT, e che per questo debba essere affrontato e gestito con gli strumenti, le metodologie e le best practice del management, è emersa in modo sostanziale da questa tavola rotonda. L’auspicio è che condividendo in modo approfondito i diversi temi trattati, i lettori coinvolti, interessati o solo incuriositi dall’open source, abbiano ricavato più di uno spunto interessante per la loro azione quotidiana e per le scelte che si apprestano a fare nell’adozione di questo tipo di soluzioni.


 

TORNA INDIETRO >>