Di Techopedia Staff, 28 settembre 2016
Takeaway: l' host Rebecca Jozwiak discute le soluzioni di architettura dei dati con Eric Little di OSTHUS, Malcolm Chisholm dei First San Francisco Partners e Ron Huizenga di IDERA.
Al momento non sei collegato. Accedi o registrati per vedere il video.
Rebecca Jozwiak: Signore e signori, ciao e benvenuti in Hot Technologies del 2016. Oggi discutiamo di "Costruire un'architettura di dati orientata al business", sicuramente un argomento caldo. Mi chiamo Rebecca Jozwiak, sarò il tuo ospite per il webcast di oggi. Facciamo tweet con un hashtag di # HotTech16, quindi se sei già su Twitter, non esitare a partecipare anche a quello. Se hai domande in qualsiasi momento, ti preghiamo di inviarle nel riquadro Domande e risposte nella parte inferiore destra dello schermo e faremo in modo che ricevano risposta. In caso contrario, faremo in modo che i nostri ospiti li prendano per te.
Quindi oggi abbiamo una formazione davvero affascinante. Ci sono un sacco di pesanti hit oggi con noi. Abbiamo Eric Little, vicepresidente della scienza dei dati di OSTHUS. Abbiamo Malcolm Chisholm, Chief Innovation Officer, che è un titolo davvero interessante, per First San Francisco Partners. E abbiamo Ron Huizenga, senior product manager di IDERA. E, sai, IDERA ha una suite davvero completa di soluzioni per la gestione e la modellazione dei dati. E oggi ci darà una demo su come funziona la sua soluzione. Ma prima di arrivare a questo, Eric Little, ti passerò la palla.
Eric Little: Ok, grazie mille. Quindi tratterò un paio di argomenti qui che penso che si relazioneranno un po 'ai discorsi di Ron e spero di preparare il terreno per alcuni di questi argomenti, alcune domande e risposte.
Quindi la cosa che mi ha interessato di ciò che IDERA sta facendo è che penso che sottolineano correttamente che ambienti complessi stanno guidando molti valori aziendali al giorno d'oggi. E per ambienti complessi intendiamo ambienti di dati complessi. E la tecnologia si sta muovendo molto velocemente ed è difficile tenere il passo nell'ambiente aziendale odierno. Quindi quelle persone che lavorano negli spazi tecnologici vedranno spesso che hai clienti che stanno risolvendo problemi con “Come posso usare i big data? Come posso incorporare la semantica? Come posso collegare alcune di queste nuove cose con i miei dati più vecchi? ”E così via, e quel tipo di guida ci conduce oggi in queste quattro v di big data che molte persone conoscono bene e capisco che possono essercene più di quattro a volte - ne ho visti fino a otto o nove - ma normalmente, quando le persone parlano di cose come i big data o se parli di big data, di solito stai guardando qualcosa che è una sorta di scala aziendale. E così la gente dirà, okay, beh, pensa al volume dei tuoi dati, che di solito è il focus - questo è quanto hai. La velocità dei dati ha a che fare con la velocità con cui posso spostarli o con la velocità con cui posso interrogarli o ottenere le risposte, e così via. E personalmente penso che il lato sinistro sia qualcosa che viene risolto e gestito in modo relativamente rapido da molti approcci diversi. Ma sul lato destro vedo molte possibilità di miglioramento e molte nuove tecnologie che stanno davvero arrivando in primo piano. E questo ha davvero a che fare con la terza colonna, la varietà di dati.
Quindi, in altre parole, oggigiorno la maggior parte delle aziende guarda a dati strutturati, semi-strutturati e non strutturati. I dati delle immagini stanno iniziando a diventare un argomento caldo, quindi essere in grado di utilizzare la visione del computer, guardare i pixel, essere in grado di grattare il testo, la PNL, l'estrazione di entità, si hanno informazioni grafiche che escono da entrambi i modelli statistici o che escono da semantiche modelli, hai dati relazionali esistenti nelle tabelle e così via. Quindi, riunire tutti questi dati e tutti questi diversi tipi rappresenta davvero una grande sfida e lo vedrai in Gartner e in altre persone che stanno seguendo le tendenze del settore.
E poi l'ultima cosa di cui le persone parlano nei big data è spesso questa nozione di voracità, che è in realtà l'incertezza dei tuoi dati, la confusione di essi. Quanto sai di cosa trattano i tuoi dati, quanto capisci cosa c'è dentro e, sai? La capacità di utilizzare le statistiche e la capacità di utilizzare un qualche tipo di informazione su ciò che potresti conoscere o utilizzare un certo contesto, può essere utile in questo caso. E così la capacità di guardare i dati in questo modo in termini di quanto hai, quanto velocemente devi spostarli o raggiungerli, tutti i tipi di dati che potresti avere nella tua azienda e quanto sei sicuro di dove è, di cosa si tratta, in che qualità è e così via. Ciò richiede davvero un grande sforzo coordinato ora tra molte persone per gestire i propri dati in modo efficace. La modellazione dei dati è quindi sempre più importante nel mondo di oggi. Quindi, i buoni modelli di dati stanno davvero dando molto successo alle applicazioni aziendali.
Hai fonti di dati da una varietà di fonti, come dicevamo, che richiedono davvero molti tipi diversi di integrazione. Pertanto, riunire tutto insieme è davvero utile per poter eseguire query, ad esempio, su numerosi tipi di origini dati e recuperare informazioni. Ma per fare ciò hai bisogno di buone strategie di mappatura e quindi mappare quei tipi di dati e tenere il passo con quelle mappature può essere una vera sfida. E poi hai questo problema di, bene, come posso collegare i miei dati legacy a tutte queste nuove fonti di dati? Quindi supponiamo di avere un grafico, prendo tutti i miei dati relazionali e li inserisco nel grafico? Di solito non è una buona idea. In che modo le persone sono in grado di gestire tutti questi tipi di modelli di dati in corso? L'analisi deve davvero essere eseguita su molti di questi diversi tipi di origini dati e combinazioni. Quindi le risposte che ne derivano, le risposte di cui le persone hanno bisogno per prendere davvero buone decisioni aziendali sono fondamentali.
Quindi non si tratta solo di costruire tecnologia per il bene della tecnologia, è davvero, cosa ho intenzione di fare, cosa posso fare con essa, che tipo di analisi posso eseguire e la capacità, quindi, come ho già sto parlando, mettere insieme queste cose, integrarle è davvero molto importante. E uno di questi tipi di analisi viene quindi eseguito su elementi come ricerca e query federate. Sta diventando davvero un must. Le tue query devono normalmente essere passate attraverso più tipi di fonti e recuperare le informazioni in modo affidabile.
L'unico elemento chiave che spesso, in particolare le persone, vedranno cose chiave come le tecnologie semantiche - e questo è qualcosa di cui spero che Ron parlerà un po 'nell'approccio IDERA - è come separare o gestire il livello di modello dei tuoi dati dal livello stesso, da quei dati grezzi? Quindi a livello di dati potresti avere database, potresti avere dati di documenti, potresti avere dati di fogli di calcolo, potresti avere dati di immagini. Se ti trovi in settori come l'industria farmaceutica hai una grande quantità di dati scientifici. E poi, di solito, queste persone cercano un modo per costruire un modello che consenta loro di integrare rapidamente quei dati e davvero quando stai cercando dati ora non stai cercando di tirare tutti i dati nel tuo livello di modello, quello che stai guardando al livello del modello da fare è darti una bella rappresentazione logica di cosa sono le cose, i vocabolari comuni, i tipi comuni di entità e relazioni e la capacità di raggiungere realmente i dati dove si trovano. Quindi deve dire quello che è, e deve dire dove si trova, e deve dire come andare a prenderlo e riportarlo indietro.
Quindi questo è stato un approccio che ha avuto abbastanza successo nel promuovere le tecnologie semantiche in avanti, che è un'area in cui lavoro molto. Quindi una domanda che volevo porre a Ron, e che penso possa essere utile nella sezione Domande e risposte, è vedere come viene realizzato questo dalla piattaforma IDERA? Quindi il livello del modello è effettivamente separato dal livello dati? Sono più integrati? Come funziona e quali sono alcuni dei risultati e dei benefici che stanno vedendo dal loro approccio? Pertanto, anche i dati di riferimento stanno diventando critici. Quindi, se hai questo tipo di modelli di dati, se sei in grado di federare e cercare tra le cose, devi davvero avere buoni dati di riferimento. Ma il problema è che i dati di riferimento possono essere davvero difficili da mantenere. Quindi spesso nominare gli standard in sé e per sé è una sfida difficile. Un gruppo chiamerà qualcosa X e un gruppo chiamerà qualcosa Y e ora hai il problema di come qualcuno trova X e Y quando cercano questo tipo di informazioni? Poiché non si desidera fornire loro solo una parte dei dati, si desidera fornire loro tutto ciò che è correlato. Allo stesso tempo i termini cambiano, il software diventa obsoleto e così via, come si mantengono e mantengono tali dati di riferimento nel tempo?
E, ancora una volta, le tecnologie semantiche, in particolare l'uso di tassonomie e vocabolari, dizionari di dati, hanno fornito un modo spaziale standard per farlo, che è davvero molto robusto, utilizza determinati tipi di standard, ma la comunità del database lo ha fatto per un anche da molto tempo, solo in diversi modi. Penso che una delle chiavi qui sia quella di pensare a come usare forse modelli di entità-relazione, come usare forse modelli di grafici o qualche tipo di approccio qui che ti darà davvero un modo spaziato standard di gestire i tuoi dati di riferimento. E poi ovviamente una volta che hai i dati di riferimento, le strategie di mappatura devono gestire un'ampia varietà di nomi ed entità. Quindi agli esperti in materia spesso piace usare i propri termini.
Quindi una sfida in questo è sempre, come si fa a fornire informazioni a qualcuno ma renderlo pertinente al modo in cui ne parlano? Quindi un gruppo può avere un modo di guardare qualcosa, ad esempio, potresti essere un chimico che lavora su un farmaco e potresti essere un biologo strutturale che lavora sullo stesso farmaco e potresti avere nomi diversi per gli stessi tipi di entità che riguardano il tuo campo. Devi trovare il modo di riunire quelle terminologie personalizzate, perché l'altro approccio è, devi costringere le persone a abbandonare il loro mandato e usare quello di qualcun altro, che spesso non gli piace. Un altro punto qui è che gestire un gran numero di sinonimi diventa difficile, quindi ci sono molte parole diverse nei dati di molte persone che possono fare riferimento alla stessa cosa. Hai un problema di riferimento lì usando un insieme di relazioni molti-a-uno. I termini specializzati variano da un settore all'altro, quindi se hai intenzione di trovare una sorta di soluzione globale per questo tipo di gestione dei dati, quanto è facilmente trasportabile da un progetto o da un'applicazione a un'altra? Questa può essere un'altra sfida.
L'automazione è importante ed è anche una sfida. È costoso gestire manualmente i dati di riferimento. È costoso mantenere la mappatura manuale ed è costoso che gli esperti in materia smettano di fare i loro lavori quotidiani e debbano andare e sistemare costantemente dizionari di dati e aggiornare le definizioni e così via, e così via. I vocabolari replicabili mostrano davvero molto valore. Quindi quelli sono spesso vocabolari che puoi trovare esterni alla tua organizzazione. Se lavori nel petrolio greggio, ad esempio, ci saranno alcuni tipi di vocabolari che puoi prendere in prestito da spazi open-source, lo stesso con i prodotti farmaceutici, lo stesso con il settore bancario e finanziario, lo stesso con molti di questi tipi di aree. Le persone mettono in circolazione vocabolari riutilizzabili, generici e replicabili che le persone possono usare.
E, ancora una volta, guardando lo strumento IDERA, sono curioso di vedere come stanno gestendo questo in termini di utilizzo di tipi di standard. Nel mondo della semantica spesso vedi cose come i modelli SKOS che forniscono standard almeno più ampi / stretti delle relazioni e quelle cose possono essere difficili da fare nei modelli ER ma, sai, non è impossibile, dipende solo da quanto macchinari e quel collegamento che è possibile gestire in questi tipi di sistemi.
Quindi, infine, volevo solo fare un paragone con alcuni motori semantici che vedo nel settore, e in qualche modo chiedere a Ron e adescarlo un po 'per parlare forse del modo in cui il sistema IDERA è stato usato insieme a qualsiasi tecnologia semantica. È in grado di integrarsi con triple store, database grafici? Quanto è facile usare fonti esterne perché questi tipi di cose nel mondo semantico possono spesso essere presi in prestito usando gli Endpoint SPARQL? Puoi importare modelli RDF o OWL direttamente nel tuo modello - fai riferimento a loro - quindi, ad esempio, l'ontologia genica o l'ontologia proteica, che possono vivere da qualche parte nel proprio spazio con la propria struttura di governance e posso semplicemente importare tutto o parte di ciò di cui ho bisogno nei miei modelli. E sono curioso di sapere come IDERA affronta questo problema. Devi mantenere tutto internamente o ci sono modi per utilizzare altri tipi di modelli standardizzati e inserirli e come funziona? E l'ultima cosa che ho menzionato qui è quanto lavoro manuale è realmente coinvolto per costruire i glossari e i repository di metadati?
Quindi so che Ron ci mostrerà alcune demo su questo tipo di cose che saranno davvero interessanti. Ma i problemi che vedo spesso consultarsi con i clienti è che si verificano molti errori se le persone scrivono nelle proprie definizioni o nei propri metadati. Quindi ricevi errori di ortografia, ricevi errori da dito grasso, questa è una cosa. Ottieni anche persone che potrebbero prendere qualcosa da, sai, solo Wikipedia o una fonte che non è necessariamente della qualità che potresti desiderare nella tua definizione, o la tua definizione è solo dal punto di vista di una persona, quindi non è completa, e non è chiaro allora come funziona il processo di governance. La governance, ovviamente, è un problema molto, molto grande ogni volta che parli di dati di riferimento e ogni volta che parli di come questo possa adattarsi ai dati anagrafici di qualcuno, come useranno i loro metadati e presto.
Quindi volevo solo mettere alcuni di questi argomenti là fuori. Questi sono elementi che vedo nello spazio aziendale attraverso molti tipi diversi di incarichi di consulenza e molti spazi diversi, e sono davvero interessato a vedere cosa Ron ci mostrerà con IDERA per sottolineare alcuni di questi argomenti . Grazie mille.
Rebecca Jozwiak: Grazie mille, Eric, e mi piace molto il tuo commento che molti errori possono verificarsi se le persone scrivono le proprie definizioni o metadati. So che nel mondo del giornalismo c'è un mantra che "molti occhi fanno pochi errori", ma quando si tratta di applicazioni pratiche, troppe mani nel barattolo di biscotti tendono a lasciarti con molti biscotti rotti, giusto?
Eric Little: Sì, e germi.
Rebecca Jozwiak: Sì. Con ciò andrò avanti e lo passerò a Malcolm Chisholm. Malcolm, il pavimento è tuo.
Malcolm Chisholm: Grazie mille, Rebecca. Vorrei guardare un po 'a quello di cui Eric stava parlando e aggiungere, in qualche modo, alcune osservazioni a cui, sapete, a Ron potrebbe interessare rispondere anche, parlando di "Verso l'architettura dei dati orientata al business" "- cosa significa essere orientati al business e perché è importante? O è solo una qualche forma di hype? Non penso lo sia.
Se guardiamo a ciò che succede da quando, sai, i computer mainframe sono diventati davvero disponibili per le aziende - diciamo, intorno al 1964 - ad oggi, possiamo vedere che ci sono stati molti cambiamenti. E questi cambiamenti vorrei riassumere come un passaggio dalla centralità del processo alla centralità dei dati. Ed è ciò che rende le architetture di dati orientate al business così importanti e così rilevanti per oggi. E penso, sai, non è solo una parola d'ordine, è qualcosa di assolutamente reale.
Ma possiamo apprezzarlo un po 'di più se ci immergiamo nella storia, quindi tornando indietro nel tempo, negli anni '60 e per qualche tempo in seguito, i mainframe hanno dominato. Questi hanno poi lasciato il posto ai PC in cui si era effettivamente ribellati agli utenti quando sono arrivati i PC. La ribellione contro l'IT centralizzata, che pensavano non soddisfacesse le loro esigenze, non era abbastanza agile. Ciò ha dato rapidamente origine al calcolo distribuito, quando i PC erano collegati tra loro. E poi ha iniziato a succedere Internet, che ha offuscato i confini dell'impresa: ora poteva interagire con le parti al di fuori di sé in termini di scambio di dati, cosa che non si era mai verificata prima. E ora siamo entrati nell'era del cloud e dei big data in cui il cloud è piattaforme che stanno davvero mercificando l'infrastruttura e quindi stiamo lasciando, per così dire, l'IT alla necessità di gestire grandi data center perché, sai, noi ci ha messo a disposizione la capacità del cloud, e in concomitanza con quei big data di cui Eric, sai, ha discusso in modo così eloquente. E nel complesso, come vediamo, con lo spostamento della tecnologia, è diventato più incentrato sui dati, ci preoccupiamo di più dei dati. Come con Internet, come vengono scambiati i dati. Con i big data, le quattro o più v dei dati stessi.
Allo stesso tempo, e forse ancora più importante, i casi di utilizzo aziendale sono cambiati. Quando i computer furono introdotti per la prima volta, furono usati per automatizzare cose come libri e dischi. E tutto ciò che era un processo manuale, che implicava registri o cose del genere, era programmato, essenzialmente, in casa. Ciò si è spostato negli anni '80 alla disponibilità di pacchetti operativi. Non hai più bisogno di scrivere il tuo libro paga, potresti comprare qualcosa che lo ha fatto. Ciò ha comportato un grande ridimensionamento al momento, o ristrutturazione, in molti dipartimenti IT. Ma poi la business intelligence, con cose come i data warehouse apparivano, soprattutto negli anni '90. Seguito da modelli di business dotcom che erano, ovviamente, una grande frenesia. Quindi MDM. Con MDM inizi a capire che non stiamo pensando all'automazione; ci stiamo solo concentrando sulla cura dei dati come dati. E poi analisi, che rappresenta il valore che puoi ottenere dai dati. E all'interno dell'analisi si vedono aziende di grande successo il cui modello di business principale ruota attorno ai dati. Google, Twitter, Facebook ne farebbero parte, ma potresti anche sostenere che Walmart lo è.
E così il business ora sta davvero pensando ai dati. Come possiamo ottenere valore dai dati? Come i dati possono guidare il business, la strategia e noi siamo nell'età d'oro dei dati. Detto questo, cosa sta succedendo in termini di architettura dei nostri dati, se i dati non sono più considerati semplicemente lo scarico che esce dal back-end delle applicazioni, ma è davvero centrale per i nostri modelli di business? Bene, parte del problema che abbiamo nel raggiungere l'IT è davvero bloccato in passato con il ciclo di vita dello sviluppo dei sistemi che era una conseguenza del dover affrontare rapidamente quella fase di automazione dei processi nella prima età dell'IT e lavorare in i progetti sono una cosa simile. Per l'IT - e questo è un po 'una caricatura - ma quello che sto cercando di dire è che alcune delle barriere per ottenere un'architettura di dati orientata al business sono perché, in un certo senso, abbiamo accettato acriticamente una cultura nell'IT che deriva da un'epoca passata.
Quindi tutto è un progetto. Dimmi le tue esigenze in dettaglio. Se le cose non funzionano, è perché non mi hai detto le tue esigenze. Bene, oggi non funziona con i dati perché non stiamo iniziando con processi manuali non automatizzati o una conversione tecnica di processi aziendali, stiamo iniziando molto spesso con dati di produzione già esistenti che stiamo provando per ottenere valore da. Ma nessuno che sta sponsorizzando un progetto incentrato sui dati comprende davvero questi dati in modo approfondito. Dobbiamo fare il rilevamento dei dati, dobbiamo fare l'analisi dei dati di origine. E questo non coincide davvero con lo sviluppo dei sistemi, sai - cascata, ciclo di vita dell'SDLC - di cui Agile, direi, è una specie di versione migliore di questo.
E ciò su cui ci si concentra è la tecnologia e la funzionalità, non i dati. Ad esempio, quando eseguiamo dei test in una fase di test, in genere lo è, la mia funzionalità funziona, diciamo il mio ETL, ma non stiamo testando i dati. Non stiamo testando le nostre ipotesi sui dati di origine in arrivo. Se lo facessimo, saremmo forse in una forma migliore e come qualcuno che ha realizzato progetti di data warehouse e sofferto di cambiamenti a monte, rompendo i miei ETL, lo apprezzerei. E in effetti, ciò che vogliamo vedere è testare come passaggio preliminare al monitoraggio continuo della qualità dei dati di produzione. Quindi abbiamo qui molti atteggiamenti in cui è difficile ottenere l'architettura dei dati orientata al business perché siamo condizionati dall'era della centralità del processo. Dobbiamo fare una transizione verso la centralità dei dati. E questa non è una transizione totale, sai, c'è ancora molto lavoro da fare là fuori, ma non stiamo davvero pensando in termini incentrati sui dati quando ne abbiamo bisogno, e le circostanze che si verificano quando siamo davvero obbligato a farlo.
Ora l'azienda comprende il valore dei dati, vogliono sbloccarli, quindi come lo faremo? Quindi, come possiamo fare la transizione? Bene, mettiamo i dati al centro dei processi di sviluppo. E permettiamo all'azienda di guidare con requisiti di informazione. E comprendiamo che nessuno capisce i dati di origine esistenti all'inizio del progetto. Si potrebbe sostenere che la struttura dei dati e i dati stessi ci sono arrivati rispettivamente attraverso l'IT e le operazioni, quindi dovremmo saperlo, ma in realtà no. Questo è uno sviluppo incentrato sui dati. Quindi, dobbiamo pensare a dove e come facciamo la modellizzazione dei dati in un mondo incentrato sui dati, dobbiamo disporre di cicli di feedback per gli utenti in termini di perfezionamento dei loro requisiti di informazione, così come facciamo scoperta dei dati e profilazione dei dati, prevedere l'analisi dei dati di origine e man mano che acquisiamo sempre più certezza sui nostri dati. E ora sto parlando di un progetto più tradizionale come un hub MDM o un data warehouse, non necessariamente i progetti di big data, anche se questo, a mio avviso, è ancora abbastanza vicino a quello. E quindi quei circuiti di feedback includono i modellatori di dati, sai, avanzano gradualmente il loro modello di dati e interagiscono con gli utenti per assicurarsi che i requisiti delle informazioni siano perfezionati in base a ciò che è possibile, ciò che è disponibile, dai dati di origine quando lo comprendono meglio, quindi non si tratta più del fatto che il modello di dati sia, sai, in uno stato che non è lì o completamente fatto, è una messa a fuoco graduale di esso.
Allo stesso modo, più a valle di ciò abbiamo la garanzia della qualità in cui sviluppiamo regole per i test di qualità dei dati per assicurarci che i dati rientrino nei parametri sui quali stiamo formulando le ipotesi. Entrando, Eric si riferiva a cambiamenti nei dati di riferimento, che potrebbero accadere. Non vuoi essere, per così dire, una vittima a valle di una sorta di cambiamento non gestito in quell'area, quindi le regole di garanzia della qualità possono andare in post-produzione, monitoraggio continuo della qualità dei dati. Quindi puoi iniziare a vedere se saremo incentrati sui dati, in che modo lo sviluppo incentrato sui dati è abbastanza diverso da SDLC e Agile basati sulla funzionalità. E poi dobbiamo prestare attenzione anche alle opinioni aziendali. Abbiamo - e di nuovo questo riecheggia ciò che Eric stava dicendo - abbiamo un modello di dati che definisce un modello di story story per il nostro database, ma allo stesso tempo abbiamo bisogno di quei modelli concettuali, di quelle viste commerciali dei dati che tradizionalmente non sono state fatte in il passato. A volte, a mio avviso, abbiamo pensato che il modello di dati potesse fare tutto, ma dobbiamo avere la visione concettuale, la semantica e esaminare i dati, renderli attraverso un livello di astrazione che traduca il modello di archiviazione in azienda Visualizza. E, ancora una volta, tutte le cose di cui Eric stava parlando in termini di semantica, diventa importante per farlo, quindi abbiamo effettivamente attività di modellazione aggiuntive. Penso che sia interessante, sai, se sei arrivato nei ranghi come modellatore di dati come ho fatto io, e ancora, qualcosa di nuovo.
E infine vorrei dire che anche l'architettura più grande deve riflettere questa nuova realtà. L'MDM cliente tradizionale, ad esempio, è un po ', okay, portiamo i dati dei nostri clienti in un hub in cui possiamo avere un senso in termini di qualità dei dati veramente giusta per le applicazioni di back office. Che dal punto di vista della strategia aziendale è una specie di sbadiglio. Oggi, tuttavia, stiamo esaminando gli hub MDM dei clienti che contengono al loro interno dati aggiuntivi sul profilo del cliente, non solo i dati statici, che in realtà hanno un'interfaccia bidirezionale con le applicazioni di transazione del cliente. Sì, supportano ancora il back office, ma ora conosciamo anche questi comportamenti dei nostri clienti. È più costoso da costruire. Questo è più complesso da costruire. Ma è guidato dal business in un modo in cui il tradizionale cliente MDM non lo è. Stai negoziando un orientamento verso il business con progetti più semplici che sono più facili da implementare, ma per il business, questo è quello che vogliono vedere. Siamo davvero in una nuova era e penso che ci sia un certo numero di livelli che dobbiamo rispondere all'architettura dei dati che guida il business e penso che sia un momento molto eccitante per fare le cose.
Quindi grazie a te, Rebecca.
Rebecca Jozwiak: Grazie Malcolm, e mi è piaciuto molto quello che hai detto sui modelli di dati deve alimentare la visione aziendale, perché, in qualche modo diverso da quello che stavi dicendo, dove l'IT ha tenuto le redini per così tanto tempo e non è più così che la cultura deve cambiare. E sono abbastanza sicuro che ci fosse un cane in background che era d'accordo con te al 100%. E con ciò ho intenzione di passare la palla a Ron. Sono davvero entusiasta di vedere la tua demo. Ron, il pavimento è tuo.
Ron Huizenga: Grazie mille e prima di passare a questo, esaminerò alcune diapositive e poi un po 'di demo perché, come hanno sottolineato Eric e Malcolm, questo è un argomento molto ampio e profondo, e con ciò di cui stiamo parlando oggi ne stiamo solo raschiando la superficie perché ci sono così tanti aspetti e così tante cose che dobbiamo davvero considerare e guardare da un'architettura guidata dal business. E il nostro approccio è quello di rendere davvero quel modello basato su un modello e ricavare un vero valore dai modelli perché puoi usarli come veicolo di comunicazione e come un livello per abilitare altri sistemi. Che si tratti di un'architettura orientata ai servizi o di altre cose, il modello diventa davvero la linfa vitale di ciò che sta succedendo, con tutti i metadati attorno e i dati che hai nella tua azienda.
Ciò di cui voglio parlare, però, è quasi fare un passo indietro, perché Malcolm ha toccato parte della storia del modo in cui le soluzioni si sono evolute e quel tipo di cose. Un modo per sottolineare davvero quanto sia importante avere un'architettura di dati audio è un caso d'uso in cui mi imbattevo molto spesso quando ero consulente prima di entrare in un ruolo di gestione del prodotto, e cioè, andavo nelle organizzazioni indipendentemente dal fatto che stessero eseguendo la trasformazione aziendale o semplicemente sostituendo alcuni sistemi esistenti e quel tipo di cose, e divenne subito evidente come le organizzazioni scarsamente comprendessero i propri dati. Se prendi un caso d'uso particolare come questo, che tu sia un consulente o forse è una persona che ha appena iniziato con un'organizzazione, o la tua organizzazione è stata costruita nel corso degli anni con l'acquisizione di aziende diverse, quello che finisci è rapidamente un ambiente molto complesso, con una serie di nuove tecnologie diverse, oltre a tecnologie legacy, soluzioni ERP e tutto il resto.
Quindi una delle cose che possiamo davvero fare con il nostro approccio alla modellazione è rispondere alla domanda, come posso dare un senso a tutto ciò? Possiamo davvero iniziare a mettere insieme le informazioni, in modo che l'azienda possa sfruttare le informazioni che abbiamo correttamente. E viene fuori, che cosa abbiamo là fuori in quegli ambienti? Come posso usare i modelli per scovare le informazioni di cui ho bisogno e comprenderle meglio? E poi abbiamo i tipi tradizionali di metadati per tutte le diverse cose come i modelli di dati relazionali, e siamo abituati a vedere cose come definizioni e dizionari di dati, sai, tipi di dati e quel tipo di cose. Ma che dire dei metadati aggiuntivi che vuoi acquisire per dare ancora più significato ad esso? Ad esempio, quali entità sono in realtà i candidati che dovrebbero essere oggetti dati di riferimento, che dovrebbero essere oggetti master di gestione dei dati e quei tipi di cose e collegarli insieme. E come scorre l'informazione attraverso l'organizzazione? I dati derivano da come vengono consumati sia dal punto di vista del processo, sia da una discendenza di dati in termini di percorso delle informazioni attraverso le nostre attività e di come si fa strada attraverso i diversi sistemi o attraverso gli archivi di dati, quindi sappiamo quando stiamo costruendo le soluzioni I, o quel tipo di cose, stiamo effettivamente consumando le informazioni corrette per l'attività a portata di mano.
E poi è molto importante, come possiamo convincere tutti quegli stakeholder a collaborare, e in particolare gli stakeholder aziendali perché sono quelli che ci danno il vero significato di cosa sono quei dati. L'azienda, alla fine, possiede i dati. Forniscono le definizioni per i vocabolari e le cose di cui parlava Eric, quindi abbiamo bisogno di un posto dove legare tutto questo insieme. E il modo in cui lo facciamo è attraverso la nostra modellazione dei dati e architetture di repository di dati.
Ho intenzione di toccare alcune cose. Parlerò di ER / Studio Enterprise Team Edition. Principalmente parlerò del prodotto di architettura dei dati in cui eseguiamo la modellazione dei dati e quel tipo di cose, ma ci sono molti altri componenti della suite che toccherò solo brevemente. Vedrai uno snippet di Business Architect, in cui possiamo fare modelli concettuali, ma possiamo anche fare modelli di processi aziendali e possiamo legare quei modelli di processo per collegare i dati reali che abbiamo nei nostri modelli di dati. Ci aiuta davvero a mettere insieme quel legame. Software Architect ci consente di realizzare costrutti aggiuntivi come alcuni modelli UML e quei tipi di cose per fornire logiche di supporto ad alcuni di quegli altri sistemi e processi di cui stiamo parlando. Ma molto importante mentre ci spostiamo verso il basso abbiamo il repository e il server di squadra, e ne parlerò come una specie di due metà della stessa cosa. Il repository è il luogo in cui archiviamo tutti i metadati modellati e tutti i metadati aziendali in termini di glossari e termini commerciali. E poiché abbiamo questo ambiente basato su repository, possiamo quindi ricucire tutte queste cose diverse nello stesso ambiente e quindi possiamo effettivamente renderle disponibili per i consumi, non solo per la gente tecnica ma anche per gli uomini d'affari. Ed è così che iniziamo davvero a guidare la collaborazione.
E poi l'ultimo pezzo di cui parlerò brevemente è, quando entri in questi ambienti, non sono solo i database che hai là fuori. Avrai un numero di database, archivi di dati, avrai anche molti manufatti legacy. Forse le persone hanno usato Visio o altri diagrammi per mappare alcune cose. Forse hanno avuto altri strumenti di modellazione e quel tipo di cose. Quindi ciò che possiamo fare con MetaWizard è in realtà estrarre alcune di quelle informazioni e portarle nei nostri modelli, renderle attuali ed essere in grado di usarle, consumarle, di nuovo in modo attuale, piuttosto che farle sedere lì fuori. Ora diventa una parte attiva dei nostri modelli di lavoro, il che è molto importante.
Quando entri in un'organizzazione, come ho detto, ci sono molti sistemi diversi, molte soluzioni ERP, soluzioni dipartimentali non corrispondenti. Molte organizzazioni utilizzano anche soluzioni SaaS, anch'esse controllate e gestite esternamente, quindi non controlliamo i database e quei tipi di cose negli host su questi, ma dobbiamo ancora sapere come sono i dati e, ovviamente, i metadati attorno a quello. Ciò che troviamo anche è un sacco di sistemi legacy obsoleti che non sono stati ripuliti a causa di quell'approccio basato sul progetto di cui Malcolm aveva parlato. È sorprendente il modo in cui negli ultimi anni le organizzazioni faranno girare i progetti, sostituiranno un sistema o una soluzione, ma spesso non è rimasto abbastanza budget per smantellare le soluzioni obsolete, quindi ora sono solo in mezzo. E dobbiamo capire di cosa possiamo effettivamente sbarazzarci nel nostro ambiente e che cosa è utile andare avanti. E questo si lega alla scarsa strategia di disattivazione. È parte integrante di quella stessa cosa.
Ciò che troviamo anche, dal momento che molte organizzazioni sono state create da tutte queste diverse soluzioni, è che vediamo molte interfacce punto-punto con molti dati che si spostano in diversi punti. Dobbiamo essere in grado di razionalizzare ciò e capire quella discendenza di dati che ho citato brevemente in precedenza in modo da poter avere una strategia più coerente come l'utilizzo dell'architettura orientata ai servizi, bus di servizio aziendali e quel tipo di cose, per fornire le informazioni corrette a un tipo di modello di pubblicazione e sottoscrizione che utilizziamo correttamente in tutta la nostra attività. E poi, ovviamente, dobbiamo ancora fare una sorta di analisi, sia che utilizziamo data warehouse, data mart con ETL tradizionale o che utilizziamo alcuni dei nuovi data lake. Tutto si riduce alla stessa cosa. Sono tutti i dati, sia che si tratti di big data, sia che si tratti di dati tradizionali nei database relazionali, dobbiamo riunire tutti questi dati in modo da poterli gestire e sapere con cosa abbiamo a che fare nei nostri modelli.
Ancora una volta, la complessità che faremo è che abbiamo una serie di passaggi che vogliamo essere in grado di fare. Prima di tutto, entri e potresti non avere quei progetti su come appare quel panorama informativo. In uno strumento di modellizzazione dei dati come ER / Studio Data Architect, per prima cosa eseguirai un sacco di reverse engineering in termini di puntamento alle fonti di dati che sono là fuori, portali dentro e poi effettivamente collegali in più rappresentativi modelli che rappresentano l'intero business. L'importante è che vogliamo essere in grado di scomporre anche questi modelli lungo le linee di business in modo da poterli mettere in relazione in blocchi più piccoli, a cui i nostri uomini d'affari possono anche fare riferimento, e i nostri analisti aziendali e altri stakeholder che stanno lavorando su di essa.
Gli standard di denominazione sono estremamente importanti e ne sto parlando in un paio di modi diversi qui. Nominare gli standard in termini di come nominiamo le cose nei nostri modelli. È abbastanza facile da fare nei modelli logici, dove abbiamo una buona convenzione di denominazione e un buon dizionario dei dati per i nostri modelli, ma poi vediamo anche convenzioni di denominazione diverse per molti di questi modelli fisici che stiamo introducendo. ingegnere inverso, abbastanza spesso vediamo nomi abbreviati e quel tipo di cose di cui parlerò. E dobbiamo tradurli in nomi inglesi significativi che siano significativi per l'azienda in modo da poter capire quali sono tutti questi dati che abbiamo nell'ambiente. E poi le mappature universali è come le uniamo insieme.
Inoltre, dovremmo documentare e definire ulteriormente ed è qui che possiamo classificare ulteriormente i nostri dati con qualcosa chiamato Allegati, che ti mostrerò un paio di diapositive. E quindi chiudendo il ciclo, vogliamo applicare quel significato di business, che è dove leghiamo i nostri glossari aziendali e possiamo collegarli ai nostri diversi artefatti del modello, quindi sappiamo, quando parliamo di un certo termine commerciale, dove implementato nei nostri dati in tutta l'organizzazione. E infine, ho già parlato del fatto che abbiamo bisogno di tutto questo come repository basato su molte funzionalità di collaborazione e pubblicazione, in modo che i nostri stakeholder possano utilizzarlo. Parlerò abbastanza rapidamente dell'ingegneria inversa. In un certo senso ti ho già dato un rapido esempio. Te lo mostrerò in una vera demo solo per mostrarti alcune delle cose che possiamo portare lì.
E voglio parlare di alcuni dei diversi tipi di modello e diagrammi che produrremmo in questo tipo di scenario. Ovviamente faremo i modelli concettuali in molti casi; Non ci passerò molto tempo. Voglio davvero parlare di modelli logici, modelli fisici e tipi specializzati di modelli che possiamo creare. Ed è importante poterli creare tutti nella stessa piattaforma di modellazione in modo da poterli ricucire. Ciò include modelli dimensionali e anche modelli che utilizzano alcune delle nuove origini dati, come NoSQL che ti mostrerò. E poi, che aspetto ha il modello di lignaggio dei dati? E come inseriremo tali dati in un modello di processo aziendale, è ciò di cui parleremo dopo.
Passerò a un ambiente di modellazione qui solo per darti una panoramica molto elevata e rapida. E credo che dovresti essere in grado di vedere il mio schermo ora. Prima di tutto voglio parlare solo di un tipo tradizionale di modello di dati. E il modo in cui vogliamo organizzare i modelli quando li introduciamo, è che vogliamo essere in grado di scomporli. Quindi quello che vedi qui sul lato sinistro è che abbiamo modelli logici e fisici in questo particolare file modello. La prossima cosa è che possiamo scomporlo lungo le scomposizioni aziendali, quindi è per questo che vedi le cartelle. Quelli azzurri sono modelli logici e quelli verdi sono modelli fisici. E possiamo anche eseguire il drill down, quindi all'interno di ER / Studio, se si dispone di una scomposizione aziendale, è possibile raggiungere tutti i livelli di profondità o sotto-modelli desiderati e le modifiche apportate ai livelli inferiori si riflettono automaticamente al livello superiore livelli. Quindi diventa un ambiente di modellazione molto potente molto rapidamente.
Qualcosa che voglio anche sottolineare che è molto importante iniziare a mettere insieme queste informazioni è che possiamo avere più modelli fisici che corrispondono anche a un modello logico. Molto spesso potresti avere un modello logico ma potresti avere modelli fisici su piattaforme diverse e quel tipo di cose. Forse ne è un'istanza di SQL Server, forse un'altra è un'istanza di Oracle. Abbiamo la capacità di legare tutto questo nello stesso ambiente di modellazione. E ancora una volta, quello che ho qui è un vero modello di data warehouse che può, ancora una volta, essere nello stesso ambiente di modellazione o possiamo averlo nel repository e collegarlo anche in diverse cose.
Quello che volevo davvero mostrarti su questo è alcune delle altre cose e altre varianti dei modelli in cui entriamo. Quindi, quando entriamo in un modello di dati tradizionale come questo, siamo abituati a vedere le entità tipiche con le colonne, i metadati e quel tipo di cose, ma quel punto di vista varia molto rapidamente quando iniziamo a gestire alcune di queste nuove tecnologie NoSQL, o come ad alcune persone piace ancora chiamarli, le tecnologie dei big data.
Quindi ora diciamo che abbiamo anche Hive nel nostro ambiente. Se eseguiamo il reverse engineering da un ambiente Hive - e possiamo inoltrare e reverse engineering da Hive con questo stesso identico strumento di modellazione - vediamo qualcosa che è un po 'diverso. Vediamo ancora tutti i dati come costrutti lì, ma il nostro TDL è diverso. Quelli di voi che sono abituati a vedere SQL, quello che vedresti ora è Hive QL, che è molto simile a SQL ma con lo stesso strumento sei ora in grado di iniziare a lavorare con i diversi linguaggi di scripting. Quindi puoi modellare in questo ambiente, generarlo nell'ambiente Hive, ma altrettanto importante, nello scenario che ho descritto, puoi decodificare tutto e dargli un senso e iniziare anche a ricucirlo .
Prendiamo un altro che è un po 'diverso. MongoDB è un'altra piattaforma che supportiamo in modo nativo. E quando inizi ad entrare nei tipi di ambienti JSON in cui hai archivi di documenti, JSON è un animale diverso e ci sono costrutti in quello, che non corrispondono ai modelli relazionali. Presto inizierai a trattare concetti come oggetti incorporati e matrici incorporate di oggetti quando inizi a interrogare il JSON e quei concetti non esistono nella notazione relazionale tradizionale. Quello che abbiamo fatto qui è che abbiamo effettivamente esteso la notazione e il nostro catalogo per essere in grado di gestirlo nello stesso ambiente.
Se guardi qui a sinistra, invece di vedere cose come entità e tabelle, li chiamiamo oggetti. E vedi notazioni diverse. Qui vedi ancora i tipi tipici di notazioni di riferimento, ma queste entità blu che sto mostrando in questo particolare diagramma sono in realtà oggetti incorporati. E mostriamo diverse cardinalità. La cardinalità del diamante significa che è un oggetto da un lato, ma la cardinalità di uno significa che abbiamo, all'interno dell'editore se seguiamo quella relazione, abbiamo un oggetto indirizzo incorporato. Nell'interrogare il JSON abbiamo scoperto che è esattamente la stessa struttura di oggetti incorporata nel client, ma che in realtà è incorporata come una matrice di oggetti. Lo stiamo vedendo, non solo attraverso i connettori stessi, ma se guardi le entità reali vedrai che vedi gli indirizzi sotto patron che lo classificano anche come una matrice di oggetti. Ottieni un punto di vista molto descrittivo su come farlo.
E di nuovo, ora ciò che abbiamo visto finora in pochi secondi sono i tradizionali modelli relazionali a più livelli, possiamo fare la stessa cosa con Hive, possiamo fare la stessa cosa con MongoDB e altre fonti di big data come bene. Ciò che possiamo anche fare e che ti mostrerò molto rapidamente è che ho parlato del fatto di portare cose da altre aree diverse. Suppongo che sto per importare un modello da un database o decodificarlo, ma lo porterò da metadati esterni. Solo per darti un punto di vista molto veloce di tutti i diversi tipi di cose che possiamo iniziare a introdurre.
Come vedi, abbiamo una miriade di cose con cui possiamo effettivamente portare i metadati nel nostro ambiente di modellazione. A partire da cose come anche Amazon Redshift, Cassandra, molte altre piattaforme di big data, quindi vedi molte di queste elencate. Questo è in ordine alfabetico. Stiamo vedendo molte fonti di big data e quel tipo di cose. Stiamo anche vedendo un sacco di ambienti di modellazione tradizionali o precedenti che possiamo effettivamente portare attraverso quei metadati. Se passo qui - e non ho intenzione di passare del tempo su ognuno di essi - vediamo molte cose diverse da cui possiamo portarlo, in termini di piattaforme di modellazione e piattaforme di dati. E qualcosa che è molto importante da realizzare qui è un'altra parte che possiamo fare quando iniziamo a parlare della discendenza di dati, su Enterprise Team Edition possiamo anche interrogare le fonti ETL, sia che si tratti di mappature Talend o SQL Server Information Services, possiamo lo inseriamo effettivamente per avviare anche i nostri diagrammi di discendenza di dati e tracciare un quadro di ciò che sta accadendo in quelle trasformazioni. Complessivamente, abbiamo oltre 130 di questi diversi ponti che fanno effettivamente parte del prodotto Enterprise Team Edition, quindi ci aiuta davvero a riunire tutti gli artefatti in un ambiente di modellazione molto rapidamente.
Ultimo ma non meno importante, voglio anche parlare del fatto che non possiamo perdere di vista il fatto che abbiamo bisogno di altri tipi di costrutti se stiamo facendo data warehousing o qualsiasi tipo di analisi. Vogliamo ancora avere la capacità di fare cose come modelli dimensionali in cui abbiamo tabelle dei fatti e abbiamo dimensioni e quel tipo di cose. Una cosa che voglio mostrarti è che possiamo anche avere estensioni ai nostri metadati che ci aiutano a classificare quali sono i tipi di dimensioni e tutto il resto. Quindi, se guardo la scheda dei dati dimensionali qui, ad esempio, su uno di questi, in realtà rileverà automaticamente, in base al modello di modello che vede, e ti darà un punto di partenza se pensa che sia una dimensione o un tabella dei fatti. Ma oltre a ciò, ciò che possiamo fare è all'interno delle dimensioni e quel tipo di cose che abbiamo anche diversi tipi di dimensioni che possiamo usare per classificare i dati anche in un tipo di ambiente di data warehousing. Funzionalità così potenti che stiamo ricucendo tutto insieme.
Ho intenzione di saltare a questo dato che sono nell'ambiente demo in questo momento e ti mostrerò un paio di altre cose prima di tornare alle diapositive. Una delle cose che abbiamo recentemente aggiunto a ER / Studio Data Architect è che ci siamo imbattuti in situazioni - e questo è un caso d'uso molto comune quando si lavora su progetti - gli sviluppatori pensano in termini di oggetti, mentre i nostri dati i modellatori tendono a pensare in termini di tabelle ed entità e quel tipo di cose. Questo è un modello di dati molto semplicistico, ma rappresenta alcuni concetti di base, in cui gli sviluppatori o anche gli analisti aziendali o gli utenti aziendali, potrebbero pensarli come oggetti o concetti aziendali diversi. Fino ad ora è stato molto difficile classificarli, ma ciò che abbiamo effettivamente fatto in ER / Studio Enterprise Team Edition, nella versione 2016, è che ora abbiamo un concetto chiamato Business Data Objects. E ciò che ci consente di fare è che ci consente di incapsulare gruppi di entità o tabelle in veri e propri oggetti business.
Ad esempio, quello che abbiamo qui in questa nuova vista è l'intestazione dell'ordine d'acquisto e la riga ordine sono stati messi insieme ora, sono incapsulati come un oggetto, li considereremmo come un'unità di lavoro quando persistiamo i dati e li riuniamo, quindi ora è molto facile metterlo in relazione con un pubblico diverso. Sono riutilizzabili in tutto l'ambiente di modellazione. Sono un vero oggetto, non solo un costrutto di disegno, ma abbiamo anche l'ulteriore vantaggio che quando stiamo effettivamente comunicando dal punto di vista della modellazione, possiamo comprimere selettivamente o espanderli in modo da poter produrre una vista riepilogativa per dialoghi con determinati pubblici di stakeholder, e, naturalmente, possiamo anche mantenere la visione più dettagliata come stiamo vedendo qui per un pubblico più tecnico. Ci dà davvero un ottimo veicolo di comunicazione. Ciò che vediamo ora è combinare diversi tipi di modelli diversi, aumentandoli con il concetto di oggetti di dati aziendali, e ora parlerò di come applichiamo effettivamente un significato più a questi tipi di cose e di come li uniamo nel nostro ambienti generali.
Sto solo cercando di trovare il mio WebEx qui in modo da poterlo fare. Ed eccoci di nuovo alle diapositive Hot Tech. Vado avanti velocemente di alcune diapositive qui perché le hai già viste nella dimostrazione del modello stesso. Voglio parlare molto rapidamente degli standard di denominazione. Vogliamo applicare e applicare diversi standard di denominazione. Quello che vogliamo fare è, abbiamo la capacità di archiviare effettivamente modelli di standard di denominazione nei nostri repository per fondamentalmente costruire quel significato attraverso, attraverso parole o frasi o persino abbreviazioni, e ricondurli a un tipo inglese di parole significative. Useremo i termini commerciali, le abbreviazioni per ciascuno e possiamo specificare l'ordine, i casi e aggiungere prefissi e suffissi. Il tipico caso d'uso per questo è in genere quando le persone hanno costruito un modello logico e poi in realtà hanno continuato a creare un modello fisico in cui avrebbero potuto usare abbreviazioni e tutto il resto.
La cosa bella è che è altrettanto potente, ancora più potente al contrario, se possiamo solo dire quali erano alcuni di quegli standard di denominazione su alcuni di quei database fisici che abbiamo invertito, possiamo prendere quelle abbreviazioni, trasformarle in più lunghe parole e riportale indietro in frasi inglesi. In realtà ora possiamo derivare nomi propri per l'aspetto dei nostri dati. Come ho detto, il tipico caso d'uso è che andremmo avanti, dal logico al fisico, e mapperemmo gli archivi di dati e quel tipo di cose. Se guardi lo screenshot sul lato destro, vedrai che ci sono nomi abbreviati dai nomi delle fonti e quando abbiamo applicato un modello di standard di denominazione, in realtà abbiamo più nomi completi. E potremmo inserire spazi e tutto il resto se vogliamo, a seconda del modello di standard di denominazione che abbiamo usato. Possiamo farlo sembrare come vogliamo che appaia nei nostri modelli. Solo quando sappiamo come si chiama qualcosa possiamo effettivamente iniziare ad associarvi delle definizioni, perché se non sappiamo cosa sia, come possiamo applicare un significato ad esso?
La cosa bella è che possiamo effettivamente invocare questo quando facciamo tutti i tipi di cose. Ho parlato di reverse engineering, possiamo effettivamente invocare simultaneamente modelli di standard di denominazione quando eseguiamo reverse engineering. Quindi in una serie di passaggi attraverso una procedura guidata, ciò che siamo in grado di fare è, se sappiamo quali sono le convenzioni, possiamo decodificare un database fisico, lo riporterà come modelli fisici in un ambiente di modellazione ed è applicherò anche quelle convenzioni di denominazione. Vedremo quindi quali sono le rappresentazioni inglesi dei nomi nel modello logico corrispondente nell'ambiente. Possiamo anche farlo e combinarlo con la generazione di schemi XML in modo da poter prendere un modello e persino spingerlo fuori con le nostre abbreviazioni, sia che stiamo facendo quadri SOA o quel tipo di cose, quindi possiamo anche spingere fuori convenzioni di denominazione diverse che abbiamo effettivamente memorizzato nel modello stesso. Ci offre molte funzionalità molto potenti.
Ancora una volta, ecco un esempio di come sarebbe se avessi un modello. Questo dimostra che avevo EMP per "dipendente", SAL per "stipendio", PLN per "piano" in una convenzione sugli standard di denominazione. Posso anche applicarli per farli funzionare in modo interattivo mentre sto costruendo modelli e inserendo le cose. Se stavo usando questa abbreviazione e ho digitato "Piano di stipendio dei dipendenti" sul nome dell'entità, agirebbe con il modello degli standard di denominazione Ho definito qui, mi avrebbe dato EMP_SAL_PLN mentre stavo creando le entità e mi avrebbe dato subito i nomi fisici corrispondenti.
Ancora una volta, ottimo anche per la progettazione e il forward engineering. Abbiamo un concetto davvero unico ed è qui che iniziamo davvero a riunire questi ambienti. E si chiama Universal Mappings. Dopo aver portato tutti questi modelli nel nostro ambiente, cosa siamo in grado di fare, supponendo che ora abbiamo applicato queste convenzioni di denominazione e che siano facili da trovare, ora possiamo usare un costrutto chiamato Universal Mappings in ER /Studio. Siamo in grado di collegare entità tra modelli. Ovunque vediamo "cliente" - probabilmente avremo "cliente" in molti sistemi diversi e molti database diversi - possiamo iniziare a collegare tutti questi insieme in modo che quando ci sto lavorando in un modello I può vedere dove sono le manifestazioni dei clienti negli altri modelli. E poiché abbiamo il livello del modello che lo rappresenta, possiamo persino collegarlo a origini dati e portarlo giù nelle nostre indagini su dove vengono utilizzati anche i database. Ci dà davvero la possibilità di legare tutto questo in modo molto coerente.
Ti ho mostrato gli oggetti dati aziendali. Voglio anche parlare delle estensioni dei metadati, che chiamiamo allegati, molto rapidamente. Quello che fa è che ci dà la possibilità di creare metadati aggiuntivi per i nostri oggetti modello. Abbastanza spesso imposto questo tipo di proprietà per scacciare molte cose diverse dal punto di vista della governance e della qualità dei dati, e anche per aiutarci con le politiche di gestione e conservazione dei dati principali. L'idea di base è che crei queste classificazioni e puoi collegarle ovunque tu voglia, a livello di tabella, a livello di colonna, quel tipo di cose. Il caso d'uso più comune, ovviamente, è che le entità sono tabelle e quindi posso definire: quali sono i miei oggetti di dati principali, quali sono le mie tabelle di riferimento, quali sono le mie tabelle transazionali? Dal punto di vista della qualità dei dati posso fare delle classificazioni in termini di importanza per l'azienda in modo da poter dare la priorità alle attività di pulizia dei dati e quel tipo di cose.
Qualcosa che viene spesso trascurato è, qual è la politica di conservazione per i diversi tipi di dati nella nostra organizzazione? Possiamo configurarli e possiamo effettivamente collegarli ai diversi tipi di artefatti informativi nel nostro ambiente di modellazione e, naturalmente, anche nel nostro repository. Il bello è che questi allegati vivono nel nostro dizionario dei dati, quindi quando utilizziamo dizionari di dati aziendali nell'ambiente, possiamo collegarli a più modelli. Dobbiamo definirli solo una volta e possiamo sfruttarli ancora e ancora attraverso i diversi modelli nel nostro ambiente. Questo è solo uno screenshot rapido per dimostrare che puoi effettivamente specificare quando fai un allegato, a cosa sono collegati tutti i pezzi. E questo esempio qui è in realtà un elenco di valori, quindi quando entrano puoi scegliere da un elenco di valori, hai un sacco di controllo nell'ambiente di modellazione di ciò che viene scelto e puoi anche impostare ciò che è predefinito valore è se un valore non viene selezionato. Quindi un sacco di potere lì. Vivono nel dizionario dei dati.
Qualcosa che voglio mostrarti un po 'più in basso in questa schermata, inoltre vedi gli allegati che si presentano nella parte superiore, sotto di essa vedi le informazioni sulla sicurezza dei dati. Possiamo effettivamente applicare politiche di sicurezza dei dati anche alle diverse informazioni nell'ambiente. Per diverse mappature di conformità, classificazioni di sicurezza dei dati, ne forniamo alcune fuori dalla scatola che puoi semplicemente generare e iniziare a utilizzare, ma puoi anche definire le tue mappature e standard di conformità. Sia che tu stia facendo HIPAA o una qualsiasi delle altre iniziative là fuori. E puoi davvero iniziare a costruire questo set molto ricco di metadati nel tuo ambiente.
E poi il Glossario e i Termini - è qui che è legato il significato del business. Abbastanza spesso abbiamo dizionari di dati là fuori che abbastanza spesso un'organizzazione utilizza come punto di partenza per iniziare a scovare glossari, ma la terminologia e la verbosità sono spesso molto tecnico. Quindi quello che possiamo fare è che, se lo desideriamo, possiamo usarli come punto di partenza per scovare i glossari, ma vogliamo davvero che l'azienda li possieda. Quello che abbiamo fatto nell'ambiente server del team è che abbiamo dato la possibilità alle persone di creare definizioni aziendali e quindi di collegarle ai diversi artefatti a cui corrispondono anche nell'ambiente di modellazione. Riconosciamo anche il punto che è stato discusso in precedenza, ovvero, più persone si digitano, maggiore è il potenziale di errore umano. Quello che facciamo anche nella nostra struttura di glossario è, uno, supportiamo una gerarchia di glossario, quindi possiamo avere diversi tipi di glossario o diversi tipi di cose nell'organizzazione, ma altrettanto importante, è se hai già alcune di queste fonti là fuori con i termini e tutto ciò che è definito, possiamo effettivamente fare un'importazione CSV per estrarre questi nel nostro ambiente di modellazione, e anche il nostro server di squadra o il nostro glossario, e quindi iniziare il collegamento da lì. E ogni volta che qualcosa viene cambiato, c'è una traccia di controllo completa di ciò che erano le immagini prima e dopo, in termini di definizioni e tutto il resto, e ciò che vedrai arrivare nel prossimo futuro è anche più un flusso di lavoro di autorizzazione così possiamo davvero controllare chi ne è responsabile, le approvazioni da parte di comitati o individui e quel tipo di cose, per rendere il processo di governance ancora più solido mentre andiamo avanti.
Ciò che fa anche questo per noi è quando abbiamo questi termini nel glossario del nostro server del team, questo è un esempio di modifica in un'entità nel modello stesso che ho introdotto qui. Può avere termini collegati, ma ciò che facciamo è anche se ci sono parole che si trovano in quel glossario che compaiono nelle note o nelle descrizioni di ciò che abbiamo nelle nostre entità qui, quelle vengono mostrate automaticamente in un colore ipertestuale più chiaro, e se noi passandoci sopra con il mouse, possiamo effettivamente vedere la definizione anche dal glossario aziendale. Ci fornisce anche informazioni più ricche quando le consumiamo, con tutti i termini del glossario disponibili. Aiuta davvero ad arricchire l'esperienza e ad applicare il significato a tutto ciò con cui stiamo lavorando.
Quindi, ancora una volta, è stato un flyby molto veloce. Ovviamente potremmo passare dei giorni su questo mentre approfondiamo le diverse parti, ma questo è un sorvolo molto veloce sulla superficie. Quello che ci impegniamo davvero a fare è capire come appaiono questi ambienti di dati complessi. Vogliamo migliorare la visibilità di tutti questi artefatti di dati e collaborare per scacciarli con ER / Studio. Vogliamo consentire modelli di dati più efficienti e automatizzati. E questo è tutti i tipi di dati di cui stiamo parlando, che si tratti di big data, dati relazionali tradizionali, archivi di documenti o altro. E ancora una volta, l'abbiamo realizzato perché abbiamo potenti capacità di ingegneria inversa e in avanti per le diverse piattaforme e gli altri strumenti che potresti avere là fuori. E si tratta di condividere e comunicare in tutta l'organizzazione con tutte le parti interessate. È qui che applichiamo il significato attraverso gli standard di denominazione. Quindi applichiamo le definizioni attraverso i nostri glossari aziendali. E quindi possiamo fare ulteriori classificazioni per tutte le altre nostre capacità di governance con le estensioni di metadati come estensioni di qualità dei dati, classificazioni per la gestione dei dati master o qualsiasi altro tipo di classificazione che si desidera applicare a tali dati. E quindi possiamo sintetizzare ulteriormente e migliorare ulteriormente la comunicazione con gli oggetti di dati aziendali, con il pubblico di diverse parti interessate, in particolare tra modellisti e sviluppatori.
E ancora, ciò che è molto importante in questo è, dietro a tutto c'è un repository integrato con capacità di gestione del cambiamento molto robuste. Non ho avuto tempo di mostrarlo oggi perché diventa abbastanza complesso, ma il repository ha funzionalità di gestione delle modifiche e audit trail molto robuste. Puoi fare rilasci nominati, puoi fare versioni nominate, e abbiamo anche la capacità per quelli di te che stanno gestendo il cambiamento, possiamo legarlo direttamente alle tue attività. Oggi abbiamo la possibilità di inserire attività e associare le modifiche del modello alle attività, proprio come gli sviluppatori assocerebbero le loro modifiche al codice alle attività o alle storie utente con cui stanno lavorando.
Ancora una volta, questa è stata una panoramica molto rapida. Spero sia stato abbastanza per stimolare il tuo appetito in modo che possiamo impegnarci in conversazioni molto più profonde sulla divisione di alcuni di questi argomenti mentre andiamo avanti in futuro. Grazie per il tuo tempo e di nuovo a te, Rebecca.
Rebecca Jozwiak: Grazie, Ron, è stato fantastico e ho alcune domande da parte del pubblico, ma voglio dare ai nostri analisti la possibilità di affondare i denti in quello che hai da dire. Eric, vado avanti e forse se vuoi affrontare questa diapositiva, o un'altra, perché non vai avanti prima? O qualsiasi altra domanda.
Eric Little: certo. Scusa, qual era la domanda, Rebecca? Vuoi che ti chieda qualcosa di specifico o …?
Rebecca Jozwiak: So che inizialmente hai avuto alcune domande per Ron. Se vuoi chiedere ora a lui di rivolgersi a qualcuno di questi, o alcuni di essi fuori dalla tua diapositiva o qualcos'altro che ha suscitato il tuo interesse di cui vuoi chiedere? Informazioni sulle funzionalità di modellazione di IDERA.
Eric Little: Sì, quindi una delle cose, Ron, quindi, ragazzi, sembra che i diagrammi che state mostrando siano tipi generali di diagrammi di relazioni tra entità che normalmente usereste nella costruzione di un database, giusto?
Ron Huizenga: Sì, in generale, ma ovviamente abbiamo i tipi estesi per i negozi di documenti e quel tipo di cose. In realtà siamo passati dalla semplice notazione relazionale, in realtà abbiamo aggiunto ulteriori notazioni anche per quegli altri negozi.
Eric Little: C'è un modo in cui voi ragazzi potete usare tipi di modellazione basati su grafici, quindi c'è un modo per integrarsi, per esempio, supponiamo che io abbia qualcosa come un quadrante superiore, uno strumento di composizione TopBraid o che abbia fatto qualcosa in Protégé o, come i finanziari di FIBO, stanno facendo un sacco di lavoro in semantica, roba da RDF - c'è un modo per inserire quel tipo di modellazione del tipo di grafico entità-relazione in questo strumento e utilizzare vero?
Ron Huizenga: Stiamo effettivamente esaminando come possiamo gestire i grafici. Oggi non gestiamo esplicitamente i database dei grafi e quel tipo di cose, ma stiamo cercando modi per farlo per estendere i nostri metadati. Voglio dire, possiamo portare le cose attraverso XML e quel tipo di cose in questo momento, se almeno possiamo fare una sorta di rendering di XML per portarlo come punto di partenza. Ma stiamo cercando modi più eleganti per farlo entrare.
E ti ho anche mostrato quell'elenco di ponti di reverse engineering che abbiamo anche lì, quindi siamo sempre alla ricerca di estensioni di quei ponti anche per piattaforme specifiche. È uno sforzo continuo e continuo, se questo ha senso, iniziare ad abbracciare molti di questi nuovi costrutti e le diverse piattaforme là fuori. Ma posso dire che siamo decisamente all'avanguardia nel farlo. Le cose che ho mostrato su, ad esempio, MongoDB e quel tipo di cose, siamo il primo fornitore di modellazione di dati a farlo in modo nativo nel nostro prodotto.
Eric Little: Okay, sì. Quindi l'altra domanda che ho avuto per te, quindi, era in termini di governance e mantenimento del - come quando hai usato l'esempio, quando hai mostrato l'esempio della persona che è un "dipendente", credo che fosse un " stipendio "e poi hai un" piano ", c'è un modo, come gestisci, ad esempio, i diversi tipi di persone che potrebbero avere - supponiamo che tu abbia una grande architettura, giusto, supponiamo che tu abbia una grande impresa e le persone iniziano a mettere insieme le cose in questo strumento e hai un gruppo qui che ha la parola "impiegato" e un gruppo qui che ha la parola "lavoratore". E una persona qui dice "stipendio" e un'altra persona dice “salario”.
Come potete conciliare, gestire e governare questi tipi di distinzioni? Perché so come lo faremmo nel mondo dei grafici, sai, useresti elenchi di sinonimi o diresti che c'è un concetto e ha diversi attributi, o potresti dire nel modello SKOS che ho un'etichetta preferita e che ho numerose etichette alternative che posso usare. Come lo fate ragazzi?
Ron Huizenga: Lo facciamo in un paio di modi diversi, e prima di tutto parliamo prima della terminologia. Una delle cose che facciamo, ovviamente, è che vogliamo avere i termini definiti o sanzionati e nel glossario aziendale ovviamente è dove li vogliamo. E consentiamo anche collegamenti a sinonimi nel glossario aziendale, quindi quello che puoi fare è che puoi dire, ecco il mio termine, ma puoi anche definire quali sono tutti i sinonimi di quelli.
Ora la cosa interessante, ovviamente, è quando inizi a guardare attraverso questo vasto panorama di dati con tutti questi diversi sistemi che hai là fuori, non puoi semplicemente uscire lì e cambiare le tabelle corrispondenti e quei tipi di cose in corrisponde a quello standard di denominazione perché potrebbe essere un pacchetto acquistato, quindi non hai alcun controllo sulla modifica del database o altro.
Ciò che potremmo fare lì, oltre ad essere in grado di associare le definizioni del glossario, è attraverso quelle mappature universali di cui ho parlato, che cosa faremmo e che tipo di approccio raccomandato, è avere un modello logico generale che delinea ciò che questi diversi concetti aziendali sono di cui stai parlando. Collega i termini del glossario aziendale a quelli e la cosa bella è che ora hai questo costrutto che rappresenta un'entità logica per così dire, puoi quindi iniziare a collegare da quell'entità logica a tutte le implementazioni di quell'entità logica in i diversi sistemi.
Quindi, dove è necessario, puoi vedere, oh, "persona" qui si chiama "impiegato" in questo sistema. "Salario" qui è chiamato "salario" qui in questo altro sistema. Perché lo vedrai, vedrai tutte le diverse manifestazioni di quelle perché le hai collegate insieme.
Eric Little: Va bene, sì, capito. In questo senso, è sicuro dire che è un po 'come alcuni degli approcci orientati agli oggetti?
Ron Huizenga: In qualche modo. È un po 'più intenso di quello che, immagino, potresti dire. Voglio dire, potresti adottare l'approccio del collegamento manuale, del controllo, dell'ispezione e anche di tutti. L'unica cosa di cui non ho davvero avuto occasione di parlare - perché, ancora una volta, abbiamo molte capacità - abbiamo anche un'interfaccia di automazione completa nello strumento Data Architect stesso. E una funzionalità macro, che è davvero un linguaggio di programmazione nello strumento. Quindi possiamo effettivamente fare cose come scrivere macro, farlo uscire e interrogare cose e creare collegamenti per te. Lo usiamo per importare ed esportare informazioni, possiamo usarlo per cambiare cose o aggiungere attributi, eventi basati sul modello stesso, oppure possiamo usarlo per eseguire in batch per uscire e interrogare le cose e popolare effettivamente diversi costrutti nel modello. Quindi c'è un'interfaccia di automazione completa di cui anche le persone possono trarre vantaggio. E utilizzare le mappature universali con quelle sarebbe un modo molto potente per farlo.
Rebecca Jozwiak: Okay, grazie Ron e grazie Eric. Quelle erano grandi domande. So che stiamo correndo un po 'oltre la cima dell'ora, ma vorrei dare a Malcolm la possibilità di fare alcune domande a Ron. Malcolm?
Malcolm Chisholm: Grazie, Rebecca. Quindi, Ron, è molto interessante, vedo che ci sono molte capacità qui. Una delle aree a cui sono molto interessato è, ad esempio, se abbiamo un progetto di sviluppo, come vedi il modellatore di dati che utilizza queste capacità e lavora forse più collaborativamente con gli analisti aziendali, con un profiler di dati, con un analista della qualità dei dati e con gli sponsor aziendali che alla fine saranno responsabili degli effettivi requisiti di informazione nel progetto. In che modo il modellatore di dati rende davvero il progetto più efficace ed efficiente con le capacità che stiamo esaminando?
Ron Huizenga: Penso che una delle prime cose che devi fare lì sia come modellatore di dati - e non intendo scegliere alcuni dei modellatori, ma lo farò comunque - alcune persone hanno ancora l'impressione che il modellatore di dati è davvero il tipo di ruolo del gatekeeper, stiamo definendo come funziona, siamo le guardie che si assicurano che tutto sia corretto.
Ora c'è un aspetto di questo, che devi assicurarti di definire un'architettura di dati audio e tutto il resto. Ma la cosa più importante è come un modellatore di dati - e l'ho trovato un po 'ovviamente quando stavo consultando - è che devi diventare un facilitatore, quindi devi riunire queste persone.
Non sarà più un progetto iniziale, generare, costruire più database - quello che devi essere in grado di fare è che devi essere in grado di lavorare con tutti questi diversi gruppi di stakeholder, fare cose come reverse engineering, importare informazioni, avere altre persone collaborano, sia che si tratti di glossari o documentazione, di tutto ciò - e di essere un facilitatore per estrarre questo nel repository, collegare i concetti insieme nel repository e lavorare con quelle persone.
È davvero molto più di un tipo di ambiente collaborativo in cui anche attraverso la definizione di attività o persino discussioni o quel tipo di cose che abbiamo nel team server, le persone possono effettivamente collaborare, porre domande e arrivare ai prodotti finali finali che essi necessità della loro architettura dei dati e della loro organizzazione. Quel tipo di risposta?
Malcolm Chisholm: Sì, sono d'accordo. Sai, penso che l'abilità di facilitazione sia qualcosa che è molto desiderabile nei modellatori di dati. Sono d'accordo sul fatto che non sempre lo vediamo, ma penso che sia necessario e suggerirei che a volte c'è un'inclinazione a rimanere nel tuo angolo a fare la modellazione dei dati, ma devi davvero essere là fuori a lavorare con gli altri gruppi di stakeholder o semplicemente non capisci l'ambiente di dati con cui hai a che fare, e di conseguenza penso che il modello soffra. Ma questa è solo la mia opinione.
Ron Huizenga: Ed è interessante perché nella tua diapositiva hai menzionato qualcosa in precedenza sulla storia di come le aziende sono un po 'allontanate dall'IT perché non stavano fornendo le soluzioni in modo tempestivo e quel tipo di cose.
È molto interessante che nei miei successivi incarichi di consulenza, prima di diventare un product manager, la maggior parte dei progetti che ho fatto negli ultimi due anni prima, fossero sponsorizzati dalle imprese, dove erano proprio le aziende a guidarla e gli architetti dei dati e i modellisti non facevano parte dell'IT. Facevamo parte di un gruppo sponsorizzato dalle imprese ed eravamo lì come facilitatori che lavoravano con il resto dei team di progetto.
Malcolm Chisholm: Quindi penso che sia un punto molto interessante. Penso che stiamo iniziando a vedere un cambiamento nel mondo degli affari in cui l'azienda sta chiedendo, o pensando forse, non tanto quanto quello che faccio, essendo un processo, ma stanno anche iniziando a pensare a quali sono i dati con cui lavoro, quali sono i miei dati necessari, quali sono i dati di cui mi occupo come dati e fino a che punto possiamo ottenere prodotti e capacità IDERA per supportare tale punto di vista, e penso che le esigenze dell'azienda, anche anche se è un po 'nascente.
Ron Huizenga: Sono d'accordo con te e penso che lo stiamo vedendo andare sempre più in questo modo. Abbiamo visto un risveglio e tu l'hai toccato prima in termini di importanza dei dati. Abbiamo visto l'importanza dei dati nelle prime fasi dell'IT o nell'evoluzione dei database, quindi, come dici tu, siamo entrati in questo intero ciclo di gestione del processo - e il processo è estremamente importante, non fraintendermi lì - ma ora cosa è successo è quando ciò è accaduto, il tipo di dati di perdita di attenzione.
E ora le organizzazioni stanno realizzando che i dati sono davvero il punto focale. I dati rappresentano tutto ciò che stiamo facendo nella nostra attività, quindi dobbiamo assicurarci di disporre di dati precisi, di poter trovare le informazioni corrette di cui abbiamo bisogno per prendere le nostre decisioni. Perché non tutto proviene da un processo definito. Alcune delle informazioni sono un sottoprodotto di altre cose e dobbiamo ancora essere in grado di trovarle, sapere cosa significa ed essere in grado di tradurre i dati che vediamo alla fine in conoscenze che possiamo usare per guidare meglio le nostre attività.
Malcolm Chisholm: Giusto, e ora un'altra area con cui ho avuto a che fare è quella che definirei il ciclo di vita dei dati che è, sapete, se guardassimo al tipo di catena di fornitura di dati che attraversa un'azienda, inizieremmo con acquisizione o acquisizione dei dati, che potrebbe essere l'inserimento dei dati, ma potrebbe anche essere lo stesso, sto ricevendo dati dall'esterno dell'azienda da alcuni fornitori di dati.
E poi dall'acquisizione dei dati andiamo alla manutenzione dei dati dove sto pensando di standardizzare questi dati e di spedirli in luoghi dove è necessario. E poi l'uso dei dati, i punti reali in cui si trovano i dati, otterrai valore dai dati.
E ai vecchi tempi tutto ciò avveniva in un unico stile, ma oggi potrebbe essere, ad esempio, un ambiente di analisi, e poi oltre, un archivio, un negozio, in cui inseriamo i dati quando non siamo più ne ho bisogno e, infine, un tipo di processo di spurgo. In che modo ritieni che la modellizzazione dei dati si adatti alla gestione dell'intero ciclo di vita dei dati?
Ron Huizenga: Questa è un'ottima domanda e una cosa che non ho davvero avuto il tempo di approfondire in alcun dettaglio qui oggi, è ciò di cui stiamo davvero iniziando a parlare è la discendenza di dati. Quindi quello che siamo effettivamente in grado di fare è che abbiamo una capacità di discendenza di dati nei nostri strumenti e, come ho detto, possiamo effettivamente estrarne una parte dagli strumenti ETL, ma puoi anche mapparlo semplicemente disegnando la discendenza. Qualsiasi di questi modelli di dati o database che abbiamo acquisito e portato in modelli potremmo fare riferimento ai costrutti da quello nel nostro diagramma di discendenza di dati.
Quello che siamo in grado di fare è disegnare un flusso di dati, come dici tu, dall'origine alla destinazione, e attraverso il ciclo di vita complessivo di come i dati transitano attraverso i diversi sistemi e quello che troverai è, prendiamo i dipendenti 'dati - è uno dei miei preferiti basato su un progetto che ho realizzato anni fa. Ho lavorato con un'organizzazione che disponeva di dati sui dipendenti in 30 sistemi diversi. Ciò che abbiamo finito per fare lì - e Rebecca ha fatto apparire la diapositiva di lignaggio dei dati - questa è una diapositiva di lignaggio dei dati abbastanza semplicistica qui, ma ciò che siamo stati in grado di fare è stato quello di inserire tutte le strutture di dati, fare riferimento a loro nel diagramma, e quindi abbiamo può effettivamente iniziare a esaminare quali sono i flussi tra e come sono collegate queste diverse entità di dati in un flusso? E possiamo andare oltre. Questo fa parte di un flusso di dati o di un diagramma di discendenza che vediamo qui. Se vuoi andare oltre, abbiamo anche l'architetto aziendale parte di questa suite e la stessa cosa si applica lì.
Qualsiasi struttura di dati acquisita nell'ambiente di modellazione dei dati, a cui è possibile fare riferimento nello strumento di modellazione aziendale in modo che anche nei diagrammi dei modelli di business o dei processi aziendali, sia possibile fare riferimento a singoli archivi di dati se si desidera uscire da l'ambiente di modellazione dei dati e mentre li stai utilizzando nelle cartelle del tuo modello di processo aziendale, puoi anche specificare il CRUD anche su quelli, su come tali informazioni vengono consumate o prodotte e quindi possiamo iniziare a generare cose come resoconti e diagrammi di impatto e di analisi.
Ciò a cui stiamo puntando e abbiamo già molte capacità, ma una delle cose che abbiamo un tipo di goalpost che stiamo guardando, mentre continuiamo a far evolvere i nostri strumenti in futuro, è in grado di mappare quella discendenza di dati organizzativi end-to-end e l'intero ciclo di vita dei dati.
Malcolm Chisholm: Ok. Rebecca, posso permetterne un'altra?
Rebecca Jozwiak: Te lo permetterò ancora, Malcolm, vai avanti.
Malcolm Chisholm: Grazie mille. Pensando alla governance dei dati e pensando alla modellazione dei dati, come possiamo far sì che questi due gruppi lavorino efficacemente insieme e si capiscano?
Eric Little: Beh, è interessante, penso che dipenda davvero dall'organizzazione, e risale al mio concetto precedente, in quelle organizzazioni in cui le iniziative erano guidate dal business in cui eravamo legati. Ad esempio, stavo conducendo un'architettura di dati team, ma eravamo collegati direttamente con gli utenti aziendali e li stavamo effettivamente aiutando a sostenere il loro programma di governance dei dati. Ancora una volta, più di un approccio consultivo, ma è davvero più di una funzione aziendale.
Ciò di cui hai veramente bisogno per essere in grado di farlo è che hai bisogno di modellatori di dati e architetti che capiscano davvero il business, possano relazionarsi con gli utenti del business e quindi aiutarli a sostenere i processi di governance che lo circondano. L'azienda vuole farlo, ma in generale abbiamo le conoscenze tecnologiche per essere in grado di aiutarli a distinguere questi tipi di programmi. Deve davvero essere una collaborazione, ma deve essere di proprietà aziendale.
Malcolm Chisholm: Okay, è grandioso. Grazie.
Dr. Eric Little: Ok.
Rebecca Jozwiak: Ok, grazie mille. Membri del pubblico, temo che non abbiamo risposto alle vostre domande, ma farò in modo che vengano inoltrate all'ospite appropriato che avevamo in linea oggi. Voglio ringraziarti tanto per Eric, Malcolm e Ron per essere stati nostri ospiti oggi. Questa era roba fantastica, gente. E se ti è piaciuto il webcast IDERA di oggi, IDERA parteciperà anche a Hot Technologies il prossimo mercoledì se vuoi partecipare, discutendo delle sfide dell'indicizzazione e degli oracoli, quindi un altro argomento affascinante.
Grazie mille, gente, abbiate cura di noi, e ci vediamo la prossima volta. Ciao ciao.
