Per personal de Techopedia, 28 de setembre de 2016
Take away: La presentadora Rebecca Jozwiak discuteix solucions d’arquitectura de dades amb Eric Little d’OSTHUS, Malcolm Chisholm de First San Francisco Partners i Ron Huizenga d’IDERA.
Actualment no teniu la sessió iniciada. Inicieu la sessió o registreu-vos per veure el vídeo.
Rebecca Jozwiak: Senyores i senyors, hola i benvinguts a Hot Technologies del 2016. Avui estem parlant de "Construir una arquitectura de dades impulsada per negocis", sens dubte és un tema candent. Em dic Rebecca Jozwiak, seré la vostra presentadora per a la transmissió web d'avui. Tweetem amb un hashtag de # HotTech16, així que si ja esteu a Twitter, si us plau, no dubteu a participar. Si teniu preguntes en qualsevol moment, envieu-les al quadre de Q & A situat a la part inferior dreta de la pantalla i ens assegurem que us responguin. Si no, ens assegurem que els nostres convidats els rebin per vosaltres.
Així, avui tenim una línia molt fascinant. Avui hi ha molts pesats. Tenim Eric Little, VP de ciències de dades d’OSTHUS. Tenim a Malcolm Chisholm, cap d’innovació, que és un títol realment fantàstic, per a First San Francisco Partners. I tenim Ron Huizenga, responsable de productes sènior de IDERA. I, ja ho sabeu, IDERA té un conjunt complet de solucions de modelització i gestió de dades. I avui ens donarà una demostració sobre com funciona la seva solució. Però abans d’arribar a això, Eric Little, us passo la pilota.
Eric Little: D'acord, moltes gràcies. Així que vaig a passar un parell de temes aquí que crec que es relacionaran una mica amb la xerrada de Ron i espero que també establisca l’escenari per a alguns d’aquests temes, algunes preguntes i preguntes.
El que m'interessa amb el que fa l'IDERA és que crec que assenyalen correctament que els entorns complexos actualment impulsen molts valors empresarials. I per entorns complexos, ens referim a entorns de dades complexos. I la tecnologia es mou ràpidament i és difícil mantenir-se en l’entorn empresarial actual. Així, les persones que treballen en espais tecnològics sovint veuran que tens clients amb problemes: "Com puc utilitzar dades grans? Com incorporo la semàntica? Com puc enllaçar algunes coses noves amb les meves dades anteriors? ”, Etcètera, i aquest tipus de problemes ens porta avui a aquestes quatre versions grans de dades que molta gent coneix, i entenc que hi pot haver més de quatre de vegades, n’he vist fins a vuit o nou, però normalment, quan la gent parla de coses com grans dades o si parleu de dades grans, normalment esteu buscant alguna cosa que és una mena d’empresa. I així la gent dirà: d’acord, bé, penseu en el volum de les vostres dades, que normalment és el focus –és el que teniu. La velocitat de les dades té a veure amb la rapidesa amb què puc moure-la o la rapidesa que puc preguntar o obtenir les respostes, etc. I personalment crec que el lateral esquerre és una cosa que s'està solucionant i gestionant de forma relativament ràpida per molts enfocaments diferents. Però, al costat dret, veig molta capacitat de millora i moltes noves tecnologies que arriben a un primer pla. I això té a veure realment amb la tercera columna, la varietat de dades.
És a dir, la majoria de les empreses actualment estudien dades estructurades, semestructurades i no estructurades. Les dades d’imatges comencen a convertir-se en un tema candent, per la qual cosa, per poder utilitzar la visió per ordinador, mirar píxels, poder raspar text, NLP, extracció d’entitats, teniu informació de gràfics que surten de models estadístics o que surten de semàntics. models, teniu dades relacionals que existeixen a les taules, etc. Així, doncs, reunir totes aquestes dades i tots aquests diferents tipus és realment un gran repte i ho podreu veure, a Gartner i a altres persones que segueixen les tendències del sector.
Aleshores, l’últim que parlen les persones en big data és sovint aquesta noció de voracitat, que és realment la incertesa de les vostres dades, la difusió d’aquest. Fins a quin punt saps de què van les teves dades, i fins a quin punt entens què hi ha? La possibilitat d’utilitzar estadístiques i la possibilitat d’utilitzar algun tipus d’informació entorn del que pugui conèixer o utilitzar algun context, pot ser de valor aquí. I, per tant, la possibilitat de mirar les dades d’aquesta manera quant a la quantitat que tens, a la velocitat que necessites per moure-la o obtenir-la, tots els tipus de dades que pots tenir a l’empresa i quina seguretat tens d’on. és, en què consisteix, en quina qualitat té, etc. Realment requereix un gran esforç coordinat entre moltes persones per gestionar les seves dades de manera eficaç. El model de dades, per tant, és cada cop més important en el món actual. Així, els bons models de dades estan aconseguint molt d’èxit en aplicacions empresarials.
Teniu fonts de dades de diverses fonts, com dèiem, que realment requereixen molts tipus d’integració diferents. Així, doncs, és útil utilitzar-lo per poder fer consultes, per exemple, a través de nombrosos tipus de fonts de dades, i tornar a obtenir informació. Però, per fer-ho, necessiteu bones estratègies de mapeig i, per tant, fer un mapa d’aquest tipus de dades i mantenir-vos al dia d’aquests mapes pot ser un repte real. I, a continuació, teniu aquest número, així com enllaço les meves dades anteriors a totes aquestes noves fonts de dades? Suposem, doncs, que tinc gràfic, agafo totes les meves dades relacionals i les poso en gràfic? Normalment no és una bona idea. Com és que la gent és capaç de gestionar tot aquest tipus de models de dades que estan passant? L’anàlisi realment s’ha de realitzar en molts d’aquests tipus de fonts i combinacions de dades diferents. Per tant, les respostes que surten d’això són crucials les respostes que la gent necessita per prendre bones decisions empresarials.
Per tant, no es tracta només de construir tecnologia pel bé de la tecnologia, és realment, què faré, què puc fer amb ella, quin tipus d’anàlisi puc fer i la capacitat, per tant, com ja ho he fet he estat parlant, per unir aquestes coses, per integrar-ho és realment, realment important. I un d'aquests tipus d'anàlisis s'encarrega de consultes federades i de consulta. És realment convertir-se en obligació. Normalment, les vostres consultes s'han d'enviar a diversos tipus de fonts i obtenir informació de manera fiable.
L’únic element clau que sovint, especialment la gent, estudiarà coses clau com les tecnologies semàntiques (i això és que espero que Ron parli una mica en l’enfocament IDERA) és com es pot separar o gestionar la model de la capa de les dades de la capa de dades en si, a partir de les dades brutes? Així, a la capa de dades podeu tenir bases de dades, podeu tenir dades de documents, podeu tenir dades de full de càlcul, podeu tenir dades d'imatge. Si trobeu en zones com la indústria farmacèutica, disposeu de grans quantitats de dades científiques. I, a sobre, aquesta gent normalment busca una manera de construir un model que els permeti integrar ràpidament aquestes dades i, realment, quan busqueu dades, ara no voleu incorporar totes les dades cap a la capa de model. El que estàs buscant a la capa de model a fer és oferir una bona representació lògica de què són les coses, vocabularis comuns, tipus d'entitats i relacions comunes, i la capacitat d’arribar realment a les dades on es troben. Per tant, ha de dir què és i ha de dir on és, i ha de dir com anar a buscar-lo i tornar-lo a portar.
Així doncs, aquest ha estat un enfocament que ha tingut un gran èxit a l’hora de propulsar les tecnologies semàntiques endavant, que és un àmbit on treballo molt. Per tant, la pregunta que volia plantejar per a Ron, i que crec que serà útil a la secció de Q&A, és veure com s’aconsegueix això per la plataforma IDERA? Per tant, la capa de model està realment separada de la capa de dades? Estan més integrats? Com funciona això i quins són alguns dels resultats i beneficis que es veuen des del seu enfocament? Per tant, les dades de referència són realment importants també. Per tant, si teniu aquest tipus de models de dades, si podreu confederar i cercar coses, hauríeu de tenir bones dades de referència. Però el problema és que les dades de referència poden ser molt difícils de mantenir. Per tant, moltes vegades el nomenament de normes en si mateix és un repte difícil. Un grup trucarà a alguna cosa X i un grup trucarà a alguna cosa Y i ara teniu el problema de com algú troba X i Y quan busca aquest tipus d’informació? Com que no voleu només donar-los una part de les dades, voleu oferir-los tot el relacionat. Al mateix temps que canvien els termes, el programari s’intueix, etc., com es pot mantenir i mantenir aquestes dades de referència al llarg del temps?
I, de nou, les tecnologies semàntiques, que utilitzen específicament coses com taxonomies i vocabularis, els diccionaris de dades, han proporcionat un espai estàndard de fer-ho, que és molt robust, utilitza certs tipus d’estàndards, però la comunitat de bases de dades ho ha fet per a una molt de temps també, de diferents maneres. Crec que una de les claus aquí és pensar en com utilitzar models de relació entre entitats, com potser utilitzar models de gràfics o algun tipus d’enfocament aquí, que realment us donarà una esperança de manejar els vostres dades de referència. I, per descomptat, un cop tingueu les dades de referència, les estratègies de mapeig han de gestionar una gran varietat de noms i entitats. Així, els experts en matèries sovint els agrada fer servir els seus termes.
Així doncs, sempre és un repte: com es pot donar a algú però fer-lo rellevant per a la manera de parlar? Per tant, un grup pot tenir una manera de mirar alguna cosa, per exemple, pot ser un químic que treballa en un medicament i potser sigui un biòleg estructural que treballi el mateix medicament i potser tindrà noms diferents per al mateix tipus d'entitats. relacionats amb el vostre camp. Heu d’esbrinar les maneres d’ajuntar aquestes terminologies personalitzades, ja que l’altre plantejament és que heu d’obligar la gent a abandonar el seu terme i a fer servir l’altra persona, que sovint no els agrada. Un altre punt aquí és el fet de manejar gran quantitat de sinònims, per la qual cosa hi ha moltes paraules diferents en les dades de moltes persones que es poden referir al mateix. Hi ha un problema de referència amb un conjunt de relacions d'un a un. Els termes especialitzats varien d’indústria a indústria, de manera que si voleu trobar una solució generalitzada d’aquest tipus de gestió de dades, quina facilitat és portàtil d’un projecte o d’una aplicació a una altra? Això pot ser un altre repte.
L’automatització és important i també és un repte. És car manejar les dades de referència de forma manual. És costós haver de mantenir el mapeig manual i és costós que els experts en matèries deixin de fer la feina quotidiana i hagin d’entrar i arreglar constantment els diccionaris de dades i re-actualitzar definicions, etc. Els vocabularis replicables mostren molt valor. De manera que es tracta de vocabularis de vegades que es pot trobar extern a la vostra organització. Si treballeu amb cru, per exemple, hi haurà certs tipus de vocabularis que podeu agafar en préstec d’espais de codi obert, igual amb els farmacèutics, el mateix amb la indústria bancària i financera, igual amb moltes d’aquestes àrees. La gent estableix vocabularis reutilitzables, genèrics i replicables per utilitzar-los.
I, una vegada més, mirant l’eina IDERA, tinc curiositat per veure com s’ho manegen en termes d’utilització de tipus d’estàndards. Al món de la semàntica sovint veieu coses com els models SKOS que ofereixen estàndards com a mínim més amples / estretes que les relacions i aquestes coses poden ser difícils de fer en models ER, però, no ho sabeu, només depèn de quant d’això. maquinària i l'enllaç que podeu manejar en aquest tipus de sistemes.
Per últim, només volia fer una comparació amb alguns motors semàntics que veig a la indústria, i preguntar-li a Ron i dedicar-li una mica per parlar de tal vegada com s’ha utilitzat el sistema d’IDERA conjuntament amb tecnologies semàntiques. És capaç d’integrar-se amb botigues triples, bases de dades gràfiques? Què tan fàcil és utilitzar fonts externes perquè aquest tipus de coses del món semàntic sovint es poden agafar en préstec mitjançant els programes finals SPARQL? Podeu importar models RDF o OWL directament al vostre model –reveieu-los–, de manera que, per exemple, l’ontologia gènica o l’ontologia de proteïnes, que poden viure en algun lloc del seu propi espai amb la seva pròpia estructura de governament i puc simplement importar-ne tot o part d’això, ja que ho necessito en els meus propis models. I tinc curiositat per saber com s’acosta l’IDERA a aquest problema. Cal mantenir-ho tot internament, o hi ha maneres d’utilitzar altres tipus de models estandarditzats i d’aplicar-los i com funciona? I l’últim que he esmentat aquí és quina quantitat de treball manual implica realment per crear els glossaris i els dipòsits de metadades?
Així que sé que Ron ens mostrarà algunes demostracions sobre aquest tipus de coses, que seran realment interessants. Però els problemes que sovint veig consultant amb els clients és que es produeixen molts errors si la gent escriu en les seves pròpies definicions o en les seves pròpies metadades. De manera que obteniu faltes d’ortografia, obteniu errors de dits grossos, això és una cosa. També obteniu persones que en poden treure alguna cosa, ja ho sabeu, només la Viquipèdia o una font que no sigui necessàriament de la qualitat que vulgueu en la vostra definició, o bé la vostra definició només sigui des de la perspectiva d'una persona, per tant no és completa, i no queda clar llavors com funciona el procés de governança. La governança, per descomptat, és un problema molt gran en qualsevol moment que parleu de dades de referència i sempre que parleu de com encaixen les dades mestres d'algú, de com utilitzaran els seus metadades i etc.
Així que només volia exposar alguns d’aquests temes. Es tracta d’elements que veig a l’espai comercial a través de diferents tipus de compromisos de consultoria i molts espais diferents, i estic molt interessat en veure què Ron ens mostrarà amb IDERA per assenyalar alguns d’aquests temes. . Així que moltes gràcies.
Rebecca Jozwiak: Moltes gràcies, Eric, i m’agrada molt el teu comentari que poden aparèixer molts errors si la gent està escrivint les seves pròpies definicions o metadades. Sé que al món del periodisme hi ha un mantra que “molts ulls cometen alguns errors”, però quan es tracta d’aplicacions pràctiques, moltes mans del pot de galetes solen deixar-vos amb moltes galetes trencades, oi?
Eric Little: Sí, i gèrmens.
Rebecca Jozwiak: Sí. Amb això vaig a tirar endavant i passaré a Malcolm Chisholm. Malcolm, el pis és teu.
Malcolm Chisholm: Moltes gràcies, Rebecca. M'agradaria mirar una mica el que parlava d'Eric i afegir a algunes observacions a les quals, ja sabeu, Ron pot interessar-vos de respondre també, parlant de "Cap a l'arquitectura de dades dirigida per negocis. ”- Què significa ser impulsat per negocis i per què és important? O és només una forma de bombo? No crec que ho sigui.
Si ens fixem en el que està passant, ja que, ja sabeu, els ordinadors mainframe es van posar realment a l’abast de les empreses (per exemple, cap al 1964) fins avui, podem veure que hi ha hagut molts canvis. I aquests canvis els resumiria com un canvi de centricitat en el procés a centrada en dades. I això és el que fa que les arquitectures de dades impulsades per empreses siguin tan importants i tan rellevants per avui. I crec que, ja ho sabeu, no és només una paraula de moda, sinó una cosa absolutament real.
Però podem apreciar-ho una mica més si ens endinsem en la història, de manera que es remunten en el temps, es remunten als anys seixanta i durant un cert temps després, es van dominar fotogrames. A continuació, es va donar pas a les PC on realment es va rebel·lar els usuaris quan van entrar les PC. La rebel·lió contra les TI centralitzades, que pensaven que no complien les seves necessitats, no van ser prou àgils. Això va donar lloc ràpidament a una informàtica distribuïda quan es van enllaçar els ordinadors. I llavors va començar a passar internet, que va desdibuixar els límits de l’empresa: ara podia interactuar amb les parts alienes a si mateix en termes d’intercanvi de dades, que abans no passava. I ara ens hem endinsat en l’era del núvol i de les grans dades on el núvol és plataformes que realment comencen a infraestructura i, per tant, deixem, per dir-ho, la necessitat de executar centres de dades grans perquè, ja ho sabeu, nosaltres Tenim la capacitat de núvol a la nostra disposició i, en conseqüència amb aquestes grans dades que Eric ha sabut, tan eloqüentment discutides. I, en general, com veiem, a mesura que el canvi tecnològic es va produir, s'ha convertit en més centrat en les dades, ens importa més les dades. Com passa amb Internet, com s’intercanvien dades. Amb les dades grans, les quatre o més versions de la pròpia informació.
Al mateix temps, i potser més important, es van canviar els casos d’ús empresarial. Quan es van introduir per primera vegada els ordinadors, es van utilitzar per automatitzar coses com llibres i registres. I tot el que fos un procés manual, que implicava registres o coses així, es programava fonamentalment a casa. Als anys 80 es va canviar la disponibilitat de paquets operatius. Ja no necessitaves escriure la vostra nòmina, podríeu comprar alguna cosa. Això va suposar una gran reducció en el seu moment o una reestructuració en molts departaments informàtics. Però després va aparèixer la intel·ligència empresarial, amb coses com els magatzems de dades, sobretot als anys 90. Seguit per models de negoci dotcom, que van ser, per descomptat, un gran frenesí. Després MDM. Amb MDM comença a veure que no pensem en automatització; En realitat ens estem centrant en la cura de dades com a dades. A continuació, les analítiques, que representen el valor que podeu treure de les dades. I dins d’analítiques, veieu empreses que tenen molt d’èxit el model de negoci principal del qual gira al voltant de les dades. Google, Twitter, Facebook serien part d’això, però també podríeu argumentar que Walmart ho és.
De manera que el negoci ara està pensant en dades. Com podem treure valor a partir de les dades? Com les dades poden impulsar el negoci, l’estratègia i estem en l’època daurada de les dades. Així, doncs, què passa pel que fa a la nostra arquitectura de dades, si les dades ja no es consideren simplement l’esgotament que surt de les aplicacions posteriors, sinó que són realment fonamentals en els nostres models de negoci? Bé, una part del problema que tenim per aconseguir que és la IT està realment enganxada en el passat al cicle de vida del desenvolupament de sistemes, la qual cosa era conseqüència d’haver d’afrontar ràpidament aquesta fase d’automatització de processos a la primera edat de les TI i treballar en els projectes són una cosa similar. Per a les TI, i això és una caricatura, però el que estic intentant dir és que algunes de les barreres per aconseguir una arquitectura de dades basada en el negoci són perquè, d'una manera, hem acceptat una cultura sense critiques en IT que deriva d’una edat passada.
Així, tot és un projecte. Explica'm els detalls de les seves necessitats. Si les coses no funcionen és perquè no em vau dir els vostres requisits. Doncs bé, això no funciona avui amb les dades perquè no estem començant per processos manuals no automatitzats o amb una conversió tècnica dels processos empresarials, ja que sovint, comencem amb dades de producció ja existents. per treure valor. Però ningú que patrocina un projecte centrat en dades realment entén aquestes dades en profunditat. Hem de fer descobriment de dades, hem de fer anàlisis de dades de font. I això no coincideix realment amb el desenvolupament dels sistemes, ja ho sabeu: la cascada, el cicle de vida SDLC, del qual Àgil, mantindria, és una mena d’una versió millor d’això.
I en què es centra és la tecnologia i la funcionalitat, no les dades. Per exemple, quan fem proves en una fase de prova, normalment serà, funciona la meva funcionalitat, diguem el meu ETL, però no estem provant les dades. No estem provant els nostres supòsits sobre les dades d'origen que provenen. Si ho féssim, estaríem en una forma potser millor, i algú que hagi realitzat projectes de magatzem de dades i que ha patit canvis aigües amunt de les meves ETL, ho agrairia. De fet, el que volem veure és provar com a pas previ al control continu de la qualitat de les dades de producció. Així doncs, hem tingut aquí moltes actituds en què és difícil assolir l’arquitectura de dades impulsada per negocis perquè estem condicionats per l’era del centratge en el procés. Hem de fer una transició cap al centrat de dades. I no es tracta d’una transició total, ja sabeu, encara hi ha molts treballs de procés per fer fora, però realment no estem pensant en termes centrats en les dades quan hem de fer-ho i les circumstàncies que es produeixen quan realment estem obligat a fer-ho.
Ara, l’empresa s’adona del valor de les dades, volen desbloquejar-les, així com ho farem? Llavors, com fem la transició? Doncs posem les dades al centre dels processos de desenvolupament. I deixem que l’empresa lideri amb necessitats d’informació. I entenem que ningú entén les dades d’origen existents al començament del projecte. Podríeu argumentar que l'estructura de dades i les dades mateixes s'obtenen a través de TI i operacions, respectivament, per la qual cosa hauríem de saber-ho, però realment no ho fem. Es tracta d’un desenvolupament centrat en les dades. Per tant, hem de tenir, per pensar on fem i com fem el modelatge de dades en un món centrat en les dades, hem de tenir bucles de retroalimentació als usuaris pel que fa a afinar els seus requisits d'informació, ja que fem descobriment de dades i perfilat de dades, preveu l’anàlisi de les dades d’origen i, a mesura que anem aconseguint cada vegada més certesa sobre les nostres dades. I ara parlo d’un projecte més tradicional com un hub MDM o un magatzem de dades, no necessàriament els grans projectes de dades, tot i que, encara ho mantinc, estic bastant a prop. I, per tant, aquests bucles de retroalimentació inclouen els modeladors de dades, ja sabeu, avançant gradualment el seu model de dades i interactuant amb els usuaris per assegurar-se que els requisits d'informació es perfeccionin en funció del que és possible, el que hi ha disponible, a partir de les dades d'origen ja que ho entenen millor, així ja no és el cas del model de dades, ja sabeu, en un estat que no hi ha o que no està completament complet, sinó que es va centrant gradualment.
De la mateixa manera, més avall tenim la garantia de qualitat quan desenvolupem regles per fer proves de qualitat de les dades per assegurar-nos que les dades estan dins dels paràmetres sobre els quals fem presumpcions. En entrar, Eric es referia a canvis de dades de referència, que podrien passar. No voldríeu ser, com ja va ser, una víctima a l’aigua d’un canvi no gestionat en aquesta zona, de manera que les regles d’assegurament de la qualitat poden entrar en un control continu de la qualitat de les dades de postproducció. Així doncs, podeu començar a veure si anem a ser centrats en les dades, com fem el desenvolupament centrat en dades és molt diferent al SDLC i a Agile basat en la funcionalitat. Llavors també hem de parar atenció a les opinions empresarials. Tenim -i de nou això fa ressò del que deia Eric-: tenim un model de dades que defineix un model d’història de dades per a la nostra base de dades, però alhora necessitem aquells models conceptuals, aquells punts de vista empresarials de dades que tradicionalment no s’han fet a el passat. De vegades, penso, de vegades, hem pensat que el model de dades ho pot fer tot, però cal tenir la visió conceptual, la semàntica i mirar les dades, fer-ho a través d’una capa d’abstracció que tradueixi el model d’emmagatzematge al negoci. vista. I, de nou, totes les coses de què parlava Eric pel que fa a la semàntica, esdevé important fer-ho, de manera que realment tenim tasques de modelització addicionals. Crec que això és interessant si vas entrar a les files com a modelador de dades com jo, i de nou, alguna cosa nova.
Per acabar, vull dir que l'arquitectura més gran també ha de reflectir aquesta nova realitat. L’MDM tradicional del client, per exemple, és una mica bo, anem a fer que les dades dels nostres clients siguin un centre on podrem, ja ho sabeu, comprendre en termes de qualitat de dades realment justes per a aplicacions de back office. El que des del punt de vista d’estratègia empresarial és un tipus de bostell. Avui en dia, però, estem buscant els hubs MDM dels clients que hi ha dades addicionals del perfil de client, no només les dades estàtiques, que llavors realment tenen una interfície bidireccional amb les aplicacions de transacció del client. Sí, encara donen suport a la oficina de correus, però ara també coneixem aquests comportaments dels nostres clients. Això és més car de construir. Això és més complex de construir. Però es basa en els negocis de manera que el MDM tradicional del client no ho és. Esteu negociant una orientació al negoci amb dissenys més senzills i més fàcils d’implementar, però per a l’empresa, això és el que volen veure. Estem realment en una nova era i crec que hi ha una sèrie de nivells que hem de respondre a l'arquitectura de dades basada en el negoci i crec que és un moment molt emocionant per fer coses.
Així que gràcies, de nou Rebecca.
Rebecca Jozwiak: Gràcies Malcolm, i em va agradar molt el que heu dit sobre els models de dades han d’alimentar la visió empresarial, perquè, a diferència del que vau dir, allà on les TI van mantenir les regnes durant tant de temps i no és més que un cas. que la cultura necessita canviar. I estic bastant segur que hi havia un gos de fons que estigués d’acord amb tu al 100%. I amb això vaig a passar la pilota a Ron. Em fa molta il·lusió veure la vostra demostració. Ron, el pis és el vostre.
Ron Huizenga: Moltes gràcies i abans de saltar a això passaré algunes diapositives i després una mica de demostració perquè, tal com han assenyalat Eric i Malcolm, aquest és un tema molt ampli i profund, i amb el que parlem avui, simplement rasguem la superfície perquè hi ha tants aspectes i tantes coses que realment hem de tenir en compte i mirar des d’una arquitectura impulsada per negocis. I el nostre enfocament és fer que aquest model es basa en el model i es tregui valor real dels models perquè podeu utilitzar-los com a vehicle de comunicació i com a capa per habilitar altres sistemes. Tant si feu arquitectura orientada al servei, com altres coses, el model es converteix realment en el que és vital de tot el que passa, amb totes les metadades que hi ha al seu voltant i les dades que teniu al vostre negoci.
Del que vull parlar, però, és gairebé fer un pas enrere, perquè Malcolm havia tocat una mica de la història de la manera com han evolucionat les solucions i aquest tipus de coses. Una manera d’assenyalar realment la importància que és tenir una arquitectura de dades sòlida és un cas d’ús que solia executar molt sovint quan feia consultes abans d’entrar en una funció de gestió de productes i, és a dir, entraria en organitzacions. tant si estaven fent transformació empresarial com si simplement substituïen alguns sistemes existents i aquest tipus de coses, i es va fer evident molt ràpidament com entenen malament les organitzacions. Si feu un cas d’ús concret com aquest, tant si sou un consultor o potser és una persona que acaba de començar amb una organització, com si la vostra organització s’ha creat al llarg dels anys amb l’adquisició de diferents empreses, el que acabes És molt ràpidament un entorn molt complex, amb diverses tecnologies diferents, així com tecnologia avançada, solucions ERP i tot el que sigui.
Una de les coses que podem fer realment amb el nostre enfocament de modelatge és respondre a la pregunta de com puc donar sentit a tot això? Realment podem començar a combinar la informació, de manera que el negoci pot aprofitar la informació que tenim adequadament. I surt, què és allò que tenim aquí en aquells entorns? Com puc utilitzar els models per generar la informació que necessito i entendre millor aquesta informació? I després tenim els tipus de metadades tradicionals per a diferents coses com els models de dades relacionals i estem acostumats a veure coses com a definicions i diccionaris de dades, ja ho sabeu, tipus de dades i aquest tipus de coses. Però, i els metadades addicionals que voleu capturar per donar-li encara més sentit? Com ara, quines entitats són realment les candidatures que haurien de ser objectes de dades de referència, que haurien de ser objectes de gestió de dades mestres i aquests tipus de coses i unir-los. I com flueix la informació a través de l’organització? Les dades flueixen de la forma en què es consumeixen tant des del punt de vista del procés, però també del llinatge de dades en termes del viatge de la informació a través dels nostres negocis i de com s’encarrega pels diferents sistemes o a través dels magatzems de dades, pel que sabem quan construïm les solucions I o aquest tipus de coses, consumim la informació correcta per a la tasca a la vostra disposició.
I, a continuació, és molt important, com podem aconseguir que tots aquells grups interessats col·laborin, i en particular els grups de negoci, perquè són els que ens donen el veritable significat de què es tracta. El negoci, al final del dia, és propietari de les dades. Proporcionen les definicions per als vocabularis i les coses de què parlava Eric, per la qual cosa necessitem un lloc per lligar-ho tot. I la nostra manera de fer-ho és mitjançant la nostra modelització de dades i arquitectures de dipòsits de dades.
Vaig a tocar algunes coses. Parlaré sobre ER / Studio Enterprise Team Edition. Principalment parlaré del producte d’arquitectura de dades on fem el modelatge de dades i aquest tipus de coses, però hi ha molts altres components de la suite que només us tocaré breument. Veureu un fragment de Business Architect, on podem fer models conceptuals, però també podem fer models de processos empresarials i podem lligar aquests models de procés per vincular les dades reals que tenim als nostres models de dades. Realment ens ajuda a unir aquest lligam. Software Architect ens permet fer construccions addicionals com ara alguns models de UML i aquest tipus de coses per donar lògiques de suport a alguns d’aquests altres sistemes i processos de què parlem. Però molt important a mesura que avancem, tenim el repositori i el servidor d'equip, i parlaré d'això com una mena de dues meitats del mateix. El repositori és on emmagatzemem tots els metadats modelats, així com totes les metadades empresarials en termes de glossaris i termes empresarials. I perquè tenim aquest entorn basat en dipòsits, podem agrupar totes aquestes coses diferents en aquest mateix entorn i, en realitat, podem posar-les a disposició per a consums, no només per als tècnics, sinó també per als empresaris. És així com realment comencem a impulsar la col·laboració.
Aleshores, l’última peça de què parlaré breument és, quan us endinseu en aquests entorns, no són només les bases de dades que teniu fora. Hi ha una gran quantitat de bases de dades, magatzems de dades, també tindràs molts artefactes antics, que jo diria. Potser la gent ha utilitzat Visio o altres diagrames per assenyalar algunes coses. Potser han tingut altres eines de modelatge i aquest tipus de coses. Aleshores, el que podem fer amb MetaWizard és, en realitat, extreure part d’aquesta informació i portar-la als nostres models, fer-la actual i poder-la utilitzar, consumir-la de manera actual de nou, en lloc de deixar-la fora. Ara esdevé una part activa dels nostres models de treball, que és molt important.
Quan entres a una organització, com he dit, hi ha molts sistemes dispars, moltes solucions ERP, solucions departamentals no coincidents. Moltes organitzacions també utilitzen solucions SaaS, que també es controlen i es gestionen externament, per la qual cosa no controlem les bases de dades i aquest tipus de coses en allotjament, però encara hem de saber com són aquestes dades i, per descomptat, les metadades al voltant d’això. El que també trobem és una gran quantitat de sistemes de successió obsolets que no han estat netejats a causa de l’enfocament basat en projectes del qual havia parlat Malcolm. És increïble com en els darrers anys les organitzacions giraran projectes, substituiran un sistema o una solució, però sovint no hi ha prou pressupost per a desembossar les solucions obsoletes, de manera que ara estan tan bé. I cal esbrinar què podem desfer-nos realment del nostre entorn i quins són els útils que es poden avançar. I això es vincula amb la pobra estratègia de desmantellament. Això és part integral de la mateixa cosa.
El que també trobem, com que s’han creat moltes organitzacions a partir de totes aquestes solucions diferents, és que veiem moltes interfícies punt a punt amb moltes dades que es mouen en diversos llocs. Hem de ser capaços de racionalitzar-ho i esbrinar el llinatge de dades que he esmentat breument abans per tal de tenir una estratègia més cohesionada com ara l’ús de l’arquitectura orientada al servei, els autobusos de servei empresarial i aquest tipus de coses, per proporcionar la informació correcta. a un tipus de model de publicació i subscripció que fem servir correctament a tota la nostra empresa. I, per descomptat, encara hem de fer algun tipus d’analítica, ja sigui si utilitzem magatzems de dades, marts de dades amb ETL tradicional o utilitzem alguns dels nous llacs de dades. Tot es refereix al mateix. Totes les dades, tant si es tracta de dades grans, com si es tracta de dades tradicionals a bases de dades relacionals, hem de reunir totes aquestes dades perquè puguem gestionar-les i saber de què tractem els nostres models.
Un cop més, la complexitat que farem és que tenim diversos passos que volem fer. Primer de tot, entreu i potser no tingueu els models de l'aparença d'aquest paisatge d'informació. En una eina de modelatge de dades com ER / Studio Data Architect, primer fareu molta enginyeria inversa en termes d’apuntar-nos a les fonts de dades que hi ha, incloure’ls i agrupar-los de manera més representativa. models que representen tot el negoci. L’important és que volem ser capaços de descomposar aquests models també segons línies de negoci per tal de relacionar-nos en fragments més petits, als quals també poden relacionar-se els nostres empresaris i els nostres analistes empresaris i altres grups d’interessos que treballen. al damunt.
Els estàndards de denominació són extremadament importants i en parlo d’aquí a diverses maneres diferents. Nomenar estàndards quant a com anomenem les coses en els nostres models. És bastant fàcil fer-ho en models lògics, on tenim una bona convenció d’anomenaments i un bon diccionari de dades per als nostres models, però també veiem diferents convencions de denominació per a molts d’aquests models físics que incorporem. enginyer invers, moltes vegades veiem noms abreviats i aquest tipus de coses de les que parlaré. I hem de traduir aquests noms en noms anglesos significatius que tinguin sentit per al negoci per tal de comprendre quines són aquestes dades que tenim al medi. I, a continuació, els mapatges universals és com els ajuntem.
A més d'això, ens documentaríem i definiríem més endavant i aquí és on podem classificar les nostres dades amb una cosa anomenada Arxius adjunts, que us mostraré un parell de diapositives. Per tancar el bucle, volem aplicar aquest significat empresarial, que és on lligem els glosaris empresarials i els podem vincular amb els nostres artefactes de diferents models, per la qual cosa sabem, quan parlem d’un terme empresarial determinat, on és implementat en les nostres dades a tota l'organització. I, per últim, ja he parlat del fet que necessitem reposar tots els dipòsits amb molta col·laboració i capacitats de publicació per tal que els nostres grups interessats puguin utilitzar-lo. Vaig a parlar d’enginyeria inversa bastant ràpidament. Ja us he donat un ressalt molt ràpid. Us la mostraré en una demostració real només per mostrar-vos algunes de les coses que hi podem portar.
I vull parlar d’alguns dels diferents tipus de models i diagrames que produiríem en aquest tipus d’escenari. Evidentment, farem els models conceptuals en molts casos; No passaré gaire temps en això. Realment vull parlar de models lògics, models físics i dels tipus especialitzats de models que podem crear. I és important que puguem crear-los tots a la mateixa plataforma de modelatge per tal de combinar-los. Inclou models dimensionals i també models que utilitzen algunes de les fonts de dades noves, com ara el NoSQL que us mostraré. I, a continuació, com és el model de llinatge de dades? De què parlarem les dades en un model de procés empresarial.
Passaré a un entorn de modelatge aquí només per donar-vos una visió general molt alta i ràpida. I crec que hauríeu de poder veure la meva pantalla ara. En primer lloc, vull parlar només d’un tipus tradicional de model de dades. I la manera com volem organitzar els models quan els introduïm és que volem descompondre’ls. De manera que el que veieu al costat esquerre és que tenim models lògics i físics en aquest fitxer de models. El següent és que podem desglossar-lo al llarg de les descomposicions empresarials, per això veieu les carpetes. Els blaus clars són models lògics i els verds són models físics. I també podem aprofundir, de manera que dins ER / Studio, si teniu una descomposició empresarial, podeu anar a tants nivells de fons o sub-models que vulgueu, i els canvis que feu als nivells inferiors es reflecteixen automàticament a l’altura superior. nivells. De manera que es converteix en un entorn de modelatge molt potent molt ràpidament.
Una cosa que també vull destacar que és molt important per començar a agrupar aquesta informació és que podem tenir diversos models físics que també corresponen a un model lògic. Molt sovint podeu tenir un model lògic, però podeu tenir models físics en diferents plataformes i aquest tipus de coses. Potser és una instància del SQL Server, potser una altra és una instància Oracle. Tenim la capacitat de lligar tot això en un mateix entorn de modelatge. I, de nou, el que tinc aquí és un model de magatzem de dades real que pot, de nou, estar en el mateix entorn de modelatge o el podem tenir al repositori i enllaçar-lo també en diferents coses.
El que realment volia mostrar-vos en això són algunes de les altres coses i altres variants dels models en què entrem. Així doncs, quan ens endinsem en un model de dades tradicional com aquest, estem acostumats a veure les entitats típiques amb les columnes i les metadades i aquest tipus de coses, però aquest punt de vista varia molt ràpidament quan comencem a tractar algunes d’aquestes noves tecnologies NoSQL. o com a algunes persones encara els agrada anomenar-les, les grans tecnologies de dades.
Així que ara diguem que també tenim rusc al nostre entorn. Si invertim l’enginyer des d’un entorn Hive, i podem avançar i revertir l’enginyer d’Hive amb aquesta mateixa eina de modelat exacta - veiem una cosa diferent. Encara veiem totes les dades com a construccions allà, però el nostre TDL és diferent. Els que esteu acostumats a veure SQL, el que veuríeu ara és Hive QL, que és molt SQL, però amb la mateixa eina que ara podeu començar a treballar amb els diferents llenguatges de script. Per tant, podeu modelar en aquest entorn, generar-lo a l’entorn del Rusc, però, de la mateixa manera que és important, en l’escenari que he descrit, podeu invertir-lo tot i tenir-ne sentit i començar a ajuntar-lo. .
Prenem-ne una altra que sigui una mica diferent. MongoDB és una altra plataforma que suportem de forma nativa. I quan comenceu a entrar en els tipus d’entorns de JSON on teniu botigues de documents, el JSON és un animal diferent i hi ha construccions en això que no corresponen a models relacionals. Ben aviat comenceu a tractar conceptes com objectes incrustats i matrius incrustades d'objectes quan comenceu a interrogar JSON i aquests conceptes no existeixen en la notació relacional tradicional. El que hem fet aquí és que realment hem ampliat la notació i el nostre catàleg per poder gestionar-ho en el mateix entorn.
Si ens fixem en l'esquerra aquí, en lloc de veure coses com entitats i taules, les anomenem objectes. I veieu diferents notacions. Encara veieu els tipus típics de notacions de referència aquí, però aquestes entitats blaves que mostro en aquest diagrama en concret són objectes incrustats. I mostrem diferents cardinalitats. La cardinalitat del diamant significa que és un objecte per un extrem, però la cardinalitat d’un vol dir que tenim, dins l’editor si seguim aquesta relació, tenim un objecte d’adreça incrustat. Al interrogar JSON, hem descobert que és exactament la mateixa estructura d’objectes incrustats al patró, però en realitat s’incorpora com a matriu d’objectes. Ho veiem, no només a través dels connectors mateixos, sinó que si ens fixem en les entitats reals, veureu que veieu adreces sota patró, que també la classifiquen com una matriu d'objectes. Obteniu un punt de vista molt descriptiu sobre com podeu introduir-ho.
I de nou, ara el que hem vist fins ara en pocs segons són els models relacionals tradicionals de diversos nivells, podem fer el mateix amb Hive, podem fer el mateix amb MongoDB i altres fonts de dades grans com bé. El que també podem fer, i només us en mostraré això amb rapidesa és, vaig parlar del fet de portar les coses des d’altres àmbits diferents. Suposo que vaig a importar un model des d’una base de dades o l’enginyerà inversament, però vaig a portar-ho des de metadades externes. Només per oferir-vos una visió molt ràpida de tots els diferents tipus de coses que podem iniciar.
Com veieu, tenim una infinitat de coses amb les que realment podem portar els metadades al nostre entorn de modelatge. A partir de coses com fins i tot Amazon Redshift, Cassandra, moltes altres plataformes de dades grans, de manera que veieu moltes d’aquestes. Això és per ordre alfabètic. Estem veient moltes fonts de dades grans i aquest tipus de coses. També estem veient molts entorns de modelatge tradicionals o més antics als quals podem arribar a produir aquests metadades. Si passo per aquí –i no em dedicaré temps a cadascuna d’elles– veiem moltes coses diferents de les quals podem aportar-ho, en termes de modelar plataformes i plataformes de dades. I una cosa que és molt important per adonar aquí és una altra part que podem fer quan comencem a parlar de llinatge de dades, a l’Edició de l’Equip de l’Enterès també podem interrogar fonts d’ETL, ja siguin coses com ara mapatges de Talend o SQL Server Information Services. realment, aportar això per començar també els nostres diagrames de llinatge de dades i fer una imatge del que passa en aquestes transformacions. A la caixa de treball, tenim més de 130 d'aquests diferents ponts que formen part del producte Enterprise Team Edition, de manera que realment ens ajuda a ajuntar tots els artefactes en un entorn de modelatge molt ràpidament.
Per últim, però no per això menys important, també vull parlar del fet que no podem perdre de vista que necessitem els altres tipus de construccions si fem magatzem de dades o qualsevol tipus d’analítica. Encara volem tenir la capacitat de fer coses com models dimensionals on tinguem taules de fet i tinguem dimensions i aquest tipus de coses. Una cosa que vull mostrar-vos també és que també podem tenir extensions als nostres metadades que ens ajudin a classificar quins són els tipus de dimensions i tota la resta. Així, si miro la fitxa de dades dimensionals aquí, per exemple, en una d’aquestes, realment detectarà automàticament, en funció del patró de model que vegi, i us donarà un punt de partida sobre si creu que és una dimensió o una taula de fets Però més enllà d’això, el que podem fer és dins de les dimensions i aquest tipus de coses fins i tot tenim diferents tipus de dimensions que podem utilitzar per classificar les dades en un tipus d’entorn d’emmagatzematge de dades també. Unes capacitats tan potents amb les que estem enganxant això.
Vaig a entrar a aquesta ja que ara mateix estic a l’entorn de demostració i us mostraré un parell d’altres coses abans de tornar a saltar a les diapositives. Una de les coses que recentment hem afegit a ER / Studio Data Architect és que ens hem trobat amb situacions, i aquest és un cas d’ús molt comú quan treballem en projectes: els desenvolupadors pensen en termes d’objectes, mentre que les nostres dades els modelistes solen pensar en taules i entitats i aquest tipus de coses. Es tracta d’un model de dades molt simplista, però representa uns quants conceptes bàsics, on els desenvolupadors, fins i tot analistes de negocis o usuaris empresarials, podrien pensar-los com objectes diferents o conceptes comercials. Ha estat molt difícil classificar-los fins ara, però el que realment hem fet a ER / Studio Enterprise Team Edition, a la versió del 2016, és que ara tenim un concepte anomenat Business Data Objects. I el que ens permet fer és que ens permet encapsular grups d’entitats o taules en objectes de negoci reals.
Per exemple, el que tenim aquí en aquesta nova visió és l’encapçalament de la comanda de compra i la línia de comandes s’han reunit ara, estan encapsulats com a objecte, els podríem pensar com una unitat de treball quan persistim les dades. i els ajuntem, de manera que ara és molt fàcil relacionar-ho amb públics diferents. Són reutilitzables a l’entorn de modelatge. Són un veritable objecte, no només una construcció de dibuix, sinó que també tenim el benefici afegit que, quan realment estem comunicant des de la perspectiva del modelat, podem reduir-los o ampliar-los selectivament de manera que puguem produir una visió resumida dels diàlegs amb determinats públics interessats, i, per descomptat, també podem mantenir la visió més detallada com ho veiem aquí per a més públics tècnics. Realment ens proporciona un vehicle de comunicació molt bo. El que veiem ara és combinar diversos tipus de models diferents, augmentar-los amb el concepte d'objectes de dades empresarials, i ara parlaré de com realment apliquem una mica més de significat a aquests tipus de coses i de com els ajuntem en el nostre entorns generals.
Simplement estic intentant trobar el meu WebEx aquí per poder fer-ho. I allà anem, de nou a les diapositives Hot Tech. Simplement vaig a avançar algunes diapositives aquí perquè ja les heu vist a la demostració del model. Vull parlar de nombres de normes molt ràpidament. Volem aplicar i aplicar diferents estàndards de denominació. El que volem fer és que puguem emmagatzemar realment plantilles d’estàndards d’anomenament als nostres dipòsits per construir bàsicament aquest significat mitjançant paraules o frases o fins i tot abreviatures i relacionar-les amb un tipus de paraula anglès significatiu. Utilitzarem termes comercials, les abreviatures de cadascun i podem especificar l’ordre, els casos i afegir prefixos i sufixos. El cas d'ús típic per a això és típicament quan la gent ha estat construint un model lògic i, per tant, realitza un model físic on podrien haver estat utilitzant sigles i tota la resta.
El més bonic és que és igual de potent, fins i tot més potent al revés, si només podem dir què eren alguns d’aquests estàndards d’anomenament en algunes d’aquestes bases de dades físiques que hem revertit, podem adoptar aquestes sigles, convertir-les en més llargues. paraules i porteu-les enrere en frases en anglès. Ara podem derivar noms propis del que semblen les nostres dades. Com dic, el cas d’ús típic és que avançaríem, lògic a físic, i mapem els magatzems de dades i aquest tipus de coses. Si mireu la captura de pantalla a la part dreta, veureu que hi ha noms abreujats dels noms d'origen i quan hem aplicat una plantilla d'estàndards de nomenament, en realitat tenim més noms complets. I podríem posar espais i tot allò, si ho volem, segons la plantilla d’estàndards d’anomenament que vàrem utilitzar. Podem fer que quedi tanmateix, però volem que tingui els nostres models. Només quan sabem com s’anomena alguna cosa, en realitat podem començar a afegir-hi definicions, perquè a menys que sapiguem què és, com podem aplicar-li un significat?
El més bo és, en realitat, podem invocar-ho quan fem tot tipus de coses. Vaig parlar d’enginyeria inversa, en realitat podem invocar plantilles d’estàndards de denominació simultàniament quan fem enginyeria inversa. De manera que, en un conjunt de passos mitjançant un assistent, el que podem fer és que, si sabem quines són les convencions, podem invertir l’enginyeria d’una base de dades física, la tornarem a convertir com a models físics en un entorn de modelatge. també s'aplicarà les convencions de denominació. Així veurem quines són les representacions de noms en anglès en el model lògic corresponent a l’entorn. També podem fer-ho i combinar-lo amb la generació d’esquema XML per tal que agafem un model i fins i tot el puguem fer servir amb les nostres sigles, ja siguem marcs SOA o aquest tipus de coses, de manera que també podrem eliminar diferents convencions de denominació. que realment hem emmagatzemat al model mateix. Ens dóna moltes capacitats molt potents.
De nou, aquí teniu un exemple del que semblaria si tingués una plantilla. Aquest està demostrant que tenia EMP per a "empleat", SAL per "salari", PLN per "pla" en una convenció de normes de nominació. També puc aplicar-los perquè s’executin de forma interactiva mentre estic elaborant models i posant coses. Si utilitzés aquesta abreviació i escrivís el “Pla de salari dels empleats” al nom de l’entitat, actuaria amb la plantilla d’estàndards d’anomenament. He definit aquí, m’hauria donat EMP_SAL_PLN a mesura que estava creant les entitats i em donaria els noms físics corresponents de seguida.
Un cop més, molt bo per a quan també estem dissenyant i avançant enginyeria. Tenim un concepte molt únic i aquí és on realment comencem a ajuntar aquests entorns. I s’anomena Mapeig Universal. Un cop hem introduït tots aquests models al nostre entorn, què podem fer, suposant que ara hem aplicat aquestes convencions de denominació i que siguin fàcils de trobar, ara podem utilitzar una construcció anomenada Mappings Universal a ER. / Estudi. Podem enllaçar entitats entre models. Sempre que veiem “client” - probablement tindrem “client” en molts sistemes diferents i en moltes bases de dades diferents - podem començar a enllaçar tots aquests junts de manera que quan treballi amb ell en un model jo. pot veure on són les manifestacions dels clients en els altres models. I perquè tenim la capa de model que representa, podem fins i tot enllaçar-la amb les fonts de dades i fer-ho arribar a les consultes on s’utilitzen les bases de dades. Realment ens dóna la capacitat de lligar tot això de manera molt cohesionada.
Us he mostrat els objectes de dades comercials. També vull parlar de les extensions de metadades, que anomenem fitxers adjunts, amb molta rapidesa. El que fa és que ens proporciona la possibilitat de crear metadades addicionals per als objectes model. Molt sovint establiria aquest tipus de propietats per generar moltes coses diferents des del punt de vista de la governança de dades i la qualitat de les dades, i també per ajudar-nos en les polítiques de gestió de dades i de retenció de dades. La idea bàsica és que creeu aquestes classificacions i les pugueu adjuntar allà on vulgueu, a nivell de taula, nivell de columna, aquest tipus de coses. El cas d’ús més comú, per descomptat, és que les entitats són taules i, a continuació, puc definir: quins són els meus objectes de dades mestres, quines són les meves taules de referència, quines són les meves taules transaccionals? Des de la perspectiva de la qualitat de les dades, puc fer classificacions en termes d’importància per al negoci per tal de prioritzar els esforços de neteja de dades i aquest tipus de coses.
Una cosa que sovint es passa per alt és, quina és la política de retenció de diferents tipus de dades de la nostra organització? Podem configurar-los i, en realitat, els podem adjuntar als diferents tipus d’artefactes d’informació del nostre entorn de modelatge i, per descomptat, també al nostre dipòsit. La bellesa és que aquests fitxers adjunts es troben al nostre diccionari de dades, de manera que quan utilitzem diccionaris de dades empresarials de l’entorn, els podem adjuntar a diversos models. Només els hem de definir una vegada i els podem aprofitar una i altra vegada entre els diferents models del nostre entorn. Es tracta només d’una captura de pantalla ràpida per mostrar que realment podeu especificar quan realitzeu un fitxer adjunt, a què són totes les peces que voleu adjuntar. I aquest exemple aquí és en realitat una llista de valors, de manera que, quan entren, podeu triar d’una llista de valors, teniu molt control en l’entorn de modelatge del que s’està escollint, i fins i tot podeu definir quina és la predeterminada. el valor és si no es selecciona un valor. Així, doncs, molta potència allà. Viuen al diccionari de dades.
Alguna cosa que vull mostrar una mica més avall en aquesta pantalla, a més, veieu els fitxers adjunts que apareixen a la part superior, que hi ha a sota, apareix informació de seguretat de dades. Realment podem aplicar polítiques de seguretat de dades a les diferents dades de l’entorn també. Per a diferents mapatges de compliment, classificacions de seguretat de dades, els enviem diversos del quadre que només podeu generar i començar a utilitzar, però també podeu definir els vostres mapatges i estàndards de compliment. Tant si esteu fent HIPAA com qualsevol altra iniciativa que hi hagi. I realment podeu començar a crear aquest conjunt de metadades molt ric al vostre entorn.
I després el Glossari i els termes, aquí és on es relaciona el significat empresarial. Molts cops hi ha diccionaris de dades que amb força freqüència una organització utilitza com a punt de partida per començar a publicar glosaris, però la terminologia i el verb. sovint molt tècnica. Aleshores, el que podem fer és que, si ho desitgem, puguem utilitzar-los com a punt de partida per elaborar glossaris, però realment volem que el negoci sigui propietari d’aquests. El que hem fet en l’entorn del servidor d’equip és que hem donat la possibilitat a les persones de crear definicions empresarials i, després, podem vincular-les als diferents artefactes de model a què corresponen també a l’entorn de modelatge. També reconeixem el punt que es va parlar anteriorment, és a dir, com més gent tinguis escrivida, més potencial hi ha d’error humà. El que també fem a la nostra estructura de glosari és, un, suportem una jerarquia de glossari, de manera que podem tenir diferents tipus de glossari o diferents tipus de coses a l’organització, però igual d’important, és si ja teniu algunes d’aquestes fonts. Allà amb els termes i tot el que es defineix, realment podem fer una importació de CSV per introduir-los al nostre entorn de modelatge, al nostre servidor d'equips o al nostre glossari, i començar a enllaçar des d'allà. I cada vegada que es canvia alguna cosa, hi ha un rastre d'auditoria complet del que eren les imatges d'abans i després, en termes de definicions i de tot, i el que veuràs arribar en un futur molt proper és també un flux de treball d'autorització. de manera que realment puguem controlar qui en té la responsabilitat, les aprovacions de comitès o persones i aquest tipus de coses, perquè el procés de govern sigui encara més robust a mesura que avancem.
El que també fa per a nosaltres és quan tenim aquests termes del glossari al glossari del servidor d'equips, aquest és un exemple d'edició en una entitat del model que he presentat aquí. Pot ser que tingui termes vinculats, però el que també fem és si hi ha paraules que es troben en aquest glossari que apareixen a les notes o descripcions del que tenim a les nostres entitats aquí, aquestes es mostren automàticament amb un color hiperenllaçat més clar i si feu clic amb el ratolí sobre ells, en realitat podrem veure la definició del glossari empresarial. Fins i tot ens proporciona informació més rica quan consumim la informació en si mateix, amb tots els termes del glossari que hi ha. Realment ajuda a enriquir l'experiència i aplicar el sentit a tot el que estem treballant.
Així que, de nou, va ser un volant molt ràpid. Evidentment, podríem dedicar-nos dies perquè aprofundim en les diferents parts, però es tracta d'un volant molt ràpid per la superfície. El que realment ens esforçem per fer és entendre com són aquests complexos entorns de dades. Volem millorar la visibilitat de tots aquests artefactes de dades i col·laborar per impulsar-los amb ER / Studio. Volem habilitar un modelatge de dades més eficient i automatitzat. I de tot tipus de dades parlem, ja siguin dades grans, relacionals tradicionals, magatzems de documents o qualsevol altra cosa. I de nou, ho vam aconseguir perquè tenim capacitats d’enginyeria avançades i inverses poderoses per a les diferents plataformes i les altres eines que puguis tenir. I es tracta de compartir i comunicar-se a tota l'organització amb tots els grups implicats. És allà on apliquem el significat mitjançant estàndards de denominació. A continuació, apliquem definicions a través dels nostres glosaris empresarials. A continuació, podem fer més classificacions per a totes les altres funcions de govern amb les extensions de metadades com ara extensions de qualitat de dades, classificacions per a la gestió de dades mestres o qualsevol altre tipus de classificacions que vulgueu aplicar a aquestes dades. A continuació, podem resumir més i millorar la comunicació encara més amb els objectes de dades empresarials, amb els diferents públics interessats, especialment entre els dissenyadors i els desenvolupadors.
I, de nou, el que és molt important al respecte és que hi ha un repositori integrat amb capacitats de gestió de canvis molt robustes. Avui no he tingut temps de mostrar-ho perquè és bastant complex, però el dipòsit té unes capacitats de gestió de canvis i rutes d’auditoria molt robustes. Podeu fer llançaments amb nombres, podeu fer versions amb nombres i, a més, podem tenir la possibilitat per a aquells que feu gestió de canvis, i els podem relacionar amb les vostres tasques. Avui tenim la capacitat d’introduir tasques i associar els vostres canvis de model amb tasques, de la mateixa manera que els desenvolupadors associarien els seus canvis de codi amb les tasques o històries d’usuaris amb els quals treballen.
Un cop més, va ser una visió general molt ràpida. Espero que hagi estat suficient per despertar la gana perquè puguem participar en converses molt més profundes per repartir alguns d’aquests temes a mesura que avancem en el futur. Gràcies pel vostre temps i, de nou, Rebecca.
Rebecca Jozwiak: Gràcies, Ron, això va ser fantàstic i tinc algunes preguntes del públic, però vull donar la possibilitat als nostres analistes d’enfonsar-se les dents en allò que havíeu de dir. Eric, aniré endavant i potser si voleu abordar aquesta diapositiva o una altra diferent, per què no aneu primer? O qualsevol altra pregunta.
Eric Little: Segur. Ho sento, quina era la pregunta, Rebecca? Voleu que us demani alguna cosa en concret o …?
Rebecca Jozwiak: Sé que inicialment teníeu algunes preguntes sobre Ron. Si voleu demanar-li ara que s’adreci a algun o algun d’ells fora de la vostra diapositiva o qualsevol altra cosa que us interessi el vostre interès? Quant a les funcionalitats de modelatge d'IDERA.
Eric Little: Sí, doncs, una de les coses, Ron, i així, com ho veieu, sembla que els diagrames que estaves mostrant són tipus generals de diagrames de relacions d'entitats com normalment en la construcció de bases de dades?
Ron Huizenga: Sí, en general, però, per descomptat, tenim els tipus ampliats per a les botigues de documents i aquest tipus de coses. Realment hem variat només per una simple notació relacional, en realitat hem afegit notacions addicionals per a les altres botigues.
Eric Little: Hi ha alguna manera que els vostres no puguin utilitzar tipus de models basats en gràfics, així que hi ha una manera d’integrar-se, per exemple, suposem que tinc una cosa com un quadrant superior, l’eina de compositor TopBraid o he fet alguna cosa. a Protégé o, com els nois financers de la FIBO, treballen molt en semàntica, coses de RDF, hi ha una manera d'aplicar aquest tipus de model de gràfics de relació entre entitats i utilitzar-lo és?
Ron Huizenga: En realitat estem estudiant la manera de manejar els gràfics. No gestionem explícitament bases de dades gràfiques i aquest tipus de coses, però estem estudiant maneres de fer-ho per ampliar les nostres metadades. Vull dir, podem introduir les coses mitjançant XML i aquest tipus de coses ara mateix, si almenys podem fer algun tipus de rendició de XML per introduir-lo com a punt de partida. Però busquem maneres més elegants.
I també us vaig mostrar aquesta llista de ponts d’enginyeria inversa que hi tenim també, de manera que sempre mirem d’obtenir extensions d’aquests ponts també per a plataformes específiques. És un esforç continu i continu, si això té sentit, començar a abraçar moltes d’aquestes noves construccions i les diferents plataformes que hi ha. Però puc dir que definitivament estem a l'avantguarda de fer això. Les coses que vaig mostrar, per exemple, MongoDB i aquest tipus de coses, som el primer venedor de modelat de dades que realment ho fa de manera nativa en el nostre propi producte.
Eric Little: D'acord, sí. Així, l’altra pregunta que us vaig plantejar, aleshores, era en termes de governança i manteniment del mateix, com quan vau utilitzar l’exemple, quan mostràveu l’exemple de la persona que és “empleada”, crec que era un “ salari ”i, després, teniu un“ pla ”, hi ha una manera, com gestioneu, per exemple, diferents tipus de persones que puguin tenir: suposem que teniu una gran arquitectura, no, suposem que teniu una gran empresa i la gent comença a agafar coses en aquesta eina i aquí teniu un grup que té la paraula "empleat" i un grup aquí que té la paraula "treballador". I una persona aquí diu "sou" i una altra persona diu. “Salari”.
Com es poden conciliar i gestionar i governar aquest tipus de distincions? Com que sé com ho faríem al món del gràfic, ja ho sabeu, faríeu servir llistes de sinònims o diríeu que hi ha un concepte i que té diversos atributs, o podríeu dir que en el model SKOS tinc una etiqueta preferida i tinc nombroses etiquetes alternatives que puc fer servir. Com ho feu això?
Ron Huizenga: Ho fem de dues maneres diferents, i sobretot parlem de la terminologia primer. Una de les coses que fem, per descomptat, és que volem tenir els termes definits o sancionats i, evidentment, al glossari empresarial és on els volem. A més, permetem enllaços a sinònims del glossari empresarial, de manera que el que podeu fer és dir, aquí és el meu terme, però també podeu definir quins són tots els sinònims d’aquests.
El més interessant, per descomptat, és quan comenceu a mirar aquest vast paisatge de dades amb tots aquests diferents sistemes que heu sortit, no podreu simplement sortir-hi i canviar les taules corresponents i aquest tipus de coses. corresponen a l'estàndard de denominació perquè pot ser un paquet que heu comprat, de manera que no teniu cap control sobre com canviar la base de dades ni res.
El que podríem fer allà, a més de poder associar les definicions del glossari, és a través d’aquells mapatges universals dels que us parlava, del que faríem i d’un tipus d’enfocament recomanat, és tenir un model lògic general que exposi el que Aquests conceptes diferents de negocis són els que parleu. Lligueu els termes del glossari comercial amb aquells i el més bon és ara que teniu aquest constructe que representa una entitat lògica tal com era, aleshores podeu començar a enllaçar des d'aquesta entitat lògica a totes les implementacions d'aquesta entitat lògica a els diferents sistemes.
Aleshores, quan ho necessiteu, podeu veure, oh, "persona" en aquest sistema, es diu "empleat". Aquí "salari" s'anomena "salari" en aquest altre sistema. Com que ho veureu, podreu veure totes les diferents manifestacions perquè les heu enllaçat.
Eric Little: Està bé, sí, ho tens. En aquest sentit, és segur dir que és així com alguns dels enfocaments orientats a objectes?
Ron Huizenga: Una mica. És una mica més intensiu que, suposo que podríeu dir. Vull dir, podríeu aprofundir en enllaçar i passar manualment, inspeccionar-los i fer-los. De la única cosa sobre la qual no he tingut l'oportunitat de parlar, ja que de nou, tenim moltes capacitats, també tenim una interfície d'automatització completa a la pròpia eina Data Architect. I una capacitat macro, que és realment un llenguatge de programació a l'eina. De manera que realment podem fer coses com escriure macros, fer-ho sortir i interrogar coses i crear enllaços per a vosaltres. La utilitzem per a la importació i exportació d’informació, la podem utilitzar per canviar coses o afegir atributs, esdeveniments basats en el model en si, o bé podem utilitzar-la per executar per lots per sortir realment i interrogar-hi coses i per completar construccions diferents. model. Així doncs, hi ha una interfície d’automatització completa que la gent també pot aprofitar. Utilitzar els mapatges universals amb aquests seria una manera molt poderosa de fer-ho.
Rebecca Jozwiak: D'acord, gràcies Ron, i gràcies Eric. Aquestes eren grans preguntes. Sé que passem una mica més amunt de l’hora, però voldria donar a Malcolm l’oportunitat de plantejar algunes qüestions sobre la manera de Ron. Malcolm?
Malcolm Chisholm: Gràcies, Rebecca. Així, Ron, és molt interessant, veig que hi ha moltes funcions. Una de les àrees que m’interessa molt és dir que si tenim un projecte de desenvolupament, com veieu el modelador de dades utilitzant aquestes capacitats i treballant potser de manera més col·laborativa amb analistes empresarials, amb un perfeccionador de dades, amb un analista de qualitat de dades. i amb els patrocinadors empresarials que, finalment, seran els responsables dels requisits d'informació reals del projecte. Com saps realment el modelador de dades, fer que el projecte sigui més eficaç i eficaç amb les capacitats que estem veient?
Ron Huizenga: Crec que una de les primeres coses que heu de fer és com a modeladora de dades (i no vull dir escollir algunes de les modelitzadores, però de totes maneres, però hi ha algunes persones que encara tenen la impressió que el modelador de dades és realment el tipus de rol de gatekeeper, estem definint el seu funcionament, som els guàrdies els que ens assegurem que tot sigui correcte.
Ara hi ha un aspecte que heu d'assegurar que esteu definint una arquitectura de dades de so i tota la resta. Però el més important és com a modelador de dades –i ho he trobat força, òbviament, quan estava consultant–, és que heu de convertir-vos en un facilitador, així que heu d’ajuntar aquestes persones.
Ja no serà un disseny per davant, generar, crear bases de dades; el que heu de poder fer és que heu de poder treballar amb tots aquests diferents grups d'interès, fent coses com enginyeria inversa, importar informació i tenir altres persones col·laboren, ja sigui en els glossaris o en la documentació, tot així, i ser un facilitador per incloure això al dipòsit i enllaçar els conceptes junts al dipòsit i treballar amb aquestes persones.
Realment és molt més un tipus d’entorn col·laboratiu on fins i tot mitjançant la definició de tasques o fins i tot fils de discussió o aquest tipus de coses que tenim al servidor d’equip, la gent pot col·laborar, fer preguntes i arribar als productes finals finals que ells. necessitat de la seva arquitectura de dades i de la seva organització. Va respondre aquest tipus de resposta?
Malcolm Chisholm: Sí, estic d'acord. Ja ho sabeu, crec que l'habilitat de facilitació és realment desitjable en els modeladors de dades. Estic d’acord que no sempre ho veiem, però crec que això és necessari i voldria suggerir que de vegades hi hagi inclinació a estar al vostre racó fent els vostres models de dades, però realment heu d’estar aquí treballant amb els altres grups d’interès. o simplement no enteneu l’entorn de dades amb què tracteu, i crec que el model pateix com a resultat. Però això és només la meva opinió.
Ron Huizenga: I és interessant perquè heu esmentat alguna cosa a la presentació sobre la història de com es desvien les empreses de les TI perquè no proporcionaven les solucions oportunes i aquest tipus de coses.
És molt interessant que en els meus compromisos de consultes posteriors, abans de convertir-me en responsable de producte, la majoria dels projectes que vaig fer durant els darrers dos anys abans d’això fossin patrocinats per empreses, on realment era el negoci que el conduïa i els arquitectes de dades. i els modelistes no formaven part de les TI. Formàvem part d’un grup patrocinat per empreses i érem allà com a facilitadors que treballaven amb la resta d’equips del projecte.
Malcolm Chisholm: Així que crec que és un punt molt interessant. Crec que comencem a veure un canvi en el món empresarial on l’empresa demana, o potser penso, no tant com faig, com en procés, però també comencen a pensar quines són les dades amb què treballo, quines són les meves necessitats de dades, quines són les dades que estic tractant com a dades i fins a quin punt podem obtenir productes i capacitats IDERA per donar suport a aquest punt de vista, i crec que les necessitats del negoci, fins i tot tot i que encara és una mica naixent.
Ron Huizenga: Estic d’acord amb tu i crec que estem veient que cada cop va més. Hem vist un despertar i el vau tocar abans quant a la importància de les dades. Vam veure la importància de les dades a principis d’informàtica o en l’evolució de bases de dades, aleshores, com dius, vam entrar en tot aquest cicle de gestió de processos, i el procés és extremadament important, no m’equivoqui allà, però ara ha passat? és quan es va produir aquest tipus de dades del focus perdut.
I ara les organitzacions s’estan adonant que les dades són realment el punt central. Les dades representen tot el que fem en el nostre negoci, de manera que hem d’assegurar-nos que disposem de dades precises, que puguem trobar la informació correcta que necessitem per prendre les nostres decisions. Perquè no tot prové d’un procés definit. Una part de la informació és un subproducte d’altres coses i encara hem de ser capaços de trobar-la, saber què significa i ser capaços de traduir les dades que veiem allà en definitiva en coneixement que podem utilitzar per impulsar millor els nostres negocis.
Malcolm Chisholm: Ara bé, i ara un altre àmbit amb què he estat lluitant és el que jo anomenaria el cicle de vida de dades que és, ja sabeu, si ens fixéssim en el tipus de cadena de subministrament de dades que travessa una empresa, començaríem amb adquisició de dades o captura de dades, que pot ser l’entrada de dades, però pot ser igualment, estic rebent dades de fora de l’empresa d’un proveïdor de dades.
A continuació, des de la captura de dades passem al manteniment de dades on penso a estandarditzar aquestes dades i a enviar-les als llocs on calgui. A continuació, l’ús de les dades, els punts reals on es troben les dades, obtindreu valor de les dades.
I en els vells temps tot es feia amb un estil individual, però avui pot ser, ja ho sabeu, un entorn d’analítica, per exemple, i més enllà d’això, un arxiu, una botiga, on posem les dades quan ja no ho necessiten i finalment un procés de purga. Com veieu que el model de dades s’adequa a la gestió de tot el cicle de vida de les dades?
Ron Huizenga: Aquesta és una molt bona pregunta i una cosa de la qual realment no he tingut temps per aprofundir en cap detall aquí avui és sobre el que de debò comencem a parlar de línia de dades. El que realment podem fer és que tinguem una capacitat de llinatge de dades a les nostres eines i, com dic, actualment podem extreure’n alguna part d’eines ETL, però també podeu fer un mapa dibuixant el llinatge també. Qualsevol d'aquests models de bases de dades o bases de dades que hem capturat i introduït en models podríem referir-nos a les construccions del diagrama de llinatge de dades.
El que podem fer és dibuixar un flux de dades, com dius, d’origen a objectiu, i a través del cicle de vida general de com transiten aquestes dades pels diferents sistemes i el que trobareu és, agafem empleats. 'dades: és un dels meus preferits basat en un projecte que vaig fer fa anys. Vaig treballar amb una organització que tenia dades d’empleats en 30 sistemes diferents. Allò que vam acabar fent allà i la presentació de Rebecca va aparèixer la diapositiva del llinatge de dades, es tracta d'una diapositiva de línia de dades bastant simplista, però el que vam poder fer va ser portar totes les estructures de dades, fer-les referència al diagrama i, a continuació, nosaltres en realitat es pot començar a mirar quins són els fluxos i com es vinculen aquestes entitats de dades diferents en un flux? I també podem anar més enllà d’això. Aquesta forma part d’un diagrama de flux o de llinatge de dades que veiem aquí. Si voleu anar més enllà d’això, també tenim l’arquitecte empresarial d’aquesta suite i el mateix s’aplica allà.
Qualsevol de les estructures de dades que hàgim capturat a l’entorn de modelat de dades, es pot fer referència a l’eina de modelatge empresarial de manera que fins i tot en els diagrames de models de negoci o en els diagrames de processos de negoci podeu fer referència a magatzems de dades individuals si voleu sortir de l'entorn de modelat de dades, i mentre les utilitzeu a les carpetes del model de procés empresarial, fins i tot podeu especificar el CRUD també sobre com es consumeix o es produeix aquesta informació i, a continuació, podem començar a generar coses com ara impactes i informes d’anàlisi i esquemes d’això.
A què volem arribar, i ja tenim moltes capacitats, però una de les coses que tenim és com una mena de punt que estem buscant, a mesura que continuem evolucionant les nostres eines cap endavant, és capaç de localitzar aquest llinatge de dades organitzatiu de final a extrem i el cicle de vida complet de les dades.
Malcolm Chisholm: D'acord. Rebecca, en tinc permès una altra?
Rebecca Jozwiak: Us permetré una altra, Malcolm, endavant.
Malcolm Chisholm: Moltes gràcies. Pensant en la governança de les dades i pensant en el modelat de dades, com podem aconseguir que aquests dos grups treballin efectivament junts i s’entenguin?
Eric Little: Bé, és interessant, crec que depèn realment de l’organització, i es remunta al meu concepte anterior, és que en aquelles organitzacions on es van impulsar les iniciatives vam estar lligades. Per exemple, dirigia una arquitectura de dades. equip, però estàvem relacionats amb els usuaris del negoci i realment els estàvem ajudant a mantenir el seu programa de govern de dades. Un cop més, és un enfocament consultiu, però és més que una funció empresarial.
El que realment necessiteu per fer-ho és que necessiteu modeladors de dades i arquitectes que entenguin de debò els negocis, puguin relacionar-se amb els usuaris del negoci i després els han ajudat a mantenir els processos de govern al seu voltant. El negoci vol fer-ho, però en general tenim els coneixements tecnològics per ajudar-los a destacar aquest tipus de programes. Realment ha de ser una col·laboració, però ha de ser propietat empresarial.
Malcolm Chisholm: D'acord, és fantàstic. Gràcies.
Eric Little: Està bé.
Rebecca Jozwiak: D'acord, moltes gràcies. Els membres del públic, em temo que no arribem a les vostres preguntes, però m’asseguraré que aconsegueixen fer arribar el convidat adequat que teníem a la línia d’avui. Vull agrair molt a Eric, Malcolm i Ron per ser els nostres convidats avui. Això va ser una gran cosa, la gent. I si us va agradar la transmissió web d’IDERA d’avui, IDERA també participarà en un Hot Technologies dimecres que ve si voleu unir-vos, discutint els reptes de la indexació i l’Oracles, així que un altre tema fascinant.
Moltes gràcies, amics, tingueu cura i ens veiem la propera vegada. Adeu.
