Articoli del meseArticoli del mese

Articoli del mese


Stampa articolo

Articolo del Mese - Settembre 2006

Managed Meta Data Environment

David Marco by David Marco

Praticamente tutte le grandi società e le agenzie governative hanno già realizzato, o stanno realizzando, oppure stanno pensando di realizzare un Managed Meta Data Environment (Mme), ovvero un ambiente di gestione dei meta-dati. Molte organizzazioni, tuttavia, continuano a compiere errori fondamentali. Un?impresa può realizzare molti repository, ovvero depositi di meta-dati, o "isole di meta-dati", che non sono collegati tra loro, con un risultato che non produce molto valore aggiunto.

Risolviamo rapidamente un semplice quiz sui meta-dati: qual è la forma più comune di un'architettura di meta-dati? Verosimilmente, la maggior parte di voi risponderà "centralizzata" ma la vera risposta è ?una cattiva architettura?. La maggior parte delle architetture dei repository sono realizzate nel medesimo modo con il quale erano state costruite le architetture dei datawarehouse: ovvero un modo sbagliato. Il problema delle architetture dei datawarehouse si è manifestato in molte società comprese nella lista Global 2000, costrette a rifare le proprie applicazioni di datawarehouse, talvolta fino dalle fondamenta. Molti dei repository realizzati e ancora in uso debbono essere riprogettati e ricostruiti completamente.

Obiettivo di questo articolo è assicurarvi che la vostra architettura Mme sia costruita su fondamenta solide come una roccia, che forniscano alla vostra organizzazione vantaggi significativi rispetto ad altre architetture Mme poco efficaci. A tale scopo, presenterò un'architettura Mme completa, una visione generale, il dettaglio dei suoi sei componenti principali e i pilastri fondamentali dell'ambiente Mme.

Mme in breve

L'ambiente di gestione dei meta-dati è composto dai componenti architetturali, persone e processi necessari per accumulare, mantenere distribuire i meta-dati in maniera appropriata all'interno dell?intera impresa. L'ambiente Mme comprende, per i meta-dati, i concetti di repository, cataloghi, dizionari e ogni altro termine utilizzato con riferimento alla gestione sistematica dei meta-dati. Alcuni descrivono erroneamente un Mme come un datawarehouse per meta-dati. Nella realtà, un Mme è un sistema operativo e come tale possiede un'architettura molto diversa da quella di un datawarehouse.

Le società che stanno cercando di gestire realmente e in maniera efficiente i meta-dati secondo una prospettiva d'impresa, debbono disporre di un Mme completamente funzionale. È importante notare che un'impresa non deve cercare di mantenere tutti i propri meta-dati all'interno di un Mme, analogamente al principio che non tutti i dati posseduti debbano essere contenuti in un datawarehouse. Senza i componenti Mme, è molto difficile essere efficaci nella gestione dei meta-dati all'interno di una grande organizzazione. I sei componenti di un Mme sono:

  • Livello delle fonti dei meta-dati
  • Livello d'integrazione dei meta-dati
  • Repository dei meta-dati
  • Livello di gestione dei meta-dati
  •  Depositi circoscritti (mart) di meta-dati
  • Livello di consegna dei meta-dati

L'ambiente Mme può essere utilizzato nelle architetture centralizzate, decentralizzate oppure distribuite: l?architettura centralizzata offre un meta-modello unico, uniforme e consistente che rappresenta lo schema per definire e organizzare i diversi meta-dati memorizzati all'interno di un repository dei meta-dati globale. Questo consente un approccio consolidato per amministrare e condividere i meta-dati nell'ambito dell?impresa. L'architettura decentralizzata crea un meta-modello uniforme e consistente, che indica lo schema per definire e organizzare un sottoinsieme globale di meta-dati da memorizzare in un repository globale e negli elementi predeterminati di meta-dati condivisi che, a loro volta, appaiono nei repository di meta-dati locali. Tutti i meta-dati condivisi e riutilizzati nell'ambito dei diversi repository locali debbono prima transitare per il repository globale, ma la condivisione e l'accesso ai meta-dati locali risultano indipendenti dal repository globale. L'architettura distribuita comprende parecchi repository di meta-dati separati e autonomi, ognuno con un meta-modello diverso e adatto al proprio contenuto e organizzazione dei meta-dati, che prevede la responsabilità univoca per ogni repository della condivisione e amministrazione dei propri meta-dati. Il repository globale dei meta-dati non manterrà i meta-dati che appaiono nei repository locali, mentre avrà al suo interno, invece, i puntatori ai meta-dati nei repository locali, unitamente ai meta-dati che indicano come accedervi[1]. Presso la società EWSolutions, abbiamo realizzato un Mme che usa tutti questi tre approcci architetturali e alcune implementazioni utilizzano combinazioni di queste tecniche all'interno di un Mme.

Il livello delle fonti dei meta-dati

Il livello delle fonti dei meta-dati è il primo componente dell'architettura di un Mme. Il compito di tale livello e di estrarre i meta-dati dalle loro fonti e di inviarli al livello di integrazione dei meta-dati, oppure direttamente all'interno del repository dei meta-dati stessi.

L'accesso ad alcuni meta-dati da parte dell'Mme avverrà mediante l'uso di puntatori (distribuiti) che presenteranno i meta-dati all'utente finale nel momento in cui verrà richiesto. I puntatori sono gestiti dal livello delle fonti dei meta-dati e sono memorizzati all'interno del repository dei meta-dati.

In termini generali, è più conveniente inviare i meta-dati estratti alla medesima locazione hardware del repository dei meta-dati dal quale provengono. Spesso, i progettisti dell'architettura dei meta-dati inseriscono, non correttamente, i processi di integrazione dei meta-dati nella medesima piattaforma dalla quale provengono i meta-dati stessi (a differenza della scelta dei record, che è accettabile). Questa commistione del livello delle fonti con il livello di integrazione dei meta-dati è un errore comune che causa una quantità di problemi.

Nel momento in cui vengano modificate e aggiunte (come accade inevitabilmente) le fonti dei meta-dati, il processo d'integrazione di questi ultimi subisce un impatto negativo. Quando il livello delle fonti viene separato dal livello di integrazione dei meta-dati, solamente il primo viene impattato da questo tipo di cambiamento. Mantenendo tutti i meta-dati sulla medesima piattaforma, l'architetto dei meta-dati può adattare il processo d'integrazione molto più facilmente.

Mantenendo poi il livello di estrazione separato dal livello delle fonti, si fornisce un back up ordinato e un punto di ripartenza efficace. Gli errori di caricamento dei meta-dati avvengono tipicamente all'interno del livello di trasformazione dei meta-dati. In mancanza di un livello di estrazione, se avviene un errore l?architetto dovrebbe tornare indietro alla fonte dei meta-dati e leggerli nuovamente. Questo causerebbe numerosi problemi. Se la fonte dei meta-dati ha subito un aggiornamento, può perdere il sincronismo con alcune altre fonti di meta-dati con le quali risulti integrata. Inoltre, la fonte di meta-dati può essere correntemente in uso e questo processo può impattare sulle performance della fonte dei meta-dati. La regola aurea dell'estrazione di meta-dati è:

Mai avere processi multipli che estraggono il medesimo meta-dato dalla stessa fonte di meta-dati

In tali situazioni, la tempestività e, conseguentemente, l'accuratezza del meta-dato può risultare compromessa. Per esempio, supponete di aver costruito un processo di estrazione dei meta-dati (Processo #1) che legga i nomi degli attributi fisici da un tabella di strumenti di modellazione, per caricare un'entità voluta nella tabella dei meta-modelli che, a sua volta, contiene i nomi degli attributi fisici. Avete poi costruito anche un secondo processo (Processo #2) per leggere e caricare i valori del dominio degli attributi. È possibile che la tabella degli attributi all'interno dello strumento di modellazione sia stata modificata tra l'applicazione del Processo #1 e del Processo #2. Questa situazione provocherà una perdita di sincronismo dei meta-dati.

Questa situazione può causare anche un ritardo non necessario nel caricamento dei meta-dati, con fonti di meta-dati che hanno finestre limitate di disponibilità/elaborazioni batch. Per esempio, se stavate leggendo i log dei database a partire dal vostro sistema di pianificazione delle risorse dell'impresa (Erp), non potrete far girare processi di estrazione multipli su questi log poiché verosimilmente questi avranno un numero limitato di finestre batch disponibili. Dato che una situazione di questo tipo non si verifica spesso, non vi è ragione per creare perturbazioni non necessarie all'interno della vostra architettura di meta-dati.

Il numero e la varietà delle fonti di meta-dati varierà fortemente in base alle richieste al vostro Mme da parte degli utenti. Anche se esistono fonti di meta-dati utilizzate contemporaneamente da molte imprese, non ho mai visto due repository di meta-dati che abbiano esattamente le medesime fonti di meta-dati (avete mai visto due datawarehouse con le stesse fonti di informazione?) ma, in termini generali, le più comuni fonti di meta-dati sono le seguenti:

  • Strumenti software

  •  Utenti finali

  •  Documenti e fogli elettronici

  • Messaggi e transazioni

  • Applicazioni

  •  Siti Web e commercio elettronico

  •  Terze parti

Strumenti software

Un gran numero di meta-dati di valore è contenuto all'interno di diversi strumenti software. Non dovete dimenticare che molti di questi strumenti dispongono di propri repository di meta-dati, progettati per consentire funzionalità specifiche e tipicamente non sono progettati per consentire l'accesso da parte degli utenti di meta-dati, oppure risultano integrati in altre fonti di meta-dati. In questo caso, avrete bisogno di attivare processi specifici per entrare in questi repository riservati ed estrarne i meta-dati.

Tra gli strumenti in questione, i database relazionali e gli strumenti di modellazione sono le fonti più comuni di meta-dati nell'ambito del livello delle fonti di meta-dati. L'Mme normalmente legge le tabelle del database di sistema per estrarre i meta-dati in termini di nomi di liste fisiche, nomi di attributi logici, nomi di tabelle fisiche, nomi di entità logiche, modalità di relazione, indicizzazione, cattura dei dati modificati e modalità di accesso ai dati stessi.

Utenti finali

Gli utenti finali costituiscono una delle fonti più importanti per i meta-dati da inserire in un Mme. Questi utenti sono di due tipi: business e tecnici.

Spesso, i meta-dati di business per una grande impresa sono conservati nella coscienza collettiva dei suoi dipendenti, ovvero nella loro "conoscenza tribale". Come risultato, l'input dei meta-dati di business nel repository risulta vitale per gli utenti dell'impresa. La necessità di avere utenti attivi e coinvolti si lega all'argomento della gestione dei dati[2].

Anche gli utenti tecnici hanno bisogno di un accesso diretto al repository dei meta-dati per l'input dei propri meta-dati tecnici. Poiché gran parte dei meta-dati tecnici sono memorizzati all'interno di vari strumenti software, per gli utenti tecnici l'attività di input non è così rigorosa come quella degli utenti di business.

Le interfacce per entrambe queste categorie di utenti debbono essere abilitate al Web. Il Web fornisce un?interfaccia facile da usare e intuitiva, familiare a tutti i tipi di utenti. L'aspetto critico è dato dal collegamento diretto dell'interfaccia ai meta-dati contenuti nel repository. A tale proposito, suggerisco caldamente l'uso di accorgimenti come i box di inserimento e le liste di prelevamento, funzioni con le quali gli utenti hanno familiarità. Inoltre, dovete sempre tenere conto dell'integrità dei riferimenti e collegamenti forniti dal software del database.

 

Documenti e fogli elettronici

Una grande quantità di meta-dati è contenuta nei documenti dell'impresa (Microsoft Word) e nei fogli elettronici (Excel). Le caratteristiche del vostro Mme saranno grandemente condizionate dal grado di dettaglio di cui avete bisogno nel trasferire i dati dai documenti o nel creare dei puntatori di riferimento. Talvolta, questi documenti e fogli elettronici sono localizzati in un'area centrale di una rete, oppure nel computer di un dipendente. In molte organizzazioni, quindi, documenti e fogli elettronici tendono a essere altamente volatili e privi di regole di standardizzazione e di presentazione. Come risultato, normalmente costituiscono una delle fonti di meta-dati meno affidabili e più problematiche, nell'ambito di un Mme. Talvolta, i meta dati di business contenuti in queste fonti possono essere trovati nelle note o nei campi di commento associati a un documento o a una cella (nel caso di foglio elettronico). I meta dati tecnici, come calcoli, dipendenze o valori di controllo sono contenuti all'interno dei data store proprietari delle applicazioni (Microsoft Excel oppure Lotus 1-2-3).

Per le imprese che hanno implementato un sistema di gestione dei documenti, è importante estrarre i meta dati da queste fonti e trasferirli nel repository Mme. Normalmente, quando una società realizza un sistema di gestione dei documenti o della conoscenza, acquista anche un prodotto software per aiutare nella gestione dei meta-dati su documenti, immagini, file audio, file geospaziali (topografici) e fogli elettronici. È importante avere un livello delle fonti di meta dati che li possa leggere all'interno degli strumenti di gestione documentale, per poi estrarli e trasferirli all?interno del repository Mme. Questo compito è molto difficile perché la maggior parte dei fornitori di sistemi per la gestione dei documenti non comprendono che si tratta di veri repository di meta dati e che, come tali, debbono essere accessibili. Questi strumenti spesso utilizzano software proprietario per il database con lo scopo di proteggerlo dalla concorrenza, così come risulta molto poco visibile la struttura interna del loro database, con l'effetto che la struttura dei meta dati non è rappresentata nel meta-modello ma, invece, è rappresentata come codifica di programma. Come risultato, può risultare difficile costruire processi che estraggano i meta dati da queste fonti.

Messaggeria e transazioni

Molte imprese e agenzie governative utilizzano una qualche forma di messaggeria e di transazioni, sia con tecniche Eai (Enterprise application integration) sia con linguaggio Xml (talvolta le applicazioni Eai utilizzano Xml), per trasferire dati da un sistema a un altro. L'uso di Eai e Xml è molto diffuso, poiché le imprese si trovano a combattere con l'alto costo di mantenimento degli attuali approcci all'integrazione dei dati da punto a punto. Il problema dell'integrazione punto a punto è che l'ambiente dell'It diviene così complesso che è impossibile gestirlo in maniera efficace ed efficiente, specialmente se non si dispone di un Mme a livello dell'impresa. Un paradigma della messaggeria Eai dovrebbe aiutare le imprese a districarsi dagli attuali approcci all'integrazione dei dati punto a punto.

Mentre la maggior delle organizzazioni non sono molto avanti nell'uso e applicazione di Eai e Xml, questi tipi di processi possono essere utilizzati per reperire meta-dati di grande valore: regole di business, statistiche sulla qualità dei dati, allineamento dei dati, processi di razionalizzazione dei dati e così via. Poiché gli strumenti Eai sono progettati per gestire il bus della messaggeria, non i meta-dati che vi transitano, è importante portare questi ultimi nell'Mme, estraendoli dagli strumenti Eai, per consentirne l?accesso globale, la gestione storica, la pubblicazione e la distribuzione. Senza un buon Mme diviene molto difficoltoso mantenere questo tipo di applicazioni. Le grandi organizzazioni governative e le grandi imprese stanno utilizzando i rispettivi Mme per affrontare questa sfida.

Applicazioni

All?interno del largo spettro di applicazioni usate all'interno dell'impresa, alcune saranno state realizzate internamente dal dipartimento It (per esempio, datawarehouse, contabilità generale, paghe e stipendi, gestione della catena logistica e via dicendo), altre saranno basate su package (per esempio, PeopleSoft, SAP, Siebel) e altre, infine, possono essere gestite in outsourcing oppure utilizzano il modello di un provider di servizi Asp (Application service provider). Questa proliferazione di applicazioni può essere abbastanza voluminosa. Per esempio, conosciamo diverse grandi società e agenzie governative il cui numero di applicazioni si conta a migliaia.

Ciascuna di queste applicazioni contiene meta-dati di valore che debbono essere estratti e trasferiti nelle applicazioni Mme. Considerando che le applicazioni siano costruite su di una delle più diffuse piattaforme di database relazionale (ovvero IBM, Oracle, Microsoft, Sybase, Teradata), il livello delle fonti di meta-dati potrà leggere le tabelle di sistema e i log di questi database. Esistono anche un numero considerevole di meta-dati memorizzati all'interno delle varie applicazioni. Le regole dell'impresa e i valori di verifica sono contenuti all'interno della codifica applicativa o nelle tabelle di controllo. In tali situazioni, è necessario costruire un processo per acquisire i meta-dati.

Siti Web e e-commerce

Una delle fonti di meta-dati meno utilizzate sono i siti Web dell'impresa. Molte società dimenticano l?ammontare dei meta-dati di valore contenuti (e, secondo noi, da custodire meglio altrove) nel linguaggio ipertestuale (Html) nei siti Web. Per esempio, gli analisti del settore della sanità hanno bisogno di conoscere le informazioni più recenti circa i test sui pazienti di una nuova medicina. Questa ricerca è tipicamente effettuata da un medico che opera in un ospedale. Normalmente, il dottore registra i suoi dati sul sito Web o sul portale dell'ospedale, per cui è importante catturare i meta-dati esistenti in questi siti Web, così come sono importanti le modalità e i tempi di aggiornamento dei dati e così via.

Il medesimo ragionamento si applica anche al commercio elettronico. Quando un cliente ordina un prodotto tramite il Web, vengono generati una serie di meta-dati di valore che possono essere trasferiti e utilizzati in un Mme.

Terze parti

Per molte società, una forte interazione con le terze parti costituisce un processo di business standard. Alcuni tipi di imprese nei settori bancario, della difesa e delle agenzie collegate, della sanità, delle finanze e in alcuni tipi di produzione debbono necessariamente interagire con i rispettivi partner, fornitori, venditori, clienti, governo o agenzie di regolamentazione (come la Food & Drug Administration e il Census Bureau, negli Stati Uniti) su base giornaliera. Per ogni interazione sistematica, queste fonti esterne di dati generano meta dati[3] che debbono essere estratti e trasportati nell'Mme.


[1] Per una disamina più dettagliata di questo approccio, vedi il Capitolo 7 di "Building and Managing the Meta Data Repository" (David Marco, Wiley 2000)

[2] Per una discussione dettagliata sulla Gestione dei Dati, vedi la quarta parte delle serie di David Marco, apparsa in DM Review December, 2002 - March 2003

[3] Vedi il Capitolo 2 di "Building and Managing the Meta Data Repository" (David Marco, Wiley 2000), per una discussione più dettagliata sulle fonti esterne di meta-dati

Managed Meta Data Environment - Technology Transfer

L’evoluzione dell’IT tra sfide e promesse
Frank Greco

Verso la new digital economy. Quale architettura per la trasformazione digitale?
Mike Rosen

Ecco come capire il cliente. I diversi punti di vista della Business Analysis
James Robertson

Ecco come capire il cliente I diversi punti di vista della Business Analysis
Suzanne Robertson

E se il Design Sprint fosse il nuovo asso nella manica? Come risolvere grandi problemi e testare nuove idee
James Hobart

Come essere veramente data driven. L’importanza dell’architettura dati
Mike Ferguson

Il Machine Learning in azienda. Come migliorare performance e previsioni
Frank Greco

Portfolio management avanzato: Come trasformare gli investimenti in cambiamento
Chris Potts

L’imbuto e le biglie. Ovvero la metafora della produttività dei team
Sander Hoogendoorn

Dal Data Warehouse al digital business. Un’architettura di trent’anni ancora valida
Barry Devlin

Dai silos a un ecosistema analitico integrato. Un approccio per avere dati da usare su più sistemi
Mike Ferguson

Come accelerare l’innovazione in azienda. La nuova generazione dell’IT enterprise
Frank Greco

Tassonomie e ricerche. Ecco come ottenere migliori risultati
Heather Hedden

Viaggio verso il data warehouse logico
Il grande dilemma della business intelligence

Rick van der Lans

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