Introduzione
Presso un’importante azienda produttrice di montature per occhiali da vista e da sole, Blue BI ha gestito un progetto di migrazione sistemi da IBM Netezza a SAP HANA.
Contesto iniziale
L’azienda utilizzava diversi DWH costruiti su Netezza (IBM) a supporto della reportistica tramite la quale era possibile analizzare e governare i dati dei diversi canali di vendita (wholesale, retail ed e-commerce). Tali dati venivano esposti e analizzati tramite strumenti di front-end quali SAP BO (Business Objects) e Qlikview. Lo strumento utilizzato per gestire i dati in fase di ETL era SAP Dataservices. Il principale sistema gestionale di riferimento era SAP.
In azienda non esisteva un DWH univoco che contenesse tutti i dati di vendita, ma era presente un set di report (nello specifico, una dashboard Qlikview) che, integrando dati provenienti dai diversi canali (wholesale, retail ed e-commerce), forniva una visione globale ma molto aggregata. Le criticità presenti su tale reportistica riguardavano soprattutto l’integrazione del dato per supportare analisi cross-canale.
Obiettivi della migrazione a SAP HANA
Gli obiettivi del progetto erano molteplici:
- Abbandonare l’utilizzo del DWH Netezza e di Dataservices, sostituendoli con SAP HANA
- Utilizzare meno risorse “fisiche” e più risorse “virtuali”
- Normalizzare ove possibile il dato a livello back-end e non più a livello front-end
- Eliminare logiche obsolete dei flussi di integrazione e snellire le logiche attuali
- Migliorare la reportistica principale e altre dashboard accessorie
- Centralizzare il dato e generare reportistica cross-canale
Strategia
L’implementazione di SAP HANA, come nuova tecnologia in azienda, si conciliava con l’obiettivo di abbandonare o ridurre l’utilizzo di risorse fisiche a favore di quelle virtuali. La strategia in tal senso è stata quella di sostituire gli step fisici tipici di SAP Dataservices (workflow, dataflow, costruzione tabelle temporanee) con step virtuali tramite l’utilizzo delle Calculation Views di SAP HANA .
Per garantire la continuità nella fruizione del dato da parte degli utenti, è quindi stato scelto un approccio volto a minimizzare l’impatto sulla componente front-end, andando ad implementare delle Calculation Views che si presentassero verso i tool analitici con una struttura analoga a quella esistente su IBM Netezza.
Le nostre competenze, ci hanno consentito di rendere vincente tale strategia.
Migrazione a SAP HANA
Fase preliminare
Il progetto ha avuto una fase preliminare nel corso della quale è stato eseguito un assessment delle logiche in essere, che ha portato ad una revisione e semplificazione di alcuni step su Dataservices, nell’ottica di creare uno scenario stabile e ottimizzato dell’ambiente esistente, prima di procedere alla migrazione vera e propria.
Il risultato di questa fase è stato un successo in quanto, grazie alle nostre competenze, abbiamo ottimizzato e ottenuto miglioramenti di performance già nell’architettura corrente.
Sfruttando le nostre competenze cross-tecnologia, nella stessa ottica sono stati effettuati degli interventi di ottimizzazione anche su Qlikview, in termini di modello dati e script delle dashboard, per snellire e aggiornare le logiche di caricamento del dato, negli step generatori di file qvd proprietari di Qlik.
Primo step di migrazione
La fase successiva del progetto ha riguardato l’implementazione di SAP HANA, adottando un approccio per step successivi e concentrandosi inizialmente soltanto su alcune anagrafiche.
Sono quindi state create delle serie di Calculation Views su SAP HANA in sostituzione di flussi Dataservices che alimentavano tali anagrafiche. In alcuni casi le attività svolte sono state anche di «integrazione», oltre che di «migrazione», in quanto a più flussi Dataservices ha corrisposto un’unica Calculation View (da qui in poi CV). Ad esempio, si è ritenuto opportuno creare un’unica anagrafica articoli su SAP HANA, integrando i dati di diversi canali quali wholesale, retail ed e-commerce in modo tale da fornire un dato completo e omogeneo ai tool di analisi, evitando la necessità di gestire tali integrazioni al loro interno.
Secondo step di migrazione
Una volta completata la costruzione delle anagrafiche su SAP HANA, è stato gestito un periodo di parallelo con Netezza-Dataservices, in modo tale da consentire lo switch graduale di report e dashboard alla nuova architettura.
Lo step successivo di progetto consiste quindi nella migrazione delle tabelle dei fatti. In questo caso si è deciso, sia per questioni di performance che per esigenze di “business”, di non unire mondi tipicamente separati (wholesale, retail, e-commerce, altro…) in un’unica struttura, ma di implementare CV separate.
Performance Tuning
Al completamento dello sviluppo delle CV su HANA, è seguita un’attività di tuning delle CV SAP HANA, per migliorare le performance misurate in fase di implementazione.
In quest’ottica si sono resi necessari alcuni step di materializzazione in ambiente HANA, prestando attenzione a mantenere l’opportuno equilibrio tra consumo di memoria virtuale e consumo di memoria fisica.
La materializzazione è stata realizzata implementando alcune stored procedures e ha consentito il miglioramento notevole delle performance e al tempo stesso un minor carico di lavoro dei sistemi HANA.
Blue BI si propone sempre di individuare la soluzione ottimale anche a progetto in corso, adeguando se necessario il disegno iniziale, sulla base dei risultati rilevati in fase di test.
Questo approccio, reso possibile dalla varietà di competenze presenti in azienda, garantisce flessibilità e la possibilità di cercare sempre la soluzione migliore per puntare all’eccellenza.
Rilascio
Il rilascio in produzione della nuova architettura e il successivo reindirizzamento del presentation layer, hanno consentito la progressiva dismissione di Netezza e dei flussi di alimentazione presenti su SAP Dataservices.
Il successo di questo progetto ha dato la possibilità di definire un’architettura basata sulle nuove strutture HANA ed utilizzarla come punto di partenza per l’implementazione di nuove ulteriori analisi.
Perchè Blue BI
Le chiavi del successo del progetto sono state molteplici: Blue BI è riuscita a portare valore aggiunto e qualità trovando il giusto equilibrio nel soddisfare le diverse esigenze del cliente.
In questo progetto sono state adottate le strategie progettuali ed implementative opportune per garantire il successo della migrazione dando continuità agli strumenti di analisi presenti e garantendo al tempo stesso un miglioramento delle performance misurate ad inizio progetto.
La scelta di procedere con una migrazione graduale è stata vincente e basata sull’esperienza di Blue BI, che in ogni step ha saputo portare le singole competenze necessarie. L’approccio “divide et impera” è stato apprezzato dal cliente, che ha potuto constatare risultati positivi in ogni fase del progetto e riconoscere il valore aggiunto portato da Blue BI, sia da un punto di vista di project management per rispondere alle dinamiche dell’azienda, che da un punto di vista tecnico ed implementativo.
