Digital Integration Hub

Affinchè gli utilizzatori possano recuperare i dati per finalità operazionali, di Real Time Analytics o di Operational Analytics, è necessario minimizzare il più possibile la latenza tra l’istante in cui un record viene inserito, modificato o cancellato nel sorgente e la propagazione dell’evento nella piattaforma di integrazione condivisa. Questo permette di ridurre la probabilità che i consumatori ricevano una versione non più aggiornata dei dati o sperimentino l’assenza di dati che invece si aspetterebbero di ricevere. La scelta delle componenti tecnologiche che compongono la soluzione di integrazione è un aspetto critico che ha un impatto diretto sulla latenza, in tutte le fasi di offloading dalle sorgenti, trasformazione in tempo reale e ingestion nella piattaforma. In ogni caso, una soluzione che prevede l’offloading dei dati dalle sorgenti deve sempre considerare la possibilità di tollerare un regime di consistenza eventuale che, seppur infinitesima, può essere un ostacolo per determinati casi d’uso che richiedano una consistenza stretta di tipo Read After Write o che necessitano i dati in hard real time. 

Affichè lo stesso dato estratto dalle sorgenti una volta sola possa essere riutilizzato tra diversi consumatori, operazionali ed analitici, è necessario prevedere nella soluzione architetturale un componente che agisca come sorgente unica di verità per la consistenza e l’integrità del dato stesso. Tale aspetto è fondamentale, in quanto bisogna garantire che tutti i consumatori che accedono ad un’entità dati ricevano la stessa versione dei record e che le repliche fisiche di un dataset su vari layer della piattaforma siano il più possibile allineate a livello temporale. In quest’ottica non basta considerare solo lo scenario standard di operatività, ma anche i casi particolari, come la necessità di correggere bug, fixare anomalie o riprocessare dall’inizio l’intero dataset (questo caso capita spesso per finalità di caricamento iniziale di un nuovo consumatore che ha necessità di sottoscriversi al dataset). I componenti architetturali che vengono scelti come single source of truth devono garantire la possibilità di conservare lo storico dei dati a tempo indeterminato (adempiendo in ogni caso ai vincoli compliance normativa relativa al trattamento dei dati personali). I dati devono essere esposti sotto forma di strutture dati di dominio, autoconsistenti, autodescrittive complete in termini di contenuto informativo che può essere di interesse per la maggior parte degli use case di consumo. La fornitura dei dati ai consumatori deve garantire una buona performance di lettura, risolvendo le complessità tecniche in fase di alimentazione delle strutture esposte, in modo da rendere l’interrogazione dell’utente il più semplice possibile.

Per rendere riusabili i dati su larga scala è necessario che la piattaforma di integrazione sia ibrida e convergente, ovvero supporti diverse tecniche di conservazione, elaborazione e accesso ai dati, per ottimizzare il recupero da parte di una categoria di consumatori più vasta ed eterogenea possibile. La piattaforma deve essere in grado di gestire dati strutturati, semistrutturati e non strutturati, estratti da applicazioni di dominio o ricavati da sorgenti esterne, come sensori, social network, open data, prodotti SaaS. Inoltre l’architettura deve prevedere la possibilità di accedere ai dati aziendali tramite interfacce API e basate su richiesta e risposta, consumo continuo di eventi, query ah-hoc, query federate, condivisione di data product.