La gara Consip per il Cloud: i tecnici non bastano, serve la regia della politica

Italia

Quando escono queste gare mi vengono sempre dei terribili mal di pancia. Sembra di leggere cose vecchie di almeno 30 anni. Ricordo quando partecipai, come consulente, ad una gara RGS: era il 1996 circa, e le cose erano assolutamente identiche.

La cosa che più mi lascia perplesso è l’ammontare del valore complessivo del bando gara: 1950 Milioni di euro: insomma, 2 Miliardi di euro, anche se divisi in quattro lotti. Ma che senso ha, mi chiedo, fare una gara di queste dimensioni oggi? E poi, come al solito, che senso ha fare una gara al massimo ribasso sperando che il risultato sia anche di qualità?

E poi non è chiaro se la proposta si riferisca a servizi per la PA centrale, per la PA locale o per entrambe.

Credo che il tema di un contratto quadro dovrebbe derivare da  un’elaborazione costruita insieme agli enti che poi dovranno essere i compratori. E’ stata costruita così? E’ importante, perché se le cose non si costruiscono insieme è poi più difficile che le cose accadano.

Nel primo caso, AGID  ha l’autorità per poter definire dei comportamenti. Nel secondo caso, fino a prova contraria, le PA locali godono di Autonomia Amministrativa e quindi potrebbero tranquillamente ignorare tutto il marchingegno risultante dalla gara. Non ho trovato da nessuna parte qualcosa che lasci pensare almeno ad una approvazione del bando da parte della commissione SPC, quindi sembra che AGID stia facendo partire qualcosa di cui non potrà governare gli esiti, a meno di modifiche normative auspicabili ma al momento inesistenti.

Comunque, partiamo dall’inizio:

Lotto 1: servizi di cloud computing, IAAS, PAAS,SAAS e Cloud Enabling, 500 Milioni

Al punto a), viene chiesto, in pratica, di rendere disponibile un insieme di risorse sotto forma diCommunity Cloud, cosa ragionevole. 
Ma poi al punto b) si chiede di rendere disponibili servizi PAAS che poggino sugli IAAS, ai fini disviluppo, collaudo ed esercizio delle applicazioni. E già questo mi piace di meno, perché si richiede esplicitamente una architettura di servizi software (solution Stack) .

Il fornitore si ritroverà nella condizione di non poter determinare a priori quali e quanti di questi stack saranno necessari, e non potrà fare né una valutazione economica né una valutazione dimensionale. E’ presumibile ipotizzare che proporrà uno degli stack che già oggi ha a disposizione, che non sarà quindi né il migliore né il più adeguato. Ma sarà poi costretto ad implementare tutti gli altri stack che gli verranno richiesti, magari dagli 8102 comuni che viaggiano in ordine sparso?

Al punto c) vengono richiesti servizi SAAS per l’erogazione di servizi applicativi alle PA tra i quali:

• Servizi per la gestione/conservazione di documenti ANCHE in conformità con gli artt. 43,44,e 44-bis del CAD: Mi sembra corretto il concetto, ma pericoloso l’avverbio anche: sarà anche in questo caso costretto ad implementare praticamente tutto?
• Servizi di collaborazione, produttività individuale, comunicazione unificata: cosa vuol dire? In base a quali criteri vengono scelti tali servizi? Nel caso della produttività individuale si sceglierà un prodotto proprietario o un prodotto Open Source? E si lasceranno sulle spalle degli enti fruitori tutti gli oneri legati alla formazione del personale rispetto alle nuove piattaforme? Oppure si penserà di erogare in SAAS tutti gli attuali servizi in uso presso i diversi utenti, alimentando la babele ed ignorando i temi legati alla standardizzazione? In realtà anche qui è previsto che il fornitore possa prendere in carico prodotti individuati da AGID nel rispetto del CAD: ma quanti? 1,2 o 10? Per il fornitore non è la stessa cosa.

In generale, sul piano fisico, è ovvio che, in un paese come il nostro, non possano esserci oltre 10.000 CED fisici, poiché c’è un problema di razionalizzazione della spesa. Ma anche pensare di ridurre il tutto a due Centri Servizi di cui uno primario ed uno secondario, mi sembra poco ragionevole.

Inoltre, l’idea del forfait che c’è dietro tutte le gare è innaturale. Non voglio dire che bisogna tornare al time and material, ma certamente alcune attività possono essere valutate solo a posteriori, e richiedere quindi la disponibilità del fornitore di accomodare tutte le soluzioni che gli verranno richieste non è politicamente corretta.

La mia opinione personale è che in Italia i fornitori di Cloud ci stiano prendendo in giro.Infatti hanno riciclato i vecchi datacenter e ce li vendono come la nuvola italiana, mentre un cloud dovrebbe avvicinarsi di più al concetto di cielo a pecorelle: tanti piccoli centri di calcolo che si scambiano non solo i dati, ma anche i programmi. Il punto è complesso e provo a spiegarlo meglio: in un vero sistema cloud, io devo poter caricare un’istanza di un programma e renderlo disponibile come SAAS.

Man mano che gli utenti richiedono di utilizzare quel programma, altre istanze dovrebbero essere attivate su altre macchine, che non devono per forza risiedere fisicamente sullo stesso nodo: insomma, la scalabilità deve essere distribuita sul territorio, i sistemi dovrebbero rispondere sulla base del minor carico o delle migliori prestazioni (compresi i tempi di risposta della rete), per garantire la migliore UX (User Experience) possibile, ed i dati dovrebbero anch’essi essere distribuiti nei diversi centri servizi, in una sorta di master/slave dinamico, dove tutte le copie sono slave per quanto riguarda la lettura ed una sola è master per la scrittura, con i dati che vengono poi replicati nelle altre copie in tempo quite near real.

Invece il bando ragiona ancora con il vecchio concetto del disaster recovery: ci sono due Centri Servizi, uno è in esercizio, mentre l’altro è in stand-by, nell’attesa di un evento disastroso che dovesse bloccare il primo. E’ un approccio datato e poco efficiente.

Il mio punto di vista è che occorrerebbe puntare ad avere esattamente 3 centri servizi direttamente connessi sul Ring 1, intuitivamente nei pressi di Roma, Milano e Catania. Questi centri servizi non dovrebbero essere distinti in primario e secondario, ma essere tutti connessi peer-to-peer e lavorare secondo i criteri descritti nel paragrafo precedente.

Tali centri servizi potrebbero anche ospitare i centri servizi regionali, riducendoli così da 20 a 3, riqualificando il personale su nuove tecnologie (che non sono assolutamente java e php).

Non sto parlando di fantascienza.

Lotto 2: Identità digitale e sicurezza applicativa

Si richiede di gestire le identità digitali in conformità all’art. 64 del CAD, la firma digitale remota comprensiva di certificati e servizi di sicurezza applicativa.

La domanda, in questo caso, è: visto che nell’agenda di Caio c’è il progetto SPID per l’identità digitale che è già in fase di realizzazione, come si accordano le due cose?

E poi, sempre in termini quantitativi, quanti sono i moduli on premise da integrare? Non è cosa di poco conto, visto che potrebbero teoricamente essercene qualche migliaio sparsi su tutto il territorio nazionale. Forse alla fine si obbligherebbero gli enti più piccoli a scegliere una soluzione specifica, ma la scelta dovrebbe essere politica e non forzata dalla convenienza tecnico/economica del fornitore.

Lotto 3: Servizi di interoperabilità per i dati e di cooperazione applicativa

Al punto a) si richiedono servizi di modellazione, progettazione e realizzazione di soluzioni di interoperabilità per i dati (Linked Data/Open Data/Big Data);

Al punto b) si richiedono servizi di progettazione, realizzazione e gestione di soluzioni di cooperazione applicativa.

Questo è, a mio parere, l’elemento più critico di tutto il bando. E lo è perché, in mancanza di un progetto strategico di governance, i tecnici si sostituiscono ai politici e rischiano di dare soluzioni tecnologiche a problemi organizzativi complessi. Questo punto mi sta particolarmente a cuore, poiché sono più di 15 anni che vado in giro raccontando un sogno e facendo proposte nel vago tentativo di sensibilizzare la politica, ho ricevuto un enorme  consenso ed approvazione bipartisan, ma poi, nei fatti, a prescindere da esperienze locali di successo, nessuno si è mai impegnato per tradurre le proposte in un progetto per il paese.

Con il senno di poi, è evidente che  alla fase dei progetti e-government è  mancata una governance che avesse ben presente il tema dell’inter-operabilità come tema di importanza strategica per garantire un ritorno degli investimenti nel tempo e per ospitare evoluzioni dei vari singoli sistemi (tema che sta sopra  le singole tecnologie  e i vari e possibili modelli di licencing e/o di riuso).

Ma le valutazioni a consuntivo dei progetti di e-gov hanno fatto emergere anche un’altra criticità di cui il bando non sembra tener conto. I vari attori che hanno  vissuto quella fase concordano abbastanza  su un limite  evidente: c’era una impostazione di push tecnologico e mancava un approccio che tenesse conto dell’importanza della conoscenza dei processi organizzativi tipici degli enti a cui ci si voleva rivolgere. Una condizione indispensabile per riuscire a produrre davvero valore per enti e cittadini  e per realizzare investimenti che potessero dare buoni frutti nel tempo.

L’approccio del nuovo bando sembra non tener conto di quel che c’è da imparare dalla storia vissuta e dei feedback da attivare per non ripetere due volte lo stesso errore. In termini di efficacia ed efficienza bisognerebbe riuscire a coniugare un approccio strutturato general-purpose con la specifica conoscenza dei processi. La conclusione è che, nelle competenze necessarie che bisognerebbe includere nella ricerca di un partner affidabile per affrontare questi problemi, non sono secondarie le conoscenze di dominio applicativo.

Mi spiego nel dettaglio. Ci sono due scuole di pensiero: quella di chi dice che bisogna costruire dei grossi datacenter nei quali centralizzare tutto, e quelli che pensano che la soluzione risieda in un numero limitato (3) di Centri Servizi distribuiti sul territorio. Io sono fra questi ultimi. Internet non ha una governance unica né risiede in un unico datacenter, anzi, è esattamente il contrario. Internet è un ecosistema che vive, cresce e funziona grazie alla produzione di informazioni  da parte di tutti i partecipanti. Quello che è importante, è essere in grado di comprendersi, di usare linguaggi condivisi, di scambiarsi le informazioni dal punto di vista semantico, non tecnico. Come affermaJeremy  Rifkin, il futuro sta nella distribuzione e nella diversificazione sulla rete, non nell’accentramento. In Italia l’e-government è in mano a dei brontosauri di stato, per i quali l’accentramento rappresenta una forma di deja-vu rispetto al loro passato mainframe based. Non è questo quello che ci serve, non è quello di cui il paese ha bisogno. Occorre guardare avanti.

Abbiamo visto sopra come sul piano fisico sarebbe fantastico risolvere il problema attraverso 3 centri servizi.

Sul piano logico, invece, e la storia e l’attualità del Made in Italy ce lo insegnano, la differenziazione è un valore, ammesso di riuscire a sopravvivere.

Oggi, a seguito della crisi e dopo una serie di acquisizioni e ristrutturazioni, in Italia ci sono meno di 10 aziende a dividersi il 95% del mercato software della PA. 15 anni fa erano circa 90. Quindi la cooperazione applicativa può essere la soluzione, ma deve essere messa in esercizio cum grano salis.

Distinguiamo due aspetti: a) la modellazione dei dati resi pubblici dalle amministrazioni sotto forma di linked open data; b) i servizi erogati dalle pubbliche amministrazioni ai propri clienti in cooperazione applicativa:

a) Servizi di modellazione, progettazione e realizzazione di soluzioni di interoperabilità per i dati (Linked Data/Open Data/Big Data)

In questo caso, ci troviamo di fronte al tema dell’interoperabilità dei dati, laddove l’introduzione di elementi di standardizzazione che ne facilitino la fruibilità e che ne chiariscano la semantica non sarebbero certo dannosi.

Un ente può decidere autonomamente di mettere a disposizione un insieme di dati: si va dai movimenti delle navi nei porti, alla spesa divisa per centri di spesa, ai consumi elettrici, idrici e di gas, alle siringhe consumate negli ospedali, e chi più ne ha più ne metta. Esistono solo poche regole che limitano le tipologie di dati pubblicabili: i dati non devono rivelare segreti di stato, i dati devono garantire la privacy (e quindi deve essere cancellato qualunque riferimento alle persone fisiche e/o giuridiche). Inoltre, per fornire maggior valore, i dati devono essere forniti in un formato raw, senza essere stati aggregati in alcun modo. Non è un problema dell’ente preoccuparsi della facilità con la quale questi dati possono essere utilizzati, però, una qualche forma di standardizzazione e di descrizione semantica ne facilita senza dubbio l’utilizzo da parte delle terze parti.

Anche qui, però, è possibile intervenire in maniera razionale: si potrebbe infatti mettere in piedi un sistema di modellazione che definisca, nel rispetto degli standard internazionali, il formato di un certo dato. Se quel dato non è mai stato modellato, sarà compito del primo produttore costruire il modello, discuterlo attraverso una peer review ed eventualmente estenderlo ed adeguarlo, per poi renderlo disponibile, in maniera versionata, nel repository dei metadati. Se invece il modello già esiste, dovrà essere utilizzato per la produzione dei dati o, in caso di evidente incoerenza del metamodello, dovrà essere prodotta una nuova versione di quest’ultimo.

b) Servizi di progettazione, realizzazione e gestione di soluzioni di cooperazione applicativa

Ci troviamo di fronte all’esercizio di un compito istituzionale che l’amministrazione deve svolgere. Proverei a metterla in questi termini: una amministrazione ha senso di esistere perché eroga servizi ai propri clienti: i cittadini, le imprese, le altre amministrazioni che a loro volta da essa dipendono per lo svolgimento dei propri compiti istituzionali. Se una qualsiasi amministrazione non erogasse servizi ad altre amministrazioni, né ai propri cittadini né alle imprese ad essa legate o associate, non avrebbe motivo di esistere, in quanto la sua esistenza avrebbe come unico fine la propria perpetuazione, e potrebbe quindi essere smantellata immediatamente, con grande risparmio di denaro pubblico e nessun impatto negativo sull’universo, anzi, probabilmente non aumenterebbe l’entropia totale. Insomma, è necessario trasformare ciascuna amministrazione in una SOO, unaService Oriented Organization, che eroga servizi a chi è abilitato a richiederli.

Dal punto di vista logico, ciascun servizio può e deve essere descritto in termini di Richiesta e di risposta, prevedendo anche la descrizione di comportamenti particolari, che chiamiamo eccezioni.

Se accettiamo, o quanto meno ipotizziamo di prendere per buono questo punto di vista, dobbiamo analizzare quali sono i servizi erogati da ciascuna classe di amministrazioni. Questo compito può essere svolto esclusivamente dall’amministrazione stessa, sotto il controllo dei clienti dichiarati.

Il discorso si applica a tutte le amministrazioni centrali (incluse INPS, ISTAT, e similari) prese singolarmente, ed a tutte le amministrazioni locali, rappresentate attraverso le loro associazioni, ad esempio l’ANCI.

Si inizia con ciascuna amministrazione che stila l’elenco dei servizi che eroga verso l’esterno, non necessariamente tutti, ma ragionevolmente tutti quelli più importanti. Successivamente si raggruppano i servizi dell’elenco secondo la regola 80/20 di Pareto, selezionando il 20% dei servizi che coprono l’80 per cento delle attività.

Si descrive quindi ciascun servizio, specificando come cosa deve contenere la richiesta, quali sono le possibili risposte, quali sono le possibili eccezioni, descrivendo inoltre se verrà trattato in modo sincrono (un servizio che fornisce una risposta immediata: ad esempio una visura di stato di famiglia) o asincrono (un servizio che attiva un processo complesso interno all’organizzazione, che fornirà una risposta all’atto del suo completamento o durante eventuali interazioni successive alla sua attivazione: ad esempio una richiesta di iscrizione scolastica).

Nel caso in cui lo stesso servizio sia erogato da enti diversi enti, il contenuto informativo di una specifica richiesta o risposta, sarà in generale concordato nel corso di tavoli di lavoro, e verrà trovata una soluzione che, nel rispetto della normativa generale, tenti di accomodare le eventuali esigenze particolari. Questo approccio è già stato utilizzato in passato, ed ha portato alla definizione condivisa dei servizi fiscali, demografici e scolastici dei comuni.

Ciascuna amministrazione detiene la ownership di uno specifico sottoinsieme di definizioni dei dati. Ad esempio, l’Agenzia delle Entrate detiene la ownership del codice fiscale, mentre il ministero degli interni detiene quella della persona fisica e qualcuno dovrebbe possedere quella di indirizzo (il catasto?). E’ compito di ciascuna organizzazione fornire la definizione pubblica delle strutture dei dati di cui detiene la ownership, mentre è dovere di tutte le altre amministrazioni utilizzare queste strutture dati per descrivere i servizi.

L’attività che ho appena descritto, si chiama costruzione dei metadati della pubblica amministrazione, ed è l’attività più importante, quella senza la quale non è possibile realizzare l’interoperabilità applicativa. E’ il primo passo necessario per la costruzione dell’ontologia della pubblica amministrazione, ed è anche il passo necessario a far si che il SPC serva a qualcosa di concreto.

Attraverso una metafora, potremmo descrivere l’infrastruttura di rete come una rete ferroviaria e l’SPC come dei vagoni portacontainer: le scritte all’esterno ci permettono di indirizzare correttamente il container, ma una volta aperto, in mancanza dei metadati, non sapremmo assolutamente come utilizzarne il contenuto.

Un altro aspetto importante di questo approccio, è che garantisce l’autonomia amministrativa degli enti: infatti, non impone agli enti uno specifico modello organizzativo interno, ma si limita a descriverne il comportamento ai morsetti, lasciandolo libero di implementare i propri processi interni. Allo stesso tempo, fornisce la base per la reingegnerizzazione dei processi interni, favorendo la costruzione di modelli di processo di riferimento, utilizzabili per una successiva riorganizzazione.

Alla luce di queste considerazioni, lasciare la realizzazione di queste attività fondamentali per il funzionamento del paese nelle mani di privati che vinceranno una gara al ribasso e che saranno quindi interessati esclusivamente a fare utili, la trovo una iniziativa criminale oltre che stupida.

Lotto 4: Servizi di realizzazione e gestione di portali e servizi on-line

Al punto a) si richiedono servizi di realizzazione e gestione di portali e siti web in logica di multicanalità.

Questo metterà in moto un meccanismo perverso di realizzazione di applicazioni non standardizzate, con un altissimo costo futuro di manutenzione correttiva, evolutiva ed adattativa.

Se si fosse proceduto come descritto precedentemente alla costruzione dell’Ontologia della PA, questi portali potrebbero essere derivati automaticamente dai metadati, e personalizzati esteticamente rispetto alle esigenze di ciascun ente. All’occorrenza di un cambiamento nell’ontologia, magari legato ad un cambiamento di legge, il portale potrebbe essere rigenerato automaticamente, con estrema rapidità, con costi ridottissimi e con il minimo time-to-market possibile.  Insomma, un approccio lontano anni luce rispetto a quelli attualmente in uso in Italia.

Al punto b) si richiedono servizi di gestione di contenuti tramite soluzione di content management

Al punto c) si richiedono servizi di realizzazione e gestione di APPS per dispositivi mobili

Qui vale lo stesso discorso del punto a): basta costruire un generatore per IOs ed Android ed il gioco sarebbe fatto, anche qui a costi ridotti e con un time-to-market ridottissimo..

Considerazioni politiche

Al di là degli aspetti tecnici che spero di aver chiarito nel capitolo precedente, vorrei ora soffermarmi su alcune considerazioni di carattere squisitamente politico.

Innanzitutto, vorrei riepilogare i numeri del bando nella seguente tabella

Ho fatto un rapido survey, e, salvo errori ed omissioni, mi sembra che le uniche aziende che hanno le potenzialità per partecipare come mandatarie, siano le seguenti 10:

• Accenture, Almaviva, Cap Gemini, Engineering, HP Italia ed IBM Italia, come system integrator
• Fastweb, Poste Italiane e Telecom Italia per la parte riguardante le infrastrutture
• Oracle, come fornitore di tecnologie (proprietaria)

Il bando incentiva (ma non dice come …) la costituzione di RTI e consorzi, con l’auspicio di favorire la partecipazione delle PMI attive sul territorio e parzialmente interessate dalle attività. Vieta inoltre la partecipazione di una stessa impresa a più di un raggruppamento o consorzio pena l’esclusione.

Insomma, a parole le idee ci sono. Vediamo cosa potrebbe succedere nella pratica.

Ipotesi 1: si formano alcune RTI che competono tra loro

In questo caso potremmo ipotizzare alcuni consorzi, diciamo da 3 a 6 che si spartiscono il montepremi.

In passato, la partecipazione a questo tipo di gare ha portato a ribassi fino al 50% sul brezzo a base d’asta.

Questo potrebbe voler dire che in media, nel caso di 3 consorzi formati da 3 aziende ciascuno, ogni azienda vincerebbe 100% * 50% / 3 = 16,6% mentre le altre 7 aziende rimarrebbero a bocca asciutta, dopo aver speso comunque qualche parecchie decine di migliaia di per partecipare al bando.

Punti di forza

• Massima riduzione dei costi
• Massima riduzione della qualità
• Imprevedibilità dell’esito finale
• Probabile strozzatura delle PMI locali (non partecipanti direttamente nella RTI) da parte della RTI vincitrice, che darebbe loro le briciole per far fare una gran parte del lavoro.
• Il software integrator vincente acquisisce di fatto il diritto di definire gli standard della PA, che ovviamente deriverebbero direttamente dalla sua produzione pregressa. Insomma, i metadati dell’azienda X diventerebbero di fatto i metadati dell’intero paese.
• Ma questa è una mia opinione molto Personale: Accenture, HP, IBM ed Oracle non sono aziende italiane. Il loro unico interesse è fare cassa per redistribuire lauti utili ai loro azionisti. Ho volutamente lasciato fuori dalla lista Capgemini che è una azienda principalmente europea e noi, fino a prova contraria, siamo in Europa.

Punti di debolezza

• Massima riduzione della qualità
• Imprevedibilità dell’esito finale
• Probabile strozzatura delle PMI locali (non partecipanti direttamente nella RTI) da parte della RTI vincitrice, che darebbe loro le briciole per far fare una gran parte del lavoro.
• Il software integrator vincente acquisisce di fatto il diritto di definire gli standard della PA, che ovviamente deriverebbero direttamente dalla sua produzione pregressa. Insomma, i metadati dell’azienda X diventerebbero di fatto i metadati dell’intero paese.
• Ma questa è una mia opinione molto personale: Accenture, HP, IBM ed Oracle non sono aziende italiane. Il loro unico interesse è fare cassa per redistribuire lauti utili ai loro azionisti. Ho volutamente lasciato fuori dalla lista Capgemini che è una azienda principalmente Europea e noi, fino a prova contraria, siamo in Europa.

Ipotesi 2: si forma una RTI che comprende tutti i player, in proporzione alla loro presenza territoriale

In questo caso, si potrebbe ipotizzare la creazione di un unico consorzio, che risponda per tutte le attività del bando. Al consorzio potrebbero partecipare tutte le aziende italiane (Almaviva, Engineering, Poste e Telecom) e Fastweb per la parte relativa alle infrastrutture (ha fatto grossi investimenti in Italia).

HP Italia, IBM Italia ed altri fornitori di HW (penso a Dell, ad esempio) o di software (Oracle) potrebbero beneficiare indirettamente attraverso la fornitura fisica dei sistemi, in questo caso davvero al ribasso.

Al consorzio potrebbero inoltre partecipare, pro quota, tutte aziende locali che hanno installazioni presso gli enti destinatari dei servizi.

In questo modo si potrebbe minimizzare il ribasso, e suddividere il montepremi, in maniera proporzionale, fra tutti i partecipanti, con il risultato che tutti, grandi e piccoli, vincono una parte del lavoro.

Inoltre, questo approccio prevedrebbe la definizione e l’utilizzo di standard indipendenti, costruiti sulla base delle esigenze della PA e non dei requisiti tecnici dei fornitori

Punti di forza

• Massimizzazione del livello di qualità
• Creazione di uno standard indipendente dal software integrator
• Difficoltà nel mettere insieme e gestire le primedonne

Punti di debolezza

• Difficoltà nel mettere insieme e gestire le primedonne

Ipotesi 3: uguale all’ipotesi 2, ma integrando la partecipazione al bando gara da 550 milioni di del 17 dicembre

Le aziende si aggregano tra loro come descritto, e lo stesso consorzio risponde contemporaneamente anche al bando da 550 Milioni di euro.

Punti di forza

• Massimizzazione del livello di qualità
• Creazione di uno standard indipendente dal software integrator
• Massima razionalizzazione della spesa
• Difficoltà nel mettere insieme e gestire le primedonne

Punti di debolezza

• Difficoltà nel mettere insieme e gestire le primedonne

Conclusioni

L’approccio che propongo presenta innumerevoli vantaggi per tutti gli attori in gioco:

• Tutti partecipano pro quota alla gara, fornendo ossigeno non soltanto alle grosse aziende, ma soprattutto alle piccole che sono quelle che probabilmente ne hanno maggior bisogno;
• Il progetto complessivo, in particolare rispetto a tutte le realizzazioni software, dovrebbe essere gestito con un approccio Agile (SCRUM).
• Rispetto ai sistemi relativi alla PA locale, si dovrebbe andare verso una standardizzazione de facto, favorendo la semplificazione e la razionalizzazione degli attuali sistemi informativi e la loro interoperabilità applicativa con l’intero universo PA.
• I servizi risultanti saranno installati presso tutti gli enti locali, in sostituzione degli attuali, e saranno per definizione, tra loro interoperabili.
• A partire dai servizi, dovrebbero essere formalizzati requisiti e test di dettaglio, sui quali impiantare uno sviluppo RDD o TDD. Questo permetterebbe di misurare la dimensione dei servizi in termini di Test Points, una misura alternativa, moderna e molto più efficace dei function points. Questo approccio, applicato a ciascun servizio,  garantirebbe l’accettazione  solo di quelli che abbiano superato i test.
• Una volta fatto il censimento dei servizi e definiti i metadati principali, la realizzazione di ciascun servizio, in ordine di importanza, potrebbe essere presa in carico da esattamente 2 fornitori, in modo da avere un backup qualitativo (una sorta di pair programming applicato alle aziende), con rilasci ogni 30 giorni.
• Si innescherebbe un circolo virtuoso che permetterebbe alle aziende più smart quelle capaci di adeguarsi in tempi rapidi all’utilizzo di tecnologie evolute ad alta produttività, di sviluppare più servizi.