ARCHIVIO DATI CENTRALE : STORIA ED EVOLUZIONI
I due temi dominanti della corporate technology negli anni 90 sono stati i data warehouse e l’ERP. Per molto tempo queste due potenti correnti sono state parti della corporate IT senza mai avere intersezioni. Era quasi come se fossero materia ed anti-materia. Ma la crescita di entrambi i fenomeni ha portato inevitabilmente a una loro intersezione. Oggi le aziende stanno affrontando il problema di che cosa fare con ERP e data warehouse. Questo articolo illustrerà quali sono i problemi e come vengono affrontati dalle aziende .
ALL’INIZIO…
All’inizio c’era il data warehouse. Data warehouse è nato per contrastare il sistema applicativo di elaborazione delle transazioni. Nei primi tempi la memorizzazione dei dati era pensata per essere solo un contrappunto alle applicazioni di elaborazione delle transazioni. Ma al giorno d’oggi ci sono visioni molto più sofisticate di quello che può fare un data warehouse. Nel mondo odierno il data warehouse è inserito all’interno di una struttura che può essere chiamata Corporate Information Factory.
LA CORPORATE INFORMATION FACTORY (CIF)
La Corporate Information Factory ha dei componenti architetturali standard: un livello di trasformazione e di integrazione del codice che integra i dati mentre i dati si muovono dall’ambiente di applicazione verso l’ambiente del data warehouse dell’impresa; un data warehouse dell’azienda dove vengono memorizzati i dati storici dettagliati e integrati. Il data warehouse dell’azienda serve da fondamento sul quale possono essere costruite tutte le altre parti dell’ambiente del data warehouse; un operational data store (ODS). Un ODS è una struttura ibrida che contiene alcuni aspetti del data warehouse e altri aspetti di un ambiente OLTP; data marts, in cui i differenti reparti possono avere loro propria versione del data warehouse; un data warehouse di esplorazione in cui i “filosofi”(thinkers) dell’azienda possono presentare le loro queries di 72 ore senza effetto nocivo sul data warehouse; e una memoria near line, in cui dati vecchi e dati bulk detail possono essere memorizzati a buon mercato.
DOVE SI UNISCE L’ERP CON LA CORPORATE INFORMATION FACTORY
L’ERP si unisce con la Corporate Information Factory in due punti. Innanzitutto come un’applicazione di base (baseline) che fornisce i dati dell’applicazione al data warehouse. In questo caso i dati, generati come sottoprodotto di un processo di transazione, vengono integrati e caricati nel data warehouse dell’azienda. Il secondo punto di unione tra ERP e CIF e l’ODS. In effetti, in molti ambienti l’ERP è utilizzato come un ODS classico.
Nel caso in cui ERP è utilizzato come applicazione di base, lo stesso ERP può essere anche utilizzato nella CIF come ODS. In ogni caso, se l’ERP deve essere utilizzato in entrambi i ruoli, ci deve essere una netta distinzione tra le due entità. In altre parole, quando l’ERP svolge il ruolo di applicazione di base e di ODS, le due entità architetturali devono essere distinte. Se una singola implementazione di un ERP prova a svolgere entrambi i ruoli contemporaneamente ci saranno inevitabilmente dei problemi nella progettazione e nell’implementazione di tale struttura.
SEPARARE ODS E APPLICAZIONI DI BASE
Ci sono molte ragioni che portano alla divisione dei componenti architetturali. Forse la questione più eloquente per separare i diversi componenti di un’architettura è che ogni componente dell’architettura ha la propria vista. L’applicazione baseline serve per uno scopo differente di quello dell’ODS. Provare a sovrapporre
una vista di applicazione baseline sul mondo di un ODS o viceversa non è un modo giusto di lavorare.
Di conseguenza, il primo problema di un ERP nella CIF è quello di verificare se c’è una distinzione fra le applicazioni baseline ed il ODS.
DATA MODELS NELLA CORPORATE INFORMATION FACTORY
Per realizzare una coesione fra i differenti componenti dell’architettura della CIF, ci deve essere un modello di dati. I modelli di dati servono da legame tra i vari componenti dell’architettura come ad esempio le applicazioni baseline e l’ODS. I modelli di dati diventano la “carta stradale intellettuale” per avere il giusto significato dai differenti componenti architettonici della CIF.
Andando di pari passo con questa nozione, l’idea è che ci dovrebbe essere un grande e unico modello di dati. Ovviamente ci deve essere un modello di dati per ciascuno dei componenti e inoltre ci deve essere un percorso sensato che collega i modelli differenti. Ogni componente dell’architettura – ODS, applicazioni baseline, data warehouse dell’azienda, e così via.. – necessita del proprio modello di dati. E quindi ci deve essere una definizione precisa di come questi modelli di dati si interfacciano a vicenda.
SPOSTARE I DATI DELL’ERP NEL DATA WAREHOUSE
Se l’origine dei dati è un’applicazione baseline e/o un ODS, quando l’ERP inserisce i dati nel data warehouse, tale inserimento deve avvenire al più basso livello di “granularity”. Ricapitolare o aggregare semplicemente i dati così come vengono fuori dall’applicazione baseline dell’ERP o dall’ODS dell’ERP non è la cosa giusta da fare. I dati dettagliati sono necessari nel data warehouse per costituire le basi del processo di DSS. Tali dati saranno rimodellati in molti modi dai data marts e dalle esplorazioni del data warehouse.
Lo spostamento dei dati dall’ambiente dell’applicazione baseline dell’ERP all’ambiente del data warehouse dell’azienda è fatto in un modo ragionevolmente disteso. Tale spostamento accade dopo che circa 24 ore dall’aggiornamento o dalla creazione nel ERP. Il fatto di avere un movimento “pigro” dei dati nel data warehouse dell’azienda permette ai dati provenienti dall’ERP di “depositarsi”. Una volta che i dati sono depositati nell’applicazione baseline, allora è possibile spostare in modo sicuro i dati dell’ERP nell’impresa. Un altro obiettivo raggiungibile grazie al movimento “pigro” dei dati è la chiara delimitazione fra processi operazionali e DSS. Con un movimento “veloce” dei dati la linea di demarcazione tra DSS e operazionale rimane vaga.
Il movimento dei dati dall’ODS dell’ERP al data warehouse dell’azienda viene fatto periodicamente, solitamente settimanalmente o mensilmente. In questo caso il movimento dei dati è basato sulla necessità di “pulire” i vecchi dati storici. Naturalmente, l’ODS contiene i dati che sono molto più recenti rispetto ai dati storici trovati nel data warehouse.
Lo spostamento dei dati nel data warehouse non è quasi mai fatto “all’ingrosso” (in a wholesaler manner). Copiare una tabella dall’ambiente ERP al data warehouse non ha senso. Un approccio molto più realistico è lo spostamento di unità selezionate dei dati. Solo i dati che sono cambiati dall’ultimo aggiornamento del data warehouse sono quelli che dovrebbero essere spostati nel data warehouse. Un modo per sapere quali dati sono stati modificati dall’ultimo aggiornamento è quello di guardare i timestamp dei dati trovati nell’ambiente ERP. Il progettista seleziona tutti i cambiamenti che si sono presentati dall’ultimo aggiornamento. Un altro approccio è quello di usare tecniche di acquisizione di cambiamento dati. Con queste tecniche vengono analizzati log e journal tapes in modo da determinare quali dati devono essere spostati dall’ambiente ERP a quello del data warehouse. Queste tecniche sono le migliori in quanto i log e i journal tapes possono essere letti dai file dell’ERP senza ulteriori effetti sulle altre risorse dell’ERP.
ALTRE COMPLICAZIONI
Uno dei problemi dell’ERP nella CIF è quello che accade ad altre fonti dell’applicazione o ai dati dell’ODS che devono contribuire al data warehouse ma non fanno parte dell’ambiente di ERP. Data la natura chiusa dell’ERP, specialmente SAP, il tentativo di integrare le chiavi dalle fonti esterne dei dati con i dati che vengono dall’ERP al momento di spostare i dati nel data warehouse, è una grande sfida. E quante sono esattamente le probabilità che i dati di applicazioni o ODS al di fuori dell’ambiente ERP saranno integrati nel data warehouse? Le probabilità sono effettivamente molto alte.
REPERIRE DATI STORICI DALL’ERP
Un altro problema con i dati dell’ERP è quello derivante dall’esigenza di avere dati storici all’interno del data warehouse. Solitamente il data warehouse ha bisogno di dati storici. E solitamente la tecnologia dell’ERP non memorizza questi dati storici, almeno non fino al punto in cui è necessario nel data warehouse. Quando una grande quantità di dati storici comincia ad aggiungersi nell’ambiente di ERP, tale ambiente deve essere ripulito. Per esempio si supponga che un data warehouse debba essere caricato con cinque anni di dati storici mentre l’ERP tiene al massimo sei mesi di questi dati. Finché la società è soddisfatta di raccogliere una serie di dati storici man mano che passa il tempo, allora non ci sono problemi nell’utilizzare l’ERP come sorgente per il data warehouse. Ma quando il data warehouse deve andare indietro nel tempo e prendere dei dati storici che non sono stati precedentemente raccolti e salvati dall’ERP, allora l’ambiente ERP diventa inefficiente.
ERP E METADATI
Un’altra considerazione da fare su ERP e data warehouse è quella sui metadati esistenti nell’ambiente ERP. Così come i metadati passano dall’ambiente ERP all’ambiente del data warehouse, i metadati devono essere spostati nello stesso modo. Inoltre, i metadati devono essere trasformati nel formato e nella struttura richiesti dall’infrastruttura del data warehouse. C’è una grande differenza tra metadati operazionali e metadati DSS. I metadati operazionali sono soprattutto per lo sviluppatore e per il
programmatore. I metadato DSS sono principalmente per l’utente finale. I metadati esistenti nelle applicazioni ERP o negli ODS devono essere convertiti e questa conversione non è sempre facile e diretta.
SOURCING THE ERP DATA
Se l’ERP è usato come fornitore di dati per il data warehouse ci deve essere una solida interfaccia che sposta i dati dall’ambiente ERP all’ambiente data warehouse. L’interfaccia deve:
- ▪ essere facile da usare
- ▪ permettere l’accesso ai dati dell’ERP
- ▪ prelevare il significato dei dati che stanno per essere spostati nel data warehouse
- ▪ conoscere le limitazioni dell’ERP che potrebbero nascere nel momento in cui viene effettuato l’accesso ai dati dell’ERP:
- ▪ integrità referenziale
- ▪ relazioni gerarchiche
- ▪ relazioni logiche implicite
- ▪ convenzione dell’applicazione
- ▪ tutte le strutture dei dati supportate dall’ERP, e così via…
- ▪ essere efficiente nell’accesso ai dati, fornendo:
- ▪ movimento diretto dei dati
- ▪ acquisizione di cambiamento dati
- ▪ essere di appoggio all’accesso tempestivo ai dati
- ▪ capire il formato dei dati, e così via… INTERFACCIARSI CON SAP L’interfaccia può essere di due tipi, homegrown o commerciale. Alcune delle principali interfacce commerciali includono:
- ▪ SAS
- ▪ Prims Solutions
- ▪ D2k, e così via… TECNOLOGIE DI ERP MULTIPLI Trattare l’ambiente ERP come se fosse un’unica tecnologia è un grosso errore. Ci sono molte tecnologie di ERP, ognuna con i suoi punti di forza. I vendor più conosciuti nel mercato sono:
- ▪ SAP
- ▪ Oracle Financials
- ▪ PeopleSoft
- ▪ JD Edwards
- ▪ Baan SAP SAP è il software di ERP più grande e più completo. Le applicazioni di SAP comprendono molti tipi di applicazioni in molte aree. SAP ha la reputazione di essere:
- ▪ molto grande
- ▪ molto difficile e costoso da implementare
- ▪ ha bisogno di molte persone e consulenti per essere implementato
- ▪ necessita di persone specializzate per l’implementazione
- ▪ ha bisogno di molto tempo per essere implementato Inoltre SAP ha la reputazione di memorizzare i suoi dati molto attentamente, rendendo difficile accedere a questi da parte di una persona esterna all’area SAP. La forza di SAP è quella di essere capace di catturare e memorizzare una grande quantità di dati. Recentemente SAP ha annunciato la sua intenzione di estendere le sue applicazioni ai data warehouse. Ci sono molti pro e contro nell’utilizzo di SAP come fornitore di data warehouse. Un vantaggio è che SAP è già installato e che la maggior parte dei consulenti già conosce SAP.
Gli svantaggi di avere SAP come fornitore di data warehouse sono molti: SAP non ha esperienza nel mondo del data warehouse Se SAP è il fornitore di data warehouse, è necessario “portare fuori” i dati da SAP al data warehouse. Dato un SAP’s track record of closed system, è improbabile che sia facile ottenere i da SAP in esso (???). Ci sono molti legacy environment che alimentano SAP, come IMS, VSAM, ADABAS, ORACLE, DB2, e così via. SAP insiste in un approccio “not invented here”. SAP non vuole collaborare con altri fornitori per usare o creare il data warehouse. SAP insiste nel voler generare tutto il proprio software da solo.
Sebbene SAP sia una compagnia grande e potente, il fatto di tentare di riscrivere la tecnologia di ELT, OLAP, amministrazione del sistema e persino il codice di base del dbms è semplicemente folle. Invece di assumere un atteggiamento di cooperazione con i fornitori di data warehouse di vecchia data, SAP ha seguito l’approccio che loro “ne sanno di più”. Questo atteggiamento frena il successo che SAP potrebbe avere nell’area dei data warehouse.
Il rifiuto di SAP nel permettere ai fornitori esterni di accedere prontamente e con garbo ai loro dati. L’essenza stessa dell’uso di un data warehouse è l’accesso facile ai dati. L’intera storia di SAP è basata sul rendere difficile l’accesso ai dati.
La mancanza di esperienza di SAP nel trattare grandi volumi di dati; nel campo dei data warehouse esistono volumi di dati mai visti da SAP e per gestire queste grandi quantità di dati occorre avere una tecnologia adatta. SAP apparentemente non è informata di questa barriera tecnologica che esiste per entrare nel campo dei data warehouse.
La corporate culture di SAP: SAP ha creato un business nell’ottenere i dati dal sistema. Ma per fare questo bisogna avere una mentalità differente. Traditionally, software companies that were good at getting data into an environment have not been good at getting data to go the other way. Se SAP r