Articoli del meseArticoli del mese

Articoli del mese


Stampa articolo

Articolo del Mese - Ottobre 2006

Managed Meta Data Environment (II parte)

David Marco by David Marco

Il livello di integrazione dei meta-dati

Il livello d'integrazione dei meta-dati (Figura 6) accede alle diverse fonti di meta-dati, li integra e li carica nel repository dei meta-dati stessi. Questo approccio differisce leggermente dalle tecniche più comuni usate per caricare i dati all'interno di un data warehouse, poiché quest'ultimo separa nettamente il processo di trasformazione (che noi chiamiamo integrazione) da quello di caricamento. In un MME le due fasi sono combinate perché, in quest'ultimo, il volume dei meta-dati è molto diverso da quello dei dati di un data warehouse. Come regola generale, l'MME mantiene da 5 a 20 gigabyte di meta-dati; tuttavia, poiché gli MME stanno cercando di indirizzare anche meta-dati relativi alla verifica dei meta-dati già contenuti, la memoria necessaria può crescere nel range dei 20-75 gigabite ed entro i prossimi cinque anni vedremo che alcuni MME raggiungeranno l'ordine dei terabyte.

 

Le fasi specifiche all'interno di questo processo dipendono dal fatto che stiate costruendo un processo personalizzato oppure che utilizziate uno strumento di integrazione dei meta-dati per assistervi in tale compito. Se decidete di usare uno strumento di integrazione dei meta-dati, la scelta di quest'ultimo impatterà grandemente sull'intero processo.

Repository dei meta-dati

Repository dei meta-dati è una definizione forse non molto chiara per un database progettato per raccogliere, mantenere e distribuire meta-dati. Il repository dei meta-dati (Figura 7) è responsabile per la catalogazione e memorizzazione durevole dei meta-dati

 

 

Il repository dei meta-dati deve essere generico, integrato, aggiornato e storico. Generico significa che il modello dei meta-dati mira a memorizzare i meta dati ordinati per soggetto, invece che specificatamente per le applicazioni. Ad esempio, un meta-modello generico avrà un attributo denominato "DATABASE_PHYS_NAME" che conterrà i nominativi dei database fisici esistenti all'interno dell'impresa. Un meta-modello specifico per un'applicazione indicherà il medesimo attributo come, ad esempio, "ORACLE_PHYS_NAME". Il problema con i meta-modelli specifici per le applicazioni è che le aree dei soggetti di riferimento dei meta-dati possono cambiare. Per tornare al nostro esempio, oggi Oracle potrebbe essere il nostro database standard. Domani, invece, potremmo passare ad un Server SQL come nuovo standard, ritenuto più vantaggioso in termini di costo e di compatibilità. Questa situazione causerebbe modifiche addizionali al meta-modello fisico, altrimenti non necessarie.[1]

Un repository dei meta-dati fornisce anche una visione integrata delle maggiori aree dei soggetti relativi ai meta-dati dell'impresa. Il repository consentirà agli utenti di vedere tutte le entità esistenti all'interno di quest'ultima e non solamente quelle caricate in Oracle, oppure quelle che si trovano unicamente nelle applicazioni CRM (Customer Relationship Management).

In terzo luogo, il repository dei meta-dati contiene i meta-dati attuali e quelli che verranno aggiunti in futuro. Questo significa che i meta-dati vengono aggiornati periodicamente per riflettere gli ambienti tecnici e di business attuali e futuri. Ricordate che il repository dei meta-dati deve essere necessariamente aggiornato per mantenere il suo valore reale.

Infine, i repository dei meta-dati hanno un grande valore storico. Un buon repository manterrà la visione storica dei meta-dati anche se questi si modificano nel tempo. Questo consente all?impresa di mantenere la conoscenza dell'evoluzione della propria attività nel tempo.Si tratta di un aspetto specialmente critico se l'ambiente MME supporta un'applicazione che contiene dati storici, come un data warehouse o un'applicazione CRM. Ad esempio, supponiamo che la definizione di "cliente" per un meta-dato di business sia "chiunque abbia comprato un prodotto della nostra società in uno dei nostri negozi o direttamente dal nostro catalogo". Un anno dopo, la società aggiunge un nuovo canale di distribuzione. La società costruisce un sito web per consentire ai clienti di ordinare direttamente i prodotti. A questo punto, la definizione del meta-dato che indica il cliente sarà modificata in "chiunque abbia comprato un prodotto della nostra società in uno dei nostri negozi, tramite ordine postale dal catalogo o tramite il web". Un buon repository dei meta-dati mantiene entrambe queste definizioni perché sono tutte e due valide, in base a quali dati verranno analizzati (oltre che in base alla loro età). Per concludere, si raccomanda fortemente di implementare il proprio repository di meta-dati su di una piattaforma di database relazionale aperto, invece di utilizzare un database proprietario.

Livello di gestione dei meta-dati

Il livello di gestione dei meta-dati fornisce una gestione sistematica del repository dei meta-dati e degli altri componenti MME (vedi Figura 8). Come per gli altri livelli, l'approccio a questo componente differisce notevolmente nel caso in cui lo strumento di integrazione dei meta-dati utilizzato per l'intero ambiente MME sia di tipo proprietario. Se uno strumento di integrazione dei meta-dati dell'impresa viene usato per la costruzione dell'MME, allora l'interfaccia di gestione dei meta-dati è verosimilmente inserita all'interno del prodotto. Questo non avviene quasi mai; tuttavia, se non è costruito all'interno del prodotto, allora dovrete realizzarlo in casa. Il livello di gestione dei meta-dati assicura le seguenti funzioni:

· Archivio

· Backup

· Modifiche del Database

· Messa a punto del Database

· Gestione dell'ambiente

· Schedulazione delle attività

· Statistiche di carico del sistema

· Depurazione dei dati

· Statistiche delle interrogazioni

· Generazione di interrogazioni e di report

· Recovery

· Processi di security

· Mappatura e movimentazione delle fonti

· Gestione dell'interfaccia utente

· Gestione delle versioni

[1] Per vedere diversi modelli di meta-dati fisici, vedi Capitoli 4 - 8 di "Universal Meta Data Models" (David Marco & Michael Jennings, Wiley 2004)

Archivio

La funzione Archivio consente all'architetto dei meta-dati di stabilire il criterio o l'evento che attiva il processo di archiviazione all'interno dell'MME. Tale funzione deve essere in grado di archiviare tutti i meta-dati all'interno del loro repository e dei data mart collegati, oltre a consentire l'archiviazione, quando necessario, di tabelle di meta-dati specifiche.

Backup

La funzione di backup spesso viene confusa con l'archiviazione. L'archiviazione riguarda la memorizzazione delle versioni più vecchie e meno utilizzate dell'MME, mentre il backup è il processo che assicura la memorizzazione dell'MME corrente in un database separato, in modo che se la versione dell'MME in produzione risulta errata oppure un suo componente non opera correttamente, una versione di backup possa essere attivata immediatamente on line. Spesso, la strategia di backup viene implementata al livello dell'hardware mediante la duplicazione (mirroring) dei dischi. Le migliori pratiche in quest'area comprendono la memorizzazione della copia di backup in una locazione fisica diversa da quella dell'MME in produzione.

Modifiche al database

Dal momento che il meta-modello è implementato in un database aperto e relazionale, spesso le tabelle e le colonne di dati all'interno del meta-modello debbono essere modificate o cancellate. Il livello di gestione dei meta-dati ha bisogno non solamente di assistenza in questo processo, ma anche di riconoscere i cambiamenti effettuati nell'MME.

Messa a punto del database

La messa a punto del repository dei meta-dati e dei data mart associati rappresenta una parte molto importante nell'ambito del livello di gestione dei meta-dati. In primo luogo, l'identificazione degli indici assicura che i report siano prodotti in maniera efficiente. Nell'analizzare le strutture del meta-modello fisico, normalmente vengono esaminati gli indici come chiavi di accesso primarie. Questo è segno di una strategia di indicizzazione inadeguata o mancante.

In secondo luogo, la messa a punto del database vi aiuta a identificare i meta-dati dormienti all?interno del repository. Un MME di grandi dimensioni, in uso anche da pochi anni, normalmente contiene una larga parte di meta-dati dormienti. Un MME ottimizzato conterrà i meta-dati che consentono le misurazioni statistiche operative sull?uso dei meta-dati nell'ambito dell'MME, in modo da permettere l'identificazione dei meta-dati inutilizzati da tempo.

Gestione dell'ambiente

Molti specialisti dei meta-dati commettono l'errore di credere che quando implementano un MME, stiano implementando e mantenendo un solo sistema. In verità, stanno costruendo e mantenendo tre (o forse più) sistemi:

  • Produzione
  • Test
  • Sviluppo

La versione di produzione dell'MME è il sistema definibile come ambiente di produzione? di un'organizzazione, oltre ad essere la versione dell'MME cui hanno accesso gli utenti finali. L?ambiente di test è la versione utilizzata per verificare la correzione dei "bachi" di sistema trovati nella versione di produzione dell'MME. La versione di sviluppo dell'MME è utilizzata per sottoporre a test i futuri e maggiori miglioramenti dell'MME.

La definizione e le dimensioni degli ambienti MME sono diversi a seconda degli standard IT interni all'organizzazione; tuttavia, i tre ambienti menzionati sopra sono i più comuni. In ogni evento, un livello di gestione dei meta-dati può gestire un numero qualsiasi di ambienti e nomi, in base alle necessità dell'organizzazione. La porzione di gestione dell'ambiente del livello di gestione dei meta-dati ha comunque bisogno di organizzare e controllare la gestione e la migrazione dei dati tra queste tre versioni di sistema.

Schedulazione delle attività

Le attività relative ai programmi ed ai processi necessari che debbono essere eseguiti per caricare l'MME e per accedere ai meta-dati contenuti debbono essere schedulate e gestite. La porzione dedicata a questa funzione del livello di gestione dei meta-dati è responsabile della loro schedulazione sia in relazione al verificarsi di determinati eventi che in termini di attivazione di elaborazioni batch.

Statistiche di carico del sistema

I livelli di estrazione e di integrazione dei meta-dati dell'MME generano un gran numero di interessanti statistiche relative al carico di lavoro del sistema. Queste statistiche di carico dell?MME debbono essere conservate nella sezione storica all'interno della porzione dell'MME definita come repository. Alcuni esempi delle statistiche di carico più comuni comprendono:

  • Quanto tempo di elaborazione assorbe un particolare passo di un processo (tempo di clock oppure di CPU)?
  • Quanto tempo viene impiegato complessivamente dalle elaborazioni relative ai livelli di estrazione e di integrazione dei meta-dati (sia clock che CPU)?
  • Quali errori sono stati incontrati nell'ambito dei livelli di estrazione e di integrazione dei meta-dati?
  • Quali erano le categorie di errori rilevati (ad es., di informazione, di allerta, gravi, critici, ecc.)
  • Quante righe sono state inserite, modificate o cancellate in ciascuna tabella del meta-modello?

Depurazione dei dati

Questa parte del livello di gestione dei dati definisce I criteri relativi alle necessità di depurazione dei dati. I vostri criteri e necessità specifiche di depurazione dei dati saranno governati dalle necessità dell'impresa. Come regola generale, un meta-dato che risulti non corretto o caricato erroneamente deve essere eliminato; tutti gli altri meta-dati debbono essere archiviati.

Statistiche delle interrogazioni

Una volta generati i vari report relativi al livello di consegna dei meta-dati, è importante ottenere le statistiche associate all'accesso a questi report e interrogazioni da parte degli utenti. Come minimo, il livello di gestione dei meta-dati deve poter accedere ai seguenti dati storici:

  • Chi ha avuto accesso al report o all'interrogazione?
  • Quali report o interrogazioni sono stati interessati?
  • Quando è avvenuto l'accesso al report o all'interrogazione?
  • Con quale frequenza avvengono gli accessi al report o all?interrogazione
  • Quanto dura l'accesso al report o all'interrogazione?

Generazione di interrogazioni e di report

I report e le interrogazioni utilizzate nell'ambito del livello di consegna dei meta-dati sono definiti e generati nella sezione di generazione dei report, all'interno del livello di gestione dei meta-dati. Come questo avvenga dipende dal fatto che sia stato implementato uno strumento di accesso ai meta-dati oppure che sia stata sviluppate un'applicazione proprietaria di consegna dei meta-dati agli utenti. Questo componente deve anche gestire qualunque funzione di pubblicazione o di sottoscrizione che venga richiesta.

Recovery

Esistono molte situazioni che possono costringere un'impresa a un'azione di ripristino e ricaricamento di una versione precedente del proprio MME: ad es.,malfunzioni hardware, errori nel database, black out elettrici o errori all'interno del livello di gestione dei meta-dati. Il processo di recovery deve essere strettamente collegato alle funzioni di backup e di archiviazione del livello di gestione dei meta-dati. I processi di recovery possono essere realizzati ad hoc oppure possono utilizzare quelli già predisposti all'interno degli strumenti di integrazione dei meta-dati. Entrambi gli approcci debbono essere integrati all'interno delle applicazioni relative ai processi di recovery già esistenti nell'organizzazione

Processi di security

I processi di security gestiscono:

  • Creazione di nuovi utenti dell?MME
  • Raggruppamento degli utenti dell?MME
  • Registrazione dei privilegi e dei profili degli utenti dell?MME
  • Firewall/Infrastruttura
  • Gestione delle password
  • Verifica della locazione degli utenti
  • Mascheramento dei meta-dati (livello dati o livello di accesso)

L'estensione dei processi di security dipende dalle necessità dell'impresa che ha realizzato l?MME. Ad esempio, le necessità di sicurezza degli MME del Dipartimento della Difesa oppure del Federal Bureau of Investigation (FBI) sono sicuramente maggiori di quelle di una banca.

Mappatura e movimentazione delle fonti

Le fonti di meta-dati debbono essere mappate con i corretti attributi ed entità del repository dei meta-dati. Questo processo di mappatura e movimentazione deve essere inserito e gestito nell?ambito del livello di gestione dei meta-dati dell'MME.

Gestione dell'interfaccia utente

Questo è il processo che consente di costruire, gestire e mantenere il sito Web (ovvero l?interfaccia utente raccomandata), che l'utente finale visiterà navigando all'interno dell'MME. Tipicamente, la schermata (versione del sito Web) che viene presentata all'utente dipende dal suo profilo e dai suoi privilegi di security. Un utente generico dell'impresa non sarà interessato a vedere le modifiche delle codifica dei programmi, per cui avrà senso non presentargli report o interrogazioni relativi meta-dati di valore esclusivamente tecnico, in base a un corretto controllo del suo ruolo aziendale.

Gestione delle versioni

Nel momento in cui un meta-dato venga modificato, aggiunto o cancellato è importante per il livello di gestione dei meta-dati mantenere una traccia storica (definita versione) del suo cambiamento di stato. Esistono due tecniche usate comunemente per mantenere traccia delle versioni dei meta-dati. La prima è basata sull'utilizzo della data. In altri termini, ad ogni riga di entità del vostro modello di meta-dati viene assegnata una data, in modo che in caso di modifiche successive si possa sempre risalire al dato storico.

La seconda tecnica consiste invece nell'assegnare un numero progressivo di versione ad ogni riga del modello dei meta-dati. I numeri di versione sono dei valori univoci (ad es., 1.1, 1.2, 1.a, ecc.). I numeri di versioni sono più limitativi delle date, che offrono una migliore visibilità agli utenti dell'MME. Per altro, i numeri di versione possono essere associati a date e valori temporali specifici, una soluzione che però aggiunge ulteriore complessità al caricamento dei meta-dati e un'aggiunta di carico negli accessi per richieste di dati o elaborazione di report.

Un'altra opportunità offerta dalla gestione delle versioni è la cattura di meta-dati che debbano essere inseriti nell'MME in un determinato momento futuro. Ad esempio, una nuova tabella fisica può essere spostata nell'ambiente di produzione in una data futura. Per gestire queste situazioni di cambiamento delle versioni, può risultare utile l'uso delle "righe con data effettiva". Le righe con data effettiva costituiscono un processo che consente di inserire i dati in un gruppo (tabella) per una elaborazione successiva allo scadere della data indicata. I dati di questo tipo possono essere storici, attuali o futuri. Qui sotto elenchiamo i concetti fondamentali relativi alle righe con data:

Data effettiva. La data alla quale la riga di meta-dati diviene effettiva; la data in cui può essere sottoposta a elaborazione.

Stato effettivo. Consente a un'applicazione di selezionare le righe con le data effettive, in corrispondenza dello scadere della data effettiva (lista dei valori: "attivo" oppure "inattivo").

Riga corrente.La prima riga di dati con una data effettiva uguale o minore della data di sistema e con uno stato effettivo "attivo". Solo una riga può trovarsi in questo stato.

Riga futura. Righe di meta-dati che posseggono una data futura rispetto a quella del sistema.

Riga storica. Righe di meta-dati che hanno una data effettiva minore di quella della riga corrente.

La Tabella 1 illustra la tecnica delle righe con data effettiva. In questo esempio, la data corrente del sistema è il 20 gennaio 2004. La riga di meta-dati datata "27.01.2004" ha uno stato effettivo di "inattivo". Tuttavia, quando la data corrente del sistema diverrà il 27 gennaio 2004, allora la riga di meta-dati datata "18.01.2004" diventerà una riga storica e la riga datata "27.01.2004" vedrà cambiare il proprio stato effettivo da "inattivo" ad "attivo".

data effettiva

Stato effettivo

Commenti allo stato effettivo

01.12.2003 12:00:00

Attivo

Riga storica

18.01.2004 12:00:00

Attivo

Riga corrente

27.01.2004 12:00:00

Inattivo

Riga futura

Tabella 1: Righe con le rispettive date effettive

I mart di meta-dati

Un mart di meta-dati è una struttura di database, normalmente derivante da un repository di meta-dati, progettata ad uso di un gruppo omogeneo di utenti dei meta-dati (vedi Figura 9). ?Gruppo omogeneo di utenti dei meta-dati? è una definizione generica di un gruppo di utenti che abbia necessità simili.

Esistono due ragioni che spiegano perché un MME debba avere una serie di mart di meta-dati. In primo luogo, una particolare comunità di utenti può richiedere che i meta-dati di proprio interesse siano organizzati in maniera diversa rispetto a quanto previsto per i componenti del repository dei meta-dati. In secondo luogo, un MME con una base di utenti estesa spesso è affetto da problemi di performance a causa del gran numero di collegamenti tra le tabelle, richieste per i report dei meta-dati. In queste situazioni, la cosa migliore è creare una serie di mart di meta-dati orientati specificatamente a soddisfare le esigenze dei diversi gruppi di utenti. I mart di meta-dati non avranno problemi di degrado delle performance perché saranno modellati in maniera multidimensionale. In aggiunta, un meta-mart separato fornisce un livello di buffer tra gli utenti finali e il repository dei meta-dati. Questo consente la manutenzione di routine, gli aggiornamenti, il backup e la recovery del repository senza impattare la disponibilità del mart dei meta-dati.

Il livello di consegna dei meta-dati

Il livello di consegna dei meta-dati è il sesto ed ultimo componente dell'architettura MME. Consegna i meta-dati agli utenti a partire dal repository dei meta-dati e alimenta ogni applicazione o strumento autorizzati alla richiesta di meta-dati (Figura 10).[1]

[1] Vedi il Capitolo 10 di "Building and Managing the Meta Data Repository" (David Marco, Wiley 2000) per una discussione dettagliata sui consumatori di meta-dati e sui problemi della loro consegna.

Le situazioni più comuni di richiesta di meta-dati a partire da un MME riguardano:

  • Applicazioni
  • Data warehouse e data mart
  • Utenti finali (business o tecnici)
  • Messaggi e transazioni
  • Mart di meta-dati
  • Strumenti software
  • Terze parti
  • Siti Web ed e-commerce

Applicazioni

Abbastanza spesso le applicazioni di tipo CRM (Customer relationship management), ERP (Enterprise resource planning) e altre debbono ricevere meta-dati dall?MME per le loro elaborazioni. In queste situazioni, normalmente viene creato un file di estrazione dal repository dei meta dati che viene reso disponibile per l'applicazione che viene reso disponibile per l?applicazione che lo abbia richiesto. Tipicamente, il repository genererà un semplice file all?interno di un'area di parcheggio, che verrà poi letto dall'applicazione quando ne avrà bisogno.

Data warehouse e data mart

Il livello di consegna dei meta-dati del data warehouse e dei data mart associati (normalmente le interrogazioni e i report vengono elaborati al livello dei data mart) è separato dalle applicazioni a causa di una sottile differenza nell'uso dei meta-dati. La Figura 11 mostra il processo di trasferimento dei meta-dati dall'MME, a fronte di interrogazioni e di creazione di report. Tipicamente l'accesso ai data mart avviene tramite strumenti di front-end (Business Objects, Cognos, Hyperion, Microstrategy e simili). Questi strumenti generano una codifica SQL. Ora, poiché il componente del repository dei meta-dati è memorizzato all'interno di un data

base relazionale aperto, è abbastanza semplice "puntare" con questi strumenti agli indici del repository e trasferire il meta-dato direttamente nell'applicazione di interrogazione o utilizzarlo per la creazione di un report (per un esempio, vedi Figura 11).

Per alcune applicazioni, per le quali il numero dei meta-dati nel data mart risulti molto voluminoso oppure che abbiano un alto numero di utenti finali, il sovraccarico di lavoro necessario per accedere a un database separato può creare tempi di ritardo alla risposta troppo penalizzanti per gli utenti. Questi problemi di implementazione possono essere risolti caricando i meta-dati direttamente all?interno dei data mart (Figura 12) durante il ciclo di caricamento dei mart.

Managed Meta Data Environment (II parte) - Technology Transfer

Enterprise information catalog. I requisiti per fare la scelta giusta
Mike Ferguson

La nuova era dell’analisi predittiva - Le aziende alla prova del Machine Learning
Frank Greco

Uno sguardo Agile - Per capire il passato e progettare il futuro
Arie van Bennekum

Trasformazione Agile
Se il product owner diventa un collo di bottiglia

Sander Hoogendoorn

Una Fiat o una Ferrari?
Qual è la più adatta per il business digitale?

Barry Devlin

Vincere la complessità dei dati. È l’ora dello smart data management
Mike Ferguson

Big Data e Analytics - Se il machine learning accelera anche la data science
Mike Ferguson

I dati al centro del business
Christopher Bradley

I Big Data forniscono il contesto e la ricchezza predittiva attorno alle transazioni di business Avere dati coerenti e di qualità resta fondamentale per il processo decisionale
Barry Devlin

Cosa c’è dietro l’angolo? Cinque mosse per diventare un digital leader
Jeroen Derynck

Managing information technology Gestire l’IT come un business nel business
Mitchell Weisberg

Data integration self-service Miglioramento della produttività o caos totale?
Mike Ferguson

Project manager vecchi miti e nuove realtà
Aaron Shenhar

La catena alimentare dei requisiti
Suzanne Robertson

Come diventare un’azienda data-centric
Lindy Ryan

Enterprise analytical ecosystem - Come comprendere il comportamento online dei clienti e capitalizzare il valore dei dati nell’era Big Data
Mike Ferguson

Agilità? Basta Volere
Suzanne Robertson

Ma la vostra architettura è efficace?
Mike Rosen

Se il NoSQL diventa SQL
Rick van der Lans

La data quality e l’impatto sul business
Danette McGilvray

Business analysis e regole di business By Ronald G. Ross con Gladys S.W. Lam
Ronald Ross

Usare Scrum su larga scala: cosa cambia?
Craig Larman

Le architetture per ridurre il debito tecnico
Mike Rosen

Conversando con un marziano
Suzanne Robertson

Cosa c’è di nuovo nel project management?
Aaron Shenhar

Reinventare la Business Intelligence
Barry Devlin

Il nuovo volto della business intelligence
Shaku Atre

Alla ricerca del valore tra i pomodori nell'orto
John Favaro

I big data cambiano il mercato dei Database Server
Rick van der Lans

Un “superstorm” di informazioni
Barry Devlin

I dieci step per la qualità dei dati
Danette McGilvray

Perché è meglio evitare il private cloud?
Jason Bloomberg

Leonardo da Vinci aveva ragione!
Chris Date

Mobile user experience: Come adottare una strategia sostenibile
James Hobart

Cosa significa occuparsi di architettura?
Mike Rosen

Virtualizzazione dei dati e sistemi di Business Intelligence Agili
Rick van der Lans

Modelli e linguaggi naturali, quale il modo migliore per definire i requisiti?
James Robertson

Extreme Scoping: un approccio Agile all'Edw e alla BI
Larissa Moss

BI², la Business Intelligence al quadrato
Barry Devlin

I test di regressione in ambienti legacy
Randy Rice

Le conseguenze della consumerizzazione e del Cloud
Chris Potts

Come vanno gli affari? Chiedetelo al vostro cruscotto
Shaku Atre

Organizzare team di progetto efficienti in ambienti DW/BI
Larissa Moss

Big Data, come e perché
Colin White

Business Capabilities e l'allineamento del business all'IT
Mike Rosen

Il valore della tassonomia nella ricerca delle informazioni
Zach Wahl

BI, ma il Data Warehouse è ancora necessario?
Colin White

Reinventare la Business Intelligence
Barry Devlin

Il cruscotto delle prestazioni: il nuovo volto della Business Intelligence
Shaku Atre

Modelli e processi di User acceptance testing
Randy Rice

I limiti nel gestire l'IT come un Business
Chris Potts

Le componenti fondamentali del Cloud
George Reese

Metadati e DW 2.0
Derek Strauss

BI Open Source: basso costo e alto valore?
Jos van Dongen

Semplicità e requisiti
Suzanne Robertson

Business intelligence e analisi testuale
Bill Inmon

Extreme Scoping™: approcci agili al DW e alla BI
Larissa Moss

Dalla BI a un'architettura IT di livello Enterprise
Barry Devlin

Ambiente efficiente di ricerca di informazioni
James Hobart

Il Business deve trainare la Strategia IT
Chris Potts

Web database: la questione MapReduce (seconda parte)
Colin White

Web database: la questione MapReduce
Colin White

Misura delle prestazioni. I sette comandamenti
Harry Chapman

Le dieci cose che un architetto deve fare per creare valore
Mike Rosen

Sviluppare applicazioni a prova di sicurezza
Ken van Wyk

The ECM Landscape in 2008
Alan Pelz-Sharpe

Ma chi sono gli operatori dell’informazione?
Colin White

Qualità dell’informazione e trasformazione del management
Larry English

Classificazione sistematica delle informazioni
Zach Wahl

L’uso intensivo del Web nelle applicazioni di Bi
Colin White

Enterprise Search
Theresa Regli

La forza dell'astrazione
Steve Hoberman

La strada verso una BI pervasiva
Cindi Howson

Soa, una strategia di test
Randy Rice

Verso una BI più semplice e a minor costo
Colin White

I contenuti “Killer” del Web
Gerry McGovern

Sviluppo iterativo del software per i Dw
Larissa Moss

Qualità delle Informazioni e Datawarehousing
Larry English

Lo scenario Ecm 2008
Alan Pelz-Sharpe

La nascita del Web 3.0
John Kneiling

Documentazione: il dossier del crimine
Suzanne Robertson

L’impatto del Web 2.0 sui portali delle imprese
Colin White

Le tecniche vincenti di IT Management
Ken Rau

Web 2.0
Ed Yourdon

Web di successo se si conosce il cliente
Gerry McGovern

Un approccio alla BI incentrato sui processi
Colin White

Integrare Master Data Management e BI (Parte Seconda)
Mike Ferguson

Integrare Master Data Management e BI (Parte Prima)
Mike Ferguson

Il Project Manager è una Tata
Suzanne Robertson

Web di successo se si conosce il cliente
Gerry McGovern

L'informazione personalizzata
Colin White

La Tassonomia dell'Impresa
Zach Wahl

Managed Meta Data Environment (II parte)
David Marco

Managed Meta Data Environment
David Marco

Migliorare le applicazioni dell'impresa con Web 2.0
James Hobart

La Balanced Scorecard migliora la Performance dell'IT
Harry Chapman

La fusione dei processi dell'impresa grazie a Soa (II parte)
Max Dolgicer

La fusione dei processi dell'impresa grazie a SOA (I parte)
Max Dolgicer

Volere è Potere, in Ogni Senso
Suzanne Robertson

Dimostrate con i numeri il valore dei contenuti del web
Gerry McGovern

Il Back-end della pianificazione strategica dell'It
Ken Rau

L'audit delle prescrizioni di progetto (II parte)
Suzanne Robertson

L'audit delle prescrizioni di progetto (I parte)
Suzanne Robertson

Il Processo di gestione delle informazioni
Ted Lewis

I requisiti come strumento di gestione dei progetti
Suzanne Robertson

Il futuro è nel contenuto killer del web
Gerry McGovern

Alla ricerca del valore tra i pomodori nell'orto
John Favaro

Rilevare i costi sulla base delle attività
Ken Rau

Un percorso verso l'impresa intelligente (II parte)
Mike Ferguson

Un percorso verso l'impresa intelligente (I parte)
Mike Ferguson

Il Data Store Operativo: un lavoro di martello
Claudia Imhoff

Il data warehouse orientato all'impresa
Michael Schmitz

Dieci punti chiave per realizzare balanced scorecard di successo
Harry Chapman

Content management: i contenuti al primo posto
Gerry McGovern

Applicazioni Web ad alta disponibilità
John Kneiling

Il 2004, sarà l'anno in cui abbandoneremo html?
James Hobart

La tecnologia EII ripropone il data warehousing virtuale?
Colin White

Misurare per Gestire
Ken Rau

Volere è Potere, in Ogni Senso
Suzanne Robertson

Realizzare il CPM e l'integrazione della BI
Mike Ferguson

Tutti i punti della FPA
Koni Thompson

Requiem per il Portale?
Colin White

Business Intelligence: dalla teoria alla realtà (II parte)
Shaku Atre

Business Intelligence: dalla teoria alla realtà (I parte)
Shaku Atre

I portali Corporate e di E-business: la nuova generazione del posto di lavoro
Mike Ferguson

I 10 errori da evitare nella realizzazione di un Meta Data Repository (II Parte)
David Marco

I 10 errori da evitare nella realizzazione di un Meta Data Repository (I parte)
David Marco

Usare i modelli per acquisire l'esperienza di progettazione
James Hobart

Realizzare l'Impresa Intelligente
Colin White

.NET or J2EE - Choosing the Right Web Services Framework
John Kneiling

Progettare Applicazioni Mobili di Successo
James Hobart

La Sociologia del Progetto: Identificare e Coinvolgere tutti i Partecipanti
Suzanne Robertson

Integrare la Business Intelligence nell'Impresa (II parte)
Mike Ferguson

Integrare la Business Intelligence nell'Impresa (I parte)
Mike Ferguson

L'Evoluzione del Portale di e-Business (II parte)
Colin White

L'Evoluzione del Portale di e-Business (I parte)
Colin White

Il Consulente WebEAI: Servizi Web, XML e l'Impresa
John Kneiling

Data Mining: Come Gestire le Relazioni con i Clienti Secondo i Principi del CRM
Weaver James

Articoli del mese - Technology Transfer