Abstract

Questo è l’articolo conclusivo di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.

Per chi non li avesse letti, consiglio di leggere gli articoli precedenti della serie, dai titoli:

• “I principi di un moderno Data Management”: descrive le sfide dell’IT nella nuova era di digitalizzazione e i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati
• “L’approccio data-centrico che cambia l’IT”: descrive i principi e i vantaggi di un orientamento di progettazione delle architetture IT che considera i dati come asset centrale e riusabile e le applicazioni come elementi effimeri che producono o consumano dati di interesse per l’intera azienda
• “L’esigenza di governo nella gestione dei dati”: descrive i principali aspetti di governance da considerare per abilitare architetture IT data centriche e distribuite e mantenere il controllo dei dati a riposo e in movimento
• “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un modello emergente di progettazione delle piattaforme dati basato sull’uso avanzato dei metadati per rendere la piattaforma più automatizzata, self-service e versatile alle diverse esigenze degli utilizzatori
• “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: descrive i principi basilari del modello di progettazione software Domain Driven Design, che ha introdotto l’idea della decentralizzazione delle responsabilità e ha avuto grande influenza sul Data Management
• “Il Data Mesh e la spinta verso una gestione dati distribuita”: descrive lo scenario di Data Management precedente al modello Data Mesh e le ragioni che hanno portato alla ricerca di decentralizzazione delle responsabilità sui dati in una prospettiva domain-oriented
• “Il Data Mesh e il consumo self service dei dati come prodotti”: descrive la visione dei dati come prodotti gestiti end-to-end da team vicini al dominio di appartenenza e condivisi con gli altri team mediante una piattaforma di integrazione fruibile da tutti e governata in modo federato.

I principi architetturali e il ruolo dell’Enterprise Architect

In Quantyca crediamo che, alla base di un’architettura enterprise, al di là dei componenti e delle tecnologie che la costituiscono, variabili in base alle esigenze specifiche del business del cliente, ci debbano essere tre principi fondamentali, che determinano la direzione verso cui l’architettura IT evolve nel tempo:

1. centricità del dato
2. governo
3. adattabilità

Negli articoli che compongono la serie abbiamo iniziato il tour parlando della necessità di evolvere da un paradigma tradizionalmente application-centrico, ereditato dalla prima ondata di digitalizzazione dei processi di business, ad un paradigma data-centrico, più adatto alle necessità digitali presenti e future, che richiedono uno sfruttamento e un riuso importante del dato come asset aziendale per supportare funzionalità di analisi avanzate, apprendimento automatico e servizi data-driven su larga scala. Abbiamo discusso come un paradigma data-centrico ha il beneficio di razionalizzare i flussi di integrazione dati e ridurne i costi di progetto e maintenance. Sono le motivazioni alla base del principio della centricità del dato.

Abbiamo poi affrontato il tema della distinzione tra le caratteristiche dei Data On The Inside, per l’utilizzo interno dei dati nelle logiche di un’applicazione, e i principi con cui dovrebbero essere gestiti i Data On The Outside, ovvero i data asset condivisi con il resto dell’architettura enterprise, che possono essere riusati all’interno di altre applicazioni a supporto di altre finalità di business. Abbiamo evidenziato la necessità di garantire basso accoppiamento tra le applicazioni, interfacce di esposizione dei dati stabili e facilmente utilizzabili, basate su standard, per favorire l’interoperabilità tra applicazioni differenti. Questi aspetti sono i pilastri su cui si basa il secondo principio architetturale, quello del governo, che diventa sempre più rilevante in un’architettura distribuita, in cui diversi componenti devono interagire e nella quale uno stesso dato può essere replicato in molteplici sistemi, passando per pipeline di integrazione più o meno complesse. Abbiamo proseguito il discorso entrando nel cuore delle tematiche di Data Governance, insistendo sulla necessità di legare, tramite il processo di Data Classification, il significato semantico dei dati, riportato nel Business Glossary, alla loro rappresentazioni fisiche, censite nel Data Catalog. Abbiamo spiegato l’utilità di tracciare il Data Lineage, per facilitare analisi di impatto, e di implementare controlli strutturati di Data Quality per garantire la completezza, la consistenza e l’affidabilità dei data asset messi a disposizione degli stakeholder interessati.

Infine abbiamo trattato il terzo principio architetturale, quello dell’adattabilità, sotto due dimensioni, quella tecnologico-architetturale e quella organizzativa. Un’architettura è adattabile se è in grado di fornire opzioni, dando la possibilità di non vincolarsi fortemente ad una scelta tecnica fatta nel presente ma di essere in grado, se necessario, di modificare tale scelta in futuro in tempi rapidi, nel momento in cui dovessero cambiare le esigenze e il contesto di business: l’adattabilità è importante sotto l’aspetto dei pattern usati, del numero e della varietà di applicazioni coinvolte, degli stack tecnologici selezionati e delle finalità di utilizzo del dato ammesse.

Dal punto di vista tecnologico-architetturale, abbiamo visto come il modello Data Fabric mette a disposizione una piattaforma di integrazione data-centrica, poliglotta, scalabile e metadata-driven, in grado di automatizzare (e quindi velocizzare) diverse attività manuali ordinarie di Data Management, tramite componenti di intelligenza in grado di sfruttare al meglio la varietà di metadati raccolti da tutti gli attori e gli agenti che prendono parte all’architettura. Abbiamo visto inoltre come la componente di piattaforma sia centrale anche nel paradigma Data Mesh, in cui assume una connotazione sempre più di elemento condiviso e self-serve, che si pone l’obiettivo di massimizzare l’autonomia dei gruppi di lavoro per ridurre colli di bottiglia e passaggi di consegna poco agili.

Dal punto di vista organizzativo, abbiamo discusso l’influenza che il Domain Driven Design ha avuto di recente anche sul mondo del data management, portando all’affermazione del paradigma Data Mesh, che propone di gestire in modo decentralizzato, federato e domain-oriented il ciclo di vita dei Data Product afferenti ad un certo dominio di business. Di conseguenza, il Data Mesh cambia lo scenario organizzativo di suddivisione e composizione dei gruppi di lavoro, non più orientato ad una dimensione tecnica, in cui le persone venivano organizzate per team competenti su una particolare fase della pipeline di gestione del dato (es: team responsabile della gestione Big Data) o su un aspetto specifico di data management (es: team esperto di modelli data warehouse), ma ad una dimensione in linea con i domini funzionali e i contesti di business. In questa nuova prospettiva, non si delinea più un unico modello dati enterprise centralizzato e difficile da evolvere, sotto la responsabilità di un unico team, ma una mesh di modelli specifici dei diversi domini di business, che portano alla formazione di elementi riusabili e componibili tra di loro in modo pienamente flessibile, detti Data as a Product.

Come Quantyca ci capita spesso di fornire ai nostri clienti servizi di consulenza per il disegno o la revisione dell’architettura IT enterprise, che può essere spinta da driver differenti, in base al contesto specifico dell’azienda: alcuni dei più comuni sono la volontà di migliorare il supporto digitale e la qualità del servizio IT, abilitare nuovi use case richiesti dall’espansione del business, razionalizzare i costi delle infrastrutture IT, ridurre il debito tecnologico, adeguare l’architettura a mutamenti organizzativi di corporate. Il lavoro che svolgiamo come Enterprise Architect è quello di valutare le priorità in termini di valore atteso dal cliente e i vincoli a contorno e identificare l’evoluzione architetturale più adatta per lo scenario specifico del cliente.

Nel disegno dell’architettura enterprise target partiamo da uno schema di riferimento della piattaforma di integrazione che riteniamo ideale sulla carta, ma operiamo poi scelte spesso diverse per declinare il disegno teorico in una soluzione ottimale per le esigenze peculiari del cliente. Non esiste l’architettura perfetta per qualunque contesto: nel proporre la soluzione si fanno delle scelte considerando diversi tradeoff tra obiettivi a volte contrastanti tra di loro, ad esempio la scalabilità della piattaforma e il contenimento dei costi, l’agilità di lavoro e il mantenimento del controllo, l’ottimizzazione dell’accesso al dato e la razionalizzazione dei sistemi.

I tre principi architetturali di base che abbiamo descritto negli articoli di questa serie ci guidano nelle scelte e nel delineare il piano di evoluzione dell’architettura: infatti, nella maggior parte dei casi, l’implementazione di un’architettura target è un processo incrementale e diviso in step, in cui la gestione del transitorio è solitamente uno degli elementi più critici, essendo una fase in cui possono moltiplicarsi i costi infrastrutturali, i costi di licenza, i costi di integrazione e i costi delle operations. La sequenza degli step di transizione e le interdipendenze tra di essi e con altre attività progettuali in essere sono fattori chiave da considerare per delineare il piano di evoluzione complessivo di un’architettura, che deve bilanciare il raggiungimento degli obiettivi business e degli obiettivi IT.

La figura dell’Enterprise Architect assume la sua importanza in un simile scenario “in movimento”, che sta diventando sempre più la nuova normalità nell’informatica e, in particolare, nell’area del Data Management: l’obiettivo dell’Architect non è solo quello di disegnare l’architettura target e il piano di evoluzione, ma anche di contribuire a definire una vera e propria Data Strategy aziendale con obiettivi condivisi di medio periodo, che orienti le attività progettuali e gli investimenti IT nell’ambito del Data Management in linea con le aspettative dell’azienda e la direzione strategica stabilita.

La Data Strategy come motore dell’IT was originally published in Quantyca on Medium, where people are continuing the conversation by highlighting and responding to this story.

Abstract

Questo è il settimo articolo di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.

Per chi non li avesse letti, consiglio di leggere gli articoli precedenti della serie, dai titoli:

• “I principi di un moderno Data Management”: descrive le sfide dell’IT nella nuova era di digitalizzazione e i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati
• “L’approccio data-centrico che cambia l’IT”: descrive i principi e i vantaggi di un orientamento di progettazione delle architetture IT che considera i dati come asset centrale e riusabile e le applicazioni come elementi effimeri che producono o consumano dati di interesse per l’intera azienda
• “L’esigenza di governo nella gestione dei dati”: descrive i principali aspetti di governance da considerare per abilitare architetture IT data centriche e distribuite e mantenere il controllo dei dati a riposo e in movimento
• “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un modello emergente di progettazione delle piattaforme dati basato sull’uso avanzato dei metadati per rendere la piattaforma più automatizzata, self-service e versatile alle diverse esigenze degli utilizzatori
• “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: descrive i principi basilari del modello di progettazione software Domain Driven Design, che ha introdotto l’idea della decentralizzazione delle responsabilità e ha avuto grande influenza sul Data Management
• “Il Data Mesh e la spinta verso una gestione dati distribuita”: descrive lo scenario di Data Management precedente al modello Data Mesh e le ragioni che hanno portato alla ricerca di decentralizzazione delle responsabilità sui dati in una prospettiva domain-oriented

L’articolo conclusivo, dal titolo “La Data Strategy come motore dell’IT” chiude la serie con un riassunto dei principi architetturali che riteniamo basilari per una strategia di Data Management efficace e una visione del ruolo dell’Enterprise Architect nel delineare l’evoluzione delle architetture dati.

Zhamak Dehghani, negli articoli How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh e Data Mesh Principles and Logical Architecture, ha proposto un cambio di paradigma radicale per il mondo del Data Management, che ha poi ripreso ed esteso nel libro Data Mesh. Il paradigma, chiamato appunto Data Mesh, si basa su quattro pillar basilari:

• domain ownership
• data as a product
• selve-serve data platform
• federated computational governance

In Quantyca riteniamo che le idee alla base del paradigma Data Mesh siano interessanti e che questo rappresenti una direzione di pensiero architetturale e organizzativo per il mondo del Data Management in linea con le aspettative di un business che intende essere sempre più data-driven. Nell’articolo precedente abbiamo discusso il primo pillar, quello della Domain Ownership: ora tratteremo gli altri tre principi fondamentali.

Data as a Product

Il paradigma Data Mesh è in linea con i principi del data-centrismo, in quanto riporta il dato ad avere piena dignità di prodotto digitale (Data as a Product) e a non essere più considerato come by-product delle applicazioni in cui esso viene generato.

Il concetto di Data Product è centrale nel paradigma Data Mesh: esso rappresenta un’unità di deploy afferente ad un determinato ambito di dominio, che mette a disposizione dei consumatori un set di entità dati logicamente correlate e tutte le strutture necessarie per rendere fruibile il loro utilizzo: interfacce di consumo (data API), diagrammi del modello concettuale, logico e fisico dei dati, documentazione funzionale, service level objectives (SLO), metriche di qualità, definizione delle modalità di accesso, delle finalità e dei termini ammessi di utilizzo e, naturalmente, implementazione e deploy delle data pipeline per alimentare le strutture dati che costituiscono il prodotto. Ogni Data Product ha un Data Product Owner, che è la figura responsabile della sua gestione e della sua roadmap di evoluzione.

Un Data Product può produrre le proprie entità dati a partire da entità elementari prodotte da altri Data Product, applicando logiche di integrazione, arricchimento e trasformazioni di rilievo per il dominio di business di afferenza e producendo in output dati derivati, che costituiscono nuova fonte di informazione e che, a loro volta, potranno essere consumati da differenti Data Product presenti nella rete. In questo modo i Data Product formano una rete di architectural quanta pienamente auto-consistenti, ma che garantiscono interoperabilità, per generare ad ogni interazione un contenuto informativo di livello più alto, con una semantica allineata con la terminologia e il modello logico proprio del dominio di riferimento. L’integrazione tra potenzialmente molteplici Data Product differenti per produrre nuovi dati elaborati viene fatta dal Data Product consumatore. In quest’ottica, non si ottiene più un unico modello dati enterprise troppo generico e difficile da evolvere, come accade nel paradigma Data Lakehouse tradizionale, ma il modello dati nel suo complesso è formato da un insieme di sotto-modelli federati specifici di un particolare dominio, eventualmente combinabili.

Affinchè i Data Product possano fornire il valore analitico atteso, devono essere:

• rintracciabili e facilmente accessibili: dovrebbero essere registrati su un portale aziendale che ne permetta la ricerca, l’esplorazione e la sottoscrizione da parte dei sistemi consumatori interessati;
• comprensibili e auto-descrittivi: dovrebbero essere corredati da adeguata documentazione e caratterizzati da una terminologia business-oriented, che esprima chiaramente il significato semantico dei dati che rappresentano;
• affidabili e autentici: dovrebbero indicare service level objectives (SLO) e service level agreements (SLA), metriche di qualità, il riferimento del product / team owner;
• auto-consistenti e componibili: di base, ogni Data Product dovrebbe poter essere utilizzabile in modo indipendente ma anche insieme ad altri data product per generare informazione derivata;
• sicuri: dovrebbero prevedere tecniche di Data Protection sugli attributi sensibili, politiche di concessione dei permessi di accesso basate sul principio di minimo privilegio e ai soli soggetti autorizzati.

Self-serve Data Platform

Dal punto di vista infrastrutturale e tecnologico, affinchè l’integrazione tra i diversi Data Product a responsabilità distribuita sia efficiente e sostenibile, è necessario predisporre una Data Platform condivisa e fruibile in modalità self-serve a livello aziendale, moderna e poliglotta, che metta a disposizione il set di tecnologie e di servizi di utilità fondamentali per implementare la pubblicazione e la messa a disposizione dei Data Product verso i sistemi consumatori nel modo più efficace possibile.

E’ importante sottolineare che un paradigma come il Data Mesh, che prevede una rete di Data Product auto-consistenti e componibili uno con l’altro non deve essere interpretato nè come una spinta a produrre dei data silos nè come la proposta di uno stile di integrazione punto a punto: al contrario, l’integrazione dovrebbe seguire uno stile hub & spoke e pattern scalabili quali, ad esempio, il pattern Publish — Subscribe, secondo cui un dominio di business pubblica i propri Data Product su uno o più componenti di middleware (come ad esempio un data bus o un object store), o li rende accessibili tramite un gateway di Data API: i domini consumatori che intendono utilizzare un Data Product di un altro dominio possono farne richiesta e ottenerne l’accesso tramite un modello a sottoscrizione.

Nell’ottica del Data Mesh, ogni dominio può attingere dati da uno o più Data Product messo a disposizione sulla piattaforma di integrazione condivisa, applicare le proprie logiche funzionali, generare nuovi dati da pubblicare a loro volta sulla piattaforma condivisa sotto forma di nuovi Data Product, come mostrato nella figura seguente.

Per rendere sostenibile la decentralizzazione delle responsabilità e della gestione dei Data Product nei diversi team cross-funzionali dei domini di business, è fondamentale mascherare ai domini la complessità tecnica delle operazioni di Data Management comuni, arricchendo l’infrastruttura con servizi di integrazione intelligenti, capaci di automatizzare i task ripetitivi ed esenti da logiche di dominio specifiche e permettere ai domini di focalizzarsi sullo sviluppo di Data Product di qualità. La piattaforma di integrazione self-serve si pone questo obiettivo, pertanto richiede un team centrale di Platform-Engineers e Data-Ops a cui affidare la responsabilità di ingegnerizzare la piattaforma, arricchire le feature di automazione e i servizi di utilità disponibili, oltre che implementare dei framework per fare enforcing continuo delle policy definite per garantire l’interoperabilità dei Data Product.

A livello organizzativo il cambiamento che ne deriva è significativo: si passa dallo scenario precedente, in cui figure specializzate in data engineering e data warehouse erano riunite in un team centrale responsabile di implementare i flussi di integrazione dati di ambiti di dominio più disparati, senza conoscerne il significato funzionale, con un effort significativo di coordinamento e passaggi di consegna con i team di dominio, ad un nuovo scenario, in cui i team di dominio gestiscono in autonomia il ciclo dei dati end-to-end, avvalendosi del supporto di una piattaforma di integrazione altamente ingegnerizzata da un team di specialisti che si concentrano solamente sugli aspetti tecnici.

Un’altra caratteristica che si osserva sempre di più nel panorama digitale è la convergenza tra processi operazionali e use case analitici, abilitata dalle tecnologie che permettono di integrare servizi ed elaborare dati in real time. L’esempio più evidente in questo senso è dato dai sistemi di real time recommendation personalizzata, che sfruttano l’output di processi analitici a bassa latenza per abilitare azioni che hanno un impatto diretto sull’esperienza utente e, di conseguenza, sull’andamento del core business. Pertanto, la piattaforma di integrazione usata per condividere i Data Product deve supportare questi use case ibridi, a cavallo tra il contesto operazionale e il mondo di Data Management analitico.

Il ruolo della piattaforma self-serve è fondamentale per implementare la parte applicativa del quarto e ultimo pillar di Data Mesh, ovvero la Federated Computational Governance, che descriviamo nella sezione seguente.

Federated Computational Governance

L’ultimo pillar del paradigma Data Mesh pone il focus sul modello di governance che è necessario adottare in uno scenario in cui i team che operativamente gestiscono lo sviluppo e la manutenzione dei Data Product sono molteplici e le responsabilità sono distribuite.

Tradizionalmente si è portati a pensare che l’indipendenza di diversi gruppi di lavoro e la garanzia di rispettare standard e convenzioni comuni siano inversamente proporzionali, pertanto la soluzione a cui spesso si fa ricorso è quella di centralizzare la facoltà di definire le policy, implementare il modello dati e sviluppare le pipeline in un unico team, che applica gli standard condivisi e detiene i permessi per usare gli strumenti tecnologici aziendali, come i tool di integrazione e orchestrazione dati e i data store alla base del data lake e del data warehouse.

Tuttavia, l’obiettivo di democratizzazione e di diffusione dei dati come asset su larga scala a cui mira il paradigma Data Mesh poco si sposa con modelli organizzativi che prevedano soggetti centrali che rallentino il lavoro autonomo delle diverse anime funzionali dell’azienda. D’altra parte, affichè i Data Product non diventino dei silos ma formino realmente una rete di elementi interoperabili e riusabili, alcuni standard sulla definizione e il trattamento dei dati condivisi vanno garantiti, altrimenti si corre il rischio di generare prodotti di bassa qualità e poco affidabili.

Il paradigma Data Mesh propone di adottare un modello di governance computazionale federato, in cui si cerca di formare una community di persone che siano rappresentanti dei diversi team di dominio che sviluppano i Data Product, del team di Platform Engineering che industrializza la piattaforma, del team di Enterprise Architecture che definisce gli stili architetturali raccomandati, uniti a esperti di aree tematiche specifiche (Subject Matter Expert) come la data privacy e la compliance normativa. La community così costituita definisce in modo cooperativo e federato le best practice, i pattern, le guidelines e i guardrail basilari a cui tutti i team di dominio devono attenersi nella realizzazione dei propri Data Product e nell’interazione con la piattaforma di integrazione self-serve condivisa.

Alcuni esempi di standard e convenzioni possono essere:

• l’assegnazione delle ownership sui data product ai team di dominio;
• la gestione degli identificativi delle entità dati core tra diversi sistemi;
• la definizione di policy di evoluzione delle interfacce (data API e schemi degli eventi), regole di compatibilità backward e forward;
• la definizione dei metadati comuni da inserire nei flussi dati per tracciare classificazione dati e lineage;
• i pattern di integrazione da seguire per i diversi casi d’uso;
• i processi per fare richiesta di accesso e sottoscrizione ad un dataset;
• la scelta della mappa tecnologica;
• il periodo di retention consentito e i vincoli per la rappresentazione in chiaro di dati sensibili.

L’implementazione del modello di governance federato fa leva sulle funzionalità avanzate di automazione messe a disposizione dall’infrastruttura self-serve alla base: infatti, mentre la definizione delle regole deve essere fatta dalla community federata di soggetti incaricati appena descritta, l’applicazione dei guardrail e di alcuni tipi di policy, affinché sia robusta, affidabile, sicura e manutenibile, dovrebbe evitare il più possibile attività manuali, che spesso sono soggette a errori, ma essere automatizzata tramite script e utility basate su codice versionabile, portabile e riproducibile.

Punti di contatto tra Data Mesh e Data Fabric

Le caratteristiche proprie della piattaforma di integrazione self-serve prevista dal paradigma Data Mesh e il suo punto di contatto con l’implementazione effettiva della governance computazionale sembrano essere in linea con i pillar basilari di un design Data Fabric (fatta eccezione per il carattere federato del modello di governance Data Mesh): in questo senso, si può comprendere come Data Mesh e Data Fabric non siano due opposti, ma rappresentano due modelli che possono coesistere, come mostrato nella figura seguente.

Infatti il modello di piattaforma Data Fabric può rappresentare una tipologia di implementazione della componente tecnologico-infrastrutturale del Data Mesh, fornendo una piattaforma di integrazione intelligente, che permette di rimuovere dai team che realizzano le data pipeline l’onere di replicare funzionalità comuni a complessità puramente tecnica, invarianti rispetto alle logiche funzionali di un particolare dominio.

Inoltre, la forte ricerca dell’automazione e la propensione all’apprendimento continuo metadata-driven che caratterizza una Data Fabric può essere, in un certo senso, un fattore abilitante per un cambiamento organizzativo in direzione Data Mesh, in particolare verso l’obiettivo di superare una divisione dei team per competenze tecniche specifiche verticali a favore della formazione di team cross-funzionali. Questo diventa possibile in quanto molte delle attività manuali normalmente affidate ad esperti di tecnologia o di aree specifiche del Data Management verrebbero automatizzate o gestite in parte tramite intelligenza artificiale dalle funzionalità della Data Fabric.

L’implementazione completa di un approccio Data Mesh può avvenire come fase successiva rispetto al consolidamento di una Data Fabric, nel momento in cui l’azienda è matura per introdurre un utilizzo della piattaforma di integrazione basato su un modello organizzativo decentralizzato, domain-oriented e controllato con un principio di governance computazionale federata.

Il Data Mesh e il consumo self-service dei dati come prodotti was originally published in Quantyca on Medium, where people are continuing the conversation by highlighting and responding to this story.

Abstract

Questo è il sesto articolo di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.

Per chi non li avesse letti, consiglio di leggere gli articoli precedenti della serie, dai titoli:

• “I principi di un moderno Data Management”: descrive le sfide dell’IT nella nuova era di digitalizzazione e i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati
• “L’approccio data-centrico che cambia l’IT”: descrive i principi e i vantaggi di un orientamento di progettazione delle architetture IT che considera i dati come asset centrale e riusabile e le applicazioni come elementi effimeri che producono o consumano dati di interesse per l’intera azienda
• “L’esigenza di governo nella gestione dei dati”: descrive i principali aspetti di governance da considerare per abilitare architetture IT data centriche e distribuite e mantenere il controllo dei dati a riposo e in movimento
• “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un modello emergente di progettazione delle piattaforme dati basato sull’uso avanzato dei metadati per rendere la piattaforma più automatizzata, self-service e versatile alle diverse esigenze degli utilizzatori
• “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: descrive i principi basilari del modello di progettazione software Domain Driven Design, che ha introdotto l’idea della decentralizzazione delle responsabilità e ha avuto grande influenza sul Data Management

Negli articoli successivi chiuderemo la discussione sui pillar del Data Mesh e trarremo le conclusioni su quella che può essere una strategia di Data Management in linea con le esigenze delle organizzazioni moderne.

I prossimi due articoli saranno:

• “Il Data Mesh e il principio di consumo self-service dei dati come prodotti”: descrive la visione dei dati come prodotti, che formano una rete di domain-oriented Data Product e sono fruiti tramite una piattaforma self-service e un modello di governance federato;
• “La Data Strategy come motore dell’IT”: chiude la serie con un riassunto dei principi architetturali che riteniamo basilari per una strategia di Data Management efficace e una visione del ruolo dell’Enterprise Architect nel delineare l’evoluzione delle architetture dati

Data Mesh: un radicale cambio di paradigma verso la democratizzazione dei dati

Nell’ambito dello sviluppo e dell’integrazione di applicazioni i principi del Domain Driven Design si sono concretizzati nella tendenza ad approcciare i progetti software distribuendo le responsabilità sui diversi Bounded Context a team cross-funzionali, allineati ai domini di business, che gestiscono il ciclo di vita end-to-end dei (micro)servizi di propria competenza: si è affermato pertanto un modello organizzativo decentralizzato e domain-oriented.

Formare dei team cross-funzionali significa prevedere all’interno del team stesso figure con specializzazione funzionale e tecnica differente: sviluppatori (Dev), specialisti di Continuous Integration e Continuous Deployment (Ops), specialisti di amministrazione di database (dbadmin), esperti di web user interface e user experience (UI/UX), esperti di dominio (Business) e subject matter expert (SME) di tematiche specifiche come, ad esempio, la web security.

Al contrario, nell’ambito del Data Management e delle analytics, si è consolidato negli anni un paradigma fortemente centralizzato, sia sotto l’aspetto tecnologico e delle piattaforme, sia sotto l’aspetto organizzativo. Esaminando infatti lo scenario tradizionale di suddivisione delle responsabilità sulle fasi di una data pipeline che abilita casi d’uso di Business Intelligence o Advanced Analytics, si delinea facilmente il quadro mostrato nella figura seguente.

Si nota che la pipeline è composta da tre blocchi principali:

• ad un’estremità della pipeline si collocano le applicazioni sorgenti (data provider) e i relativi team di dominio che le gestiscono, i quali considerano i dati prodotti dalle applicazioni di propria competenza come un by-product, di cui vengono chieste delle estrazioni per esigenze di altri gruppi di lavoro, senza avere visibilità sulle finalità dell’utilizzatore finale e sulle modalità di utilizzo;
• nella parte centrale della pipeline si collocano una serie di team con una forte caratterizzazione tecnica e competenze specifiche su determinate aree di Data Management, che si mappano sulle diverse fasi di ETL / ELT: il team di Data Engineering si occupa dello sviluppo della pipeline, oltre che della definizione e ottimizzazione del modello dati, il team esperto di tecnologie Big Data si occupa dell’organizzazione e l’elaborazione dei dati nel Data Lake, il team di Data Governance definisce centralmente le policy e gli standard di gestione dei dati, il team di Data Security e Data Privacy stabilisce quali tecniche di Data Protection implementare sui dati personali e quali politiche di controllo di accesso prevedere. A questi team nel loro complesso viene chiesto di integrare e consolidare una serie di entità dati di cui non conoscono il significato di business, nè le finalità e le modalità di utilizzo da parte degli utilizzatori finali che ne hanno fatto richiesta;
• all’estremità finale della pipeline si colloca una pletora di team di analisti, esperti di Business Intelligence e Data Science, che chiedono ai team centrali responsabili dell’integrazione la messa a disposizione dei dati, esprimendo ciascuno le sue esigenze in termini di priorità e deadline di delivery: questi team non hanno alcuna visibilità sulla provenienza, sulla qualità e sull’affidabilità dei dati che vengono loro forniti.

A livello architetturale e tecnologico, si è passati dalle prime architetture incentrate sull’Enterprise Data Warehouse, in cui si mirava alla raccolta e l’integrazione di dati consolidati e ben strutturati in un repository centralizzato quale era appunto l’EDW, che avrebbe assolto a tutte le necessità analitiche, all’avvento dei Big Data e alla diffusione dei Data Lake, in cui si pensava di poter superare i limiti del Data Warehouse collezionando nel lake ingenti moli di dati, non obbligatoriamente strutturati, e demandando a query time (schema on read) l’onere di interpretarne correttamente il contenuto ed estrarne le informazioni di interesse. Successivamente sono state proposte le più moderne architetture Data Lakehouse, che cercano di sfruttare i punti di forza di entrambe le famiglie di tecnologie che si erano affermate in precedenza (Data Warehouse, tipicamente basati su data store colonnari, MPP e OLAP da un lato, cloud object store, virtualizzatori, query engine Big Data e framework di calcolo distribuito dall’altro), per fornire una migliore esperienza analitica a supporto di vari use case.

In ogni caso, le evoluzioni tecnologiche che si sono succedute hanno una caratteristica comune, ovvero la presenza di un componente di data storage centralizzato che avrebbe la funzione di rappresentare tutti i dati aziendali in un unico modello enterprise-wide. Si è però osservato che, con l’aumentare del numero e della varietà delle applicazioni data provider e data consumer, ma soprattutto della complessità di dominio, in molti contesti non è più realistico pensare di progettare un unico modello dati aziendale, in quanto non riuscirebbe a rappresentare in modo esaustivo le sfaccettature delle diverse aree del dominio e diventerebbe un punto di accoppiamento forte tra le diverse sorgenti e i diversi target, rendendo poco agile l’evoluzione della base dati.

Zhamak Dehghani, negli articoli How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh e Data Mesh Principles and Logical Architecture, ha proposto un cambio di paradigma radicale per il mondo del Data Management, che ha poi ripreso ed esteso nel libro Data Mesh. Il paradigma, chiamato appunto Data Mesh, si basa su quattro pillar basilari:

• domain ownership
• data as a product
• selve-serve data platform
• federated computational governance

In Quantyca riteniamo che le idee alla base del paradigma Data Mesh siano interessanti e che questo rappresenti una direzione di pensiero architetturale e organizzativo per il mondo del Data Management in linea con le aspettative di un business che intende essere sempre più data-driven. Nella prossima sezione introduciamo il primo pillar, quello della Domain Ownership, lasciando al prossimo articolo la discussione sugli altri.

Domain Ownership

Il paradigma Data Mesh propone di ricondurre la responsabilità end-to-end sui dati analitici al team che gestisce il dominio di business (il Bounded Context, in termini Domain Driven Design) a cui i dati appartengono.

Invece di occuparsi solamente dello sviluppo del software di dominio e delle integrazioni operazionali, lasciando l’onere di estrarre, integrare, consolidare e distribuire i dati ad un team centrale di data engineer non a conoscenza delle logiche di dominio e del significato semantico dei dati, il team che gestisce il Bounded Context e le sue applicazioni dovrebbe prendersi in carico anche la generazione, la condivisione e la manutenzione dei dati analitici di propria competenza. In quest’ottica, i domini di business richiedono di essere gestiti da team cross-funzionali non solo sul piano dei sistemi operazionali, ma anche per il mondo del data management, affiancando allo staff Dev-Ops che gestisce le applicazioni di dominio figure di data engineer, data-ops, data analyst, data scientist ed esperti di data privacy.

Avendo una conoscenza diretta del significato dei dati prodotti dal Bounded Context e ricevendo direttamente le richieste di utilizzo dei dati di propria competenza da parte dei team consumatori (analisti, data scientist, partner esterni, ad esempio), il team responsabile di un dominio di business può condividere i dati core di dominio secondo i principi dei Data On The Outside in modo maggiormente efficace e consumer-oriented.

Un altro obiettivo di questo principio è quello di rimuovere colli di bottiglia nella gestione del ciclo di vita dei dati, rappresentati dai team centrali, aumentando l’autonomia, l’agilità e la velocità di sperimentazione e delivery di servizi data-driven a beneficio del business aziendale.

Il raggiungimento di un modello organizzativo di Data Management completamente decentralizzato può avvenire in modo incrementale, passando per periodi transitori più o meno lunghi in cui l’azienda, in base alle esigenze particolari e ai vincoli del contesto in cui opera, può strutturarsi con modelli ibridi, in base ai quali la decentralizzazione delle responsabilità in ottica domain-oriented viene applicata solo ad alcune tipologie di dati e non ad altre. Una possibile distinzione può essere data dalla gestione dei dati grezzi, intesi come i dati che spesso vengono estratti dai sistemi data provider, non secondo i principi di Data On The Outside consumer-oriented ma secondo un approccio di integrazione tradizionale, dai dati elaborati, intesi come gli eventi di dominio, che sono già passati per le fasi di modellazione semantica, standardizzazione e cleansing, o gli eventi di business arricchiti che sono pronti a supportare le analisi.

La figura seguente rappresenta alcuni esempi di scenari che si possono collocare sulla scala di Data Mesh.

Il quadrante in basso a sinistra nella figura rappresenta lo scenario di completa assenza di Data Mesh, in cui sia l’offloading dei dati dalle sorgenti e l’alimentazione della data platform, così come lo sviluppo dei data mart per le analisi sono gestiti da team centrali, specialisti delle funzioni di data engineering e data analysis.

Il quadrante in basso a destra nella figura rappresenta un modello ibrido verso il Data Mesh, in cui le prime fasi di estrazione dati dalle sorgenti e alimentazione dei livelli bassi della data platform sono ancora in carico ad un team centrale che, ad esempio, racchiude le competenze sulle tecnologie di elaborazione dei big data e sulle tecniche di data offloading da sistemi legacy, mentre le fasi di alimentazione dei modelli dimensionali specifici dei diversi domini è gestito dai team verticali delle singole linee di business, in modo indipendente e federato, ciascuno secondo le particolari esigenze e priorità.

Il quadrante in alto a sinistra rappresenta invece la situazione opposta, in cui i diversi Bounded Context hanno la responsabilità di produrre sulla piattaforma di integrazione dati i Data On The Outside dei rispettivi domini, prevedendo le fasi di cleansing e standardizzazione del formato e della semantica internamente ai Bounded Context, precedentemente alla pubblicazione dei dati sulla piattaforma di integrazione; al contrario, la fase di consolidamento dei dati e la traduzione in un modello analitico enterprise è ancora gestita da un team centrale di esperti di modellazione di data warehouse. Questo modello può essere utile quando si vuole centralizzare la gestione dei dati elaborati per dare garanzie forti di consistenza e integrità dei dati messi a disposizione delle analisi.

Il quadrante in alto a destra rappresenta lo scenario Data Mesh puro, in cui sia i dati grezzi sia i dati elaborati sono gestiti in modo decentralizzato, portando alla formazione di una rete di architectural quanta rappresentati da domain-oriented Data Product, la cui responsabilità è assegnata ai team di dominio.

Nel prossimo articolo tratteremo gli altri tre pillar, rispettivamente Data as a Product, Self-Serve Data Platform e Federated Computational Governance, tracciando anche un confronto con il modello di piattaforma Data Fabric, discusso in uno dei precedenti articoli.

Il Data Mesh e la spinta verso una gestione dati distribuita was originally published in Quantyca on Medium, where people are continuing the conversation by highlighting and responding to this story.

Abstract

Questo è il quinto articolo di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.

Per chi non li avesse letti, consiglio di leggere gli articoli precedenti della serie, dai titoli:

• “I principi di un moderno Data Management”: descrive le sfide dell’IT nella nuova era di digitalizzazione e i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati
• “L’approccio data-centrico che cambia l’IT”: descrive i principi e i vantaggi di un orientamento di progettazione delle architetture IT che considera i dati come asset centrale e riusabile e le applicazioni come elementi effimeri che producono o consumano dati di interesse per l’intera azienda
• “L’esigenza di governo nella gestione dei dati”: descrive i principali aspetti di governance da considerare per abilitare architetture IT data centriche e distribuite e mantenere il controllo dei dati a riposo e in movimento
• “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un modello emergente di progettazione delle piattaforme dati basato sull’uso avanzato dei metadati per rendere la piattaforma più automatizzata, self-service e versatile alle diverse esigenze degli utilizzatori

Negli articoli successivi tratteremo ulteriori aspetti che riteniamo interessanti per costruire piattaforme dati in grado di rispondere alle esigenze pressanti di un business che sta diventando sempre più data-driven.

Questo l’elenco dei prossimi articoli:

• “Il Data Mesh e la spinta verso una gestione dati distribuita”: descrive le ragioni che hanno contribuito alla proposta del paradigma Data Mesh, in favore di una gestione dei dati decentralizzata e domain-oriented per ottenere scalabilità organizzativa
• “Il Data Mesh e il principio di consumo self-service dei dati come prodotti”: descrive la visione dei dati come prodotti, che formano una rete di domain-oriented Data Product e sono fruiti tramite una piattaforma self-service e un modello di governance federato;
• “La Data Strategy come motore dell’IT”: chiude la serie con un riassunto dei principi architetturali che riteniamo basilari per una strategia di Data Management efficace e una visione del ruolo dell’Enterprise Architect nel delineare l’evoluzione delle architetture dati

Il Domain Driven Design e la decentralizzazione delle responsabilità

Nel ventennio scorso, nell’ambito dello sviluppo software, si è affermato un modello di progettazione software chiamato Domain Driven Design (DDD), proposto inizialmente da Eric Evans nel 2003 e esteso successivamente da Vaughn Vernon; in particolare, l’approccio ha visto una nuova ondata di diffusione negli ultimi anni con l’adozione sempre più marcata dello stile architetturale a microservizi. Il modello DDD propone alcuni strumenti di progettazione strategica e altri di progettazione tattica: in questo articolo discuteremo solo il sottoinsieme dei concetti di interesse per le implicazioni sui processi di Data Management.

Il Domain Driven Design si fonda sull’idea che un dominio applicativo complesso difficilmente può essere implementato da un unico modello software, in quanto uno stesso concetto di business può assumere significati e proprietà differenti in base al particolare contesto in cui viene utilizzato.

Per chiarire il concetto, facciamo l’esempio della Transazione di Vendita per un’azienda che opera nel settore della grande distribuzione. La prospettiva di interesse e, di conseguenza, le proprietà rilevanti dell’entità Transazione di Vendita nell’ambito delle analisi commerciali e della valutazione dei fornitori possono essere abbastanza differenti dal significato con cui si usa il medesimo termine nel contesto della segmentazione clienti e dei processi di loyalty, piuttosto che della gestione della logistica dei magazzini o, ancora, dei processi finanziari e contabili.

Nell’esempio illustrato, sarebbe arduo rappresentare le diverse accezioni del concetto di Transazione di Vendita in un’unica classe o gerarchia di classi (ipotizzando che si scelga un paradigma di programmazione ad oggetti): uno sforzo in tale direzione produrrebbe un’entità dal significato sfumato e ambiguo, che non soddisferebbe le esigenze specifiche dei vari contesti di dominio e rischierebbe di dar vita ad un modello software complesso, ad alto accoppiamento e senza nessun confine logico tra le sue sottoparti.

Un modello simile ha spesso conseguenze negative sulla manutenibilità e sull’agilità di evoluzione dell’applicazione: diversi team presumibilmente andrebbero a lavorare sullo stesso progetto software, gli impatti di una modifica creerebbero, con buona probabilità, effetti a cascata su diverse parti del modello di difficile governo. Questi comporterebbero interdipendenze e necessità di coordinamento tra team di lavoro che avrebbero l’effetto di rallentare la delivery delle funzionalità richieste dal business e aumentare i costi del progetto.

Il Domain Driven Design propone di andare in direzione opposta: il dominio applicativo complessivo viene scomposto in diversi Bounded Context, il cui confine logico è definito in modo esplicito, all’interno di ciascuno dei quali il significato di un’entità del modello è inequivocabile e univoco, specifico del particolare contesto. L’insieme dei termini per cui vale un determinato significato semantico all’interno di un Bounded Context è detto Ubiquitous Language, in quanto è business-oriented e si permea sia nel linguaggio comune del team che gestisce il Bounded Context, sia nel codice applicativo, nel modello concettuale, logico e fisico del software e dei dati alla base, nel nome degli eventi, delle API e in tutti gli aspetti implementativi.

Tornando all’esempio considerato in precedenza, in ciascun Bounded Context di interesse verrà definita un’entità Transazione di Vendita, indipendente e disaccoppiata dalla medesima entità negli altri Bounded Context: nel contesto dei processi commerciali verranno potenzialmente rappresentati gli attributi della transazione di rilievo per analizzare e gestire i fornitori, nel contesto della gestione loyalty e segmentazione clienti si modelleranno gli attributi che permettono di ricollegare la transazione ad uno specifico cliente e al suo comportamento di acquisto. Nel contesto della logistica saranno invece definiti gli attributi necessari per gestire l’inventario, i rifornimenti, i movimenti di merce; infine, nel contesto finanziario / contabile si porrà il focus sugli attributi relativi ai fattori di cambio, alla percentuale di tassazione, al valore a costo dei prodotti venduti.

In ciascun contesto il significato semantico del linguaggio è protetto dalle perturbazioni esterne e, ogni qual volta è necessaria un’interazione (e di conseguenza uno scambio di informazioni) tra diversi Bounded Context, deve essere prevista una trasformazione di contesto, detta Context Mapping, per permettere di adattare il significato delle entità condivise proprio del contesto sorgente nel linguaggio adatto per l’utilizzo da parte del contesto ricevente. Esistono diverse forme di Context Mapping, da quelle a più alto accoppiamento, ad esempio il mapping di tipo Shared Kernel, in cui due Bounded Context condividono un sottoinsieme del modello software e si coordinano per evolverlo, a quelle a più basso accoppiamento. Un esempio comune è il mapping che prevede un Anti Corruption Layer: all’ingresso del Bounded Context ricevente viene sviluppato un livello software per tradurre il linguaggio straniero e potenzialmente contaminante del Bounded Context sorgente nel modello software autentico e puro del contesto ricevente: questo è particolarmente utile negli scenari in cui il contesto sorgente è un sistema legacy con un modello Big Ball Of Mud e il contesto ricevente è un microservizio moderno.

Il Domain Driven Design si basa pertanto su una strategia Divide Et Impera, per permettere di scomporre lo spazio problema (il dominio) in componenti più piccole (dette Sottodomini): la soluzione verrà implementata per mezzo di diversi Bounded Context, ciascuno dei quali possiede un perimetro semantico e un linguaggio caratterizzante e unico, l’Ubiquitous Language.

I vantaggi di un simile approccio sono molteplici: in primo luogo è possibile assegnare un singolo Bounded Context ad un team specifico e i diversi team hanno la possibilità di evolvere e controllare il software e il modello dati del Bounded Context in modo autonomo, secondo il proprio passo di delivery, minimizzando l’interdipendenza con altri team e la necessità di coordinamento; in secondo luogo, la complessità di dominio dei singoli Bounded Context rimane entro limiti gestibili, evitando di creare software troppo estesi e con dipendenze intrinseche che ne rendono difficile l’evoluzione. Infine, il significato degli elementi del modello e dei concetti semantici dentro il perimetro del Bounded Context rimane puro, autentico e specifico del contesto, evitando di creare ambiguità o eccessive generalizzazioni finalizzate a rappresentare sfaccettature diverse, che spesso sono causa di inconsistenze.

Sotto l’aspetto delle integrazioni di dati e servizi, il Domain Driven Design ha delle implicazioni rilevanti: infatti, mentre all’interno del perimetro di un Bounded Context è ammissibile che le applicazioni (ad esempio i microservizi) comunichino in modo diretto, tramite chiamate API sincrone o condivisione di database, in quanto le applicazioni ricadono sotto la ownership di un unico team, è fortemente raccomandato che le integrazioni tra Bounded Context differenti siano il più possibile a basso accoppiamento, comunicando tramite interfacce stabili e che astraggano la complessità i dettagli implementativi privati del Bounded Context. Solitamente, per la comunicazione inter Bounded Context si usa lo stile event-driven, basato su pubblicazione e sottoscrizione di comandi ed eventi di dominio tramite broker di messaggi (data bus).

Con l’affermazione dello stile architetturale a microservizi per lo sviluppo di applicazioni moderne e scalabili, è diventato possibile applicare in modo più efficace il Domain Driven Design rispetto che in precedenza: l’intero progetto software è implementato da diverse unità di deploy, i microservizi, detti architectural quanta, ciascuno dei quali afferisce ad un determinato Bounded Context ed è gestito in modo autonomo dal team owner del Bounded Context. Accettando di scomporre un’unica applicazione logica in diverse unità di deploy fisiche si rende ancora più forte l’indipendenza dei Bounded Context, in quanto questa si concretizza in una scelta indipendente degli stack tecnologici con cui implementare i servizi e in una segregazione fisica degli ambienti, della base di codice e degli strumenti di lavoro.

L’orientamento Domain Driven Design non solo ha prodotto risultati immediati nel mondo dello sviluppo software, ma ha anche generato un’influenza significativa negli studi innovativi sulle tecniche di Data Management: si è iniziato a comprendere che la decentralizzazione delle responsabilità sui dati e l’organizzazione domain-oriented potesse dare benefici anche nella gestione di tutte le fasi del ciclo di vita del dato, dall’offloading dalle sorgenti, passando per le fasi di integrazione e trasformazione, fino all’utilizzo da parte delle applicazioni analitiche. Il risultato è stata la proposta di un nuovo paradigma per la gestione dei dati, chiamato Data Mesh, che discuteremo nei prossimi articoli.

Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione was originally published in Quantyca on Medium, where people are continuing the conversation by highlighting and responding to this story.

Abstract

Questo è il quarto articolo di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.

Per chi non li avesse letti, consiglio di leggere gli articoli precedenti della serie, dai titoli:

• “I principi di un moderno Data Management”: descrive le sfide dell’IT nella nuova era di digitalizzazione e i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati
• “L’approccio data-centrico che cambia l’IT”: descrive i principi e i vantaggi di un orientamento di progettazione delle architetture IT che considera i dati come asset centrale e riusabile e le applicazioni come elementi effimeri che producono o consumano dati di interesse per l’intera azienda
• “L’esigenza di governo nella gestione dei dati”: descrive i principali aspetti di governance da considerare per abilitare architetture IT data centriche e distribuite e mantenere il controllo dei dati a riposo e in movimento

Negli articoli successivi tratteremo diversi aspetti che riteniamo interessanti per costruire piattaforme dati in grado di rispondere alle esigenze pressanti di un business che sta diventando sempre più data-driven.

Questo l’elenco dei prossimi articoli:

• “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: riporta i punti fondamentali del modello di sviluppo software Domain Driven Design, che ha influenzato la proposta di nuovi modelli organizzativi anche per il Data Management
• “Il Data Mesh e la spinta verso una gestione dati distribuita”: descrive le ragioni che hanno contribuito alla proposta del paradigma Data Mesh, in favore di una gestione dei dati decentralizzata e domain-oriented per ottenere scalabilità organizzativa
• “Il Data Mesh e il principio di consumo self-service dei dati come prodotti”: descrive la visione dei dati come prodotti, che formano una rete di domain-oriented Data Product e sono fruiti tramite una piattaforma self-service e un modello di governance federato;
• “La Data Strategy come motore dell’IT”: chiude la serie con un riassunto dei principi architetturali che riteniamo basilari per una strategia di Data Management efficace e una visione del ruolo dell’Enterprise Architect nel delineare l’evoluzione delle architetture dati

Verso un‘architettura metadata-driven: il modello Data Fabric

Le tipologie di metadati collezionate nei processi di Data Governance costituiscono una base importante di conoscenza sul landscape dei dati aziendali, finalizzata al controllo e alla sostenibilità di un’architettura distribuita. Si tratta tuttavia di metadati che possiamo definire passivi: sono informazioni raccolte e aggiornate periodicamente, alcune in modalità manuale e altre in modalità automatica, che però si limitano a descrivere e fornire insight sullo stato dell’arte dei data asset.

Gartner presenta il concetto di Data Fabric come un modello di design delle piattaforme di data management che si fonda sull’utilizzo intelligente di una base ricca di metadati per supportare la realizzazione di servizi di integrazione e di delivery dei dati automatizzati e dinamici. L’obiettivo auspicato è quello di ridurre i task manuali di data integration e data preparation, in particolare le attività a basso valore aggiunto, e di migliorare la flessibilità, l’efficacia e la rapidità di adeguamento delle pipeline dati al variare delle condizioni esterne.

L’implementazione di una Data Fabric non è basata obbligatoriamente su un unico prodotto, al contrario solitamente è costituita da un insieme di tecnologie che collaborano tra di loro per mettere a disposizione le funzionalità peculiari del modello.

In aggiunta ai metadati statici descritti nella sezione relativa alla Data Governance, il modello Data Fabric si pone l’obiettivo di collezionare una serie di metadati, dinamici per natura, da ciascun sistema facente parte dell’architettura aziendale: alcuni esempi possono essere statistiche operazionali e di runtime dei flussi dati (metadati di performance e durata dei job, frequenza di accesso ai dataset per utente, distribuzione giornaliera degli accessi per fascia oraria, utilizzo medio risorse…) e metadati social generati dagli utenti tramite funzionalità di collaborazione (commenti, note, assegnazione di task, metadati di interazione con partner…). Sfruttando la rappresentazione integrata della base di metadati messa a disposizione dal knowledge graph, la Data Fabric permette di “attivare” i metadati, rendendo possibili delle analisi su di essi e la generazione dinamica di KPI.

I KPI così ottenuti possono essere forniti come parametri in input ad algoritmi di AI/ML che consentono al motore decisionale della Data Fabric di fare previsioni ed attuare azioni intelligenti e automatiche per adeguare e ottimizzare i processi di integrazione e distribuzione dei dati in base alle variabili del contesto. Ad esempio, gli algoritmi possono stimare il sizing di risorse ottimale e valutare il tipo di infrastruttura più adatto per un determinato flusso di replicazione dati tra due sistemi in modo dinamico, basandosi sui feedback derivati dalle analisi in tempo reale sui metadati di volumi e utilizzo delle risorse raccolti: di conseguenza, la Data Fabric può azionare in automatico delle procedure di provisioning e configuration management che vanno ad effettuare il deploy di un’infrastruttura con il nuovo setup desiderato.

Inoltre la Data Fabric, tramite le insight messe a disposizione dal knowledge graph, intende abilitare la creazione di modelli dati flessibili, facilmente integrabili con valore semantico da parte del team business ed esposti ad un livello di astrazione dagli dettagli tecnici che permette un consumo self-service.

Il concetto di Data Fabric prevede di avere alla base dei processi di integrazione e delivery intelligente dei dati un‘infrastruttura costituita da tecnologie moderne, poliglotta ed eventualmente distribuita su diversi ambienti, in cloud e on-premises o in una configurazione ibrida, che supporti molteplici modalità di consegna dei dati, per adattarsi in modo flessibile alle esigenze di consumo dei vari casi d’uso. La piattaforma di una Data Fabric può essere dotata di componenti per supportare flussi ETL/ELT standard, integrazione tramite API, stream processing e distribuzione dati in real time, elaborazioni big data e accessi al dato di vario tipo. L’intelligenza di cui è dotata, derivata dalle funzionalità di AI/ML, può consentire anche di adattare in automatico la scelta dello stile di integrazione: ad esempio, si può pensare che, in caso di arrivo in ingresso di grosse moli di dati storici, la piattaforma metta in opera on-demand un’integrazione via flussi batch o export di file su un object store, mentre, in risposta alla produzione in ingresso di uno stream di eventi a bassa latenza da parte delle sorgenti, avvii un flusso di consegna dati in real-time ai sistemi consumatori.

La piattaforma della Data Fabric favorisce un approccio data & metadata centrico al design dell’architettura: il modello prevede infatti la presenza di uno o più sistemi di storage in grado di salvare in modo durevole un qualsiasi volume di dati, in formati diversi e tali da consentire ai consumatori di usare il pattern di accesso più adatto alle proprie esigenze. Un’architettura che ha alla base una piattaforma Data Fabric consente di ridurre i costi di integrazione, razionalizzando l’effort di offloading dei dati dalle sorgenti e abilitando il riuso dei data asset core aziendali per molteplici finalità, sia di tipo operazionale sia di tipo analitico. Infatti, il modello Data Fabric va nella direzione di una piattaforma di integrazione ibrida e convergente, adatta a supportare sia l’integrazione real-time di applicazioni per rispondere ai processi digitali core dell’azienda, sia tutte le fasi che compongono il ciclo di vita del dato per abilitare servizi avanzati data-driven.

La piattaforma mette a disposizione anche le componenti tecnologiche per offrire funzionalità avanzate di orchestrazione dei vari step delle pipeline dati, dando la possibilità di implementare e schedulare workflow complessi a piacere.

Il modello Data Fabric rappresenta una direzione da percorrere, ma può essere implementato con un approccio graduale, realizzando inizialmente alcuni servizi di base che arricchiscono le funzionalità della piattaforma e semplificano le attività di sviluppo dei data engineer, garantendo economia di velocità, per poi aggiungere in un secondo momento le feature avanzate che si basano sul machine learning e sullo sfruttamento attivo dei metadati. Alcuni esempi di funzionalità di base che possono essere di grande beneficio sono:

• il deploy semplificato di flussi di replicazione dati da una sorgente al layer di storage offerto dalla piattaforma di integrazione;
• il deploy di un’applicazione che effettua la traduzione di formato e di schema dati tra un tracciato sorgente e un tracciato standardizzato, arricchito di metadati, adatto per pubblicare i dati nella piattaforma;
• l’implementazione di procedure automatizzate e parametriche di svecchiamento dei dati storici;
• la generazione automatica di certificati SSL e l’assegnazione di permessi di accesso per soggetti autorizzati all’accesso ai dati;
• provisioning automatico di dataset di test;
• applicazione automatica delle tecniche di anonimizzazione o pseudo-anonimizzazione dei campi sensibili.

Per riassumere, le funzionalità di una Data Fabric vanno ad estendere e potenziare le feature base delle tecnologie che compongono l‘infrastruttura di integrazione, offrendo servizi intelligenti di piattaforma, ad un livello di astrazione superiore, per automatizzare buona parte dell’effort di integrazione, elaborazione e orchestrazione delle pipeline dati, in direzione di un‘architettura metadata-driven: è un modello che si prevede raccolga sempre maggior interesse nei prossimi anni. In quest’ottica, figure professionali come il DataOps e il Platform Engineer sono in via di espansione.

Il modello Data Fabric consente di ottenere scalabilità ed efficienza a livello tecnologico e di piattaforma: per raggiungere questi obiettivi anche a livello organizzativo e di gestione è interessante considerare gli approcci Domain Driven Design e Data Mesh, che tratteremo nei prossimi tre articoli.

L’adattabilità della piattaforma di integrazione in un modello Data Fabric was originally published in Quantyca on Medium, where people are continuing the conversation by highlighting and responding to this story.

Abstract

Questo è il terzo articolo di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.

Per chi non li avesse letti, consiglio di leggere gli articoli precedenti della serie, dai titoli:

• “I principi di un moderno Data Management”: descrive le sfide dell’IT nella nuova era di digitalizzazione e i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati
• “L’approccio data-centrico che cambia l’IT”: descrive i principi e i vantaggi di un orientamento di progettazione delle architetture IT che considera i dati come asset centrale e riusabile e le applicazioni come elementi effimeri che producono o consumano dati di interesse per l’intera azienda

Negli articoli successivi tratteremo diversi aspetti che riteniamo interessanti per costruire piattaforme dati in grado di rispondere alle esigenze pressanti di un business che sta diventando sempre più data-driven.

Questo l’elenco dei prossimi articoli:

• “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un nuovo modello di piattaforma architetturale intelligente e automatizzata
• “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: riporta i punti fondamentali del modello di sviluppo software Domain Driven Design, che ha influenzato la proposta di nuovi modelli organizzativi anche per il Data Management
• “Il Data Mesh e la spinta verso una gestione dati distribuita”: descrive le ragioni che hanno contribuito alla proposta del paradigma Data Mesh, in favore di una gestione dei dati decentralizzata e domain-oriented per ottenere scalabilità organizzativa
• “Il Data Mesh e il principio di consumo self-service dei dati come prodotti”: descrive la visione dei dati come prodotti, che formano una rete di domain-oriented Data Product e sono fruiti tramite una piattaforma self-service e un modello di governance federato;
• “La Data Strategy come motore dell’IT”: chiude la serie con un riassunto dei principi architetturali che riteniamo basilari per una strategia di Data Management efficace e una visione del ruolo dell’Enterprise Architect nel delineare l’evoluzione delle architetture dati

La Data Governance come strumento di controllo e insight sull’architettura IT

Considerare i dati come asset e metterli in condivisione a livello di intera organizzazione implica la necessità di mantenere il controllo del ciclo di vita di questi ultimi: tanto più l’architettura è distribuita e l’organizzazione aziendale è complessa, tanto più è marcata l’esigenza di governo dei dati.

Infatti, mentre l’utilizzo dei Data On The Inside si esaurisce all’interno dell’applicazione che li gestisce, l’esposizione nel data layer dell’architettura aziendale dei Data On The Outside presuppone che attori diversi potenzialmente interagiscano con i dati esposti, siano essi altre applicazioni, team verticali di differenti linee di business, gruppi di analisti e data scientist, società partner o altri: il data layer è normalmente un elemento architetturale condiviso e multi-tenant.

Inoltre è altamente probabile che le esigenze di integrazione e le caratteristiche dell’architettura comportino la replicazione di uno stesso dataset in diverse copie, distribuite su diversi sistemi, infrastrutture, componenti tecnologiche; spesso le data pipeline che implementano i flussi dati prevedono il coinvolgimento di più job, ciascuno dei quali opera un particolare step di trasformazione sul dataset.

Uno scenario architetturale del genere richiede pertanto di raccogliere una base ricca ed organica di metadati che permettano di mantenere il governo su diversi aspetti della gestione dei data asset; alcuni esempi di tipologie di metadati che è consigliabile raccogliere sono descritti nelle sezioni seguenti.

Business Glossary, Data Catalog e Data Classification

L’attività di modellazione semantica dei data asset dà l’opportunità di definire un glossario, detto Business Glossary, in cui censire le entità di business di interesse aziendale e gli attributi elementari che le costituiscono: si tratta di concetti logici, inquadrati nel modello concettuale del business e agnostici rispetto ai dettagli tecnici e alla rappresentazione fisica che viene invece implementata sui sistemi.

Per fare un esempio, consideriamo questa volta il dominio del Retail, in cui il concetto di Transazione di vendita è uno degli elementi chiave del modello di business. Nel glossario semantico sarà definita un’entità per la transazione di vendita, che riporterà una descrizione espressa nel linguaggio dei termini comunemente usato dal team business, eventuali sinonimi utilizzati per riferirsi allo stesso concetto (aliases), eventuali etichette (tag) utili per arricchire la classificazione semantica dell’entità e altri metadati di interesse.

Inoltre, nel glossario si andranno a definire gli attributi specifici associati all’entità, indicando per ciascuno di essi il tipo logico (booleano, numerico, stringa…), eventuali vincoli che il valore assunto deve osservare (esempio: valore non negativo), l’espressione di calcolo qualora l’attributo fosse una metrica complessa, così come eventuali pattern che il valore deve rispettare (esempio: un numero fisso di caratteri). Per una Transazione di vendita, alcuni attributi comunemente definiti sono la data della transazione, il punto vendita di interesse, il cliente acquirente, l’eventuale tessera fedeltà usata, l’importo pagato, l’importo degli sconti applicati.

I data asset vengono poi rappresentati a livello fisico in più copie sotto forma di tabelle o strutture dati di altro tipo all’interno dei sistemi che compongono l’architettura IT aziendale: dal momento che i sistemi coinvolti sono molteplici e basati su tecnologie differenti, è consigliabile estrarre da essi i metadati relativi agli schemi, alle strutture dati, ai campi specifici, ai vincoli fisici e raccoglierli in un catalogo centralizzato, detto Data Catalog. Il catalogo può essere arricchito riportando anche le informazioni sugli utenti che hanno accesso ai sistemi o a determinate strutture dati.

Per garantire un pieno controllo dei dati gestiti e condivisi nell’architettura è utile effettuare una mappatura tra i concetti di business definiti nel glossario semantico e le corrispondenti rappresentazioni fisiche nelle strutture dati, registrate nel catalogo dati: una simile mappatura costituisce il processo di Data Classification e può essere effettuata in modalità semiautomatica tramite un motore di valutazione di regole di classificazione e una successiva integrazione manuale.

Considerando il numero potenziale di repliche di uno stesso data asset tra i vari sistemi o su più strutture dati all’interno di uno stesso sistema, la mappatura tra il mondo concettuale e il mondo fisico permette di mantenere una tracciabilità dei punti di utilizzo dei dati e di facilitare la scoperta, l’esplorazione e l’accesso in modalità self-service ai data asset di valore aziendale. Inoltre, saper identificare tempestivamente tutte le strutture dati in cui è rappresentato un certo tipo di informazione, come ad esempio i Personally Identifiable Information (PII) dei clienti, consente di rispondere agilmente a esigenze di compliance dettate dalle normative legate alla Data Privacy, come eventuali requisiti di anonimizzazione o cancellazione su finestre temporali più vecchie di un certo numero di mesi.

Data Lineage

I metadati raccolti nel glossario dei concetti semantici, nel catalogo delle strutture dati e la mappatura tra il mondo fisico e il mondo logico forniscono una conoscenza sulla situazione dei dati at rest. Tuttavia, per rendere effettivamente accessibili i data asset ai vari consumatori vengono implementati diversi tipi di processi che hanno a che fare con i dati in motion, sia che si tratti di data pipeline che operano ETL/ELT in modalità batch, sia che si tratti di flussi in real time di stream processing, di integrazione tramite API piuttosto che di accesso tramite layer di virtualizzazione.

Pertanto, la raccolta di metadati utili a fornire insight per il governo dei dati dovrebbe coprire anche l’aspetto del Data Lineage, per permettere di tracciare il percorso end-to-end di un dataset, dal data provider, passando per i vari step di integrazione e trasformazione nel data layer, fino ai diversi data consumer, censendo tutte le applicazioni che sono coinvolte nella pipeline del flusso.

Il percorso tracciato può essere poi analizzato nel verso che va dalle sorgenti alle destinazioni (forward lineage) o in verso opposto (backward lineage). Il tracciamento del lineage dei dati è fondamentale per effettuare con efficacia delle analisi di impatto del cambiamento, nel momento in cui è necessario introdurre delle modifiche agli schemi e alle interfacce dei Data On The Outside, che necessitano di identificare tutte le componenti applicative eventualmente impattate da monitorare ed eventualmente modificare.

Per favorire la raccolta di metadati utili ai fini del lineage, può essere conveniente introdurre nello schema dei dati elaborati dalla pipeline alcuni campi tecnici come, per esempio, il timestamp di elaborazione di ogni step di trasformazione, o arricchire il singolo record con un identificativo univoco che permetta poi di fare delle analisi di correlazione tra più copie dello stesso record in diversi sistemi.

Data Quality

Un altro aspetto da non sottovalutare riguarda la qualità dei Data On The Outside che vengono pubblicati nel data layer e distribuiti ai diversi consumatori. Un dato fornisce valore nel momento in cui è consistente, coerente con il contesto semantico di appartenenza, integro e aggiornato di frequente. Al contrario, data set di scarsa qualità possono essere origine di impatti negativi sul business, come ad esempio previsioni di vendita errate, performance di raccomandazione e personalizzazione dell’esperienza utente modeste o, nel caso di consumatori operazionali, azioni errate che possono portare a perdite di revenue o di reputazione per l’azienda. Si pensi alle conseguenze di un calcolo errato dello stock dei prodotti per un business di e-commerce: i clienti rischierebbero di vedere i propri ordini cancellati per mancanza effettiva della merce in magazzino e questa situazione sgradevole potrebbe portare a perdere clienti a favore dei competitor.

Pertanto, all’interno dei processi di Data Governance è auspicabile definire dei controlli di Data Quality da effettuare in modo periodico e automatico sui dataset, sulla base dei quali prevedere delle azioni di alert o di rimedio automatico in caso di situazioni problematiche.

Esempi di controlli di qualità che è utile implementare sono i seguenti:

• controlli di integrità referenziale tra fatti e dimensioni di un data warehouse;
• controlli di quadratura tra una metrica calcolata e i dati di riferimento generati dalla sorgente;
• controlli sulla frequenza di ricezione degli aggiornamenti dei dati dalla sorgente;
• controlli di completezza di un master / reference data set;
• controlli di compliance di un attributo rispetto agli invarianti di calcolo, ai vincoli e ai pattern definiti a livello semantico nel glossario di business ( correttezza valori numerici, controllo su valori ammessi di campi categorici…).

Eseguire periodicamente i controlli di qualità permette di conservare i risultati in un database, abilitando la possibilità di effettuare analisi storiche tramite dashboard e di identificare trend positivi o negativi sulla qualità dei data asset condivisi, correlandoli con eventuali attività evolutive operate sulle pipeline dati.

Altri metadati

Un’area molto specifica è quella della Data Compliance e riguarda alcuni aspetti come il censimento del registro dei trattamenti sui dati, la definizione dei data subject e la notarizzazione dei consensi degli interessati all’utilizzo dei dati personali, che per alcune tipologie di dati sono richieste dalle normative sulla Data Privacy.

Inoltre, per ogni dataset pubblicato nel data layer, è utile tracciare informazioni riguardo la ownership del data asset, in termini di team o sotto-dominio di appartenenza e di applicazione provider, nonchè documentare all’interno di un data sharing agreement, per ciascun sistema consumatore che chiede la sottoscrizione al data set, le finalità specifiche e i vincoli con cui i dati vengono condivisi.

Knowledge graph

Per massimizzare la conoscenza estraibile dai metadati raccolti, è possibile organizzarli e tracciare le relazioni tra di essi in una rappresentazione a grafo, detta knowledge graph, che permette una navigazione a 360° e una visualizzazione efficace di tutti gli aspetti di gestione dei data asset. Questo è uno dei driver più rilevanti a favore dell’adozione a livello aziendale di un tool centralizzato di Data Governance in cui salvare in modo integrato i metadati raccolti e supportarne facilmente la consultazione e l’aggiornamento.

Blindata è una società che produce un’applicazione SaaS di Data Governance e Data Compliance. Un esempio della tipologia di visualizzazione dei metadati che si può ottenere sfruttando il knowledge graph è illustrato nella figura seguente (in cui viene mostrata la prospettiva del Data Lineage).

I metadati abilitano il modello Data Fabric

La possibilità di centralizzare in un unico strumento una base ricca e organica di metadati è il primo passo verso la creazione di un modello di piattaforma di integrazione intelligente, che mira ad una forte spinta verso l’automazione, detto Data Fabric, che discuteremo in dettaglio nel prossimo articolo.

L’esigenza di governo nella gestione dei dati was originally published in Quantyca on Medium, where people are continuing the conversation by highlighting and responding to this story.

Abstract

Questo è il secondo articolo di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.

Per chi non lo avesse letto, consiglio di leggere l’articolo introduttivo della serie, dal titolo “I principi di un moderno Data Management”, in cui abbiamo descritto i driver che spingono verso la ricerca di un cambio di paradigma nella progettazione delle architetture dati.

Negli articoli successivi tratteremo diversi aspetti che riteniamo interessanti per costruire piattaforme dati in grado di rispondere alle esigenze pressanti di un business che sta diventando sempre più data-driven.

Questo l’elenco dei prossimi articoli:

• “L’esigenza di governo nella gestione dei dati”: discute la necessità di costruire un framework di governance metadata-driven per mantenere il controllo della distribuzione dei dati nell’architettura enterprise
• “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un nuovo modello di piattaforma architetturale intelligente e automatizzata
• “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: riporta i punti fondamentali del modello di sviluppo software Domain Driven Design, che ha influenzato la proposta di nuovi modelli organizzativi anche per il Data Management
• “Il Data Mesh e la spinta verso una gestione dati distribuita”: descrive le ragioni che hanno contribuito alla proposta del paradigma Data Mesh, in favore di una gestione dei dati decentralizzata e domain-oriented per ottenere scalabilità organizzativa
• “Il Data Mesh e il principio di consumo self-service dei dati come prodotti”: descrive la visione dei dati come prodotti, che formano una rete di domain-oriented Data Product e sono fruiti tramite una piattaforma self-service e un modello di governance federato;
• “La Data Strategy come motore dell’IT”: chiude la serie con un riassunto dei principi architetturali che riteniamo basilari per una strategia di Data Management efficace e una visione del ruolo dell’Enterprise Architect nel delineare l’evoluzione delle architetture dati

La spinta verso un nuovo paradigma data-centrico

Nell’articolo precedente, “I principi di un moderno Data Management”, abbiamo descritto le sfide che l’IT si trova di fronte nella nuova era di digitalizzazione, caratterizzata da una produzione e un consumo di dati di volumi, varietà e finalità di utilizzo di gran lunga superiori al passato, oltre che dalla presenza, all’interno delle architetture enterprise, di un numero molto più rilevante di applicativi che devono cooperare. La necessità di razionalizzare e ottimizzare le integrazioni e di riutilizzare gli stessi dati per processi e finalità differenti impone un cambio di prospettiva, per garantire all’IT di spendere al meglio il budget a disposizione e rilasciare le funzionalità digitali data-driven nei tempi rapidi richiesti da un contesto di business sempre più competitivo e incerto, in cui la possibilità di sperimentare diventa un potenziale fattore importante di profitto.

Il cambio di prospettiva non può che partire dal riconoscere che il vero valore digitale di un’organizzazione è costituito dai dati che l’azienda produce, utilizza ed elabora. Le applicazioni, nell’implementare le funzionalità di business, sono certamente importanti ma, in un certo senso, anche effimere e sostituibili. I dati persistono al di là del ciclo di vita dei sistemi stessi e possono essere riutilizzati per molteplici scopi: sono a tutti gli effetti gli asset digitali aziendali. Come vale per tutti gli altri tipi di asset delle aziende tradizionali, i dati, per essere sfruttati al meglio, dovrebbero essere controllati, resi accessibili facilmente e in sicurezza e condivisi a livello di intera organizzazione, per abilitare processi diversi da quelli all’interno dei quali sono stati generati.

Il design di un’architettura IT aziendale deve partire dall’identificare quali sono i data asset di rilevo per l’azienda, mediante un’analisi approfondita del dominio di business, dei concetti e dei processi core e una conseguente modellazione semantica dei dati, con uno sforzo congiunto tra il personale del team business e lo staff IT. La scelta dei prodotti che implementano le applicazioni aziendali dovrebbe essere coerente con la strategia di gestione dei dati che si intende perseguire.

Un data asset core rappresenta, dal punto di vista logico e fisico, un concetto informativo di primaria importanza per il business dell’azienda. Ogni data asset è generato da parte di un’applicazione, che nel libro “Data Management At Scale” è detta golden source (o, alternativamente, data provider) del dato stesso. In quanto tale, l’applicazione è responsabile di produrre e condividere i dati, assicurarne la comprensibilità, la qualità e la consistenza, ma non ne è proprietaria esclusiva: i dati sono un bene condiviso, un asset aziendale, pertanto l’applicazione deve entrare in una prospettiva di cooperazione per favorirne l’accesso, l’utilizzo, l’integrazione e la distribuzione ad altre applicazioni nel modo più efficiente ed efficace.

In termini concreti, questo significa che l’applicazione deve fornire delle interfacce (chiamate anche data endpoint) facilmente accessibili, sicure e auto descrittive per permettere di estrarre i dati in un formato aperto secondo gli standard più comunemente usati nelle tecniche di data management moderne: infatti, i data asset non devono rimanere confinati all’interno delle applicazioni, come by product, ma devono essere fisicamente portati al centro dell’architettura, devono risiedere nel data layer. Inoltre, le applicazioni di dominio (system of records) non dovrebbero ricoprire il ruolo di hub di elaborazione, trasferimento o distribuzione di dati ad altri sistemi: queste non sono le attività per cui tali applicazioni sono ottimizzate e rischiano di degradarne le performance per le finalità operazionali critiche per il business, che sono invece i compiti primari che le applicazioni dovrebbero assolvere.

La nuova prospettiva proposta viene definita data-centrica. Il “Data Centric Manifesto” illustra in modo chiaro i principi alla base dell’orientamento data-centrico. La tabella seguente, presente nel Manifesto, riassume le differenze tra un approccio application-centrico, che rappresenta lo stato dell’arte per diverse aziende, e un approccio data-centrico, che dovrebbe invece essere la direzione da perseguire per l’evoluzione presente e futura.

Possiamo riassumere i punti salienti dicendo che un approccio data-centrico di design delle architetture enterprise permette di abbassare i costi di integrazione e del cambiamento, rendendo sostenibili i progetti IT e abbassando il rischio di investimento; il data-centrismo favorisce inoltre l’adattabilità delle architetture aziendali, rendendole pronte ad evolvere rapidamente in risposta ad un contesto di business altamente variabile e incerto e permette di estrarre dai dati un valore strategico e trasversale per l’azienda, da sfruttare come elemento differenziante rispetto ai competitor.

In un’architettura pensata con un paradigma data centrico, i processi di offloading dei dati dalle applicazioni sorgenti sono impostati non con l’obiettivo di alimentare un sistema consumatore specifico per soddisfare le esigenze di un particolare caso d’uso di cui è stata fatta richiesta all’IT nel momento in cui è emersa l’esigenza, quanto piuttosto di estrarre e mettere a disposizione i dati su una piattaforma condivisa con un tracciato e un formato sufficientemente generico da rispondere alle aspettative di applicazioni differenti, che in qualunque momento possano richiedere di utilizzare i dati, in un’ottica di sottoscrizione. Nella prospettiva descritta, il design del modello dati e delle integrazioni è orientato più al significato e al valore del dato di per sè, rispetto che ai requisiti di un particolare use case.

In questo modo, si evita di moltiplicare l’implementazione dei processi (e di conseguenza i costi) di estrazione dalle sorgenti per ogni necessità differente di utilizzo degli stessi dati: questi ultimi sono già a disposizione sulla piattaforma di integrazione, a cui un potenziale nuovo sistema può agganciarsi per fruirne.

Data On The Outside versus Data On The Inside

Pat Helland, nel suo whitepaper intitolato “Data on the Outside versus Data on the Inside”, mette in luce la differenza tra le caratteristiche del modello dati interno di un’applicazione, a cui fa riferimento con il termine di “Data On the Inside”, e le caratteristiche dei dati di interesse generale che un’applicazione dovrebbe mettere a disposizione degli altri sistemi IT, detti “Data On The Outside”.

La maggior parte delle applicazioni software moderne è generalmente caratterizzata da un’architettura interna a livelli, detta layered architecture, in cui si distinguono il livello più alto, detto di presentation, costituito dall’interfaccia utente, il livello di business, che contiene le logiche funzionali, e infine il livello di persistence, detto anche livello dati, che implementa il modello dati interno dell’applicazione in un database dedicato. Quest’ultimo è ad uso privato dell’applicazione e, di conseguenza, viene progettato secondo il formato di rappresentazione dati e la tecnologia di data store più congeniale alle logiche funzionali che l’applicativo implementa. Si tratta dei Data On the Inside.

A livello concreto, questo significa che il software engineer, nella fase di design di un’applicazione, sceglie se rappresentare i dati in un modello document-oriented, in uno schema relazionale piuttosto che in un altro formato, che grado di normalizzazione adottare, quali tipi di dato utilizzare tra quelli messi a disposizione dal DBMS scelto e quali campi tecnici introdurre, in funzione esclusivamente delle esigenze dei layer superiori dell’applicazione, che tipicamente avranno necessità di creare dati, leggerli, modificarli o cancellarli, molto spesso secondo il modello CRUD. Nel caso in cui si utilizzi un data store relazionale, solitamente le modifiche nel livello dati sono gestite dall’applicazione con un modello di consistenza transazionale (ACID); inoltre, il layer delle Application Programming Interface (API), esposte dal livello di business, maschera i dettagli del modello dati all’esterno, secondo i buoni principi di information hiding ed encapsulation.

La mentalità application-centrica che si è consolidata negli anni ha portato i software architect e i software engineer a concentrare la maggior parte degli sforzi di progettazione sui Data on the Inside e sui layer applicativi, come se la responsabilità dell’applicazione si esaurisse all’interno del suo stesso perimetro e si limitasse a soddisfare al meglio i requisiti di dominio per cui è stata realizzata.

Secondo quanto discusso in precedenza, al giorno d’oggi una prospettiva simile inizia a mostrare i suoi limiti: la necessità di integrazione tra le applicazioni, l’esigenza di condivisione e riuso dei data asset core di importanza strategica per l’azienda sono inevitabili. Per questo motivo, l’attività di sviluppo e di design di un’applicazione moderna dovrebbe considerare come uno dei punti di maggior valore la modellazione semantica e fisica dei dati che dovranno essere messi a disposizione per l’integrazione con gli altri sistemi. Tali dati costituiscono i Data On The Outside: al contrario dei Data on The Inside, non si tratta di dati ad uso privato ed esclusivo dell’applicazione, ma di dati condivisi con il resto dell’architettura IT, pertanto è necessario che siano rappresentati in un formato orientato alle esigenze dei consumatori, autodescrittivo e aperto, facilmente comprensibile e che siano resi fruibili in modo efficace tramite diversi pattern di accesso. Un’applicazione che funge da data provider di certi dati è responsabile (accountable) della consistenza, della qualità e della sicurezza dei Data On The Outside che espone al mondo esterno.

Come esempio, consideriamo i dati delle prenotazioni di un’azienda di viaggi, il cui ciclo di vita è gestito da servizi di back-end del portale web aziendale: ipotizziamo che una prenotazione venga rappresentata all’interno del layer di persistenza dell’applicazione con un modello relazionale, tramite una struttura di “testata” con le informazioni generali della prenotazione, una o più strutture di dettaglio in base al tipo di soluzioni (alloggi, trasporti, altri servizi…) inserite nella prenotazione, in relazione N:1 con la tabella di testata, contenenti diversi attributi specifici del tipo di soluzione. Considerando la totalità degli attributi rappresentati, probabilmente non tutti sono di interesse a livello aziendale al di fuori dell’applicazione web, per abilitare altri processi.

Pertanto, fare un’adeguata modellazione dei Data On The Outside richiede prima di tutto di porsi quesiti come i seguenti: che cos’è una Prenotazione dal punto di vista logico di business? Quali attributi semantici basilari sono di rilievo trasversale per l’azienda? Che significato hanno? Che tipo di valori possono assumere? Quali sono le regole invarianti che gli attributi devono garantire? Questo tipo di analisi non dovrebbe essere portata avanti considerando le esigenze specifiche di un unico sistema consumatore, come può essere il data warehouse, la Business Intelligence, o le richieste del team di data science, al contrario dovrebbe tenere un approccio più generale, finalizzato ad identificare le informazioni importanti per un qualunque processo aziendale che ne possa far richiesta.

Una volta completata la modellazione semantica e definito il set di informazioni da rendere accessibili per le integrazioni, si passano in rassegna aspetti più tecnici: ad esempio, a prescindere dalla rappresentazione relazionale del modello interno, si potrebbe valutare di esporre ogni prenotazione ai sistemi esterni come unico oggetto document-oriented, con le informazioni generali al livello più alto e le entry di dettaglio rappresentate su livelli innestati, scegliendo JSON come formato di rappresentazione e mappando i nomi dei campi relazionali del modello Data On The Inside con nomi comprensibili e agnostici dalle specificità dell’applicazione, da utilizzare nei Data On The Outside esposti.

A differenza del modello interno dei Data On The Inside, su cui l’applicazione mantiene totale autonomia e libero arbitrio nell’effettuare modifiche o evolutive, le interfacce che espongono i Data On The Outside al resto dell’architettura dovrebbero rispettare delle regole di evolvibilità concordate a livello di governance aziendale e garantire determinati livelli di servizio definiti in documenti detti data delivery contract.

Nella nuova visione data-centrica, in base a quanto discusso, un’applicazione non solo mantiene la sua importanza funzionale, ma soprattutto assume rilevanza nel suo ruolo di data provider, di produttore di asset digitali afferenti ad un determinato ambito del dominio aziendale.

A questo punto sorge però una domanda: come l’applicazione può esporre in modo ottimale e funzionale ai consumatori i dati core di cui è responsabile, per portarli al centro dell’architettura? Quali tecnologie e metodologie si rendono necessarie?

Per rispondere è necessario introdurre i concetti di Data Governance e Data Fabric, che tratteremo nei prossimi due articoli.

L’approccio data-centrico che cambia l’IT was originally published in Quantyca on Medium, where people are continuing the conversation by highlighting and responding to this story.

Abstract

Questo articolo costituisce l’introduzione di una serie di blog post finalizzata a trasmettere i punti salienti della visione delle architetture IT enterprise e del Data Management che, come Quantyca, proponiamo ai nostri clienti.

Negli articoli successivi tratteremo diversi aspetti che riteniamo interessanti per costruire piattaforme dati in grado di rispondere alle esigenze pressanti di un business che sta diventando sempre più data-driven.

Questo l’elenco dei prossimi articoli:

• “L’approccio data-centrico che cambia l’IT”: sostiene la visione dei dati come asset condivisi attorno a cui costruire le architetture enterprise
• “L’esigenza di governo nella gestione dei dati”: discute la necessità di costruire un framework di governance metadata-driven per mantenere il controllo della distribuzione dei dati nell’architettura enterprise
• “L’adattabilità della piattaforma di integrazione in un modello Data Fabric”: descrive un nuovo modello di piattaforma architetturale intelligente e automatizzata
• “Il Domain Driven Design applicato ai dati per una maggiore agilità nella progettazione”: riporta i punti fondamentali del modello di sviluppo software Domain Driven Design, che ha influenzato la proposta di nuovi modelli organizzativi anche per il Data Management
• “Il Data Mesh e la spinta verso una gestione dati distribuita”: descrive le ragioni che hanno contribuito alla proposta del paradigma Data Mesh, in favore di una gestione dei dati decentralizzata e domain-oriented per ottenere scalabilità organizzativa
• “Il Data Mesh e il principio di consumo self-service dei dati come prodotti”: descrive la visione dei dati come prodotti, che formano una rete di domain-oriented Data Product e sono fruiti tramite una piattaforma self-service e un modello di governance federato;
• “La Data Strategy come motore dell’IT”: chiude la serie con un riassunto dei principi architetturali che riteniamo basilari per una strategia di Data Management efficace e una visione del ruolo dell’Enterprise Architect nel delineare l’evoluzione delle architetture dati

Le sfide dell’IT nell’era dei dati

Nella mia esperienza come Data Architect in Quantyca, ho l’occasione di conoscere svariate realtà aziendali, più o meno mature dal punto di vista della trasformazione digitale.

In generale lo stato di avanzamento di un’azienda nel processo di trasformazione digitale è direttamente proporzionale alla concezione che l’organizzazione ha del ruolo dell’IT: le aziende in ritardo considerano ancora la funzione IT come centro di costo, al contrario le imprese leader considerano l’IT come funzione di business alla pari delle altre, come abilitatore di vantaggio competitivo.

La capacità dell’IT di fornire valore strategico può dipendere da diversi fattori, uno dei quali è il grado di modernità ed efficacia dell’architettura dati e applicativa. La maggior parte delle aziende non native digitali ha ereditato negli anni una strategia IT che si può definire application-centrica: l’organizzazione ha scelto di implementare soluzioni custom o acquistare prodotti di mercato dai vendor più affermati per rispondere alle funzionalità digitali richieste dal dominio di business (come la necessità di implementare un sistema ERP, un sistema di gestione del magazzino, un software di cassa, un sistema di controllo qualità o di monitoraggio degli impianti produttivi). Il design interno dei vari livelli (presentation layer, business layer, persistence layer) che costituiscono le applicazioni è stato comunemente il fattore primario considerato nella progettazione dell’architettura IT, dalla scelta degli stili architetturali alla scelta degli stack tecnologici e delle infrastrutture a supporto. In quest’ottica i dati erano considerati un by-product delle applicazioni, un elemento funzionale a mantenere lo stato applicativo e a supportare le logiche di processo.

Una strategia di questo genere era più che giustificata nella prima era di digitalizzazione, nella quale le applicazioni necessarie all’azienda erano relativamente poche: in un simile scenario, il contributo richiesto all’IT era, in primo luogo, di fornire supporto digitale ai processi aziendali core (ad esempio digitalizzare la gestione del magazzino, delle commesse ecc…). Pertanto, l’obiettivo primario era fondare un’architettura IT basata su applicazioni robuste ed affidabili nel svolgere il proprio compito operativo.

Gli applicativi aziendali, per supportare alcuni processi, richiedevano comunque un minimo di integrazione a livello di servizi: per adempiere a questa esigenza, si è consolidato negli anni il modello Service Oriented Architecture (SOA), basato sui sistemi di Enterprise Service Bus (ESB).

Oltre all’esigenza operazionale di digitalizzare i processi di business, era stato compreso fin da subito anche il valore dell’analytics e della Business Intelligence, come area funzionale a supporto dei processi di decision-making aziendali. Tuttavia, essendo relativamente limitate le applicazioni sorgenti di dati e avendo incentrato le piattaforme analitiche dell’epoca su un unico data store centralizzato costituito dal data warehouse, le integrazioni rimanevano in un numero contenuto e venivano progettate secondo uno stile di Extract, Transform and Load (ETL) point-to-point, dalle applicazioni sorgenti al DWH target.

Nella nuova era di digitalizzazione tipica degli ultimi anni, l’esigenza non è più quella di digitalizzare i processi core, quanto piuttosto di usare il digitale per creare nuovi modelli di business. Il numero e la varietà delle sorgenti dati e delle applicazioni utilizzatrici, così come la pletora di finalità possibili di utilizzo dei dati per scopi operazionali e analitici, sono aumentate esponenzialmente: questo fenomeno ha reso le integrazioni, che prima erano considerate di secondo ordine, un aspetto di centrale importanza.

Infatti, nell’ultimo ventennio lo scenario è radicalmente cambiato: l’avvento del business online, la diffusione delle applicazioni mobile, la necessità di fornire all’utente più touch point con il brand aziendale su canali differenti, la personalizzazione dell’esperienza utente e gli investimenti sui sistemi di engagement, i progressi significativi fatti nell’area dell’intelligenza artificiale e della data science, la necessità sempre più spinta di integrare gli applicativi e i dati aziendali, come ad esempio per la realizzazione delle customer data platform, hanno portato a rivedere le scelte alla base delle architetture IT.

I modelli IT tradizionali che affidavano le attività di integrazione a team centrali, quali il team SOA per i processi operazionali e il team DWH per il mondo analitico, hanno iniziato a vacillare, in quanto questi team sono presto diventati dei colli di bottiglia che rallentano la capacità di delivery dei servizi digitali.

Alla luce di questo fatto, è il momento di cambiare prospettiva, gli strumenti tecnologici per farlo sono disponibili, quello che occorre è modificare radicalmente la visione sulla strategia digitale. Ci possono essere diverse vie, ma un tratto comune che si osserva è che le aziende più mature nella trasformazione digitale hanno iniziato un percorso per cercare diversi modelli di organizzazione verso un trend data centrico.

Questo implica interrogarsi su che valore hanno i dati prodotti e consumati da un’azienda all’interno dei processi digitali, al di là del loro utilizzo ai fini dei processi stessi e del ciclo di vita delle applicazioni che li producono o li consumano: come è possibile spendere al meglio il budget IT per costruire una piattaforma dati moderna, scalabile e versatile, che offra all’azienda nuovi asset duraturi e riusabili, da sfruttare per trarne vantaggio competitivo?

Il rischio di non affrontare questi temi nel modo corretto è di accumulare debito tecnologico: i prodotti software selezionati, tradizionali o moderni che siano, diventano con buona probabilità dei legacy, che tendono ad accentrare all’interno di essi sempre più funzionalità e dati, raggiungendo con buona probabilità livelli di complessità e costi di manutenzione insostenibili, al punto di condizionare e rallentare le scelte future sull’evoluzione dell’architettura.

Dal lato loro, i vendor di applicazioni enterprise spingono in questa direzione, per accentuare il lock-in dell’azienda cliente sul prodotto e garantirsi una fonte di revenue maggiore, fornendo piattaforme sempre più estese e apparentemente auto-consistenti, costruite attorno alle funzionalità core del prodotto stesso. Esempi di tali sistemi sono anche alcune piattaforme cloud native, che hanno sostituito in molte aziende i sistemi ERP e CRM tradizionali, ma che comunque fondano il loro business sull’attrarre il cliente a rimanere legato alla suite offrendo moduli fortemente integrati tra di loro e funzionalità di analytics on top della piattaforma centrale, offerta con modelli Platform as a Service(PaaS) o Software as a Service(SaaS).

Tuttavia, nella realtà delle cose si osserva che non esiste un prodotto in grado di soddisfare bene tutte le esigenze digitali di un’azienda, pertanto l’integrazione non è una scelta, ma una necessità.

Le conseguenze del debito tecnologico accumulato e dell’approccio application-centrico vengono pagate nel momento in cui si presenta la necessità di integrare le soluzioni software per realizzare nuovi servizi data-driven. In quel momento ci si rende conto che si ha spesso a che fare con diversi data silos che è difficile far comunicare.

Il documento “2022 Connectivity benchmark report” di Mulesoft ha evidenziato che i costi di integrazione assorbono più di 1/3 della spesa IT annuale nel mondo. Non deve pertanto sorprendere il fatto che si osservi una quantità ingiustificabile di progetti IT che eccedono il budget iniziale di ordini di grandezza e che immancabilmente sforano le deadline. Sempre secondo il report, infatti, nel 2021 la percentuale di progetti che non sono stati consegnati in tempo è del 52%.

Del resto, la richiesta di nuove funzionalità e di servizi digitali è sempre più pressante (nel 2021 il report stima una crescita della domanda del 40%), il budget IT cresce ma in modo non proporzionale alla domanda e gran parte di esso viene inevitabilmente investito in attività di integrazione, per cui il risultato è una difficoltà di delivery dei servizi. In un contesto competitivo altamente variabile e incerto, un fattore determinante di successo è dato non tanto da un un’economia di scala ma da un’economia di velocità: essere veloci nel rispondere ai cambiamenti delle esigenze di business, al variare delle priorità delle evolutive in backlog, poter adattare modalità e finalità di utilizzo dei dati in tempi brevi e cambiare agilmente la direzione strategica sono aspetti di fondamentale importanza.

In aggiunta ai costi diretti, è doveroso considerare anche la perdita indiretta che un’azienda subisce se non sfrutta al meglio il valore potenziale dei dati. Infatti, se questi rimangono confinati all’interno dei database privati delle singole applicazioni e, per ogni necessità esterna all’applicazione, bisogna mettere in opera una nuova soluzione di integrazione ad-hoc con il sistema consumatore, è difficile riutilizzare i dati per abilitare servizi data-driven e applicazioni analitiche avanzate (casi d’uso molto richiesti oggigiorno, come monitoraggio in real time dei processi, previsioni e modelli di machine learning, identificazione di frodi, sistemi di raccomandazione, customer data platform, solo per citarne alcuni).

Pertanto è necessario rivedere le priorità che diamo nella progettazione delle architetture aziendali. Buona parte dello sforzo di design di un’architettura IT dovrebbe essere dedicato alla strategia di gestione dei dati: i componenti nell’architettura che salvano, elaborano, orchestrano e distribuiscono i dati sono quelli che avranno il peso specifico più determinante nelle scelte di evoluzione. Infatti, uno dei fattori primari che si considerano nel valutare migrazioni di prodotti o revisioni architetturali è l’incidenza della Data Gravity: tipicamente migrare una funzionalità software in un’altra applicazione è un’attività meno onerosa che spostare grossi volumi di dati in un nuovo sistema, che solitamente comporta la necessità di gestire i costi di trasferimento, la compatibilità dei modelli, l’allineamento continuo durante il transitorio e la gestione del caricamento iniziale.

Dopo questa breve introduzione alle sfide che l’IT si trova a dover affrontare nell’era moderna, nei prossimi articoli di questa serie cercheremo di delineare i pillar su cui si basano la visione architetturale e di data management che, come Quantyca, proponiamo ai clienti per rispondere alle loro necessità digitali. Ogni realtà aziendale ha il suo contesto e le sue esigenze peculiari, pertanto non esiste una strategia unica e perfetta per ogni organizzazione, al contrario l’architettura IT ottimale per un’azienda è spesso riflesso dell’organizzazione e della cultura aziendale: esistono però dei buoni principi che tracciano la direzione da seguire nell’evolvere l’architettura dati, per raggiungere l’agilità necessaria per la richiesta digitale di oggi e di domani.

In questa serie di blog post inizieremo illustrando il valore del principio di centricità dei dati, sostenendo l’approccio proposto dal Data Centric Manifesto, in cui i dati sono considerati come asset condivisi e riusabili a livello di intera organizzazione, che oltrepassano il perimetro di una singola applicazione. Vedremo poi la differenza tra i concetti di Data On The Inside e Data On The Outside, che pone le basi per gli stili di integrazione moderni. Continueremo poi il percorso ponendo l’attenzione sul principio di governo di un’architettura IT, entrando nel merito delle tematiche specifiche di Data Governance e di automazione metadata-driven. Concluderemo parlando del principio di adattabilità che, sotto l’aspetto tecnologico e architetturale trova concretizzazione nella proposta dei modelli di Data Fabric e Data Mesh. Quest’ultimo, in particolare, sfruttando l’influenza rilevante del Domain Driven Design sul mondo dati, aggiunge un’ulteriore dimensione di adattabilità, proponendo modelli organizzativi federati e decentralizzati, per massimizzare la rapidità di delivery dei progetti di data management.

I principi di un moderno Data Management was originally published in Quantyca on Medium, where people are continuing the conversation by highlighting and responding to this story.

Le scie luminose possono rappresentare il concetto di flusso di dati o quello di real-time: anche l’informazione più microscopica, se raccolta in modo opportuno e poi trasformata, insieme a tantissime altre può produrre risultati esaltanti. Se pensiamo a tutti i dati prodotti dalle applicazioni e alle opportunità che possono derivare dal loro sfruttamento, chi non vorrebbe catturare le scie luminose lasciate dai dati?

E’ con questa immagine in mente che vi invito a leggere questo blogpost che parla di real-time analytics, dei diversi volti che assumono i dati oggi e di come evolvono le tecnologie per far fronte a nuovi requisiti creando nuove opportunità. In particolare parleremo di SingleStore (fino a qualche settimana fa noto come MemSQL) e di come si sia affermato tra le tecnologie HTAP, anello di congiunzione tra tecnologie OLTP e OLAP, che permettono l’implementazione di casi d’uso di tipo operational e real-time analytics.

Introduzione

Negli ultimi 40 anni si è affermata la best-practice di implementare use-case analitici su data store separati da quelli adottati per fornire supporto operazionale/transazionale. Questa scelta è stata condizionata dalle performance limitate dei sistemi tradizionali, che rendeva impossibile concentrare volumi elevati di letture e di scritture nello stesso perimetro.

Questo è vero ancora oggi: nella maggior parte dei casi si impiegano database disegnati ed ottimizzati per elaborazioni transazionali (OLTP) per workload di tipo operazionale e si utilizzano tecnologie di tipo OLAP per BI e workload analitici.

Dati Operazionali e Analitici: due facce della stessa medaglia

Ultimamente quando si parla di Data Dichotomy si pone l’accento su una dimensione attorno alla quale i dati sono distinguibili: dati operazionali e dati analitici.

I dati di tipo operazionale servono agli scopi del business permettendo il funzionamento di applicativi e servizi in genere. Sono organizzati tipicamente in Row Store e direttamente su di essi si appoggiano le applicazioni che eseguono accessi puntuali per leggere/scrivere informazioni. Per questo motivo è fondamentale che siano ottimizzati per garantire alti throughput (in particolare per la scrittura) e per sostenere elevata concorrenza. Spesso questi dati sono chiamati “data on the inside” intendendo che questa è la porzione contenuta nel servizio stesso ed esposta solo se necessario via API per stabilire cosa far vedere e a chi. Ci sono diverse tipologie di prodotti tra cui scegliere per questa tipologia di dati: dai classici DB relazionali ai DB a grafo, per casi d’uso dove privilegiare le relazioni tra entità, a quelli NoSQL per maggiore flessibilità e per il supporto all’out-scaling, oppure ancora ai Document Store per gestire dati semi-strutturati. Tra le tecnologie in gioco ci sono grandi player storici come Oracle, PostgreSQL o Microsoft SQL Server, a cui si aggiungono prodotti più recenti che presidiano particolari sotto-aree come Elasticsearch, Redis, Neo4j o MongoDB. A questi si affiancano le offerte dei vari cloud provider tra cui Amazon RDS, Google Cloud SQL o Microsoft Azure SQL

Sull’altra faccia della medaglia ci sono i dati di tipo analitico, che nascono come supporto alla BI e quindi con l’obiettivo di calcolare KPI allo scopo di migliorare processi aziendali. Sono organizzati tipicamente in Column Store e permettono l’interrogazione di grandi volumi di dati con profondità storica. Sono quindi pensati per sostenere elevati throughput di lettura e bassa latenza. Questi dati rientrano nei “data on the outside”, trattandosi di informazioni che sono scambiate tra più componenti tra loro indipendenti: cioè avviene attraverso la propagazione di eventi, lo scambio di file o l’integrazione dei dati in tabelle. Tra i tipi di prodotti che trattano questa categoria di dati ci sono gli object store (soprattutto per raccogliere dati raw costruendo dei data lake), i database analitici (che ottimizzano il formato dei dati per l’interrogazione via SQL) o gli streams (per la propagazione delle informazioni introducendo un disaccoppiamento tra chi produce e chi consuma). Tra le tecnologie citiamo come data warehouse Teradata e Vertica, come Data Platform si affermano invece Cloudera e Snowflake e naturalmente non mancano i prodotti dei cloud provider tra cui Amazon Redshift, Google BigQuery e Azure Synapse Analytics.

Integration

I dati fluiscono tra questi due mondi andando dai sistemi operazionali a quelli analitici. Questo può avvenire in due modalità:

• via batch, trasferendo i dati in modo asincrono e processandoli in lotti che sono disponibili sul target con un ritardo nell’ordine delle ore.
• in streaming, propagando i dati in modo continuo (o quasi) eseguendo dei micro-batch e riducendo il ritardo nell’ordine dei minuti.

Non è escluso naturalmente anche un ciclo di ritorno in cui alcuni dati analitici sono portati sui sistemi OLTP per il loro utilizzo all’interno delle applicazioni (es. app che riporta statistiche settimanali/mensili).

Tuttavia questo fenomeno migratorio dei dati consuma del tempo e il tempo è denaro: i casi d’uso analitici hanno dei veri e propri requisiti temporali per poter garantire un azione contestuale che porti valore. In base a quanto tempo si è disposti ad attendere per l’elaborazione di un insight si possono distinguere varie casistiche a cui corrispondono diversi stack tecnologici: si parla di finestra di reattività.

Siamo in presenza di Strategic Analytics quando il tempo che intercorre tra la produzione di un insight e l’azione è compreso tra mesi e anni: ad esempio se si registrano incrementi delle richieste di mobili, si decide di espandere la linea di produzione. Oppure quando questo intervallo è compreso tra minuti e mesi si parla di Performance Analytics: un caso tipico è una previsione di incremento delle vendite a cui corrisponde l’azione di incrementare le scorte. Per queste prime due categorie di analytics i sistemi tradizionali di BI calzano alla perfezione: sia i Data Warehouse che i Data Lake sono adeguati: si preferirà uno all’altro in funzione del volume dei dati e del loro formato. Il tutto viene reso possibile attraverso una fitta rete di flussi di data integration che raccolgono i dati dai sistemi sorgente e li depositano su questi storage.

E quando i requisiti temporali sono più stretti quali sono gli scenari che si prospettano?

Si parla di Operational Analytics quando la reattività è compresa tra i secondi e i minuti: importante ad esempio per sistemi di vendita online nel momento in cui i profitti sono inferiori agli obiettivi per correggere i prezzi on-the-fly in funzione del volume delle richieste. Mentre per requisiti ancora più stringenti, inferiori al secondo o al massimo nell’ordine dei secondi, si parla di Real-time Analytics: ad esempio durante lo shopping online se il cliente inserisce nel carrello un prodotto si fa recommendation di un prodotto correlato oppure si pensi all’integrazione con sistemi di natural language, processing, di image recognition o di fraud detection che devono reagire in modo tempestivo. Per sostenere queste due categorie di analytics i sistemi tradizionali non sono più adeguati.

Perchè? Proprio per via di come tali sistemi sono strutturati a basso livello: non riescono a rispondere a entrambi i requisiti richiesti, fast ingestion e bassa latenza per query analitiche. Infatti i Row Store supportano fast ingestion trattando i dati nel loro formato nativo senza applicare alcuna ottimizzazione a livello di encoding o compression, ma proprio per questo motivo non sono adeguati per workload analitici. Al contrario i Column Store sono adeguati a workload analitici ma se ricevono grossi volumi di dati in ingresso a distanza troppo ravvicinata vedono un degrado considerevole delle performance di lettura a causa delle operazioni necessarie alla compaction e all’ottimizzazione di tutti i dati ricevuti nel frattempo.

Fortunatamente, negli ultimi 5 anni si è affermato un nuovo tipo di soluzione che cerca di colmare questo buco tecnologico. Si tratta dei sistemi HTAP (Hybrid Transactional and Analytical Processing) o HOAP (privilegiando il termine Operational a Transactional, per non escludere sistemi NoSQL e non relazionali).

I prodotti che rientrano in questa categoria sono molteplici: a partire da SAP Hana, pioniere sul mercato, e continuando con prodotti NewSQL (che portano la scalabilità dei sistemi NoSQL per workload OLTP pur continuando a garantire le proprietà ACID dei sistemi tradizionali). Tra questi spicca SingleStore, di cui parleremo tra poco. Hanno introdotto il supporto a questo tipo di workload anche alcuni sistemi documentali e database NoSQL come Redis Labs e Aerospike o In-Memory Computing Platform come GridGain.

Tuttavia SingleStore rispetto a SAP Hana e ad altri prodotti blasonati ha un TCO decisamente più basso mentre rispetto ai NoSQL ha evidentemente il notevole vantaggio di supportare il linguaggio SQL.

Inoltre un altro aspetto da considerare nel confronto tra prodotti documentali e SingleStore è la flessibilità nella definizione di single view. Infatti, nonostante i documentali permettano ormai di creare cross-reference tra più elementi, quando le viste coinvolgono più di un paio di entità o richiedono interrogazioni complesse ci si scontra presto con un degrado delle performance di aggiornamento delle single view (che può superare la decina di secondi).

Un esempio di vista complessa? ottenere il dettaglio di un cliente che fa 4/5 visite al mese in un negozio e per ogni visita fa uno scontrino da almeno 20 prodotti di categoria X, con le relative promozioni utilizzate.

Entità coinvolte: cliente, negozio, scontrino, prodotti, promozioni

Naturalmente anche i big player come Oracle e SQL Server non sono rimasti a osservare e anche loro hanno previsto copertura per questi workload. Tuttavia SingleStore prevale anche in questo caso dal momento che essendo stato realizzato nativamente per workload HTAP raggiunge performance migliori a parità di risorse computazionali e quindi con TCO inferiore.

Per approfondire il confronto tra SingleStore e i competitor si rimanda a questo link.

Una precisazione è d’obbligo: questo tipo di sistemi non entra in competizione con i prodotti OLAP. Infatti lo use-case primario su cui si fondano i sistemi HTAP è il supporto al real-time analytics sui dati operazionali, per individuare insight a partire dati prodotti dalle applicazioni prima ancora che questi vengano estratti e trasferiti sul Data Warehouse. Tuttavia dal momento che sempre più vendors di storage OLTP annunciano o aspirano ad annunciare l’apertura a workload di tipo HTAP, ci si chiede se avrà ancora senso in futuro fare una distinzione tra OLTP e HTAP. Si stima che nel 2021 i workload di tipo HTAP costituiranno oltre il 40% dei nuovi workload di tipo operazionale (come incremento sugli anni precedenti).

Overview di SingleStore

SingleStore si posiziona a pieno titolo tra le tecnologie HTAP e questo grazie principalmente a 3 features:

• Fast Data Ingest
• Low Latency Queries
• High Concurrency

Grazie a queste features permette un’alimentazione in real-time garantendo la fruibilità del dato in pochi istanti con tempi di lettura ridotti e costanti anche in presenza di elevata concorrenza, soddisfando quindi i requisiti per use case di tipo Operational e Real-Time Analytics.

Queste features sono sorrette a livello tecnico da un utilizzo efficiente della memoria, che sfrutta sia il disco che la memoria volatile, da un’architettura distribuita e scalabile orizzontalmente e da un’interfaccia relazionale verso utenti e applicazioni basata su linguaggio SQL e binary compliant con MySQL (la connessione a SingleStore via JDBC avviene con driver MySQL)

A livello fisico i dati sono organizzabili su due tipologie di storage:

• In-Memory RowStore, particolarmente indicato per l’ingestion di stream di dati ed elaborazioni real-time
• ColumnStore che sfrutta la capacità di dischi fisici, più adatto all’interrogazione di grosse moli di dati storici

La tipologia di storage viene scelta in fase di creazione di una tabella e i dati possono fluire tra le tabelle (e quindi gli storage corrispondenti) attraverso le pipeline: per sfruttare il formato più efficiente in ogni situazione.

SingleStore ha avviato ormai da diversi mesi un progetto chiamato Universal Storage con cui sta cercando sempre più di far convergere questi due formati. Lavorando in tal senso, la versione 7.1 ha escogitato diverse soluzioni, tra cui citiamo:

• la possibilità di consentire al RowStore di gestire un volume di dati molto superiore alla quantità di RAM disponibile, riducendo il TCO e preservando le performance. Questo grazie soprattutto alla compressione di valori NULL, che permette di risparmiare molta memoria per dataset sparsi.
• il supporto ad accessi puntuali per il ColumnStore per sostenere workload con elevata concorrenza di read/write, introducendo Hash Indexes, Row-Level Locking e Subsegment Access.

L’ingestion dei dati può avvenire via streaming o attraverso l’esecuzione di batch. Mentre le tipologie di dati supportati spaziano dal chiave-valore, ai formati semi-strutturati come JSON e Avro, ai dati geo-spaziali e alle time-series. Inoltre SingleStore può essere usato ovunque: dal deploy on-premise, all’utilizzo di container su Kubernetes oppure ancora in modalità SaaS (con la versione SingleStore Managed).

Con queste caratteristiche ha tutte le carte in regola per coprire sia use-case analitici che operazionali. E’ evidente quindi come siano tante le tipologie di situazioni in cui si può impiegare SingleStore: di seguito si tratterà un primo set di use case che ruotano attorno al concetto di omnicanalità e all’architettura del Digital Integration Hub. Per chi fosse curioso di scoprirne altri, vi invito a registrarvi a questo link dove troverete il webinar che abbiamo fatto di recente con Quantyca: al suo interno parliamo anche dell’adozione di SingleStore per costruire un feature store per modelli di machine learning o ancora per generare single view all’interno di un serving layer.

Qualche use case a proposito di Digital Integration Hub

Ultimamente quando si parla di omnicanalità e viene sempre più spesso citato il Digital Integration Hub (DIH). Infatti il DIH è un pattern architetturale con cui è possibile raccogliere in real-time dati provenienti da più sistemi, senza sovraccaricare questi ultimi, e renderli fruibili a una fitta rete di micro-servizi esposti via API che li adattano alle esigenze degli utenti finali per costruire piattaforme omnicanale. Tuttavia, questa architettura non può gravare sulle spalle dei sistemi legacy sottostanti:

• la maggior parte di questi sistemi può essere già a corto di risorse
• tipicamente non si tratta di sistemi in grado di scalare orizzontalmente
• i costi di licenza o legati al consumo di risorse sono elevati

La scelta critica per implementare questa architettura è quindi la scelta dello storage per costruire le single view, asset logici con cui interagiscono micro-servizi e applicazioni di real-time analytics, e la loro alimentazione a partire dai sistemi sottostanti. Questo layer deve poter garantire supporto OLAP e OLTP, ingestion e consumo in real-time ed essere capace di scalare orizzontalmente per far fronte a volumi crescenti di dati o di consumers. Il tutto riducendo il più possibile il TCO.

Con questa architettura si può rispondere a uno scenario molto diffuso: risolvere i limiti del pattern di Event Sourcing per i micro-servizi. Questo pattern prevede che ad ogni modifica ai dati corrisponda la produzione di un evento sul data bus e che ogni consumer interessato debba ricevere tutto lo storico di eventi per saper ricostruire lo stato in un dato istante temporale. Se da un lato questo approccio va bene per scenari complessi, dall’altro è eccessivo richiedere la riproduzione di tutti gli eventi a un micro-servizio che avesse bisogno solo di un accesso puntuale a una porzione dei dati. Per ovviare a questo limite si può impiegare il pattern del DIH introducendo SingleStore come High Performance Data Store che consuma tutti gli eventi prodotti dai micro-servizi creando uno stato condiviso accessibile a tutti. A questo punto i mini-servizi (chiamati così perchè condividono il data store) che hanno bisogno di fare un’accesso puntuale possono semplicemente interrogare SingleStore via SQL. Questo inoltre semplifica scenari come il calcolo di metriche cross-entità o l’aggregazione di dati in una singola entità, che richiederebbero diversi sforzi in assenza dello store condiviso e del supporto SQL.

Un’altra casistica in cui il DIH può venire in nostro soccorso è quella della modernizzazione dei sistemi legacy: attraverso l’integrazione dei dati prodotti da essi in un’architettura che li renda fruibili ad altri sistemi senza impatti sul legacy stesso. Questo è possibile collegando un Change Data Capture al transaction log dei sistemi legacy e riproducendo tutti gli eventi sul Data Bus. In dati sono scodati in real-time dal bus e salvati sull’High Performance Data Store da cui poi i micro-servizi possono leggere le informazioni. I micro-servizi che hanno anche l’esigenza di modificare i dati pubblicano eventi sul Data Bus, da cui verranno scodati ed eseguiti in modo asincrono i “command” (seguendo il pattern CQRS) da parte del sistema legacy. I dati modificati seguiranno poi il percorso già descritto. In questo modo si genera un loop di modifica e propagazione dell’informazione che genera una finestra di incosistenza eventuale: letture intercorse prima del termine del loop si baserebbero su dati consistenti ma non ancora aggiornati. E’ fondamentale quindi la scelta di un prodotto che garantisca fast intestion e bassa latenza per ridurre l’ampiezza di questa finestra. SingleStore risulta quindi perfetto per lo scopo.

Un’ultima situazione che si cita è quella relativa alla gestione delle informazioni provenienti da sensori IoT. Anche in questo caso gli eventi sono raccolti sul Data Bus, per disaccoppiare produttori e consumatori sia in termini temporali (ritmi diversi tra chi scrive e chi legge) che spaziali (evitando connessioni punto punto tra sistemi). Dal Bus gli eventi sono poi propagati sull’High Performance Data Store dove si possono attuare sia analisi classiche di BI, sia algoritmi di real-time analytics, ad esempio per generare delle azioni correttive sui sensori. Ancora una volta SingleStore calza perfettamente come data store da impiegare per questo caso d’uso grazie alla sua capacità di scalare orizzontalmente e alla fast-ingestion. Inoltre in questo contesto, grazie al supporto per le time-series e per le funzioni geo-spaziali, permette lo sviluppo di applicazioni avanzate con sforzo minimo.

Integrazioni con altri prodotti

Tra le integrazioni con prodotti di terze parti vale la pena citare:

• Confluent Kafka. Integrazione possibile in modalità pull, con le Pipeline di SingleStore, o in modalità push, attraverso il Connector di Confluent per Singlestore
• Spark. Utilizzando un connettore ad-hoc che supporta la traduzione delle operazioni fatte sui dataframe in SQL e il push-down della computazione su SingleStore. A questo link potete trovare un webinar sul tema.
• Talend. Attraverso un set di componenti ad-hoc
• Strumenti di BI in genere. Utilizzando il driver jdbc di MySQL

Conclusioni

Le società stanno sempre più prediligendo soluzioni di analytics avanzato per il supporto a decisioni strategiche agendo in misura sempre crescente sulla riduzione della finestra di reattività .

I prodotti emergenti di tipo HTAP permettono di coprire quello che era un punto cieco, fare analytics subsecond, e rispondere a domande che prima non potevano essere espresse. Sono tanti gli use-case che possono trarre vantaggio da queste nuove soluzioni. Grazie a tecnologie come SingleStore, sorgono nuove opportunità per rispondere meglio e più in fretta alle esigenze analitiche e per rispondere quindi più efficacemente a decisioni importanti per il business.

Spero che questo blogpost vi sia piaciuto e abbia fatto luce sugli aspetti fondamentali di SingleStore, dei contesti in cui impiegarlo e delle sfide che permette di risolvere. Se vi è piaciuto lasciate qualche clap per farmelo sapere e state sintonizzati sul profilo ufficiale di Quantyca su linkedin e qui su medium.

Per chi è interessato a questo link potete iscrivervi al webinar che parla dei temi citati in questo blogpost e di altri ancora.

Come catturare le scie luminose prodotte dai dati con SingleStore was originally published in Quantyca on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this post, I will explain what serverless computing is and how to design a serverless architecture using Amazon Web Services (AWS) tools. In the first chapter, we will introduce the concept of serverless computing and list the advantages and disadvantages of this approach. In the second part, we will explore a typical three-tier architecture and which AWS services we can implement based on our needs. Finally, I will describe the sequence diagram of a simple use case implemented with some AWS serverless services.

What Is Serverless Computing?

Serverless computing is a method of providing backend services on an “as used” basis. Serverless architecture allows users to write and implement code without having to worry about the underlying infrastructure. However, despite the name, serverless does not mean that the code runs without servers, but it means that the concerns about the server management disappear for developers. For this reason, in this architectural paradigm, there is no need to purchase, rent, or provision servers in advance in order to host and execute the server-side code.

Traits of serverless architectures:

• Low barrier-to-entry: it’s relatively straightforward to start getting your code running in a serverless architecture.
• Hostless: there are no servers to work with, this brings a significantly less operational overhead on their maintenance.
• Stateless: the compute containers running your code will automatically be created and destroyed by your platform hence you can’t store anything in memory.
• Elasticity: this means there is no need for the manual management of resources, and that many challenges in resource allocation disappear.
• Distributed: since deployment units are very small, serverless architecture is intrinsically distributed.
• Event-driven: this paradigm promotes production, detection, consumption, and reaction to events and as a result, there will be a low level of coupling between the components of the architecture.

Limitations of serverless architectures:

• Vendor control: with any outsourcing strategy you are giving up control of some of your system to a third-party vendor and such lack of control may manifest as system downtime, unexpected limits, cost changes, loss of functionality, and more.
• Vendor lock-in: almost certainly Serverless features from one vendor will be implemented differently by another vendor. So, if you want to switch vendors you’ll probably need to change your operational tools, your code and, your design or architecture.
• Startup latency: cold starts may add latency to an invocation.
• Execution duration: the duration of executions can be limited.
• Unpredictable cost: since the majority of services are pay-per-use, it’s difficult to predict the final cost.
• Testing and debugging: since everything is and runs in the cloud, there is no local environment to test and debug the developed code.
• Monitoring and observability: the choice of adopting an architecture where services are decoupled leads to significant difficulty in monitoring and observing what is happening in the system.

Three-Tier Serverless Architecture With Amazon Web Services

In this section, I describe how AWS’s serverless services can be used to change the way you design three-tier architectures and implement popular patterns such as microservices, mobile backends, and Single-Page Applications. In order to give readers a more complete view of this type of architecture, some AWS non-serverless — but widely used — services will also be described.

A three-tier application generally consists of the following components:

1. Presentation Tier: it is a component that users directly interact with (Mobile App UI, Web Pages, etc.)
2. Logic Tier: it contains the application Business Logic (data processing, database operations, etc.)
3. Data Tier: it storages media (Databases, Object Stores, Caches, File Systems, etc.) and hold the data relevant to the application.

Presentation Tier

The presentation tier is responsible for interacting with the logic tier via the endpoints exposed over the internet. Any client or device can communicate with these endpoints, giving your presentation tier the flexibility to take many forms (Desktop Applications, Mobile Apps, Web Pages, IoT devices, etc.). Depending on your requirements, your presentation tier can use the following AWS serverless offerings:

• Amazon Cognito is a serverless user identity and data synchronization service that allows you to add user sign-up, sign-in, and access control to your web and mobile apps quickly and easily.
• Amazon Simple Storage Service (S3) allows you to serve static websites, such as single-page applications, directly from an S3 bucket without requiring the provision of a web server.
• AWS Amplify is a static web hosting service that accelerates the application release cycle by providing a simple CI / CD workflow for building and deploying static web applications.
• Amazon CloudFront is a content delivery service that uses Amazon’s global network of edge locations as connection points for clients using your API. This helps decrease the response latency of your API.

Logic Tier

The logic tier of the three-tier architecture is where the business logic is implemented. You can design a serverless logic tier by adopting these services:

• Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. Clients integrate with the APIs exposed via API Gateway using standard HTTPS requests. API Gateway allows you also to associate a method with a Lambda function, so when you call that endpoint, API Gateway invokes the related Lambda function.
• AWS Lambda is a serverless computing service that allows you to run arbitrary code functions in any of the supported languages without provisioning, managing, or scaling servers. Lambda functions can perform any kind of computing task, from serving web pages and processing streams of data to calling APIs and integrating with other AWS services. You can use an AWS Lambda when: tasks run for a short time; tasks are self-contained; you need to decouple your application modules due to different levels of workload.
• Amazon Elastic Computing Service (ECS) is a highly scalable, fast, container management service that makes it easy to run, stop, and manage containers on a cluster. Your containers are defined in a Task Definition which you use to run individual tasks or as a service. Within an ECS cluster, you can adopt both AWS Fargate that is the serverless compute engine for containers and Amazon Elastic Compute Cloud (EC2) where you have complete control over your computing resources.

Data Tier

AWS offers a number of serverless and non-serverless data stores that you can use to compose a serverless data tier of your application.

These are serverless data storage options:

• Amazon Simple Storage Service (S3) is an object-oriented storage service that offers scalability, data availability, security, and performance.
• Amazon Aurora is a relational database that combines the performance and availability of traditional databases (e.g. MySQL and PostgreSQL) with the simplicity and cost-effectiveness of open source databases.
• Amazon DynamoDB is a fast and flexible non-relational (NoSQL), key-value, and document database. It is a fully managed, serverless, multi-region, multi-master, durable database with built-in security, backup and restore, and in-memory caching for internet-scale applications.
• Amazon Athena is an interactive query service that makes it easy to analyze data in Amazon S3 using standard SQL.
• Amazon Redshift Spectrum is a serverless feature of Amazon Redshift. It is a query processing engine that allows to join data that sits in Amazon S3 with data in Amazon Redshift.

These are non-serverless data storage options:

• Amazon Relational Database Service (RDS) is a managed web service that makes it easier to set up, operate, and scale a relational database using any of the available engines (Amazon Aurora, PostgreSQL, MySQL, MariaDB, Oracle, and SQL Server) and running on several different database instance types that are optimized for memory, performance, or I/O.
• Amazon Redshift is a fast, fully managed, data warehouse service that makes it simple and cost-effective to efficiently analyze all your data using your existing business intelligence tools (optimized for datasets ranging from a few hundred gigabytes to a petabyte).
• Amazon ElastiCache makes it easy to set up, manage, and scale distributed in-memory cache environments. It is a fully managed deployment of Redis or Memcached.

Logging And Monitoring

• CloudWatch is a monitoring and management service that provides data and insights for AWS, hybrid, and on-premises applications and infrastructure resources. CloudWatch enables you to monitor your complete stack (applications, infrastructure, and services) and leverage alarms, logs, and events data to take automated actions.

Web Application — Simple Use Case

In this section, I want to propose a serverless design and five AWS serverless services that can be used to implement a very simple Web Application.

These are the steps and the AWS services proposed:

1. The Client, via the specific URL, retrieves the static content of the Web Page located in an Amazon S3 Bucket.
2. The authentication of users is through Amazon Cognito which manages both the sign-up and the login.
3. In order to get dynamic content, the request passes through the Amazon API Gateway.
4. The request is authenticated with Amazon Cognito.
5. After request authentication, Amazon API Gateway invokes the AWS Lambda related to the specific endpoint.
6. The AWS Lambda implements Business Logic. When it is invoked, it processes the request and according to its purpose, it can create, retrieve, update, delete objects on a database, and make some computations over the data. In our example, the AWS Lambda interacts with Amazon DynamoDB. Finally, it is also in charge of preparing the response.
7. The response computed by the AWS Lambda is returned through the Amazon API Gateway to the Client that made the request.

Conclusion

The serverless approach can answer many of the architectural and operational questions, simplifying the life of developers as well as the operational team. In the previous chapter, we have seen that with only five AWS serverless services — and zero effort for managing and tuning the infrastructure— is possible to have an up and running Web Application. Anyway, adopting a serverless architecture is not the solution to all our problems. The decision to move to serverless should involve a careful analysis of business and technical requirements, taking into account all the pros and cons.

References

1. Mike Roberts (2018). Serverless Architectures.
2. Wisen Tanasa (2019). The traits of serverless architectures.
3. Amazon Web Services documentation

Designing Serverless Web Applications with Amazon Web Services was originally published in Quantyca on Medium, where people are continuing the conversation by highlighting and responding to this story.