Construyendo una arquitectura de datos orientada a los negocios

Por el personal de Techopedia, 28 de septiembre de 2016

Para llevar: la presentadora Rebecca Jozwiak discute soluciones de arquitectura de datos con Eric Little de OSTHUS, Malcolm Chisholm de First San Francisco Partners y Ron Huizenga de IDERA.

Actualmente no has iniciado sesión. Inicia sesión o regístrate para ver el video.

Rebecca Jozwiak: Damas y caballeros, hola y bienvenidos a Hot Technologies de 2016. Hoy estamos discutiendo “Construyendo una arquitectura de datos orientada a los negocios”, definitivamente un tema candente. Mi nombre es Rebecca Jozwiak, seré su anfitrión para la transmisión web de hoy. Tuiteamos con un hashtag de # HotTech16, así que si ya estás en Twitter, no dudes en unirte a eso también. Si tiene preguntas en cualquier momento, envíelas al panel de preguntas y respuestas en la parte inferior derecha de su pantalla y nos aseguraremos de que sean respondidas. De lo contrario, nos aseguraremos de que nuestros huéspedes los reciban por usted.

Así que hoy tenemos una alineación realmente fascinante. Hoy hay muchos bateadores fuertes con nosotros. Tenemos a Eric Little, vicepresidente de ciencia de datos de OSTHUS. Tenemos a Malcolm Chisholm, director de innovación, que es un título realmente genial, para First San Francisco Partners. Y tenemos a Ron Huizenga, gerente senior de productos de IDERA. Y, ya sabes, IDERA tiene un conjunto realmente completo de soluciones de modelado y gestión de datos. Y hoy nos dará una demostración sobre cómo funciona su solución. Pero antes de llegar a eso, Eric Little, te voy a pasar la pelota.

Eric Little: Bien, muchas gracias. Así que voy a repasar un par de temas aquí que creo que se relacionarán un poco con la charla de Ron y espero que también preparen el escenario para algunos de estos temas, algunas preguntas y respuestas.

Entonces, lo que me interesó con lo que está haciendo IDERA es que creo que señalan correctamente que los entornos complejos realmente están impulsando muchos valores comerciales hoy en día. Y por entornos complejos nos referimos a entornos de datos complejos. Y la tecnología se está moviendo realmente rápido y es difícil mantenerse al día en el entorno empresarial actual. Entonces, las personas que trabajan en espacios tecnológicos a menudo verán que usted tiene clientes que están resolviendo problemas con: “¿Cómo uso big data? ¿Cómo incorporo la semántica? ¿Cómo relaciono algunas de estas cosas nuevas con mis datos más antiguos? ”, Y así sucesivamente, y eso nos lleva hoy en día a estos cuatro v de big data con los que muchas personas están bastante familiarizadas, y entiendo que puede haber más de cuatro a veces, he visto hasta ocho o nueve, pero normalmente, cuando la gente habla de cosas como big data o si estás hablando de big data, generalmente estás mirando algo que es una especie de escala empresarial. Y entonces la gente dirá, bueno, bueno, piense en el volumen de sus datos, que normalmente es el foco, eso es lo que tiene. La velocidad de los datos tiene que ver con qué tan rápido puedo moverlos o qué tan rápido puedo consultarlos u obtener las respuestas, y así sucesivamente. Y personalmente creo que el lado izquierdo de eso es algo que se está resolviendo y manejando relativamente rápido con muchos enfoques diferentes. Pero en el lado derecho veo mucha capacidad de mejora y muchas nuevas tecnologías que realmente están llegando a primer plano. Y eso realmente tiene que ver con la tercera columna, la variedad de datos.

En otras palabras, la mayoría de las empresas hoy en día buscan datos estructurados, semiestructurados y no estructurados. Los datos de imagen comienzan a convertirse en un tema candente, por lo que al poder usar la visión por computadora, mirar píxeles, raspar texto, PNL, extracción de entidades, tiene información gráfica que proviene de modelos estadísticos o que sale de semántica modelos, tiene datos relacionales que existen en tablas, etc. Por lo tanto, reunir todos esos datos y todos estos tipos diferentes realmente representa un gran desafío y lo verán, ya sabes, en Gartner y otras personas que están siguiendo las tendencias en la industria.

Y luego, lo último de lo que la gente habla en big data es a menudo esta noción de voracidad, que es realmente la incertidumbre de sus datos, lo confuso de los mismos. ¿Qué tan bien sabes de qué se tratan tus datos, qué tan bien entiendes lo que hay allí, y sabes? La capacidad de utilizar estadísticas y la capacidad de utilizar algún tipo de información en torno a lo que podría saber o utilizar algún contexto, puede ser valioso allí. Entonces, la capacidad de ver los datos de esta manera en términos de cuánto tiene, qué tan rápido necesita moverlos o acceder a ellos, todos los tipos de datos que puede tener en su empresa y qué tan seguro está de dónde es, de qué se trata, de qué calidad está, etc. Esto realmente requiere un gran esfuerzo coordinado ahora entre muchas personas para administrar sus datos de manera efectiva. El modelado de datos, por lo tanto, es cada vez más importante en el mundo de hoy. Por lo tanto, los buenos modelos de datos realmente están generando mucho éxito en las aplicaciones empresariales.

Tiene fuentes de datos de una variedad de fuentes, como decíamos, lo que realmente requiere muchos tipos diferentes de integración. Por lo tanto, reunir todo esto es realmente útil para poder ejecutar consultas, por ejemplo, en numerosos tipos de fuentes de datos y recuperar información. Pero para hacer eso necesita buenas estrategias de mapeo y, por lo tanto, mapear ese tipo de datos y mantenerse al día con esos mapeos puede ser un verdadero desafío. Y luego tiene este problema, ¿cómo puedo vincular mis datos heredados a todas estas nuevas fuentes de datos? Supongamos que tengo un gráfico, ¿tomo todos mis datos relacionales y los pongo en un gráfico? Por lo general, esa no es una buena idea. Entonces, ¿cómo es que las personas pueden administrar todo este tipo de modelos de datos que están sucediendo? El análisis realmente tiene que ejecutarse en muchos de estos diferentes tipos de fuentes de datos y combinaciones. Entonces, las respuestas que surgen de esto, las respuestas que las personas necesitan para tomar realmente buenas decisiones comerciales son críticas.

Así que no se trata solo de construir tecnología por el bien de la tecnología, es realmente, qué voy a hacer, qué puedo hacer con él, qué tipo de análisis puedo ejecutar y la capacidad, por lo tanto, como ya he hecho he estado hablando, juntar todo esto, integrarlo es muy, muy importante. Y uno de estos tipos de análisis se ejecuta en cosas como búsqueda y consulta federadas. Eso realmente se está volviendo imprescindible. Normalmente, sus consultas deben estar enhebradas en múltiples tipos de fuentes y extraer información de forma confiable.

El único elemento clave que a menudo, especialmente las personas, analizarán aspectos clave como las tecnologías semánticas, y es algo de lo que espero que Ron hable un poco en el enfoque IDERA, es cómo se separa o gestiona capa de modelo de sus datos de la capa de datos en sí, de esos datos en bruto? Entonces, en la capa de datos, puede tener bases de datos, puede tener datos de documentos, puede tener datos de hojas de cálculo, puede tener datos de imágenes. Si se encuentra en áreas como las industrias farmacéuticas, tiene grandes cantidades de datos científicos. Y además, las personas normalmente buscan una forma de construir un modelo que les permita integrar rápidamente esos datos y realmente cuando están buscando datos ahora no están buscando incorporar todos los datos en su capa de modelo, lo que está buscando hacer en la capa de modelo es darle una buena representación lógica de lo que son las cosas, vocabularios comunes, tipos comunes de entidades y relaciones, y la capacidad de llegar realmente a los datos donde están. Entonces tiene que decir qué es, y tiene que decir dónde está, y tiene que decir cómo ir a buscarlo y traerlo de vuelta.

Así que este ha sido un enfoque que ha tenido bastante éxito en impulsar las tecnologías semánticas, que es un área en la que trabajo mucho. Entonces, una pregunta que quería hacerle a Ron, y que creo que será útil en la sección de preguntas y respuestas, es ver cómo la plataforma IDERA logra esto. Entonces, ¿la capa modelo está realmente separada de la capa de datos? ¿Están más integrados? ¿Cómo funciona eso y cuáles son algunos de los resultados y beneficios que están viendo de su enfoque? Por lo tanto, los datos de referencia se están volviendo realmente críticos. Entonces, si va a tener este tipo de modelos de datos, si va a poder federarse y buscar entre las cosas, realmente debe tener buenos datos de referencia. Pero el problema es que los datos de referencia pueden ser realmente difíciles de mantener. A menudo, nombrar estándares en sí mismos es un desafío difícil. Un grupo llamará a algo X y un grupo llamará a algo Y y ahora tiene el problema de cómo alguien encuentra X e Y cuando está buscando este tipo de información. Debido a que no solo desea darles una parte de los datos, desea darles todo lo relacionado. Al mismo tiempo, los términos cambian, el software queda obsoleto, y así sucesivamente, ¿cómo mantiene y mantiene esos datos de referencia a lo largo del tiempo?

Y, de nuevo, las tecnologías semánticas, específicamente usando cosas como taxonomías y vocabularios, diccionarios de datos, han proporcionado una forma espacial estándar de hacerlo, que es realmente muy robusta, utiliza ciertos tipos de estándares, pero la comunidad de bases de datos lo ha hecho por un mucho tiempo también, solo de diferentes maneras. Creo que una de las claves aquí es pensar en cómo usar quizás modelos de relación de entidad, cómo usar quizás modelos de gráficos o algún tipo de enfoque aquí que realmente le brindará una forma espaciada estándar de manejar sus datos de referencia. Y luego, por supuesto, una vez que tenga los datos de referencia, las estrategias de mapeo deben administrar una amplia variedad de nombres y entidades. Entonces, a los expertos en la materia a menudo les gusta usar sus propios términos.

Entonces, un desafío en esto es siempre, ¿cómo le das información a alguien pero la haces relevante para la forma en que hablan sobre ella? Entonces, un grupo puede tener una forma de ver algo, por ejemplo, puede ser un químico que trabaja en un medicamento, y puede ser un biólogo estructural que trabaja en el mismo medicamento, y puede tener diferentes nombres para los mismos tipos de entidades que se relacionan con tu campo. Tienes que encontrar formas de unir esas terminologías personalizadas, porque el otro enfoque es, tienes que obligar a las personas a abandonar su término y usar el de otra persona, que a menudo no les gusta. Otro punto aquí es que manejar un gran número de sinónimos se vuelve difícil, por lo que hay muchas palabras diferentes en los datos de muchas personas que pueden referirse a lo mismo. Tiene un problema de referencia allí usando un conjunto de relaciones de muchos a uno. Los términos especializados varían de una industria a otra, por lo que si va a encontrar una solución global para este tipo de gestión de datos, ¿con qué facilidad es portátil de un proyecto o de una aplicación a otra? Ese puede ser otro desafío.

La automatización es importante y también es un desafío. Es costoso manejar manualmente los datos de referencia. Es costoso tener que seguir mapeando manualmente y es costoso que los expertos en la materia dejen de hacer su trabajo diario y tengan que ingresar y corregir constantemente los diccionarios de datos y actualizar las definiciones, etc. Los vocabularios replicables realmente muestran mucho valor. Esos son vocabularios que a menudo puedes encontrar externos a tu organización. Si está trabajando en petróleo crudo, por ejemplo, habrá ciertos tipos de vocabularios que puede pedir prestados en espacios de código abierto, lo mismo con productos farmacéuticos, lo mismo con la industria bancaria y financiera, lo mismo con muchos de estos tipos de áreas. La gente está poniendo vocabularios reutilizables, genéricos y replicables para que la gente los use.

Y, nuevamente, mirando la herramienta IDERA, tengo curiosidad por ver cómo manejan esto en términos de uso de tipos de estándares. En el mundo de la semántica, a menudo se ven cosas como los modelos SKOS que proporcionan estándares para al menos relaciones más amplias / estrechas que las relaciones y esas cosas pueden ser difíciles de hacer en los modelos ER pero, ya sabes, no es imposible, solo depende de cuánto de eso maquinaria y ese enlace que puede manejar en ese tipo de sistemas.

Así que, por último, solo quería hacer una comparación con algunos motores semánticos que veo en la industria, y pedirle a Ron e invitarlo un poco a hablar sobre quizás cómo se ha utilizado el sistema IDERA junto con cualquier tecnología semántica. ¿Es capaz de integrarse con tiendas triples, bases de datos de gráficos? ¿Qué tan fácil es usar fuentes externas porque ese tipo de cosas en el mundo semántico a menudo se pueden tomar prestadas usando puntos finales SPARQL? Puede importar modelos RDF u OWL directamente en su modelo, consultarlos de nuevo, por lo que, por ejemplo, la ontología genética o la ontología de proteínas, que pueden vivir en algún lugar de su propio espacio con su propia estructura de gobierno y simplemente puedo importar todo o parte de eso, ya que lo necesito en mis propios modelos. Y tengo curiosidad por saber cómo IDERA aborda este problema. ¿Tiene que mantener todo internamente, o hay formas de utilizar otros tipos de modelos estandarizados e incorporarlos y cómo funciona? Y lo último que mencioné aquí es cuánto trabajo manual implica realmente para construir los glosarios y los repositorios de metadatos.

Así que sé que Ron nos mostrará algunas demostraciones sobre este tipo de cosas que serán realmente interesantes. Pero el problema que a menudo veo al consultar con los clientes es que se producen muchos errores si las personas escriben en sus propias definiciones o sus propios metadatos. Entonces obtienes errores ortográficos, errores de dedo gordo, eso es una cosa. También obtienes personas que pueden tomar algo de, ya sabes, solo Wikipedia o una fuente que no necesariamente tiene la calidad que deseas en tu definición, o tu definición es solo desde la perspectiva de una persona, por lo que no está completa, y no está claro entonces cómo funciona el proceso de gobernanza. La gobernanza, por supuesto, es un problema muy, muy grande cada vez que habla de datos de referencia y cuando habla de cómo esto puede encajar en los datos maestros de alguien, cómo van a usar sus metadatos y pronto.

Así que solo quería presentar algunos de estos temas. Estos son elementos que veo en el espacio comercial a través de muchos tipos diferentes de trabajos de consultoría y muchos espacios diferentes, y estoy realmente interesado en ver lo que Ron nos mostrará con IDERA para señalar algunos de estos temas . Así que muchas gracias.

Rebecca Jozwiak: Muchas gracias, Eric, y realmente me gusta tu comentario de que pueden ocurrir muchos errores si las personas escriben sus propias definiciones o metadatos. Sé que en el mundo del periodismo hay un mantra de que "muchos ojos cometen pocos errores", pero cuando se trata de aplicaciones prácticas, demasiadas manos en el tarro de galletas tienden a dejarte con muchas galletas rotas, ¿verdad?

Eric Little: Sí, y gérmenes.

Rebecca Jozwiak: Sí. Con eso voy a seguir adelante y pasarlo a Malcolm Chisholm. Malcolm, el piso es tuyo.

Malcolm Chisholm: Muchas gracias, Rebecca. Me gustaría mirar un poco sobre lo que Eric ha estado hablando, y agregar, más o menos, algunas observaciones a las que, ya sabes, Ron también podría responder, al hablar sobre "Hacia una arquitectura de datos orientada a los negocios "- ¿Qué significa ser impulsado por los negocios y por qué es tan importante? ¿O es solo alguna forma de exageración? No lo creo.

Si observamos lo que ha estado sucediendo desde, ya sabes, las computadoras mainframe realmente estuvieron disponibles para las empresas, por ejemplo, alrededor de 1964, hasta hoy, podemos ver que ha habido muchos cambios. Y resumiría estos cambios como un cambio de centrado en el proceso a centrado en los datos. Y eso es lo que hace que las arquitecturas de datos impulsadas por los negocios sean tan importantes y relevantes para la actualidad. Y creo que, ya sabes, no es solo una palabra de moda, es algo que es absolutamente real.

Pero podemos apreciarlo un poco más si nos sumergimos en la historia, por lo que retrocediendo en el tiempo, hasta la década de 1960 y durante algún tiempo después, dominaron los mainframes. Estos luego dieron paso a las PC donde realmente había una rebelión de los usuarios cuando las PC entraron. La rebelión contra la TI centralizada, que pensaban que no satisfacía sus necesidades, no era lo suficientemente ágil. Eso rápidamente dio lugar a la informática distribuida, cuando las PC se vincularon entre sí. Y luego Internet comenzó a suceder, lo que desdibujó los límites de la empresa: ahora podía interactuar con terceros fuera de sí misma en términos de intercambio de datos, lo que no había sucedido antes. Y ahora hemos entrado en la era de la nube y los grandes datos, donde la nube son plataformas que realmente son una infraestructura comercial y, por lo tanto, estamos dejando, por así decirlo, a la necesidad de ejecutar grandes centros de datos porque, ya sabes, nosotros Tenemos la capacidad en la nube disponible para nosotros, y concomitante con esa gran cantidad de datos que Eric ha, ya sabes, tan elocuentemente discutido. Y en general, como vemos, a medida que ocurrió el cambio en la tecnología, se ha centrado más en los datos, nos preocupamos más por los datos. Al igual que con Internet, cómo se intercambian los datos. Con Big Data, las cuatro o más v de los datos en sí.

Al mismo tiempo, y quizás lo más importante, los casos de uso de negocios cambiaron. Cuando se introdujeron las computadoras por primera vez, se utilizaron para automatizar cosas como libros y registros. Y todo lo que era un proceso manual, que involucraba libros de contabilidad o cosas así, se programaban, esencialmente, en casa. Eso cambió en los años 80 a la disponibilidad de paquetes operativos. Ya no necesitaba escribir su propia nómina, podía comprar algo que lo hiciera. Eso dio lugar a una gran reducción en el momento, o reestructuración, en muchos departamentos de TI. Pero luego apareció la inteligencia empresarial, con cosas como almacenes de datos, principalmente en los años 90. Seguido por los modelos de negocio de dotcom que, por supuesto, fueron un gran frenesí. Entonces MDM. Con MDM comienzas a ver que no estamos pensando en la automatización; en realidad nos estamos centrando en curar datos como datos. Y luego análisis, que representan el valor que puede obtener de los datos. Y dentro de la analítica se ven empresas que tienen mucho éxito cuyo modelo de negocio principal gira en torno a los datos. Google, Twitter, Facebook serían parte de eso, pero también se podría argumentar que Walmart lo es.

Y así, el negocio ahora está realmente pensando en los datos. ¿Cómo podemos obtener valor de los datos? Cómo los datos pueden impulsar el negocio, la estrategia y estamos en la era dorada de los datos. Entonces, dado que, ¿qué está pasando en términos de nuestra arquitectura de datos, si los datos ya no se consideran simplemente como el escape que sale del back-end de las aplicaciones, sino que son realmente centrales para nuestros modelos de negocio? Bueno, parte del problema que tenemos para lograrlo es que la TI está realmente atrapada en el pasado con el ciclo de vida del desarrollo de sistemas, que fue la consecuencia de tener que lidiar rápidamente con esa fase de automatización de procesos en la era temprana de la TI, y trabajar en proyectos es una cosa similar. Para TI, y esto es un poco una caricatura, pero lo que estoy tratando de decir es que algunas de las barreras para obtener una arquitectura de datos impulsada por los negocios se deben a que, de alguna manera, hemos aceptado sin cultura una cultura en TI que deriva de una época pasada.

Entonces todo es un proyecto. Cuéntame tus requisitos en detalle. Si las cosas no funcionan, es porque no me dijiste tus requisitos. Bueno, eso no funciona hoy con datos porque no estamos comenzando con procesos manuales no automatizados o una, ya sabes, una conversión técnica de procesos comerciales, estamos comenzando muy a menudo con datos de producción ya existentes que estamos intentando para obtener valor de Pero nadie que esté patrocinando un proyecto centrado en datos realmente entiende esos datos en profundidad. Tenemos que hacer descubrimiento de datos, tenemos que hacer análisis de datos de origen. Y eso realmente no coincide con el desarrollo de sistemas, ya sabes, cascada, ciclo de vida SDLC, de los cuales Agile, diría, es una especie de mejor versión de eso.

Y en lo que se está centrando es en la tecnología y la funcionalidad, no en los datos. Por ejemplo, cuando hacemos pruebas en una fase de prueba, generalmente será, ¿funciona mi funcionalidad, digamos mi ETL, pero no estamos probando los datos? No estamos probando nuestras suposiciones sobre la entrada de datos de origen. Si lo hiciéramos, tal vez estaríamos en mejor forma y, como alguien que ha realizado proyectos de almacenamiento de datos y sufrió cambios aguas arriba, rompiendo mis ETL, lo agradecería. Y, de hecho, lo que queremos ver es probar como un paso preliminar para el monitoreo continuo de la calidad de los datos de producción. Así que tenemos muchas actitudes en las que es difícil lograr la arquitectura de datos orientada a los negocios porque estamos condicionados por la era de los procesos centrados. Necesitamos hacer una transición a la centralización de datos. Y esta no es una transición total, ya sabes, todavía hay mucho trabajo de proceso por hacer, pero realmente no estamos pensando en términos centrados en datos cuando sea necesario, y las circunstancias que ocurren cuando realmente estamos obligado a hacer eso.

Ahora la empresa se da cuenta del valor de los datos, quieren desbloquear los datos, entonces, ¿cómo vamos a hacer eso? Entonces, ¿cómo hacemos la transición? Bueno, ponemos los datos en el corazón de los procesos de desarrollo. Y dejamos que el negocio lidere con los requisitos de información. Y entendemos que nadie comprende los datos de origen existentes al comienzo del proyecto. Se podría argumentar que la estructura de datos y los datos en sí llegaron a través de TI y operaciones, respectivamente, por lo que deberíamos saberlo, pero en realidad no. Este es un desarrollo centrado en datos. Por lo tanto, al pensar dónde y cómo hacemos el modelado de datos en un mundo centrado en los datos, debemos tener bucles de retroalimentación para los usuarios en términos de refinar sus requisitos de información, a medida que hacemos el descubrimiento de datos y el perfil de datos, prevemos el análisis de datos de origen y, a medida que gradualmente obtengamos más y más certeza sobre nuestros datos. Y ahora estoy hablando de un proyecto más tradicional, como un centro MDM o un almacén de datos, no necesariamente los proyectos de Big Data, aunque esto, todavía lo mantengo, bastante cerca de eso. Entonces, esos bucles de retroalimentación incluyen a los modeladores de datos, ya sabes, avanzando gradualmente su modelo de datos e interactuando con los usuarios para asegurarse de que los requisitos de información se refinen en función de lo que es posible, lo que está disponible, de los datos de origen a medida que lo entienden mejor, por lo que ya no se trata de que el modelo de datos esté, ya sabes, en un estado que no está allí o que está completamente hecho, es un enfoque gradual.

Del mismo modo, más abajo de eso tenemos garantía de calidad donde desarrollamos reglas para pruebas de calidad de datos para asegurarnos de que los datos estén dentro de los parámetros sobre los que estamos haciendo suposiciones. Al entrar, Eric se refería a los cambios en los datos de referencia, que pueden suceder. No quiere ser, por así decirlo, una víctima aguas abajo de una especie de cambio no administrado en esa área, por lo que las reglas de garantía de calidad pueden entrar en el monitoreo continuo de la calidad de datos posterior a la producción. Por lo tanto, puede comenzar a ver si vamos a estar centrados en los datos, la forma en que hacemos el desarrollo centrado en los datos es bastante diferente al SDLC y Agile basados ​​en la funcionalidad. Y luego tenemos que prestar atención también a las opiniones comerciales. Tenemos, y de nuevo esto hace eco de lo que Eric estaba diciendo, tenemos un modelo de datos que define un modelo de historia de datos para nuestra base de datos, pero al mismo tiempo necesitamos esos modelos conceptuales, esas opiniones comerciales de datos que tradicionalmente no se han hecho en el pasado. A veces, creo, pensamos que el modelo de datos puede hacerlo todo, pero necesitamos tener la visión conceptual, la semántica y analizar los datos, presentarlos a través de una capa de abstracción que traduzca el modelo de almacenamiento al negocio. ver. Y, de nuevo, todas las cosas de las que Eric estaba hablando en términos de semántica se vuelven importantes para hacer eso, por lo que en realidad tenemos tareas de modelado adicionales. Creo que es interesante, ya sabes, si has subido en las filas como modelador de datos como lo hice yo, y de nuevo, algo nuevo.

Y finalmente me gustaría decir que la arquitectura más grande también tiene que reflejar esta nueva realidad. El MDM tradicional del cliente, por ejemplo, es un tipo de, bueno, vamos a llevar los datos de nuestros clientes a un centro donde podamos, ya sabes, tener sentido en términos de calidad de datos realmente justa para aplicaciones de back office. Lo que desde el punto de vista de la estrategia comercial es una especie de bostezo. Hoy, sin embargo, estamos analizando los centros MDM de clientes que tienen datos de perfil de clientes adicionales en ellos, no solo los datos estáticos, que realmente tienen una interfaz bidireccional con las aplicaciones de transacciones del cliente. Sí, todavía admiten el back office, pero ahora también conocemos estos comportamientos de nuestros clientes. Esto es más costoso de construir. Esto es más complejo de construir. Pero está orientado a los negocios de una manera en que el cliente tradicional MDM no lo es. Está intercambiando una orientación hacia el negocio por diseños más simples que son más fáciles de implementar, pero para el negocio, esto es lo que quieren ver. Estamos realmente en una nueva era y creo que hay varios niveles que tenemos que responder a la arquitectura de datos que impulsa el negocio y creo que es un momento muy emocionante para hacer las cosas.

Así que gracias, de vuelta a ti Rebecca.

Rebecca Jozwiak: Gracias, Malcolm, y realmente disfruté lo que dijiste sobre los modelos de datos que deben alimentar la visión del negocio, porque, a diferencia de lo que estabas diciendo, TI mantuvo las riendas durante tanto tiempo y ya no es así. que la cultura necesita cambiar. Y estoy bastante seguro de que había un perro en el fondo que estuvo de acuerdo contigo al 100%. Y con eso voy a pasarle el balón a Ron. Estoy realmente emocionado de ver tu demo. Ron, el piso es tuyo.

Ron Huizenga: Muchas gracias y antes de saltar a eso, revisaré algunas diapositivas y luego un poco de demostración porque, como Eric y Malcolm han señalado, este es un tema muy amplio y profundo, y Con lo que estamos hablando hoy, solo estamos raspando la superficie porque hay muchos aspectos y tantas cosas que realmente necesitamos considerar y observar desde una arquitectura orientada a los negocios. Y nuestro enfoque es hacer que ese modelo se base realmente y obtener un verdadero valor de los modelos porque puede usarlos como un vehículo de comunicación, así como una capa para habilitar otros sistemas. Ya sea que esté haciendo arquitectura orientada al servicio u otras cosas, el modelo realmente se convierte en el elemento vital de lo que está sucediendo, con todos los metadatos a su alrededor y los datos que tiene en su negocio.

Sin embargo, de lo que quiero hablar es de dar un paso hacia atrás, porque Malcolm había tocado algo de la historia de la evolución de las soluciones y ese tipo de cosas. Una forma de señalar realmente lo importante que es tener una arquitectura de datos sólida es un caso de uso que solía encontrar muy a menudo cuando consultaba antes de asumir un rol de gestión de productos, y eso era, entraría en organizaciones si estaban haciendo una transformación comercial o simplemente reemplazando algunos sistemas existentes y ese tipo de cosas, y se hizo evidente muy rápidamente cómo las organizaciones entienden mal sus propios datos. Si toma un caso de uso particular como este, ya sea que sea un consultor entrando o tal vez sea una persona que acaba de comenzar con una organización, o su organización se haya desarrollado a lo largo de los años con la adquisición de diferentes compañías, lo que termina Un entorno muy complejo es muy rápido, con una serie de nuevas tecnologías diferentes, así como tecnología heredada, soluciones ERP y todo lo demás.

Entonces, una de las cosas que realmente podemos hacer con nuestro enfoque de modelado es responder a la pregunta de, ¿cómo puedo entender todo esto? Realmente podemos comenzar a juntar la información, para que la empresa pueda aprovechar la información que tenemos correctamente. Y resulta que, ¿qué es lo que tenemos ahí fuera en esos entornos? ¿Cómo puedo usar los modelos para eliminar la información que necesito y comprender mejor esa información? Y luego tenemos los tipos tradicionales de metadatos para todas las cosas diferentes, como los modelos de datos relacionales, y estamos acostumbrados a ver cosas como definiciones y diccionarios de datos, ya sabes, tipos de datos y ese tipo de cosas. Pero, ¿qué pasa con los metadatos adicionales que desea capturar para realmente darle aún más significado? Por ejemplo, qué entidades son realmente las candidatas que deberían ser objetos de datos de referencia, que deberían ser objetos de gestión de datos maestros y ese tipo de cosas y vincularlos. ¿Y cómo fluye la información a través de la organización? Los datos fluyen de cómo se consumen desde el punto de vista del proceso, sino también del linaje de datos en términos del viaje de información a través de nuestros negocios y cómo se abre paso a través de los diferentes sistemas, o a través de los almacenes de datos, por lo que sabemos cuando estamos construyendo las soluciones I, o ese tipo de cosas, estamos consumiendo la información correcta para la tarea en cuestión.

Y lo más importante es, ¿cómo podemos lograr que todos esos interesados ​​colaboren, y particularmente los interesados ​​comerciales porque son los que nos dan el verdadero significado de cuáles son esos datos? El negocio, al final del día, posee los datos. Proporcionan las definiciones de los vocabularios y las cosas de las que Eric estaba hablando, por lo que necesitamos un lugar para unir todo eso. Y la forma en que lo hacemos es a través de nuestro modelado de datos y arquitecturas de repositorio de datos.

Voy a tocar algunas cosas. Voy a hablar sobre ER / Studio Enterprise Team Edition. Principalmente voy a hablar sobre el producto de arquitectura de datos donde hacemos el modelado de datos y ese tipo de cosas, pero hay muchos otros componentes de la suite que voy a mencionar muy brevemente. Verá un fragmento del Business Architect, donde podemos hacer modelos conceptuales, pero también podemos hacer modelos de procesos de negocio y podemos vincular esos modelos de proceso para vincular los datos reales que tenemos en nuestros modelos de datos. Realmente nos ayuda a unir ese lazo. Software Architect nos permite hacer construcciones adicionales, como algunos modelos UML y ese tipo de cosas, para proporcionar lógicas de soporte a algunos de esos otros sistemas y procesos de los que estamos hablando. Pero muy importante a medida que avanzamos, tenemos el repositorio y el servidor del equipo, y hablaré de eso como una especie de dos mitades de la misma cosa. El repositorio es donde almacenamos todos los metadatos modelados, así como todos los metadatos comerciales en términos de los glosarios y términos comerciales. Y debido a que tenemos este entorno basado en el repositorio, podemos unir todas estas cosas diferentes en ese mismo entorno y luego podemos hacer que estén disponibles para consumos, no solo para la gente técnica sino también para los empresarios. Y así es como realmente comenzamos a impulsar la colaboración.

Y luego, la última pieza de la que hablaré brevemente es, cuando entras en estos entornos, no son solo las bases de datos las que tienes ahí fuera. Vas a tener varias bases de datos, almacenes de datos, también vas a tener muchos, lo que yo llamaría, artefactos heredados. Tal vez la gente ha usado Visio u otros diagramas para trazar algunas cosas. Quizás hayan tenido otras herramientas de modelado y ese tipo de cosas. Entonces, lo que podemos hacer con MetaWizard es extraer parte de esa información y llevarla a nuestros modelos, actualizarla y poder usarla, consumirla, de una manera actual nuevamente, en lugar de simplemente tenerla ahí fuera. Ahora se convierte en una parte activa de nuestros modelos de trabajo, lo cual es muy importante.

Cuando entras en una organización, como dije, hay muchos sistemas dispares, muchas soluciones ERP, soluciones departamentales incompatibles. Muchas organizaciones también están utilizando soluciones SaaS, que también se controlan y administran externamente, por lo que no controlamos las bases de datos y ese tipo de cosas en los hosts, pero aún necesitamos saber cómo se ven esos datos y, por supuesto, los metadatos alrededor de eso. Lo que también encontramos es una gran cantidad de sistemas heredados obsoletos que no se han limpiado debido a ese enfoque basado en proyectos del que Malcolm había hablado. Es sorprendente cómo en los últimos años las organizaciones reorganizarán proyectos, reemplazarán un sistema o una solución, pero a menudo no queda suficiente presupuesto para desmantelar las soluciones obsoletas, por lo que ahora están en el camino. Y tenemos que descubrir de qué podemos deshacernos en nuestro entorno y qué es útil en el futuro. Y eso se vincula con la pobre estrategia de desmantelamiento. Eso es parte integral de esa misma cosa.

Lo que también encontramos, debido a que muchas organizaciones se han construido a partir de todas estas soluciones diferentes, es que vemos muchas interfaces punto a punto con una gran cantidad de datos que se mueven en varios lugares. Necesitamos ser capaces de racionalizar eso y descubrir ese linaje de datos que mencioné brevemente antes para que podamos tener una estrategia más coherente, como la utilización de la arquitectura orientada a servicios, buses de servicios empresariales y ese tipo de cosas, para entregar la información correcta. a un tipo de modelo de publicación y suscripción que usamos correctamente en toda nuestra empresa. Y luego, por supuesto, todavía tenemos que hacer algún tipo de análisis, ya sea que usemos almacenes de datos, data marts con ETL tradicional o usemos algunos de los nuevos lagos de datos. Todo se reduce a lo mismo. Son todos datos, ya sean grandes datos, ya sean datos tradicionales en bases de datos relacionales, necesitamos reunir todos esos datos para que podamos administrarlos y saber a qué nos enfrentamos en todos nuestros modelos.

Una vez más, la complejidad que vamos a hacer es que tenemos una serie de pasos que queremos poder hacer. En primer lugar, entras y es posible que no tengas esos planos de cómo se ve ese panorama de información. En una herramienta de modelado de datos como ER / Studio Data Architect, primero va a hacer una gran cantidad de ingeniería inversa en términos de señalar las fuentes de datos que existen, incorporarlas y luego unirlas en forma más representativa modelos que representan todo el negocio. Lo importante es que queremos ser capaces de descomponer esos modelos también a lo largo de las líneas de negocios para que podamos relacionarnos con ellos en fragmentos más pequeños, con los que nuestros empresarios también pueden relacionarse, y nuestros analistas de negocios y otras partes interesadas que están trabajando en eso.

Los estándares de nomenclatura son extremadamente importantes y estoy hablando de esto de dos maneras diferentes aquí. Nombramiento de estándares en términos de cómo nombramos las cosas en nuestros modelos. Es bastante fácil de hacer en modelos lógicos, donde tenemos una buena convención de nomenclatura y un buen diccionario de datos para nuestros modelos, pero también vemos diferentes convenciones de nomenclatura para muchos de estos modelos físicos que estamos incorporando. ingeniería inversa, a menudo vemos nombres abreviados y ese tipo de cosas de las que hablaré. Y tenemos que traducirlos de nuevo a nombres significativos en inglés que sean significativos para el negocio para que podamos entender cuáles son todas estas piezas de datos que tenemos en el entorno. Y luego los mapeos universales es cómo los unimos.

Además de eso, luego documentaríamos y definiríamos más, y ahí es donde podemos clasificar nuestros datos aún más con algo llamado Adjuntos, en el que le mostraré un par de diapositivas. Y luego, cerrando el ciclo, queremos aplicar ese significado comercial, que es donde vinculamos nuestros glosarios comerciales y podemos vincularlos con nuestros diferentes artefactos modelo, para que sepamos, cuando hablamos de un cierto término comercial, dónde es implementado en nuestros datos en toda la organización. Y, por último, ya he hablado sobre el hecho de que necesitamos que todo esto se base en un repositorio con muchas capacidades de colaboración y publicación, para que nuestros interesados ​​puedan utilizarlo. Voy a hablar sobre ingeniería inversa con bastante rapidez. Ya te he dado un resumen muy rápido de eso. Te lo mostraré en una demostración real solo para mostrarte algunas de las cosas que podemos traer allí.

Y quiero hablar sobre algunos de los diferentes tipos de modelos y diagramas que produciríamos en este tipo de escenario. Obviamente haremos los modelos conceptuales en muchos casos; No voy a pasar mucho tiempo en eso. Realmente quiero hablar sobre modelos lógicos, modelos físicos y los tipos especializados de modelos que podemos crear. Y es importante que podamos crear todo esto en la misma plataforma de modelado para poder unirlos. Eso incluye modelos dimensionales y también modelos que utilizan algunas de las nuevas fuentes de datos, como el NoSQL que le mostraré. Y luego, ¿cómo se ve el modelo de linaje de datos? Y cómo unimos esos datos en un modelo de proceso de negocio, es de lo que hablaremos a continuación.

Voy a cambiar a un entorno de modelado aquí solo para darle una visión general muy alta y rápida. Y creo que deberías poder ver mi pantalla ahora. En primer lugar, quiero hablar sobre un tipo tradicional de modelo de datos. Y la forma en que queremos organizar los modelos cuando los traemos, es que queremos poder descomponerlos. Entonces, lo que está viendo aquí en el lado izquierdo es que tenemos modelos lógicos y físicos en este archivo de modelo en particular. Lo siguiente es que podemos desglosarlo a lo largo de las descomposiciones de negocios, por eso ves las carpetas. Los azules claros son modelos lógicos y los verdes son modelos físicos. Y también podemos profundizar, por lo que dentro de ER / Studio, si tiene una descomposición empresarial, puede ir a tantos niveles de profundidad o submodelos como desee, y los cambios que realice en los niveles inferiores se reflejarán automáticamente en los niveles superiores. niveles. Por lo tanto, se convierte en un entorno de modelado muy poderoso muy rápidamente.

Algo que también quiero señalar que es muy importante para comenzar a reunir esta información es que también podemos tener múltiples modelos físicos que corresponden a un modelo lógico. Muy a menudo puede tener un modelo lógico pero puede tener modelos físicos en diferentes plataformas y ese tipo de cosas. Tal vez sea una instancia de SQL Server, tal vez otra sea una instancia de Oracle. Tenemos la capacidad de vincular todo eso en el mismo entorno de modelado. Y de nuevo, lo que tengo aquí es un modelo de almacén de datos real que puede, nuevamente, estar en el mismo entorno de modelado o podemos tenerlo en el repositorio y vincularlo a través de diferentes cosas también.

Lo que realmente quería mostrarles sobre esto es algunas de las otras cosas y otras variantes de los modelos en los que nos metemos. Entonces, cuando entramos en un modelo de datos tradicional como este, estamos acostumbrados a ver las entidades típicas con las columnas y los metadatos y ese tipo de cosas, pero ese punto de vista varía muy rápidamente cuando comenzamos a tratar con algunas de estas nuevas tecnologías NoSQL, o como a algunas personas todavía les gusta llamarlas, las tecnologías de big data.

Así que ahora digamos que también tenemos Hive en nuestro entorno. Si realizamos ingeniería inversa desde un entorno Hive, y podemos realizar ingeniería inversa e inversa desde Hive con esta misma herramienta de modelado, vemos algo que es un poco diferente. Todavía vemos todos los datos como construcciones allí, pero nuestros TDL son diferentes. Aquellos de ustedes que están acostumbrados a ver SQL, lo que verían ahora es Hive QL, que es muy similar a SQL pero que con la misma herramienta ahora pueden comenzar a trabajar con los diferentes lenguajes de secuencias de comandos. Para que pueda modelar en este entorno, generarlo en el entorno de Hive, pero igual de importante, en el escenario que he descrito, puede aplicar ingeniería inversa a todo y darle sentido y comenzar a unirlo también .

Tomemos otro que sea un poco diferente. MongoDB es otra plataforma que admitimos de forma nativa. Y cuando comienzas a entrar en los tipos de entornos JSON donde tienes almacenes de documentos, JSON es un animal diferente y hay construcciones en eso, que no corresponden a modelos relacionales. Pronto comienza a lidiar con conceptos como objetos incrustados y matrices incrustadas de objetos cuando comienza a interrogar al JSON y esos conceptos no existen en la notación relacional tradicional. Lo que hemos hecho aquí es que hemos ampliado la notación y nuestro catálogo para poder manejar eso en el mismo entorno.

Si miras a la izquierda aquí, en lugar de ver cosas como entidades y tablas, los llamaremos objetos. Y ves notaciones diferentes. Todavía ve los tipos típicos de notaciones de referencia aquí, pero estas entidades azules que estoy mostrando en este diagrama en particular son en realidad objetos incrustados. Y mostramos diferentes cardinalidades. La cardinalidad de diamante significa que es un objeto en un extremo, pero la cardinalidad de uno significa que tenemos, dentro del editor si seguimos esa relación, tenemos un objeto de dirección incrustado. Al interrogar al JSON, hemos encontrado que es exactamente la misma estructura de objetos que está incrustada en el usuario, pero que en realidad está incrustada como una matriz de objetos. Estamos viendo eso, no solo a través de los propios conectores, sino que si observa las entidades reales, verá que ve las direcciones bajo el patrón que también lo clasifica como una matriz de objetos. Obtiene un punto de vista muy descriptivo de cómo puede aportar eso.

Y de nuevo, ahora lo que hemos visto hasta ahora en solo unos segundos son modelos relacionales tradicionales que son multinivel, podemos hacer lo mismo con Hive, podemos hacer lo mismo con MongoDB y otras fuentes de datos grandes como bien. Lo que también podemos hacer, y les voy a mostrar esto muy rápido es que hablé sobre el hecho de traer cosas de otras áreas diferentes. Asumiré que voy a importar un modelo de una base de datos o aplicarle ingeniería inversa, pero lo traeré de metadatos externos. Solo para darle un punto de vista muy rápido de todos los diferentes tipos de cosas que podemos comenzar a aportar.

Como puede ver, tenemos una miríada de cosas con las que podemos llevar los metadatos a nuestro entorno de modelado. Comenzando con cosas como incluso Amazon Redshift, Cassandra, muchas de las otras plataformas de big data, por lo que verá muchas de estas en la lista. Esto está en orden alfabético. Estamos viendo muchas fuentes de grandes datos y ese tipo de cosas. También estamos viendo muchos entornos de modelado tradicionales o antiguos a través de los cuales podemos llevar esos metadatos. Si paso por aquí, y no voy a pasar tiempo con cada uno de ellos, vemos muchas cosas diferentes de las que podemos traerlo, en términos de plataformas de modelado y plataformas de datos. Y algo que es muy importante tener en cuenta aquí es otra parte que podemos hacer cuando comenzamos a hablar sobre el linaje de datos, en Enterprise Team Edition también podemos interrogar las fuentes de ETL, ya sea que se trate de mapeos de Talend o SQL Server Information Services, podemos en realidad, tráelo para comenzar también con nuestros diagramas de linaje de datos y dibuje lo que está sucediendo en esas transformaciones. En conjunto, tenemos más de 130 de estos puentes diferentes que en realidad son parte del producto Enterprise Team Edition, por lo que realmente nos ayuda a reunir todos los artefactos en un entorno de modelado muy rápidamente.

Por último, pero no menos importante, también quiero hablar sobre el hecho de que no podemos perder de vista el hecho de que necesitamos los otros tipos de construcciones si estamos haciendo el almacenamiento de datos o cualquier tipo de análisis. Todavía queremos tener la capacidad de hacer cosas como modelos dimensionales donde tenemos tablas de hechos y tenemos dimensiones y ese tipo de cosas. Una cosa que quiero mostrarles también es que también podemos tener extensiones a nuestros metadatos que nos ayudan a clasificar cuáles son los tipos de dimensiones y todo lo demás. Entonces, si miro la pestaña de datos dimensionales aquí, por ejemplo, en uno de estos, en realidad detectará automáticamente, en función del patrón de modelo que ve, y le dará un punto de partida sobre si cree que es una dimensión o un tabla de hechos. Pero más allá de eso, lo que podemos hacer es dentro de las dimensiones y ese tipo de cosas, incluso tenemos diferentes tipos de dimensiones que también podemos usar para clasificar los datos en un tipo de entorno de almacenamiento de datos. Capacidades muy poderosas con las que estamos uniendo esto por completo.

Voy a saltar a este ya que estoy en el entorno de demostración en este momento y le mostraré un par de otras cosas antes de volver a las diapositivas. Una de las cosas que hemos agregado recientemente a ER / Studio Data Architect es que nos encontramos con situaciones, y este es un caso de uso muy común cuando trabajas en proyectos: los desarrolladores piensan en términos de objetos, mientras que nuestros datos los modeladores tienden a pensar en términos de tablas y entidades y ese tipo de cosas. Este es un modelo de datos muy simplista, pero representa algunos conceptos básicos, donde los desarrolladores o incluso los analistas de negocios o usuarios de negocios, pueden pensar en ellos como diferentes objetos o conceptos de negocios. Hasta ahora ha sido muy difícil clasificarlos, pero lo que hemos hecho realmente en ER / Studio Enterprise Team Edition, en la versión 2016, es que ahora tenemos un concepto llamado Business Data Objects. Y lo que nos permite hacer es encapsular grupos de entidades o tablas en verdaderos objetos comerciales.

Por ejemplo, lo que tenemos aquí en esta nueva vista es que el encabezado de la orden de compra y la línea de orden se han agrupado ahora, están encapsulados como un objeto, pensamos en ellos como una unidad de trabajo cuando conservamos los datos, y los reunimos, por lo que ahora es muy fácil relacionarlo con diferentes audiencias. Son reutilizables en todo el entorno de modelado. Son un verdadero objeto, no solo una construcción de dibujo, sino que también tenemos el beneficio adicional de que cuando realmente nos estamos comunicando desde la perspectiva de modelado, podemos colapsarlos o expandirlos selectivamente para que podamos producir una vista resumida de los diálogos con ciertas audiencias de partes interesadas, y también podemos, por supuesto, mantener una vista más detallada como la que estamos viendo aquí para más audiencias técnicas. Realmente nos da un muy buen vehículo de comunicación. Lo que vemos ahora es combinar varios tipos de modelos diferentes, aumentarlos con el concepto de objetos de datos comerciales, y ahora voy a hablar sobre cómo realmente aplicamos algo más de significado a este tipo de cosas y cómo los unimos en nuestro Ambientes generales.

Solo estoy tratando de encontrar mi WebEx aquí para poder hacerlo. Y ahí vamos, de vuelta a las diapositivas de Hot Tech. Voy a adelantar algunas diapositivas aquí porque ya las has visto en la demostración del modelo. Quiero hablar sobre los nombres de los estándares muy rápidamente. Queremos aplicar y aplicar diferentes estándares de nomenclatura. Lo que queremos hacer es que tengamos la capacidad de almacenar plantillas de estándares de nombres en nuestros repositorios para construir básicamente ese significado a través de palabras o frases o incluso abreviaturas, y vincularlas a un tipo de palabra en inglés significativo. Vamos a utilizar términos comerciales, las abreviaturas para cada uno, y podemos especificar el orden, los casos y agregar prefijos y sufijos. El caso de uso típico para esto es típicamente cuando las personas han estado construyendo un modelo lógico y luego en realidad creando un modelo físico donde podrían haber estado usando abreviaturas y todo lo demás.

Lo hermoso es que es igual de poderoso, incluso más poderoso en reversa, si podemos decir cuáles fueron algunos de esos estándares de nomenclatura en algunas de esas bases de datos físicas que hemos invertido en ingeniería, podemos tomar esas abreviaturas, convertirlas en más tiempo palabras, y llevarlas al revés en frases en inglés. De hecho, ahora podemos derivar nombres propios de cómo se ven nuestros datos. Como digo, el caso de uso típico es que avanzaríamos, lógico a físico, y mapearíamos los almacenes de datos y ese tipo de cosas. Si mira la captura de pantalla en el lado derecho, verá que hay nombres abreviados de los nombres de origen y cuando hemos aplicado una plantilla de estándares de nombres, en realidad tenemos más nombres completos. Y podríamos poner espacios y todo eso si quisiéramos, dependiendo de la plantilla de estándares de nombres que utilizamos. Podemos hacer que se vea como queramos que traiga a nuestros modelos. Solo cuando sabemos cómo se llama algo, podemos comenzar a adjuntarle definiciones, porque a menos que sepamos qué es, ¿cómo podemos aplicarle un significado?

Lo bueno es que podemos invocar esto cuando hacemos todo tipo de cosas. Hablé sobre ingeniería inversa, en realidad podemos invocar plantillas de estándares de nombres simultáneamente cuando hacemos ingeniería inversa. Entonces, en un conjunto de pasos a través de un asistente, lo que podemos hacer es que, si sabemos cuáles son las convenciones, podemos realizar ingeniería inversa en una base de datos física, la devolverá como modelos físicos en un entorno de modelado y es También se aplicarán esas convenciones de nomenclatura. Entonces veremos cuáles son las representaciones de nombres en inglés en el modelo lógico correspondiente en el entorno. También podemos hacerlo y combinarlo con la generación de esquemas XML para que podamos tomar un modelo e incluso sacarlo con nuestras abreviaturas, ya sea que estemos haciendo marcos SOA o ese tipo de cosas, para que también podamos sacar diferentes convenciones de nomenclatura que realmente hemos almacenado en el modelo mismo. Nos da muchas capacidades muy poderosas.

Nuevamente, aquí hay un ejemplo de cómo se vería si tuviera una plantilla. En realidad, esto muestra que tenía EMP para "empleado", SAL para "salario", PLN para "plan" en una convención de normas de nomenclatura. También puedo aplicarlos para que se ejecuten de manera interactiva a medida que construyo modelos y pongo cosas. Si estaba usando esta abreviatura y escribía "Plan de salario de empleado" en el nombre de la entidad, actuaría con la plantilla de estándares de nomenclatura He definido aquí, me habría dado EMP_SAL_PLN mientras creaba las entidades y me habría dado los nombres físicos correspondientes de inmediato.

Nuevamente, muy bueno para cuando también estamos diseñando y enviando ingeniería. Tenemos un concepto único y aquí es donde realmente comenzamos a unir estos entornos. Y se llama Mapeos universales. Una vez que hemos traído todos estos modelos a nuestro entorno, lo que podemos hacer, suponiendo que ahora hayamos aplicado estas convenciones de nomenclatura y que sean fáciles de encontrar, ahora podemos usar una construcción llamada Mapeos universales en ER /Estudio. Podemos vincular entidades a través de modelos. Donde sea que veamos "cliente", probablemente tendremos "cliente" en muchos sistemas diferentes y en muchas bases de datos diferentes, podemos comenzar a vincularlos a todos juntos para que cuando esté trabajando con él en un modelo, yo Puede ver dónde están las manifestaciones de los clientes en los otros modelos. Y debido a que tenemos la capa de modelo que representa eso, incluso podemos vincularlo a las fuentes de datos y reducirlo a nuestras consultas donde se utilizan en qué bases de datos también residen. Realmente nos da la capacidad de unir todo esto de manera muy coherente.

Te mostré los objetos de datos comerciales. También quiero hablar sobre las extensiones de metadatos, que llamamos Adjuntos, muy rápidamente. Lo que hace es que nos da la capacidad de crear metadatos adicionales para nuestros objetos modelo. Muy a menudo, configuraba este tipo de propiedades para expulsar muchas cosas diferentes desde una perspectiva de gobernanza y calidad de datos, y también para ayudarnos con la gestión de datos maestros y las políticas de retención de datos. La idea básica es crear estas clasificaciones y puede adjuntarlas donde quiera, a nivel de tabla, columna, ese tipo de cosas. El caso de uso más común, por supuesto, es que las entidades son tablas, y luego puedo definir: ¿cuáles son mis objetos de datos maestros, cuáles son mis tablas de referencia, cuáles son mis tablas transaccionales? Desde la perspectiva de la calidad de los datos, puedo hacer clasificaciones en términos de importancia para el negocio para que podamos priorizar los esfuerzos de limpieza de datos y ese tipo de cosas.

Algo que a menudo se pasa por alto es, ¿cuál es la política de retención para los diferentes tipos de datos en nuestra organización? Podemos configurarlos y, de hecho, podemos adjuntarlos a los diferentes tipos de artefactos de información en nuestro entorno de modelado y, por supuesto, también en nuestro repositorio. La belleza es que estos archivos adjuntos viven en nuestro diccionario de datos, por lo que cuando utilizamos diccionarios de datos empresariales en el entorno, podemos adjuntarlos a múltiples modelos. Solo tenemos que definirlos una vez y podemos aprovecharlos una y otra vez en los diferentes modelos de nuestro entorno. Esta es solo una captura de pantalla rápida para mostrar que en realidad puede especificar cuándo hace un archivo adjunto, a qué partes desea adjuntarlo. Y este ejemplo aquí es en realidad una lista de valores, por lo que cuando entran, puede elegir de una lista de valores, tiene mucho control en el entorno de modelado de lo que se está seleccionando, e incluso puede establecer cuál es el valor predeterminado valor es si no se elige un valor. Hay mucho poder allí. Viven en el diccionario de datos.

Algo que quiero mostrarle un poco más abajo en esta pantalla, además, verá los archivos adjuntos que se muestran en la parte superior, debajo de él verá información de seguridad de datos. De hecho, también podemos aplicar políticas de seguridad de datos a las diferentes piezas de información del entorno. Para diferentes asignaciones de cumplimiento, clasificaciones de seguridad de datos, enviamos una serie de ellas listas para usar que puede generar y comenzar a usar, pero también puede definir sus propias asignaciones y estándares de cumplimiento. Ya sea que esté haciendo HIPAA o alguna de las otras iniciativas que existen. Y realmente puede comenzar a construir este conjunto muy rico de metadatos en su entorno.

Y luego el Glosario y los Términos: aquí es donde se vincula el significado del negocio. Con frecuencia tenemos diccionarios de datos que la organización suele utilizar como punto de partida para comenzar a sacar los glosarios, pero la terminología y la verborrea son A menudo muy técnico. Entonces, lo que podemos hacer es, si lo deseamos, usarlos como punto de partida para eliminar los glosarios, pero realmente queremos que el negocio sea el propietario de estos. Lo que hemos hecho en el entorno del servidor del equipo es que hemos dado la posibilidad a las personas de crear definiciones comerciales y luego podemos vincularlas a los diferentes artefactos del modelo a los que corresponden también en el entorno de modelado. También reconocemos el punto que se discutió anteriormente, que es, cuanta más gente escriba, mayor será el potencial para el error humano. Lo que también hacemos en nuestra estructura de glosario es, uno, admitimos una jerarquía de glosarios, por lo que podemos tener diferentes tipos de glosarios o diferentes tipos de cosas en la organización, pero igual de importante es si ya tiene algunas de estas fuentes con los términos y todo lo definido, en realidad podemos hacer una importación CSV para incorporarlos a nuestro entorno de modelado y a nuestro servidor de equipo o nuestro glosario también, y luego comenzar a vincular desde allí. Y cada vez que se cambia algo, hay una pista de auditoría completa de lo que fueron las imágenes de antes y después, en términos de definiciones y todo lo demás, y lo que verá en un futuro muy cercano también es más un flujo de trabajo de autorización así que realmente podemos controlar quién está a cargo, las aprobaciones de comités o individuos, y ese tipo de cosas, para hacer que el proceso de gobernanza sea aún más robusto a medida que avanzamos.

Lo que esto también hace por nosotros es cuando tenemos estos términos del glosario en el glosario del servidor de nuestro equipo, este es un ejemplo de edición en una entidad en el modelo en sí que mencioné aquí. Puede tener términos vinculados, pero lo que también hacemos es si hay palabras que están en ese glosario que aparecen en las notas o descripciones de lo que tenemos en nuestras entidades aquí, esas se muestran automáticamente en un color hipervinculado más claro, y si Pase el mouse sobre ellos, también podemos ver la definición del glosario empresarial. Incluso nos da información más rica cuando estamos consumiendo la información en sí, con todos los términos del glosario que están disponibles. Realmente ayuda a enriquecer la experiencia y aplicar el significado a todo lo que estamos trabajando.

Entonces, nuevamente, ese fue un sobrevuelo muy rápido. Obviamente podríamos pasar días en esto mientras profundizamos en las diferentes partes, pero este es un sobrevuelo muy rápido sobre la superficie. Lo que realmente nos esforzamos por hacer es comprender cómo son esos entornos de datos complejos. Queremos mejorar la visibilidad de todos esos artefactos de datos y colaborar para expulsarlos con ER / Studio. Queremos habilitar un modelado de datos más eficiente y automatizado. Y de eso estamos hablando todos los tipos de datos, ya sean datos grandes, datos relacionales tradicionales, almacenes de documentos o cualquier otra cosa. Y nuevamente, lo logramos porque tenemos poderosas capacidades de ingeniería directa e inversa para las diferentes plataformas y las otras herramientas que puede tener. Y se trata de compartir y comunicarse en toda la organización con todas las partes interesadas involucradas. Ahí es donde aplicamos el significado a través de los estándares de nomenclatura. Luego aplicamos definiciones a través de nuestros glosarios comerciales. Y luego podemos hacer más clasificaciones para todas nuestras otras capacidades de gobernanza con las extensiones de metadatos, como extensiones de calidad de datos, clasificaciones para la gestión de datos maestros o cualquier otro tipo de clasificaciones que desee aplicar a esos datos. Y luego podemos resumir aún más y mejorar aún más la comunicación con los objetos de datos comerciales, con las diferentes audiencias de partes interesadas, particularmente entre los modeladores y desarrolladores.

Y de nuevo, lo que es muy importante de esto es que detrás de todo hay un repositorio integrado con capacidades de administración de cambios muy robustas. No tuve tiempo de mostrarlo hoy porque se vuelve bastante complejo, pero el repositorio tiene capacidades muy sólidas de gestión de cambios y pistas de auditoría. Puede hacer lanzamientos con nombre, puede hacer versiones con nombre, y también tenemos la capacidad para aquellos de ustedes que están haciendo la gestión de cambios, podemos vincular eso directamente a sus tareas. Hoy tenemos la capacidad de poner tareas y asociar los cambios de su modelo con tareas, al igual que los desarrolladores asociarían sus cambios de código con las tareas o historias de usuarios con las que también están trabajando.

Nuevamente, esa fue una descripción muy rápida. Espero que haya sido suficiente para despertar su apetito para que podamos entablar conversaciones mucho más profundas sobre la división de algunos de estos temas a medida que avanzamos en el futuro. Gracias por su tiempo, y de vuelta a usted, Rebecca.

Rebecca Jozwiak: Gracias, Ron, eso fue fantástico y tengo bastantes preguntas de la audiencia, pero quiero darles a nuestros analistas la oportunidad de hundir sus dientes en lo que has dicho. Eric, voy a seguir adelante y tal vez si quieres abordar esta diapositiva, o una diferente, ¿por qué no continúas primero? O cualquier otra pregunta.

Eric Little: Claro. Lo siento, ¿cuál era la pregunta, Rebecca? ¿Quieres que te pregunte algo específico o …?

Rebecca Jozwiak: Sé que inicialmente tenías algunas preguntas para Ron. Si desea pedirle ahora que se dirija a cualquiera de ellos, o algunos de ellos de su diapositiva o cualquier otra cosa que despertó su interés sobre el que desea preguntar. Sobre las funcionalidades de modelado de IDERA.

Eric Little: Sí, así que una de las cosas, Ron, ¿cómo, chicos, parece que los diagramas que mostraban son tipos generales de diagramas de relación de entidades que normalmente usarían en la construcción de bases de datos, correcto?

Ron Huizenga: Sí, en términos generales, pero, por supuesto, tenemos los tipos extendidos para las tiendas de documentos y ese tipo de cosas también. En realidad, hemos variado desde la simple notación relacional, también hemos agregado anotaciones adicionales para esas otras tiendas también.

Eric Little: ¿Hay alguna manera de que ustedes puedan utilizar tipos de modelado basados ​​en gráficos? Entonces, ¿hay alguna forma de integrar, por ejemplo, supongamos que tengo algo como un cuadrante superior, una herramienta de composición TopBraid o he hecho algo? en Protégé o, como saben, los financieros en FIBO, están haciendo mucho trabajo en semántica, RDF, ¿hay alguna manera de incorporar ese tipo de modelado de tipo gráfico de entidad-relación en esta herramienta y utilizarlo? ¿eso?

Ron Huizenga: En realidad estamos viendo cómo podemos manejar los gráficos. No estamos manejando explícitamente las bases de datos de gráficos y ese tipo de cosas hoy, pero estamos buscando formas de hacerlo para extender nuestros metadatos. Quiero decir, podemos traer cosas a través de XML y ese tipo de cosas en este momento, si al menos podemos hacer algún tipo de representación de XML para traerlo como punto de partida. Pero estamos buscando formas más elegantes de introducir eso.

Y también le mostré esa lista de puentes de ingeniería inversa que también tenemos allí, por lo que siempre estamos buscando obtener extensiones de esos puentes para plataformas específicas también. Es un esfuerzo continuo y continuo, si tiene sentido, comenzar a adoptar muchas de estas nuevas construcciones y las diferentes plataformas que existen. Pero puedo decir que definitivamente estamos a la vanguardia de hacer eso. Lo que mostré en, por ejemplo, MongoDB y ese tipo de cosas, somos el primer proveedor de modelado de datos que lo hace de forma nativa en nuestro propio producto.

Eric Little: De acuerdo, sí. Entonces, la otra pregunta que tenía para usted, entonces, era en términos de la gobernanza y el mantenimiento del - como cuando usó el ejemplo, cuando mostró el ejemplo de la persona que es un "empleado", creo que fue un " salario "y luego tienes un" plan ", ¿hay alguna forma de cómo manejas, por ejemplo, los diferentes tipos de personas que pueden tener? Supongamos que tienes una gran arquitectura, bien, supongamos que tienes una gran empresa y la gente comienza a juntar las cosas en esta herramienta y tienes un grupo aquí que tiene la palabra "empleado" y un grupo aquí que tiene la palabra "trabajador". Y una persona aquí dice "salario" y otra persona dice "salario."

¿Cómo se reconcilian, gestionan y gobiernan ese tipo de distinciones? Porque sé cómo lo haríamos en el mundo de los gráficos, ya sabes, usarías listas de sinónimos o dirías que hay un concepto y tiene varios atributos, o podrías decir en el modelo SKOS que tengo una etiqueta preferida y tengo Numerosas etiquetas alternativas que puedo usar. ¿Cómo hacen eso ustedes?

Ron Huizenga: Lo hacemos de dos maneras diferentes, y principalmente hablemos primero de la terminología. Una de las cosas que hacemos, por supuesto, es que queremos tener los términos definidos o sancionados y, obviamente, en el glosario comercial es donde los queremos. Y también permitimos enlaces a sinónimos en el glosario empresarial, por lo que lo que puede hacer es decir, aquí está mi término, pero también puede definir cuáles son todos los sinónimos para esos.

Ahora, lo interesante, por supuesto, es que cuando comienzas a mirar a través de este vasto panorama de datos con todos estos sistemas diferentes que tienes, no puedes simplemente salir y cambiar las tablas correspondientes y ese tipo de cosas a corresponde a ese estándar de nomenclatura porque puede ser un paquete que compró, por lo que no tiene control sobre el cambio de la base de datos ni nada en absoluto.

Lo que podríamos hacer allí, además de poder asociar las definiciones del glosario, es a través de esas asignaciones universales de las que hablé, lo que haríamos, y una especie de enfoque recomendado, es tener un modelo lógico general que establezca qué estás hablando de estos diferentes conceptos de negocio. Ate los términos del glosario comercial a esos, y lo bueno es que ahora que tiene esta construcción que representa una entidad lógica como tal, puede comenzar a vincular desde esa entidad lógica a todas las implementaciones de esa entidad lógica en Los diferentes sistemas.

Entonces, cuando lo necesite, puede ver, oh, "persona" aquí se llama "empleado" en este sistema. "Salario" aquí se llama "salario" aquí en este otro sistema. Porque verás eso, verás todas las diferentes manifestaciones de esos porque los has vinculado.

Eric Little: Muy bien, sí, lo tengo. En ese sentido, ¿es seguro decir que es algo así como algunos de los enfoques orientados a objetos?

Ron Huizenga: Algo. Es un poco más intenso que, supongo que se podría decir. Quiero decir, podría adoptar el enfoque de vincular manualmente y revisar e inspeccionar y hacer todos ellos también. La única cosa de la que realmente no tuve oportunidad de hablar, porque nuevamente, tenemos muchas capacidades, también tenemos una interfaz de automatización completa en la herramienta Data Architect. Y una capacidad macro, que es realmente un lenguaje de programación en la herramienta. Por lo tanto, podemos hacer cosas como escribir macros, hacer que salgan e interrogar cosas y crear enlaces para usted. Lo usamos para importar y exportar información, podemos usarlo para cambiar cosas o agregar atributos, eventos basados ​​en el modelo en sí, o podemos usarlo para ejecutar en lotes para salir e interrogar cosas y llenar diferentes construcciones en el modelo. Entonces, hay una interfaz de automatización completa que las personas también pueden aprovechar. Y utilizar los mapeos universales con esos sería una forma muy poderosa de hacerlo.

Rebecca Jozwiak: Bien, gracias Ron y gracias Eric. Esas fueron grandes preguntas. Sé que estamos pasando un poco más allá de la hora, pero me gustaría darle a Malcolm la oportunidad de arrojar algunas preguntas en el camino de Ron. Malcolm?

Malcolm Chisholm: Gracias Rebecca. Entonces, Ron, es muy interesante, veo que hay muchas capacidades aquí. Una de las áreas en las que estoy muy interesado es, por ejemplo, si tenemos un proyecto de desarrollo, ¿cómo ve al modelador de datos usando estas capacidades y trabajando quizás de manera más colaborativa con analistas de negocios, con un analizador de datos, con un analista de calidad de datos?, y con los patrocinadores comerciales que finalmente serán responsables de los requisitos de información reales en el proyecto. ¿Cómo hace el modelador de datos para que el proyecto sea más efectivo y eficiente con las capacidades que estamos viendo?

Ron Huizenga: Creo que una de las primeras cosas que tienes que hacer allí es como modelador de datos, y no pretendo elegir algunos de los modeladores, pero lo haré de todos modos, es que algunas personas todavía tienen la impresión de que el modelador de datos es realmente el tipo de función de guardián de puerta, estamos definiendo cómo funciona, somos los guardias que se aseguran de que todo sea correcto.

Ahora hay un aspecto de eso, que debes asegurarte de que estás definiendo una arquitectura de datos de sonido y todo lo demás. Pero lo más importante es que, como modelador de datos, y lo encontré bastante obvio cuando estaba consultando, es que debe convertirse en un facilitador, por lo que debe reunir a estas personas.

Ya no será un diseño inicial, generar, construir bases de datos; lo que debe poder hacer es poder trabajar con todos estos diferentes grupos de partes interesadas, hacer cosas como ingeniería inversa, importar información, tener otras personas colaboran, ya sea en los glosarios o la documentación, todo eso, y sean un facilitador para llevar esto al repositorio, y vincular los conceptos en el repositorio, y trabajar con esas personas.

Realmente es mucho más un tipo de entorno colaborativo en el que, incluso a través de la definición de tareas o incluso hilos de discusión o ese tipo de cosas que tenemos en el servidor del equipo, las personas pueden realmente colaborar, hacer preguntas y llegar a los productos finales finales que ellos necesidad de su arquitectura de datos y su organización. ¿Ese tipo de respuesta?

Malcolm Chisholm: Sí, estoy de acuerdo. Sabes, creo que la habilidad de facilitación es algo realmente deseable en los modeladores de datos. Estoy de acuerdo en que no siempre vemos eso, pero creo que es necesario y sugeriría que a veces hay una inclinación a permanecer en su esquina haciendo su modelado de datos, pero realmente necesita estar trabajando con los otros grupos de partes interesadas. o simplemente no comprende el entorno de datos con el que está tratando, y creo que el modelo sufre como resultado. Pero esa es solo mi opinión.

Ron Huizenga: Y es interesante porque mencionaste algo anteriormente en tu diapositiva sobre la historia de cómo las empresas están un poco alejadas de TI porque no estaban entregando las soluciones de manera oportuna y ese tipo de cosas.

Es muy interesante que en mis posteriores trabajos de consultoría, antes de convertirme en gerente de producto, la mayoría de los proyectos que hice en los últimos dos años anteriores fueron patrocinados por empresas, donde realmente fue la empresa la que lo impulsó y los arquitectos de datos y los modeladores no eran parte de TI. Formamos parte de un grupo patrocinado por empresas y estuvimos allí como facilitadores trabajando con el resto de los equipos del proyecto.

Malcolm Chisholm: Entonces creo que es un punto muy interesante. Creo que estamos comenzando a ver un cambio en el mundo de los negocios en el que la empresa pregunta, o piensa, tal vez, no tanto como lo que hago, como proceso, sino que también comienzan a pensar en qué son los datos con la que trabajo, cuáles son mis necesidades de datos, cuáles son los datos que estoy tratando como datos y en qué medida podemos obtener los productos y capacidades de IDERA para respaldar ese punto de vista, y creo que las necesidades del negocio, incluso aunque todavía es un poco incipiente.

Ron Huizenga: Estoy de acuerdo con usted y creo que lo estamos viendo ir más y más de esa manera. Hemos visto un despertar y lo mencionó anteriormente en términos de la importancia de los datos. Vimos la importancia de los datos al principio de TI o en la evolución de las bases de datos, luego, como usted dice, nos metimos en todo este ciclo de gestión de procesos, y el proceso es extremadamente importante, no me malinterpreten, pero ahora qué sucedió es cuando eso sucedió, los datos perdieron el foco.

Y ahora las organizaciones se están dando cuenta de que los datos realmente son el punto focal. Los datos representan todo lo que estamos haciendo en nuestro negocio, por lo que debemos asegurarnos de tener datos precisos, de que podamos encontrar la información correcta que necesitamos para tomar nuestras decisiones. Porque no todo proviene de un proceso definido. Parte de la información es un subproducto de otras cosas y todavía necesitamos poder encontrarla, saber lo que significa y poder traducir los datos que vemos allí en última instancia en conocimiento que podemos usar para impulsar nuestros negocios mejor.

Malcolm Chisholm: Correcto, y ahora otra área con la que he estado luchando es lo que llamaría el ciclo de vida de los datos, que es, ya sabes, si observamos el tipo de cadena de suministro de datos que atraviesa una empresa, comenzaríamos con adquisición de datos o captura de datos, que podría ser la entrada de datos pero igualmente podría ser, estoy obteniendo datos de fuera de la empresa de algún proveedor de datos.

Y luego, desde la captura de datos, vamos al mantenimiento de datos, donde estoy pensando en estandarizar estos datos y enviarlos a los lugares donde se necesitan. Y luego, el uso de datos, los puntos reales donde están los datos, va a obtener valor de los datos.

Y en los viejos tiempos, todo esto se hace en un estilo individual, pero hoy podría ser, ya sabes, un entorno analítico, por ejemplo, y más allá de eso, un archivo, una tienda, donde colocamos los datos cuando ya no estamos lo necesito y finalmente un proceso de purga. ¿Cómo ve que el modelado de datos se ajusta a la gestión de todo este ciclo de vida de datos?

Ron Huizenga: Esa es una muy buena pregunta y una cosa que realmente no tuve tiempo de profundizar en ningún detalle aquí hoy es que de lo que realmente estamos comenzando a hablar es del linaje de datos. Entonces, lo que realmente podemos hacer es que tenemos una capacidad de linaje de datos en nuestras herramientas y, como digo, podemos extraer parte de las herramientas de ETL, pero también puede mapearla simplemente dibujando el linaje. Cualquiera de estos modelos de datos o bases de datos que hemos capturado y llevado a modelos podríamos hacer referencia a las construcciones a partir de eso en nuestro diagrama de linaje de datos.

Lo que podemos hacer es dibujar un flujo de datos, como usted dice, desde el origen hasta el destino, y a través del ciclo de vida general de cómo esos datos transitan por los diferentes sistemas y lo que va a encontrar, llevemos a los empleados 'datos: es uno de mis favoritos basado en un proyecto que hice hace años. Trabajé con una organización que tenía datos de empleados en 30 sistemas diferentes. Lo que terminamos haciendo allí, y Rebecca apareció la diapositiva de linaje de datos, esta es una diapositiva de linaje de datos bastante simplista aquí, pero lo que pudimos hacer fue incorporar todas las estructuras de datos, hacer referencia a ellas en el diagrama y luego en realidad puede comenzar a ver cuáles son los flujos entre ellos y cómo se relacionan esas diferentes entidades de datos en un flujo. Y podemos ir más allá de eso también. Esto es parte de un diagrama de flujo de datos o linaje que vemos aquí. Si desea ir más allá de eso, también tenemos al arquitecto comercial que forma parte de esta suite y lo mismo se aplica allí.

Cualquiera de las estructuras de datos que hemos capturado en el entorno de modelado de datos, se puede hacer referencia a ellas en la herramienta de modelado de negocios para que incluso en sus diagramas de modelo de negocio o sus diagramas de proceso de negocio, pueda hacer referencia a almacenes de datos individuales si desea salir de el entorno de modelado de datos, y mientras los está utilizando en las carpetas en su modelo de proceso de negocio, incluso puede especificar el CRUD en esos, en cuanto a cómo se consume o produce esa información, y luego podemos comenzar a generar cosas como informes de impacto y análisis y diagramas de eso.

A lo que aspiramos llegar, y ya tenemos muchas capacidades, pero una de las cosas que tenemos como una especie de meta que estamos viendo, a medida que continuamos evolucionando nuestras herramientas en el futuro, es poder mapear ese linaje de datos de organización de extremo a extremo y el ciclo de vida completo de los datos.

Malcolm Chisholm: De acuerdo. Rebecca, ¿tengo permitido uno más?

Rebecca Jozwiak: Te permitiré uno más, Malcolm, adelante.

Malcolm Chisholm: Muchas gracias. Pensando en la gobernanza de datos y pensando en el modelado de datos, ¿cómo hacemos que esos dos grupos trabajen juntos y se comprendan de manera efectiva?

Eric Little: Bueno, es interesante, creo que realmente depende de la organización, y se remonta a mi concepto anterior: en aquellas organizaciones donde las iniciativas fueron impulsadas por los negocios, estábamos directamente vinculadas. Por ejemplo, estaba liderando una arquitectura de datos equipo, pero estábamos vinculados directamente con los usuarios comerciales y en realidad los estábamos ayudando a defender su programa de gobierno de datos. Una vez más, es más un enfoque consultivo, pero en realidad es más una función comercial.

Lo que realmente necesita para poder hacer eso es que necesita modeladores de datos y arquitectos que realmente entiendan los negocios, puedan relacionarse con los usuarios comerciales y luego los hayan ayudado a defender los procesos de gobierno a su alrededor. La empresa quiere hacerlo, pero en términos generales tenemos el conocimiento tecnológico para poder ayudarlos a destacar ese tipo de programas. Realmente tiene que ser una colaboración, pero debe ser propiedad de un negocio.

Malcolm Chisholm: Bien, eso es genial. Gracias.

Dr. Eric Little: De acuerdo.

Rebecca Jozwiak: Muy bien, muchas gracias. Miembros de la audiencia, me temo que no hemos respondido a sus preguntas, pero me aseguraré de que se envíen al invitado apropiado que tuvimos en la línea hoy. Quiero agradecerles mucho a Eric, Malcolm y Ron por ser nuestros invitados hoy. Esto fue genial, amigos. Y si disfrutó de la transmisión web de IDERA de hoy, IDERA también estará en Hot Technologies el próximo miércoles si desea unirse, discutiendo los desafíos de la indexación y los oráculos, por lo que es otro tema fascinante.

Muchas gracias amigos, cuídense y nos vemos la próxima vez. Adiós.