Tre principi di sviluppo del data warehouse

Gartner stima che quasi il 70-80% dei progetti di business intelligence appena avviati falliscono. Ciò è dovuto a una miriade di ragioni, dalla scelta sbagliata dello strumento alla mancanza di comunicazione tra IT e stakeholder aziendali. Avendo implementato con successo progetti di BI in tutti i settori, spero di condividere le mie esperienze in questo post del blog ed evidenziare i motivi chiave per cui i progetti di business intelligence falliscono. Questo articolo presenterà le contromisure al fallimento basate su tre principi che dovrebbero governare il modo in cui vengono costruiti i data warehouse. Seguire questi concetti di data warehouse dovrebbe aiutare gli sviluppatori di data warehouse a navigare nel percorso di sviluppo evitando le buche comuni o addirittura le voragini delle implementazioni BI.

Implementazione del data warehouse di business intelligence

Sebbene i criteri per un data warehouse di business intelligence di successo varino in base al progetto, sono previsti e richiesti determinati requisiti minimi in tutti i progetti. Di seguito è riportato un elenco degli attributi principali che di solito si trovano in un data warehouse di business intelligence di successo:

• Valore: i progetti di business intelligence possono durare molti mesi o addirittura anni. Tuttavia, è importante mostrare i vantaggi di un data warehouse agli stakeholder aziendali molto presto nel progetto per garantire finanziamenti e interessi continui. Idealmente, alle parti interessate dovrebbe essere mostrato un valore commerciale significativo dal nuovo sistema entro le prime tre settimane di un progetto.
• BI self-service: i giorni di attesa dell'IT per evadere le richieste di dati o effettuare analisi dei dati sono finiti. Il successo di qualsiasi progetto di BI è ora misurato da quanto bene consente agli utenti aziendali di estrarre valore dal sistema stesso.
• Costo: i progetti di BI hanno generalmente costi di implementazione iniziali relativamente elevati. Per controbilanciare e compensare l'alto costo iniziale, è importante progettare magazzini con bassi costi di manutenzione. Se il cliente richiede un team completo di sviluppatori BI per garantire/diagnosticare problemi di qualità dei dati, apportare modifiche di routine ai modelli di dati o gestire errori ETL, il budget del sistema sarebbe costoso e rischierebbe di spegnersi dopo un po' di tempo .
• Adattabilità: la capacità di adattarsi alle esigenze aziendali in evoluzione è fondamentale. È importante tenere a mente il numero infinito di strumenti di BI disponibili sul mercato e il ritmo con cui si evolvono per includere funzionalità e funzionalità aggiuntive. Insieme al fatto che le aziende si evolvono continuamente, i requisiti per il magazzino cambieranno; l'adattabilità richiede che i data warehouse siano progettati per consentire l'uso di strumenti BI alternativi come back-end diversi o strumenti di visualizzazione in futuro e siano adattabili a cambiamenti spesso imprevisti dei requisiti.

Attraverso la mia esperienza nella creazione di soluzioni di successo e, forse ancora più importante, il coinvolgimento in progetti falliti, sono giunto alla conclusione che tre principi chiave sono fondamentali per aumentare le probabilità di un'implementazione di successo del sistema di business intelligence. Tuttavia, prima di trattarli in dettaglio, iniziamo con un po' di contesto.

Che cos'è un data warehouse?

Prima di approfondire diversi concetti di data warehouse, è importante capire che cos'è effettivamente un data warehouse.

I data warehouse sono spesso considerati sistemi di business intelligence creati per aiutare con le esigenze di reporting quotidiane di un'entità aziendale. Non hanno gli stessi requisiti di prestazioni in tempo reale (nelle implementazioni standard) dei sistemi di dati OLTP e, mentre i sistemi OLTP conterranno solo i dati relativi a un piccolo sottoinsieme dell'attività, i data warehouse cercano di comprendere tutti i dati relativi al affari .

I modelli di data warehouse offrono vantaggi a un'azienda solo quando il warehouse è considerato l'hub centrale di "tutti i dati delle cose" e non solo uno strumento attraverso il quale vengono prodotti i report operativi. Tutti i sistemi operativi dovrebbero avere una comunicazione bidirezionale con il data warehouse per alimentare i dati e ricevere feedback su come migliorare l'efficienza operativa. Qualsiasi cambiamento aziendale, come un aumento dei prezzi o una riduzione della fornitura/delle scorte, deve essere prima prototipato e previsto all'interno del tuo ambiente di data warehouse in modo che la tua azienda possa prevedere e quantificare in modo affidabile il risultato. In questo contesto, tutte le funzioni di data science e di analisi dei dati sarebbero incentrate sul data warehouse.

Esistono molti componenti di un data warehouse e non è semplicemente un database:

• Un database è un mezzo attraverso il quale memorizzi i tuoi dati.
• Un data warehouse va oltre per includere strumenti e componenti necessari per estrarre valore aziendale dai dati e può includere componenti come pipeline di integrazione, framework di qualità dei dati, strumenti di visualizzazione e persino plug-in di apprendimento automatico.

Ecco una rappresentazione più visiva della differenza tra un database e una struttura di database warehouse. I database o i nuovi meta store di dati logici come Hive formano la stella centrale del sistema stellare di un data warehouse, con tutti gli altri componenti come pianeti in rotazione. Tuttavia, a differenza di un sistema stellare, un data warehouse può avere uno o più database e questi database dovrebbero essere intercambiabili con le nuove tecnologie, come discuteremo più avanti nell'articolo.

Primo principio del data warehouse: la qualità dei dati regna sovrana

I data warehouse sono utili e preziosi solo nella misura in cui i dati all'interno sono considerati affidabili dagli stakeholder aziendali. Per garantire ciò, è necessario creare strutture che acquisiscano e correggano automaticamente (ove possibile) i problemi di qualità dei dati. La pulizia dei dati dovrebbe far parte del processo di integrazione dei dati con regolari audit dei dati o profilazione dei dati per identificare eventuali problemi di dati. Sebbene queste misure proattive vengano implementate, è necessario considerare anche misure reattive quando dati errati superano questi gate e vengono segnalati dall'utente.

Per garantire la fiducia degli utenti nel sistema di data warehouse, eventuali dati non validi evidenziati dagli utenti aziendali dovrebbero essere esaminati in via prioritaria. Per aiutare con questi sforzi, la derivazione dei dati e i quadri di controllo dei dati dovrebbero essere integrati nella piattaforma per garantire che eventuali problemi di dati possano essere identificati e risolti rapidamente dal personale di supporto. La maggior parte delle piattaforme di integrazione dei dati integra un certo grado di soluzioni per la qualità dei dati, come DQS in MS SQL Server o IDQ in Informatica.

Sfrutta queste piattaforme integrate se stai utilizzando uno strumento commerciale nelle pipeline di integrazione dei dati, ma in aggiunta o meno assicurati di creare i meccanismi che ti aiuterebbero a mantenere la qualità dei tuoi dati. Ad esempio, la maggior parte degli strumenti di integrazione dei dati non dispone di una buona funzionalità per tenere traccia della derivazione dei dati. Per superare questa limitazione, è possibile creare un framework di controllo batch personalizzato utilizzando una serie di tabelle di controllo per tenere traccia di ogni flusso di dati che si verifica all'interno del sistema.

È molto difficile riconquistare la fiducia delle parti interessate della tua attività se riscontrano una cattiva qualità all'interno della tua piattaforma, quindi l'investimento iniziale nei framework di qualità dei dati dovrebbe valere il costo.

Secondo principio del data warehouse: capovolgi il triangolo

Questa figura illustra la divisione degli sforzi nell'implementazione e nell'utilizzo della maggior parte dei data warehouse.

La maggior parte degli sforzi viene investita nella costruzione e nella manutenzione del magazzino, mentre il valore aggiunto di avere un magazzino per l'analisi aziendale è una parte molto più piccola dello sforzo. Questo è un altro motivo per cui i progetti di business intelligence spesso falliscono. A volte, ci vuole troppo tempo nel ciclo del progetto per mostrare un valore significativo al cliente e, quando il sistema è finalmente installato, è comunque necessario uno sforzo IT elevato per ricavarne un valore aziendale. Come abbiamo detto nell'introduzione, la progettazione e l'implementazione di sistemi di business intelligence può essere un processo lungo e costoso. Pertanto, le parti interessate si aspetteranno giustamente di iniziare rapidamente a raccogliere il valore aggiunto dalle loro attività di business intelligence e data warehousing. Se non si concretizza alcun valore aggiunto, o se i risultati sono semplicemente troppo tardi per avere un valore reale, non c'è molto che impedisca loro di staccare la spina.

Il secondo principio dello sviluppo del data warehouse consiste nel capovolgere il triangolo come illustrato qui.

La scelta degli strumenti di business intelligence e dei framework che metti in atto devono garantire che una parte maggiore dello sforzo destinato al magazzino sia l'estrazione del valore aziendale piuttosto che la sua creazione e manutenzione. Ciò garantirà alti livelli di coinvolgimento da parte degli stakeholder aziendali perché vedranno immediatamente il valore dell'investimento nel progetto. Ancora più importante, consenti all'azienda di essere autosufficiente nell'estrazione di valore senza avere una così forte dipendenza dall'IT.

Puoi aderire a questo principio seguendo metodologie di sviluppo incrementale durante la costruzione del magazzino per assicurarti di fornire la funzionalità di produzione il più rapidamente possibile. Seguire la strategia del data mart di Kimball o le metodologie di progettazione del data warehouse di Data Vault di Linstedt ti aiuteranno a sviluppare sistemi che si costruiscono in modo incrementale mentre tengono conto del cambiamento senza intoppi. Utilizza un livello semantico nella tua piattaforma come un cubo MS SSAS o anche un Business Objects Universe per fornire un'interfaccia aziendale di facile comprensione per i tuoi dati. Nel primo caso, fornirai anche un semplice meccanismo per consentire agli utenti di eseguire query sui dati da Excel, ancora lo strumento di analisi dei dati più popolare.

L'integrazione di strumenti di BI che promuovono la BI self-service come Tableau o PowerBI non farà altro che migliorare il coinvolgimento degli utenti, poiché l'interfaccia per eseguire query sui dati è ora drasticamente semplificata rispetto alla scrittura di SQL.

L'archiviazione dei dati di origine in un data lake prima di popolare un database aiuterà a esporre i dati di origine agli utenti molto presto nel processo di onboarding. Almeno gli utenti avanzati come Business Quants saranno ora in grado di digerire i dati di origine (attraverso i file grezzi) collegando strumenti come Hive/Impala sopra i file. Ciò contribuirà a ridurre il tempo necessario all'azienda per analizzare un nuovo punto dati da settimane a giorni o addirittura ore.

Terzo principio del magazzino di database: Plug and Play

I dati stanno per diventare l'equivalente digitale del petrolio. Negli ultimi anni abbiamo assistito a un'esplosione del numero di strumenti che possono essere utilizzati come parte di una piattaforma di data warehouse e del tasso di innovazione. A guidare la carica sono la miriade di strumenti di visualizzazione disponibili in questo momento, con opzioni avanzate per i back-end vicini. Dato questo ambiente e la propensione per i requisiti aziendali a cambiare costantemente, è importante tenere presente che è necessario sostituire i componenti del proprio stack tecnologico o addirittura introdurne/rimuoverne altri con il tempo, in base ai cambiamenti aziendali e tecnologici.

Sulla base dell'esperienza personale, sarebbe una fortuna se una piattaforma potesse durare 12 mesi senza alcun tipo di cambiamento significativo. In queste situazioni è inevitabile uno sforzo ragionevole; tuttavia, dovrebbe sempre essere possibile modificare le tecnologie o il design e la tua piattaforma dovrebbe essere progettata per soddisfare questa eventuale esigenza. Se il costo di migrazione di un magazzino è troppo alto, l'azienda potrebbe semplicemente decidere che il costo non è giustificato e abbandonare ciò che hai costruito invece di cercare di migrare la soluzione esistente a nuovi strumenti.

Costruire un sistema che soddisfi tutte le immaginabili esigenze future è impossibile. Pertanto, quando si costruiscono data warehouse è necessario un certo livello di apprezzamento per il fatto che qualsiasi cosa si progetta e si costruisce ora potrebbe essere sostituita con il tempo. A tal fine, consiglierei l'uso di strumenti e progetti generici ove possibile piuttosto che collegare strettamente la piattaforma agli strumenti su cui è in esecuzione. Naturalmente, questo deve essere fatto dopo un'attenta pianificazione e considerazione poiché il potere di molti strumenti, in particolare i database, è nella loro individualità e in stretto complemento.

Ad esempio, le prestazioni ETL sono notevolmente migliorate quando si utilizzano procedure archiviate in un database per creare nuovi dati di analisi aziendale anziché estrarre ed elaborare i dati al di fuori del database utilizzando Python o SSIS. Per quanto riguarda il livello di reporting, gli strumenti di visualizzazione offrono alcune funzionalità che non sono prontamente disponibili in altri, ad esempio Power BI supporta query MDX personalizzate, ma non Tableau. Il mio punto non è sostenere l'abbandono delle procedure archiviate o l'eliminazione dei cubi SSAS o di Tableau nei tuoi sistemi. La mia intenzione è semplicemente quella di promuovere l'importanza di essere consapevoli nel giustificare qualsiasi decisione di accoppiare strettamente la tua piattaforma ai suoi strumenti.

Un'altra potenziale voragine è nello strato di integrazione. È molto facile utilizzare uno strumento come SSIS per l'integrazione dei dati grazie alle sue capacità di debug o alla facilità d'uso con la piattaforma SQL Server. Tuttavia, la migrazione di centinaia di pacchetti SSIS a un altro strumento diventerebbe un progetto molto costoso. Nei casi in cui stai principalmente facendo "EL", cerca di utilizzare uno strumento generico per eseguire l'elaborazione. L'uso di un linguaggio di programmazione come Python o Java per scrivere un caricatore generico per caricare il livello di staging aiuterà a ridurre i singoli pacchetti SSIS che avresti altrimenti richiesto. Questo approccio non solo aiuta a ridurre i costi di manutenzione e di migrazione futura, ma aiuta anche ad automatizzare più aspetti del processo di onboarding dei dati senza dover scrivere nuovi pacchetti individuali (in linea con il Principio 2).

In tutti questi casi, è necessario decidere un compromesso pratico tra i vantaggi immediati e i costi di migrazione futuri per garantire che il magazzino non venga scartato perché non può gestire il cambiamento o perché il cambiamento avrebbe richiesto troppo tempo, sforzo o investimento.

Avvolgendo

Ci sono molte ragioni per cui un determinato sistema di business intelligence potrebbe non funzionare e ci sono anche alcune sviste comuni che possono portare a un eventuale fallimento. Il panorama tecnologico in continua evoluzione, il budget limitato per i sistemi di dati a causa di una priorità secondaria errata rispetto ai sistemi operativi e l'assoluta complessità e difficoltà di lavorare con i dati significano che è necessario considerare attentamente non solo gli obiettivi immediati ma anche i piani futuri durante la progettazione e costruire i componenti di un data warehouse.

I fondamenti del data warehousing descritti in questo articolo hanno lo scopo di guidare l'utente quando si effettuano queste importanti considerazioni. Naturalmente, prendere in considerazione questi principi non garantisce il successo, ma sicuramente faranno molto per aiutarti a evitare il fallimento.