Alcune settimane fa ho scritto su questo blog di come l’intelligenza artificiale stia cambiando il mondo dei data warehouse SAP. Era un’esplorazione nata dal mio lavoro quotidiano, da quello che vedevo accadere nei progetti con i miei clienti.
Mentre scrivevo quell’articolo, mi sono fatto una domanda che mi incuriosiva: e nel mondo Google, come funziona? Non era una domanda accademica. Stavo seguendo un progetto che mi aveva portato a esplorare l’ecosistema di Business Intelligence di Google ( BigQuery, Looker, Looker Studio) e mi ritrovavo a fare lo stesso gioco mentale: confrontare quello che vedevo con quello che conoscevo. Stesso problema, piattaforma diversa e medesimo obiettivo: trasformare dati grezzi in decisioni , ma architettura, filosofia e integrazione con l’AI profondamente differenti.
Il punto di partenza: un data warehouse senza complessità
Nel mondo dei data warehouse tradizionali, costruire l’infrastruttura analitica richiede tempo e struttura prima ancora di poter fare la prima analisi. Bisogna definire modelli dati, configurare pipeline di caricamento, orchestrare i flussi. La prima cosa che colpisce esplorando BigQuery è l’assenza apparente di tutto questo. Carichi i dati, scrivi SQL, ottieni la risposta. Dietro c’è un’architettura sofisticata che distribuisce ogni query su migliaia di nodi in parallelo, ma quella complessità è invisibile. E il modello di costo riflette questa filosofia: non si paga per un server sempre acceso, ma per i dati che le query effettivamente scansionano
Il semantic layer: una vecchia idea, un’implementazione nuova
Chi ha lavorato con Business Objects ricorda il concetto di Universe: quel layer intermedio dove si definivano metriche e regole di business una volta sola, per tutti. Era una buona idea, con un problema: difficile da versionare, problematico da modificare.
Looker riprende quella filosofia con LookML, un linguaggio di modellazione che tratta le metriche aziendali come codice vero: versionato su Git, testabile, deployabile come qualsiasi progetto software. “Fatturato netto”, “tasso di riacquisto”, “clienti attivi” si definiscono una volta e si propagano automaticamente a ogni dashboard e ogni analisi ad-hoc. Se cambia una regola di business, la modifichi in un posto solo.
È lo stessa concetto del semantic layer, con una maturità ingegneristica che rende la governance delle metriche più sostenibile nel tempo.
L’AI integrata: stesso obiettivo, approccio diverso
Nell’articolo su SAP avevo raccontato come Joule stia portando il linguaggio naturale dentro i processi ERP e analitici — con una profondità di integrazione sui dati SAP che nessun altro può replicare, ma con i limiti di un ecosistema ancora in evoluzione.
Google ha percorso una strada diversa. Ha integrato Gemini direttamente nel motore di BigQuery, non come funzionalità aggiuntiva ma come parte dell’infrastruttura. ( https://cloud.google.com/blog/products/data-analytics/whats-new-in-the-agentic-data-cloud)
In BigQuery, Gemini genera query SQL da linguaggio naturale e con la funzionalità Data Insights analizza autonomamente un dataset suggerendo pattern rilevanti che non avevi cercato: anomalie, correlazioni, variazioni rispetto al periodo precedente. Non sostituisce l’analista, ma gli risparmia le ore di esplorazione iniziale.
In Looker, Gemini interpreta le richieste nel contesto del modello dati aziendale definito in LookML con tutte le regole di business già certificate. Non un report generico: una risposta coerente con le definizioni che l’organizzazione ha stabilito. È la stessa promessa del self-service analytics che la BI fa da vent’anni, ma stavolta con un fondamento solido sotto.
Il confronto con Joule è istruttivo: Joule conosce il dominio SAP in profondità, sa cosa è un ordine di vendita o un centro di costo. Gemini lavora su qualsiasi struttura dati con maggiore flessibilità, ma senza quella conoscenza di dominio nativa. Punti di forza diversi, non uno migliore dell’altro.
La differenza architetturale che cambia tutto
La cosa che mi ha colpito di più non è stata nessuna funzionalità specifica. È stato un principio di fondo.
Negli ambienti tradizionali esiste sempre una latenza tra il dato originale e il dato analizzato, replicato, materializzato, aggiornato a orari prestabiliti. In BigQuery i dati restano sempre nella sorgente. Ogni dashboard, ogni query, ogni risposta di Gemini attinge direttamente al dato originale, in tempo reale. Per chi usa i dati per prendere decisioni, è la differenza tra un numero certamente aggiornato e un numero che forse lo è.
