Emportar: 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 discutim "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 hi esteu, no dubteu a participar-hi. Si teniu preguntes en qualsevol moment, envieu-les al quadre de Q & A que hi ha a la part inferior dreta de la pantalla i ens assegurem que us respondran. Si no, ens assegurem que els nostres convidats els rebin per vosaltres.
Avui tenim una llista 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. Per tant, vaig a passar un parell de temes aquí que crec que es relacionaran amb la conversa de Ron una mica 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 actualment els entorns complexos 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 d’avui. 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. De manera que la gent dirà, d’acord, bé, pensa en el volum de les teves dades, que normalment és el focus - que és el que tens. 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 costat esquerre és una solució que es resol i maneja relativament ràpidament amb 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 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, NLP, extracció d’entitats, teniu informació de gràfics que surten de models estadístics o que surten de models semàntics. , teniu dades relacionals que existeixen a les taules, etc. Així, doncs, reunir totes aquestes dades i tots aquests diferents tipus és realment un repte important 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è es tracta, i què sabeu què hi ha? La possibilitat d’utilitzar estadístiques i la possibilitat d’utilitzar algun tipus d’informació entorn del que puguis conèixer o utilitzar algun tipus de connexió, 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 mapatge 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 el que es converteix en una 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à aspectes 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 us trobeu a zones com la indústria farmacèutica, tindreu moltes 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é. De manera que si tindreu 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 Y i ara teniu el problema de com es troba algú X i Y quan busquen aquest tipus d’informació? Com que no voleu simplement 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ó general per a 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 costós gestionar manualment les dades de referència. És costós haver de mantenir el mapeig manual i és costós que els experts en matèries deixin de fer les tasques quotidianes i hagin d’entrar i arreglar constantment els diccionaris de dades i re-actualitzar les 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à alguns tipus de vocabulari que podeu agafar en préstec d’espais de codi obert, igual que amb productes farmacèutics, el mateix amb la indústria bancària i financera, i també amb moltes d’aquestes àrees. La gent estableix vocabularis reutilitzables, genèrics i replicables per utilitzar-los.
I, de nou, mirant l’eina IDERA, tinc curiositat per veure com ho gestionen en termes d’ús 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 sobre potser com s’ha fet servir 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. Així que rebeu les 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 a mi m’agrada molt el vostre comentari que es poden produir molts errors si la gent escriu 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ò, seguiré endavant i passaré a Malcolm Chisholm. Malcolm, el pis és teu.
Chisholm de Malcolm: 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 passa, ja ho sabeu, els ordinadors mainframe es van posar realment a disposició 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 paraula, sinó que és 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 lloc a les PC on realment es va rebel·lar els usuaris quan van entrar els PC. La rebel·lió contra les TI centralitzades, que pensaven que no complien les seves necessitats, no eren 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 dades grans, les quatre o més v 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 necessitava 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 només ens centrem 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, seria 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. Doncs això, què passa en termes de la nostra arquitectura de dades, si les dades ja no es consideren simplement l'exhauriment 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.
Tot és tot 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 de 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 basada en el negoci perquè estem condicionats per l’època del centratge en els processos. 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 que, però realment, no ho som. 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 d’això. 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 es troben dins dels paràmetres sobre els quals fem supòsits. 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 baix de cap tipus de canvi no gestionat en aquesta zona, de manera que les regles de garantia de 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 una història de dades en blau per a la nostra base de dades, però alhora necessitem aquells models conceptuals, aquelles visions comercials de dades que tradicionalment no s’han fet en 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 de clients, per exemple, és correcte, anem a fer que les dades dels nostres clients siguin un centre on puguem, ja ho sabeu, entendre en termes de qualitat de dades reals 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 una forma en què 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. Ens trobem realment en una nova era i crec que hi ha diversos nivells que hem de respondre a l’arquitectura de dades que condueix a l’empresa 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 ha d’alimentar la visió empresarial, perquè, a diferència del que estàveu dient, on TI va mantenir les regnes durant tant de temps i és una mena de casos que ja no és així i que la cultura. necessita canviar. I estic bastant segur que hi ha un gos de fons que va estar d’acord amb tu al 100%. I amb això vaig a passar la pilota a Ron. Estic molt emocionat de 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è, com han assenyalat Eric i Malcolm, aquest és un tema molt ampli i profund, i amb el que nosaltres Avui estem parlant del rastreig 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 entre altres coses, el model es converteix realment en el punt de vida del 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 ja estàvem vist 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 aleshores, és molt important, com podem aconseguir que tots aquells grups interessats col·laborin, i en particular els grups d’interès empresarials, 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 l’arquitecte empresarial, 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 dels 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 a una meitat 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 com que 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. I és així com realment comencem a impulsar la col·laboració.
I després l’última peça de la qual parlaré breument és que quan entreu en aquests entorns, no són només les bases de dades que hi ha fora. Va a tenir diverses bases de dades, magatzems de dades, també tindràs molts artefactes heretats, el que jo anomenaria. 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 patrimoni obsolets que no han estat netejats a causa de l’enfocament basat en projectes sobre el qual havia parlat Malcolm. És sorprenent com en els darrers anys les organitzacions invertiran projectes, substituiran un sistema o una solució, però sovint no hi ha prou pressupost del projecte per desactivar les solucions obsoletes, així que ara ho són. I hem de descobrir què podem desfer-nos realment del nostre entorn i quins són els útils per avançar. I això es vincula amb la pobra estratègia de desmantellament. Això és la mateixa part.
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 fem servir magatzems de dades, marts de dades amb ETL tradicional o si 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 de bases de dades relacionals, hem de reunir totes aquestes dades perquè puguem gestionar-les i saber amb què tractem els nostres models.
Una vegada més, la complexitat que farem és que tenim diversos passos que volem fer. Primer de tot, entreu i potser no teniu cap aspecte del que sembla aquest paisatge informatiu. 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 nomenament són extremadament importants i en parlo de diverses maneres aquí. 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 és allà on podem classificar les dades més endavant amb una cosa que es diu 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, finalment, ja he parlat del fet que necessitem que tot això sigui repositori basat en molta col·laboració i capacitats de publicació, per tal que els nostres grups interessats puguin utilitzar-lo. 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 em dedicaré gaire temps a 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 connectar-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 oferir-vos una visió general molt ràpida 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 d’aquest fitxer de model concret. 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 començar a reunir 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 es tracta d’una instància del SQL Server, potser d’una altra instància d’Oracle. Tenim la capacitat de lligar tot això en un mateix entorn de modelatge. I de nou, el que tinc aquí és un model real de magatzem de dades que pot, de nou, estar en el mateix entorn de modelatge o el podem tenir al dipòsit i també enllaçar-lo entre 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.
Ara diguem que també hem tingut rusc al nostre entorn. Si invertim l’enginyer d’un entorn Hive, i podem avançar i invertir l’enginyer de Hive amb aquesta mateixa eina de modelatge exacta, veiem una cosa que és una mica 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ò de 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. .
En prenguem 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’ambients JSON on teniu botigues de documents, el JSON és un animal diferent i hi ha construccions que no corresponen a models relacionals. 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 en realitat 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. Aquí encara veieu els tipus típics de notacions de referència, 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 en un extrem, però la cardinalitat d'un significa que, dins de l'editor, 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ò realment incrustada com una 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 t’ho explicaré molt ràpidament, vaig parlar del fet d’incloure coses des d’altres àmbits diferents. Suposo que vaig a importar un model des d’una base de dades o l’enginyerà inversament, però el faré servir 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. Veiem 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 aportar 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 un 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 tallant això.
Passaré a aquesta, ja que ara mateix estic a l’entorn de demostració i us mostraré un parell d’altres coses abans de tornar 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 empresarials. Ha estat molt difícil classificar-les fins ara, però el que realment hem fet a ER / Studio Enterprise Team Edition, a la publicació de 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. Es poden reutilitzar 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ó realment 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. Acabo de 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 de negoci, 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 observeu la captura de pantalla a la part dreta, veureu que hi ha noms abreujats dels noms d'origen i quan apliquem una plantilla d'estàndards de denominació, en realitat tindrem 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à aquelles 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 guardat 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 dissenyar i avançar enginyeria. Tenim un concepte molt únic i aquí és on realment comencem a ajuntar aquests entorns.I es diu Assignació 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 ho representa, fins i tot la podem relacionar 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 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 feu HIPAA com si hi ha alguna de les altres iniciatives 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 se’ns ha donat la possibilitat a les persones de crear definicions d’empresa i, després, podem vincular-los als diferents artefactes de model als quals corresponen 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é passa per a nosaltres és quan tenim aquests termes de 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. Ajuda realment 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 intentem és entendre com semblen 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 es tracta de tot tipus de dades de què parlem, ja siguin dades grans, dades 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 un 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 dipòsit 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 possibilitat 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 les històries d’usuaris amb els quals treballen.
Un cop més, va ser una visió general molt ràpida. Espero que hagi estat prou amb 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 el que havíeu de dir. Eric, seguiré endavant i, potser, si voleu abordar aquesta diapositiva o una altra, 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í, 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 ara que faríeu servir en la construcció de bases de dades, correcte?
Ron Huizenga: Sí, en general, però també tenim els tipus ampliats per a les botigues de documents i aquest tipus de coses. En realitat hem variat només per una simple notació relacional, en realitat hem afegit notacions addicionals per a la resta de 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 alguna cosa com un quadrant superior, l’eina de compositor TopBraid o he fet alguna cosa a Protégé o , ja sabeu, com els nois financers de la FIBO, treballen molt en semàntica, coses de RDF, hi ha alguna manera d'aplicar aquest tipus de model de gràfics de relació entre entitats i utilitzar-lo?
Ron Huizenga: Estem estudiant la manera de gestionar gràfics. Avui 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ò estem estudiant formes més elegants.
I també us vaig mostrar aquesta llista de ponts d’enginyeria inversa que també hi tenim, de manera que sempre estem mirant d’obtenir extensions a aquests ponts per a plataformes específiques. Es tracta d’un esforç constant i continuat, si té sentit, per començar a abraçar moltes d’aquestes novetats i les diferents plataformes que hi ha. Però puc dir que definitivament estem a l'avantguarda de fer això. Les coses que he mostrat, 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 diverses maneres i, primer, parlem de la terminologia. 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. Així que el que podeu fer és dir, aquí és el meu terme, però també podeu definir quins són tots els sinònims.
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 veuràs, veuràs totes les manifestacions diferents perquè les heu enllaçat.
Eric Little: Està bé, sí, ho tens. En aquest sentit, és segur dir que són alguns dels plantejaments orientats a objectes?
Ron Huizenga: Una mica. És una mica més intensiu que, suposo que podríeu dir-ho. Vull dir, podríeu aprofundir en enllaçar i passar manualment, inspeccionar-los i fer-los. De la mateixa cosa, de la que realment no he tingut l'oportunitat de parlar - perquè, 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: Molt bé, gràcies Ron, i gràcies Eric. Aquestes eren grans preguntes. Sé que hem passat una mica més avall de l’hora, però voldria donar a Malcolm l’oportunitat de plantejar algunes preguntes a la manera de Ron. Malcolm?
Chisholm de Malcolm: Gràcies, Rebecca. Així, Ron, és molt interessant, veig que hi ha moltes funcions aquí. 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 sabeu, realment, el model de dades, que el projecte sigui més eficaç i eficaç amb les funcions 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 modeladores, però ho faré), però, hi ha algunes persones que encara tenen la impressió que el modelador de dades. realment és 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?
Chisholm de Malcolm: Sí, hi 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 anterior a la presentació sobre la història de com les empreses es desvien de les TI perquè no proporcionaven les solucions de manera puntual 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.
Chisholm de Malcolm: 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 la veiem anar cada cop més. Hem vist un despertar i ho 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, així 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.
Chisholm de Malcolm: 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 examinéssim el tipus de cadena de subministrament de dades que travessa una empresa, començaríem amb l'adquisició de dades o captura de dades, que pot ser l’entrada de dades, però també podria ser, 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 les 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 la 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, en realitat podem extreure’n alguna part d’eines ETL, però també podeu fer un mapa dibuixant també el llinatge. Qualsevol d'aquests models de bases de dades o bases de dades que hem capturat i introduït en models podríem fer referència a les construccions a partir 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 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.
Chisholm de Malcolm: Bé. Rebecca, en tinc permès una altra?
Rebecca Jozwiak: Us permetré un altre, Malcolm, endavant.
Chisholm de Malcolm: 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, jo dirigia un equip d’arquitectura de dades, però nosaltres es van relacionar amb els usuaris de l'empresa i, en realitat, els vam ajudar a mantenir el seu programa de govern de dades. Un cop més, un enfocament consultiu, però és una funció empresarial més.
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.
Chisholm de Malcolm: Està bé, està molt bé. Gràcies.
Eric Little: Bé.
Rebecca Jozwiak: D'acord, moltes gràcies. Membres del públic, tinc por que no arribem a les vostres preguntes, però m’asseguraré que es facin arribar al 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 agrada 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 veurem la propera vegada. Adeu.