Architettura DXC

Possiamo finalmente aprire una discussione sulla proposta di DXC dal momento che si sta concretizzando il progetto dei fabbisogni.
Premetto che la presentazione preliminare mi sembra pienamente convincente e anche i tempi previsti di realizzazione soddisfano la logica devops che sta alla base del progetto.
Credo tuttavia che alcuni aspetti meritino come è naturale un approfondimento che costituirà il lavoro dei prossimi giorni, con questo primo intervento vorrei segnalare alcune caratteristiche dell' architettura che rappresentano altrettante scelte realizzative.

• Per l' ETL è stato scelto/proposto il framework SPRING il che vuol dire che ci muoveremo in ambiente JAVA, in mancanza di ulteriori specifiche dobbiamo presupporre che non verranno utilizzati prodotti specifici per le funzioni di omogeneizzazione, normalizzazione, deduplica, rating delle fonti, ma tutto sarà scritto ex novo.
• Tre oggetti appaiono ancora sfumati e non a caso sono rappresentati in grigio; nell' ordine sono il web presentation server, il geo-server e le Data abstraction API. Tutte e tre le componenti appartengono alla parte persistente del sistema, ma mi chiedo come mai non risiedano in containers. Nel progetto originale esisteva un database dei metadati che credo debba essere collocato nel componente Data abstraction API per dargli la necessaria flessibilità e potenzialità di sviluppo,
• Occorre inserire degli handle per il lavoro che svilupperà Almaviva riguardo alle app e alla gamification, non credo sia sufficiente una interazione solo tramite API
• Non trovo tra i containers nulla riguardo alla profilazione utente e alla user experience, dobbiamo quindi presumere che tali funzioni verranno equamente suddivise tra il web presentation server, elastic serach e il machine learning, tuttavia non mi è chiaro dove persisteranno le informazioni.
• Per il machine learning l' unica specifica è il linguaggio python e postgres per le persistenze; quindi anche qui mi pare di capire che tutti gli algoritmi verranno scritti ex novo

Mi fermo perchè ho messo abbastanza carne al fuoco e attendo i vostri commenti.

Intervengo sul post di Luca per unificare le nostre osservazioni.

Piano di lavoro - presentazione pag. 4
1. Non si vedono punti di interazione/verifica tecnica. Molte attività come ad esempio l'armonizzazione dei Metadati, necessitano di una fase di approvazione e consolidamento. Premesso che mediaGEO si adopererà ad assistere per velocizzare queste fasi, vanno comunque previste e definite nel programma.
2. Così come proposto si termina lo sviluppo ad Aprile 2020 e la manutenzione / garanzia a Luglio 2020. Credo che si debba analizzare il conseguente allungamento del progetto ad Aprile 2021 considerando l'anno inizialmente previsto per l'avvio, che ricordo ha necessità di far crescere la conoscenza e il bagaglio di dati dell'intelligenza artificiale, derivandola dalle interazioni utente.

Architettura di riferimento - pag. 5
1. Non vedo l'apertura o collegamento alle attività di sviluppo per il Lotto4 (Almaviva). Ricordiamo la necessità per il successo del progetto di prevedere un momento di interazione tra i due fornitori Lotto1 e Lotto 4.
2. GeoServer e WebServer sono un unico sistema di presentazione dati agli utenti e non vanno visti come elementi separati, la visualizzazione geografica di Forma Romae è tra i prerequisiti essenziali per l'interazione con gli utenti. Credo che questa parte necessiti una maggiore attenzione.
Così come inserito nella slide il GeoServer sembra una appendice inserita senza motivazione, mentre vale ricordare l'importanza della generazione di mappe proprie di Forma Romae che potranno andare a contribuire alle mappe di base della NIC con i necessari servizi WEB (WMS, WCS, etc.) da realizzare.

Riferimenti Organizzativi - pag. 7
Non sono riportati i riferimenti della mediaGEO che assiste nella progettazione:
Ing. Renzo Carlucci (r.carlucci@mediageo.it), Ing. Aldo Riggio (a.riggio@mediageo.it)