Devops - Software House - Integration

Ciao.

Riporto un concetto visto con un tecnico del mondo finanziario.
Nel mondo finanziario (e comunque nel privato) il concetto di integrazione è pressochè normale. E’ difficile che un sistema viva di vita propria, ma spesso va integrato con altri sistemi (crm con erp con paghe con altro). Quindi l’integration o interoperabilità è naturale.

Nel mondo della PA invece il monolito software è sempre stato abbastanza uno standard. Questo tirandosi dietro un lock-in che sembrava una difesa al cambio di software.

Può essere che il vero valore aggiunto del futuro per i pacchetti applicativi sia proprio (o anche) questo cambiamento: l’applicativo vincente non sarà quello che potenzia il lock-in, ma quello che garantisce di più integrazione con i vari sistemi (piattaforme abilitanti, altri software non core, altri servizi, siti, app etc etc) in modo continuo e fluido.

Cosa ne pensate?

Andrea

Ciao Andrea.
my two cents.
Standard (formato standard, interfaccia standard…) questa e’ la parola magica.

Gianni

1 Mi Piace

la risposta è mettere a bando la fornitura del servizio e non del software, con l’obbligo di utilizzare solo software open source. In questo modo rinasce la concorrenza e si sconfiggono le pratiche di lock-in dei fornitori.
Ormai in campo software gestionali c’è poco da inventare, ma la qualità e le modalità di erogazione dei servizi sono le uniche cose che dovrebbero fare la differenza.
Ad esempio: software per la gestione delle rilevazioni di infrazioni di passaggi con il semaforo rosso. Il software viene prodotto da un unico fornitore, che guarda caso è anche il produttore dell’unico hardware compatibile. Se avessero l’obbligo di erogare un servizio in cloud con software open, il risultato sarebbe che l’ente potrebbe scegliere un fornitore diverso senza dover cambiare il sistema di rilevazione.
Questo naturalmente vale anche per sistemi di protocollo informatico, gestione anagrafe, ecc… dove esistono già degli standard per i tracciati dati, ma tutti i fornitori se ne infischiano e non adeguano le loro strutture dati. L’informatica è fatta di standard, sarebbe ora di fare bandi più completi e di alzare il livello delle forniture.

Sicuramente migliorare i bandi mettendoci principi e concetti (cloud first, interoperabilità etc etc) è una strada percorribile e anzi molto consigliata.

Pensare di “cancellare” il mercato delle software house tramite l’open source lo trovo piuttosto utopico. Dei grandi cambiamenti richiedono piccoli passi, che sono gli unici fattibili: non sono attuabili i modelli “ruspa” (butta via tutto e riparti da zero). Perlomeno ad oggi.

Andrea

e allora continuiamo a rimanere indietro di 10/15 anni rispetto ai più evoluti in Europa. Non è un modello ruspa, è un grande passo per recuperare il tempo perso. Non c’è nulla di utopico, è solo questione di volontà politica e sta ai tecnici spingere nelle giuste direzioni.

Credo sia importante trovare soluzioni al di là dell’emotività del momento.
Pensare che i tecnici possano cambiare le cose, è un’idea che mi piace ma non credo sia fattibile.
Anche l’open source mi piace, ma credo sia un percorso complesso in questa fase.

Solo mi piacerebbe trovare percorsi e soluzioni che fossero attuabili da subito e portassero risultati nel breve periodo.

Perlomeno queste sono considerazioni che derivano dalla mia esperienza con i piccoli comuni, magari in altri contesti l’open source è la soluzione migliore.

Andrea

facciamo un po’ di esempi così tanto per rimanere sul pratico:
Browser predefinito per la PA: Firefox. Vuol dire che quando una qualsiasi software house deve sviluppare un prodotto web (applicazione o sito) per la PA, questo dovrà rispettare tutte le varie leggi (accessibilità, linee guida grafiche, ecc…) ed essere compatibile al 100% con Firefox. Perché perché mozilla è presente su tutte le piattaforme, è indipendente e rispetta gli standard aperti.
Siti web: privilegiare un cms rispetto ad altri, quale? Drupal. Perché: anche la Commissione Europea lo ha adottato come cms predefinito, per una serie di infiniti motivi.
Sistemi di firma digitale: c’è dike, aruba, infocert, ecc. Basterebbe produrne uno solo per la PA e sarebbe molto più facile l’educazione dei dipendenti pubblici sulla questione digitalizzazione dei processi e dei documenti.
Suite per ufficio: LibreOffice. Perché: è gratuita, quindi anche i cittadini potrebbero accedere ai documenti in forma gratuita. Anche il nostro esercito l’ha adottata, quindi abbiamo esperienza e buone pratiche da riutilizzare.
Poi si potrebbe proseguire con vari software di gestione, controllo, file server, ecc… e mi pare che siano tutte buone pratiche adottabili in poco tempo anche dai piccoli enti.
Tanto per metterci la ciliegina: https://juliareda.eu/2018/12/eu-fossa-bug-bounties/ , la Commissione Europea crede nell’os tanto da creare un programma per il miglioramento dei software open più utilizzati nelle istituzione europee.
Passando ad un discorso economico: se i grandi enti italiani, tipo le università, le regioni o i comuni sopra i 100.000 abitanti facessero bandi più orientati all’open si creerebbe maggiore sviluppo e collaborazione anche tra le software house private, riducendo di molto l’overhead e la sovrapposizioni di sistemi diversi, ma che fanno le stesse cose, che si è creata in questi anni. il tutto porterebbe ad una convergenza verso buone pratiche, stessi software, ma tenendo differenziati i veri servizi che fanno preferire un fornitore piuttosto che un altro: la qualità/velocità dell’assistenza e la continuità del servizio. Senza tralasciare il risparmio economico, si creerebbero gli spazi finanziari per aggiungere “servizi di backup” o “disaster recovery” veramente efficienti e pronti in pochissimo tempo, oltre ad accrescere la sicurezza informatica e i servizi di protezione dei dati/comunicazioni (cosa che oggi in pochi fanno sul serio…).
Questa è la mia modesta opinione da informatico che ha trascorso 12 anni di carriera come dipendente pubblico in un grande ente (licenziato per sfinimento), e 5 da amministratore pubblico di un piccolo comune. Ora sono un consulente per la PA europea e devo dire che tutto ciò lo vedo molto più vicino di quello che potrebbe sembrare, basterebbero anche solo 100 tecnici che si impegnassero ad inserire nei bandi di gara l’obbligo di compatibilità al 100% con i browser open source per cambiare veramente tante cose.

Direi che stiamo convergendo.

La standardizzazione proposta da @giannibassiniprCR è sicuramente la via.
Se sommiamo l’open source visto come strumento e aggiunto nei bandi e non come sviluppo open, probabilmente ci siamo, seguendo il pensiero di @kimlop .

Si parte probabilmente dai bandi, dove è importante introdurre tutti i principi indicati dal piano triennale (cloud first, interoperabilità, evitare il lock-in, …) e poi proseguire per capire come fare ad avere uno standard che si può prendere da chi ha già fatto questo percorso di standardizzazione (evitando di reinventare la ruota), come ad esempio l’esercito, l’eu o qualsiasi altra esperienza di chi è più avanti. Come dice @kimlop (di cui riesco a capire , lo sfinimento da 12 anni da PA) “basterebbero 100 tecnici”, e qui si ricade in un altro tema: 800 persone nel TeamDigitale UK, 35-40 nel TeamDigitale Italiano.

Potrebbe anche essere interessante creare delle linee guida per l’approvvigiornamento di software per la PA (partendo o considerando https://docs.italia.it/italia/designers-italia/design-linee-guida-docs/it/stabile/index.html come riferimento per alcuni aspetti). In tale modo cambierebbe il modo di fare bandi in ottica digitale e il modo di rispondere.

Sono tanti temi in pochi passaggi, ma sicuramente tutti validi e da considerare per uno sviluppo standard della PA.

Questo è un luogo dove raccogliere idee e alcune sono emerse, vediamo se ne escono altre.

Grazie del contributo @giannibassiniprCR e @kimlop (sicuramente la tua esperienza europea è MOLTO interessante).

Andrea

mi piace questa sintesi, e mi piace moltissimo l’idea delle linee guida per l’approvvigionamento del software/servizi informatici.
Secondo me il vero problema è far arrivare queste linee guida fino all’ultimo piccolo Comune, non sono pronti, non hanno personale qualificato.
Anche il tema Team Digitale/Agid sarebbe da approfondire, perché conoscendo l’esperienza uk direi che siamo sicuramente sulla buona strada, ma si potrebbe fare di più. Temo però che sia un tema molto complesso da affrontare qui.
Ps: l’esperienza che sto maturando per la eu è molto interessante perché c’è fermento in vari ambiti ed è un ambiente fertile per lo scambio di conoscenze in diversi settori dell’IT.
Se vi può interessare queste sono le linee guida per i siti della EC/EU: https://github.com/ec-europa/europa-component-library
e queste quelle per le app web: https://eui.ecdevops.eu

1 Mi Piace

Provo a mettere un po’ di “sale” sulla discussione…

Domanda: possiamo essere piu’ precisi? Di quali “software” o “servizi” parliamo? Chi e’ il “target” di queste linee guida?
Siamo sicuri di voler fornire delle linee guida ad oltre 8000 persone (almeno tanti quanti sono i Comuni in Italia) che dovranno farsi carico di “capire che esistono” (1), “leggerle” (2), “decidere di attuarle” (3), “attuarle” (4), “sperare di averlo fatto in modo giusto” (5) ?

Non sono un esperto di “burocrazia tecnologica moderna” ma… mi pareva di aver capito che l’input che arriva dal “centro” e’ tutto diverso: in periferia NON si compra piu’ nulla (in linea di principio), se non quello che e’ deciso dal centro. Alias: tenderei a sistemare le cose “dal centro”, e non dalla periferia.

Le linee guida, quindi, servirebbero per CONSIP, per AdE, per INPS, per MEF. Servirebbero anche per le Regioni ma… questi Enti (purtroppo) ormai sono dei “molossi” (parlo delle Regioni) talmente forti e possenti che… neanche piu’ il centro riesce a… rimetterli in riga.

In questo senso, forse la mia e’ una visione pessimistica ma… (quelli che seguono sono solo i primi “esempi” che mi vengono in mente):

  • Regioni: se penso che le società “in-house” di molte Regioni (a partire dalla mia - l’Abruzzo) sono semplicemente dei contenitori che hanno una funzione “sociale” (attraverso un consistente numero di dipendenti e collaboratori a vario titolo) o semplicemente “economica” (attraverso la gestione --in passato molto piu’ che ora-- di un budget considerevole --milioni di euro/anno-- speso al 99,99% in acquisto di hardware o servizi ad esso strettamente correlati --ossia: con ZERO impatto a livello locale, se non in termini di “margini di vendita del rivenditore locale”–);
  • CONSIP: se guardo all’uso che viene fatto della tecnologia in uno strumento web come Acquisti in Rete utilizzato dalle PA (per cercare quello di cui hanno bisogno) o dalle aziende (per “promuovere” i propri prodotti/servizi - MePA), scopro lacune ai limiti dell’incredibile. Non pretendo che vengano esposti web-services (che non ci sono), ma rendere agevole la “ricerca” di prodotti a quei pochi funzionari pubblici che, armati di santa pazienza, decidono di “cercare” qualcosa… sarebbe utile (No! La ricerca per “descrizione”, nella realta’, è inutilizzabile.). In un caso (che conosco direttamente), la ricerca viene effettuata unicamente per “codice prodotto” ([sarcasmo=on] …che, come noto, e’ una informazioni che e’ normale che sia nota PRIMA di avviare la ricerca. Giusto? [sarcasmo=off])
    Per dirla in termini comprensibili a chi non conosce lo strumento di cui parlo: è come se lo sviluppo di un portale web con target da qualche milione di utenti, fra PA e aziende, venisse affidato ad uno stagista… a cui viene detto di sviluppare la soluzione con OpenCMS (che lui non conosce, e deve studiare), e un qualche backend Java. Nulla di piu’. E lo svlluppo registrato da quando e’ nato il portale, ad oggi… e’ praticamente trascurabile (in termini pratici; il layout del frontend è stato “riverniciato” piu’ volte. Ma il backend… e’ quello).
  • AdE: la fatturazione elettronica è emblematica. Il non essere stati in grado di rilasciare un “tool”, una “libreria”, un “framework”, una QUALSIASI_COSA in un QUALSIASI_LINGUAGGIO che potesse aiutare un qualunque sviluppatore freelancer e/o una qualunque software-house di questo Paese a diramarsi nel mare-magnum di SDICOOP… la dice lunga.
    Qui, penso che sia andata cosi’: un qualche super-tecnico-senior, che in SOGEI ha passato gli ultimi 15 anni a lavorare con XML e SOAP (nelle implementazioni di IBM), ha pensato: “Cavolo! Ti do le specifiche WSDL, ti do gli XSD, ti do i riferimenti ai WebServices… Cosa vuoi di piu’?”. Non lo dico (io) con cattiveria. E’ semplicemente che la persona di cui sopra ignora il funzionamento del 90% del web moderno. E’ convinto che negli ambienti enterprise, oggi, nel 2019, si utilizzino i framework JAVA con base XML e SOAP. Se gli parli di NodeJS lui ride. Se gli parli delle architetture a container, lui non ti segue. Se gli parli delle API di AWS, di S3 e delle tendenze recenti al “serverless computing”, lui pensa (“Umh… ca%%ate. Il mondo enterprise e’ JAVA + XML”).
    Non sono riusciti neanche a rendere fruibile uno straccio di visualizzatore XML per la fatturazione elettronica, che fosse utilizzabile BANALMENTE per l’utente medio (quello che c’é, per qualche misterioso motivo, è accessibile “solo” agli utenti del servizio F&C. Mi chiedo per quale motivo non sia linkato in Home-Page, ad accesso universale. Hanno forse paura del “carico”?)
  • INPS e MEF: qui, in realtà vedo cose positive. Vedo i primi VERI segnali di innovazione sul versante IT, ormai gia’ “in produzione” da diversi anni (forse anche 10). Qui, il problema che vedo e’ di “fatica a seguire l’evoluzione tecnologica”. Mi rendo conto che non è certamente banale stare al passo con la tecnologia, specialmente se nei propri datacenter c’e’ un certo “carico” gestito da (costosi) sistemi “legacy”. Pero’, prima o poi, lo “svecchiamento tecnologico” ci deve pur essere. Vedo che lato “front-end” i passi avanti sono stati molti… Ma appena si varca la soglia dei “servizi” e si iniziano a toccare i backend, la sensazione di “ragnatele” e l’odore di “legacy” sono fortissimi. Soprattutto il profumo del moderno (responsive, interfacce web asincrone, utilizzo intensivo di framework javascript) è del tutto assente.
  • …potrei continuare, ma mi fermo…

…ecco, se penso a questo, tenderei a dire che prima di pensare ad 8000 segretari comunali ed a qualche migliaio di altri funzionari pubblici, forse potremmo chiedere a questi signori qui sopra di… “seguire delle linee guida” (magari condivise fra loro).

Il problema è complesso e –come mi pare abbia più volte detto lo stesso Piacentini– è solo in parte “tecnico”. Anzi: personalmente credo che la complessità “tecnica” sia facilmente risolubile (un team come quello attuale, se venisse lasciato operare nel “contesto giusto”, potrebbe fare cose incredibil). Il fatto, però, che lo stesso TEAM non sia riuscito a lasciare un benché minimo “segnale” sul fronte Fatturazione Elettronica, la dice lunga (e… SI, il Framework in PHP l’ho scaricato, l’ho guardato, l’ho studiato e… ho capito che non mi serviva a nulla).
Insomma: fino a quando il TEAM è costretto a muoversi in una “piazza” dove tutte le vie d’uscita (verso il MEF/AdE/SOGEI, verso i principali ministeri, verso le software-house “commerciali”, verso altre “nicchie” di rilievo quali Atenei e Centri di Ricerca, e dulcis in fundo, verso il Garante) sono sbarrate da una porta con sorveglianza armata e di cui non si hanno le chiavi (si intravede --a volte-- solo il campanello), si fa fatica a credere che possa incidere seriamente sullo sviluppo ICT di questo Paese, nel prossimo futuro.
Non sto dicendo che non serve a niente. Dico solo che fra l’essere utili (1) e l’incidere seriamente nello sviluppo IT del Sistema Paese (2) ci passa una bella differenza. E finora… siamo in (1).

Quando metti attorno allo stesso tavolo (meglio: alla stessa mailing-list) un gruppetto di tecnici un po’ attempati (ma che sanno quello che dicono…) e magari gli metti vicino delle giovani teste pensanti (magari dei 25enni/30enni, che non hanno (ancora) problemi familiari e… possono dedicarsi anima e corpo… e giorno e notte… a “divertirsi” con queste cosette) ed aggiungi al tavolo qualche Dirigente Pubblico che ha chiaro in mente (in senso “positivo”) cosa sia la “Responsabilità Dirigenziale” quando si tratta di PRENDERE DECISIONI, la quantita’ di know-how che produci è incredibile. Su questo, non ci piove.

Come trasformare questo “know-how” (…che magari e’ anche “case-history” reale, provata e adottata con successo da qualcuno) in soluzioni che EFFETTIVAMENTE adotta qualcun altro, anche GRATUITAMENTE… è tutto un altro film. Ed a valle della mia esperienza diretta (ormai ultra ventennale), direi anche, purtroppo, impossibile. E l’impossibile NON deriva da aspetti tecnici.

In realta’, a pensarci bene, una volta un risultato e’ arrivato: nel 2009 ebbi la fortuna di partecipare ai Lavori del Tavolo Tecnico di Università Digitale, al DIT/MIUR. Fra gli altri, ne uscì fuori la verbalizzazione elettronica degli esami universitari, con tanto di regolamento MIUR e relativa “legge di attuazione”. All’inizio sembrava fantascienza. Dopo 18 mesi, era realta’. Da diversi anni, gli esami NON si registrano piu’ “su carta”. Il Libretto di carta, non esiste piu’ da tempo.

Mi fermo qua. Ho scritto fin troppo.

Saluti,
DV

3 Mi Piace

Io sono stato uno dei primi implementatori di questa strategia, e non solo di quella. Ho lavorato a diversi progetti di trasformazione digitale e devo dire che il Cineca, con tutti i suoi difetti, è riuscito a creare dei servizi online per coprire quasi tutte le esigenze degli atenei. Poi che siano tutti java xml, poco mi importa, invece il fatto che non siano responsive e accessibili lo ritengo un problema enorme.
Su tutto il resto sono d’accordo, hai descritto la situazione così com’è, ma io rimango ottimista sul fatto che anche in Italia possiamo darci un’organizzazione, forse manca solo un partner tecnologico moderno e forte, ma qui rientriamo nei problemi politici.
Secondo me la creazione di linee guida può essere soltanto positiva, almeno ci saranno delle regole, ad oggi c’è il delirio più totale. Basta vedere i siti comunali realizzati dalle mille software house… Trovarne uno in regola è un’impresa, trovarne uno che rispetta le linee guida grafiche è fantascientifico.

1 Mi Piace

Sempre restando nel “sembra fantascienza ma poi diventa realtà” anche per noi era così 1 anno fa, ad oggi abbiamo diversi comuni che hanno il sito secondo standard agid.

Sistemi complessi e articolati richiedono grandi sforzi per il cambiamento, ci vuole tanta pazienza e tanto impegno oltre che tante energie.

Per il momento quindi abbiamo:

  1. standard
  2. eventualmente open
  3. linee guida per l’acquisto di software e servizi (che darei oltre a meg, ade etc etc anche ai centri di competenza che dovrebbero formarsi per aiutare le esperienze eccellenti ad essere replicate e per aiutare gli 8.000 comuni a implementare la digitalizzazione e linee guida)
  4. attenzione ai modelli europei e italiani già funzionanti

Andrea

per il punto 1: open standard
per il punto 2: open source first (non eventualmente)
altrimenti non ha senso il discorso fatto fin’ora, e non avrebbero senso le normative già emanate tramite il CAD:

Mi scuso perché rileggendo ciò che ho scritto mi rendo conto di essermi espresso in modo non chiaro.
Quello che vorrei vedere sono delle linee guida molto più precise, che effettuano delle scelte, ciò che c’è oggi non è abbastanza selettivo, anche se fosse sempre rispettato avrei già la stragrande parte dei software per la gestione del Comune con licenze open source.
Sarebbe interessante mettere in piedi un sistema di monitoraggio e controllo, perché non è possibile emanare delle linee guida che poi vengono bellamente ignorate. Ci sono enti che acquistano software/beni/servizi ignorando totalmente le convezioni consip, o il mepa, figuriamoci se conoscono le linee guida…