Modelado de datos en un entorno ágil.

Por el personal de Techopedia, 16 de noviembre de 2016

Para llevar: El presentador Eric Kavanagh discute la importancia del modelado de datos en el desarrollo ágil con Robin Bloor, Dez Blanchfield y Ron Huizenga de IDERA.

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

Eric Kavanagh: Muy bien, damas y caballeros. Bienvenido de nuevo. Es miércoles a las 4:00 EST. Eso significa que es hora de Hot Technologies. Si, de hecho. Mi nombre es Eric Kavanagh, seré tu anfitrión.

Para el tema de hoy, es un viejo pero bueno. Está mejorando cada día porque está dando forma a nuestro mundo de gestión de datos, "Modelado de datos en un entorno ágil". Hay una diapositiva sobre los suyos, contácteme en Twitter @eric_kavanagh. Realmente deberíamos ponerlo en esa diapositiva. Tendré que seguir con eso.

Entonces el año es caluroso. El modelado de datos ha existido desde siempre. Realmente ha estado en el corazón y el alma del negocio de administración de información, diseñando modelos de datos, tratando de comprender los modelos de negocios y alinearlos con sus modelos de datos. Eso es realmente lo que estás tratando de hacer, ¿verdad?

El modelo de datos representa el negocio de una manera fundamental, entonces, ¿cómo están cambiando el juego todas estas nuevas fuentes de datos? Vamos a averiguar sobre eso. Vamos a descubrir cómo puede mantenerse al tanto de las cosas de una manera ágil. Y, por supuesto, esa es la palabra del año.

Robin Bloor está con nosotros, nuestro analista jefe, Dez Blanchfield llamando desde Sydney, Australia y Ron Huizenga, Gerente de Producto Senior de IDERA, amigo mío desde hace mucho tiempo, excelente orador en este espacio, conoce sus cosas, así que no seas tímido, pregunta las preguntas difíciles, amigos, las preguntas difíciles. Con eso, voy a hacer que Robin sea el presentador, y me lo llevaré.

Dr. Robin Bloor: De acuerdo. Bueno, gracias por eso, Eric. Tengo que decir sobre el modelado que creo que en realidad estaba en el mundo de TI antes de que existiera, en el sentido de que recuerdo en la compañía de seguros para la que trabajé, que había un tipo que vino y nos dio a todos un tipo de taller sobre cómo modelar datos. Entonces, estamos viendo alrededor de 30 años, ¿son 30 años? Tal vez incluso más que eso, tal vez hace 35 años. Un modelo de mucho, mucho tiempo en realidad ha sido parte de la industria y, por supuesto, no tiene nada que ver con las damas en las pasarelas.

Lo que quería decir, porque lo que normalmente hacemos, es que Dez y yo hablamos de cosas diferentes y pensé en dar una visión general del modelado, pero hay una realidad en esto, que ahora se está volviendo evidente.

Tenemos, ya sabes, la realidad del big data, tenemos más datos, más fuentes de datos, tenemos flujos de datos que han entrado en la ecuación en los últimos tres o cuatro años y están comenzando a obtener una mayor parte de ella, y existe una mayor necesidad de comprender los datos y un aumento en la tasa de cambio que se agrega más datos y también se utilizan más estructuras de datos.

Es un mundo dificil. Aquí hay una imagen de eso, que en realidad es algo que dibujamos hace tres años, pero básicamente, una vez que incluye la transmisión en la mezcla y tiene esta idea de la refinería de datos, el centro de datos, el enlace de datos o lo que sea, verá que hay datos que son genuinamente en reposo, en el sentido de que no se mueve mucho. Y luego están los datos, las transmisiones y usted tiene todas las aplicaciones transaccionales, además hoy en día tiene eventos, flujos de datos de eventos que suceden en las aplicaciones y pueden ser necesarios, y hoy en día con las arquitecturas lambda de las que todos hablan, son genuinamente teniendo un impacto en todo el campo de datos.

Y hoy en día piensa en términos de que hay una capa de datos. La capa de datos existe de una manera virtual, en el sentido de que una buena parte de ella podría estar en la nube y puede extenderse a través de centros de datos, puede existir en estaciones de trabajo. La capa de datos está, en cierta medida, en todas partes y, en ese sentido, hay procesos en todas partes que intentan de una forma u otra procesar los datos y moverlos. Pero también saber qué es cuando lo mueves es un gran problema.

Si observamos el modelado de datos en el sentido más general, en la parte inferior de este tipo de pila tienes archivos y bases de datos. Tiene elementos de datos, que tienen claves, definiciones de elementos, alias, sinónimos, formatos físicos específicos y luego tenemos esta capa de metadatos.

Lo interesante de los metadatos es que los metadatos son completamente cómo los datos adquieren su significado. Si en realidad no tiene metadatos, en el mejor de los casos puede adivinar el significado de los datos, pero tendrá muchas dificultades. Los metadatos deben estar allí, pero el significado tiene estructura. No quiero entrar en la filosofía del significado, pero incluso en la forma en que tratamos los datos, hay mucha sofisticación en el pensamiento humano y el lenguaje humano, que no se expresa fácilmente en los datos. Pero incluso en términos de los datos que realmente procesamos en el mundo, los metadatos tienen significado y la estructura de los metadatos: un dato en relación con otro y lo que eso significa cuando se juntan y lo que eso significa cuando ' re unirse con otros datos, exige que lo modelemos. No es lo suficientemente bueno como para grabar etiquetas de metadatos en las cosas, en realidad tiene que registrar el significado por estructuras y la relación entre las estructuras.

Luego tenemos en la capa superior, las definiciones de negocios, que normalmente es una capa que intenta transferir el significado entre metadatos, que es una forma de definición de datos que se adapta a la forma en que los datos se organizan en la computadora y el significado humano. Entonces tiene términos comerciales, definiciones, relaciones, conceptos de nivel de entidad que existen en esa capa. Y si vamos a tener una incoherencia entre estas capas, entonces tenemos que tener un modelado de datos. No es realmente opcional. Cuanto más pueda hacerlo en términos de automatización, mejor. Pero debido a que tiene que ver con el significado, es realmente difícil alternar. Es bastante fácil capturar los metadatos dentro de un registro y poder obtenerlos de una serie de significados, pero no le dice la estructura de los registros o qué significan los registros o el contexto del registro.

Entonces, de esto se trata el modelado de datos, en mi opinión. Puntos a tener en cuenta: cuanto más complejo se vuelve el universo de datos, más necesita modelarlo. En otras palabras, es un poco como si estuviéramos agregando no solo más instancias de cosas al mundo, lo que correspondería a registros de datos, sino que en realidad estamos agregando más significado al mundo al capturar datos sobre más y más cosas. Se está convirtiendo en una sensación cada vez más compleja que tenemos que entender.

En teoría, hay un universo de datos y necesitamos una visión de él. En la práctica, los metadatos reales son parte del universo de datos. Entonces, no es una situación simple. El modelado inicial es de arriba hacia abajo y de abajo hacia arriba. Debe construir en ambas direcciones y la razón es que los datos tienen un significado para la computadora y el proceso, que tienen que procesarlos, pero tienen significado por derecho propio. Por lo tanto, necesita un significado de abajo hacia arriba, que satisfaga el software que necesita acceder a los datos y necesita el significado de arriba hacia abajo para que los seres humanos puedan entenderlo. La construcción de modelos de metadatos no es y nunca puede ser un proyecto; es una actividad continua, debe ser una actividad continua en todos los entornos que existan. Afortunadamente, hay muchos entornos, donde ese no es el caso y las cosas se descontrolan en consecuencia.

En el futuro, el modelado aumenta con importancia a medida que la tecnología avanza. Esa es mi opinión. Pero si observa el IoT, podemos entender el móvil más de lo que solíamos hacerlo, aunque ha introducido nuevas dimensiones: la dimensión de la ubicación con el móvil. Una vez que llegue al IoT, observaremos problemas de datos extraordinarios que nunca tuvimos que hacer antes y necesitamos, de una forma u otra, comprender correctamente exactamente lo que tenemos, exactamente cómo podemos agregarlo, qué podemos hacer en términos de obtener significado de la agregación y, por supuesto, qué podemos hacer con ella cuando la procesamos.

Creo que soy yo habiendo dicho lo suficiente. Voy a pasar a Dez Blanchfield, quien dirá algo completamente diferente.

Dez Blanchfield: Gracias. Siempre es un acto difícil de seguir, pero este es un tema que acordamos y hablamos brevemente sobre esto en las bromas previas al espectáculo, y si llamaste temprano, probablemente habrás atrapado un montón de grandes gemas. Una de las conclusiones, y no quiero robar el trueno de esta en particular, pero una de las conclusiones de nuestras bromas previas al show que quiero compartir, en caso de que no lo hayan captado, fue solo sobre el tema de el viaje de los datos, y me sorprendió escribirlo pensando en el viaje que toman los datos en un contexto diferente en torno a la vida generacional: año, meses, semana, día, hora, minuto, segundo, y el contexto en torno a los datos son posicionado dentro de ese contexto. Si soy un desarrollador que ejecuta código, o si soy un especialista en datos y estoy pensando en la estructura y el formato y los metadatos en torno a cada uno de los elementos, o la forma en que los sistemas y el negocio interactúan con él.

Es un pequeño comentario interesante solo para notar, pero de todos modos, déjenme sumergirme. El diseño de datos, en particular, es una frase que uso para hablar sobre todos los datos y el desarrollo específico de aplicaciones o infraestructura de base de datos. Creo que el diseño de datos es un término que simplemente lo capta todo muy bien en mi mente. En estos días, cuando hablamos de diseño de datos, hablamos de diseño de datos ágil moderno, y mi opinión es que no hace mucho tiempo que los desarrolladores y expertos en datos trabajaban solos; estaban en sus propios silos y las piezas de diseño iban de un silo a otro. Pero tengo mucha opinión en estos días, que no solo es el caso el que ha cambiado, sino que tiene que cambiar; es una necesidad y esa es la aplicación: los desarrolladores y todo lo que tenga que ver con el desarrollo que se ocupa de datos, los diseñadores que hacen los elementos de diseño relevantes de esquemas y campos y registros y sistemas e infraestructuras de ubicación y bases de datos, modelado y toda la gestión desafiar alrededor de eso. Ese es un deporte de equipo ahora y, por lo tanto, mi foto de un grupo de personas saltando de un avión actuando en equipo para representar esa imagen visualmente interesante de personas cayendo por el cielo.

Tercero, ¿qué ha sucedido para provocar esto? Bueno, hay un artículo en 1986 escrito por un par de caballeros cuyos nombres traté desesperadamente de hacer justicia, Hirotaka Takeuchi e Ikujiro Nonaka, creo que se pronuncia, produjeron un artículo que titularon "Moving the Scrum Downfield". Introdujeron Esta idea de una metodología para ganar un juego de rugby a partir de esta actividad de scrum, donde todos se mueven en un lugar y dos equipos esencialmente bloquean las cabezas en algo llamado scrum para tratar de obtener el control del balón y jugarlo en el campo para llegue a la línea de prueba y toque el suelo con la pelota y obtenga un punto, llamado trígono, y repita este proceso y obtendrá más puntos para el equipo.

Este artículo fue publicado en 1986 en Harvard Business Review, y curiosamente recibió mucha atención. Obtuvo mucha atención porque introdujo nuevos conceptos sorprendentes y aquí hay una captura de pantalla del frente. Entonces sacaron este concepto de scrum del juego de rugby y lo pusieron en el negocio y particularmente en el juego de diseño y entrega de proyectos, específicamente entrega de proyectos.

Lo que hizo scrum fue darnos una nueva metodología en comparación con los gustos de PRINCE2 o PMBOK que habíamos usado previamente en lo que llamamos la metodología de cascada, ya sabes, hacer esto y esto y esto y seguirlos en secuencia y conectarlos todos los puntos alrededor, que depende de lo que tengas, o no hagas la segunda parte hasta que hayas hecho la primera parte porque dependía de la primera parte. Lo que nos dio es una nueva metodología para ser un poco más ágil, que es de donde proviene el término, sobre cómo entregamos las cosas, y específicamente sobre el diseño y el desarrollo de proyectos de base.

Algunos de los inquilinos clave, solo para seguir adelante con esto, son los inquilinos clave de scrum. Introdujo la idea de construir inestabilidad, que efectivamente si piensas en el miedo al caos, el mundo existe en un estado de caos, pero el planeta se formó, lo cual es interesante, por lo que construir inestabilidad, la capacidad de rebotar un poco y todavía hace que las cosas funcionen, equipos de proyectos autoorganizados, favores superpuestos a través de un desarrollo muy responsable, diferentes tipos de aprendizaje y control a través del viaje de la entrega del proyecto, la transferencia organizacional del aprendizaje. Entonces, ¿cómo tomamos información de una parte del negocio y la transferimos a otra de personas que tienen una idea pero que no desarrollan código o no desarrollan bases de datos e infraestructuras, sino datos para esas personas? Y específicamente resultados de tiempo determinado. En otras palabras, hagamos esto por un período de tiempo, ya sea un día como en 24 horas, o una semana o un par de semanas para ver qué podemos hacer y luego dar un paso atrás y mirarlo.

Entonces, si perdonas el juego de palabras, este es realmente un juego nuevo en la entrega de proyectos y los tres componentes principales que tendrán sentido a medida que avancemos un poco más aquí: ahí está el producto: todas estas personas tienen la idea y tienen la necesidad de hacer algo y la historia que los rodea. Desarrolladores que operan en el modelo ágil de obtener sus historias y a través de stand-ups diarios utilizando la metodología scrum para discutirlo y comprender lo que necesitan hacer, y luego simplemente seguir adelante y hacerlo. Entonces, personas, hemos oído hablar de maestros de scrum que supervisan todo esto y entienden la metodología lo suficientemente bien como para manejarlo. Todos hemos visto estas imágenes que obtuve en el lado derecho aquí de paredes y pizarras blancas llenas de notas Post-It y fueron servidas como paredes Kanban. Si no sabe quién es Kanban, lo invito a Google quién era el Sr. Kanban y por qué fue un cambio en la forma en que movemos las cosas de un lado a otro en una pared, literalmente, pero en un proyecto.

De un vistazo, el flujo de trabajo de scrum hace esto: toma una lista de las cosas que una organización quiere hacer, las ejecuta a través de una serie de cosas que llamamos sprints que se dividen en períodos de 24 horas, períodos de un mes y nosotros obtenga esta serie incremental de salidas. Es un cambio significativo en la forma en que se entregan los proyectos, se entregaron hasta esa etapa porque parte de eso fluye como el ejército de los EE. UU. Que tuvo una gran parte de desarrollar algo llamado PMBOK, como la idea de no llevar el tanque al campo hasta que pones balas en la cosa porque si un tanque en el campo no tiene balas, es inútil. Entonces, la primera parte es poner balas en el tanque, la segunda parte es poner el tanque en el campo. Sin embargo, desafortunadamente, lo que sucedió con los desarrolladores en el mundo del desarrollo de alguna manera se apoderó de esta metodología ágil y corrió con ella, si perdonas el juego de palabras, en un sprint.

Invariablemente, lo que sucedió es que, cuando pensamos en ágil, generalmente pensamos en desarrolladores y no en bases de datos y en algo que tenga que ver con el mundo de las bases de datos. Fue un resultado desafortunado porque la realidad es que ágil no se limita a los desarrolladores. De hecho, el término ágil en mi opinión a menudo se asocia erróneamente exclusivamente con desarrolladores de software y no con diseñadores y arquitectos de bases de datos. Invariablemente, los mismos desafíos que enfrenta en el desarrollo de software y aplicaciones se enfrentan en todo lo que tiene que ver con el diseño y desarrollo, operación y mantenimiento y, por lo tanto, de la infraestructura de datos y particularmente de las bases de datos. Los actores en este reparto de datos en particular incluyen arquitectos de datos, moldeadores, administradores, administradores de las infraestructuras de bases de datos y las bases de datos reales hasta analistas y arquitectos de negocios y sistemas, personas que se sientan y piensan cómo funcionan los sistemas. y el negocio operan y cómo hemos llegado a transmitir datos a través de estos.

Es un tema que menciono regularmente porque es una frustración constante mía porque creo que los especialistas en datos deben, no deberían, estar íntimamente involucrados en todos los componentes de la entrega del proyecto, realmente, particularmente en el desarrollo. Para que no lo hagamos, entonces realmente no nos estamos dando la mejor oportunidad para un buen resultado. A menudo tenemos que dar la vuelta y pensar de nuevo en estas cosas porque existe un escenario, llegamos a una aplicación que se está creando y descubrimos que los desarrolladores no siempre son expertos en datos. Trabajar con bases de datos requiere habilidades muy especializadas, particularmente en torno a los datos, y crea una experiencia. No solo se convierte instantáneamente en un gurú de bases de datos o experto en conocimiento de datos de la noche a la mañana; Esto es a menudo algo que proviene de una experiencia de toda la vida y, ciertamente, con los gustos del Dr. Robin Bloor en el Código Hoy, que escribió el libro con bastante riqueza.

En muchos casos, y es desafortunado pero es una realidad, hay dos partes de esta moneda, es decir, los desarrolladores de software tienen un apagón propio en cuanto a especialistas en bases de datos y desarrollan las habilidades que necesita en el modelado de diseño de bases de datos, el desarrollo de modelos es solo el fundamental para la ingeniería de los gurús de cómo ingresan los datos y cómo se organiza la jornada y qué aspecto debería o no debería ser, o indudablemente que se ingiere y comprende que generalmente se obtiene en las habilidades nativas establecidas para los desarrolladores de software. Y algunos de los desafíos comunes que enfrentamos, solo para ponerlo en contexto, incluyen los gustos de la creación básica y el mantenimiento y la administración del diseño de la base de datos central, documentar los datos y la infraestructura de la base de datos y luego reutilizar esos activos de datos, diseños de esquemas, Generaciones de esquemas, administración y mantenimiento de esquemas y el uso de ellos, compartir el conocimiento sobre por qué este esquema está diseñado de una manera particular y las fortalezas y debilidades que conlleva el paso del tiempo, el modelado de datos y los tipos de los modelos que aplicamos a los sistemas y los datos que fluimos a través de ellos. Generación de código de base de datos y continúa con la integración y luego modela los datos a su alrededor y luego accede más rápidamente para controlar la seguridad alrededor de los datos, la integridad de los datos es que estamos moviendo los datos a medida que conservamos su integridad, ¿hay suficientes metadatos alrededor? ¿Deberían las ventas ver todos los registros en la tabla o solo deberían ver la dirección, el nombre y el apellido que le envían las cosas en la publicación? Y, por supuesto, el mayor desafío de todos es el modelado de plataformas de bases de datos, que es una conversación completamente diferente en sí misma.

Soy de la opinión de que con todo esto en mente para hacer posible este nirvana, es absolutamente crítico que tanto los especialistas en datos como los desarrolladores tengan las herramientas adecuadas y que esas herramientas sean capaces de entregar proyectos centrados en el equipo, diseño, desarrollo y mantenimiento operativo continuo. Ya sabes, cosas como colaborar en proyectos entre expertos en datos y desarrolladores de software, un solo punto de verdad o una sola fuente de verdad para todo lo relacionado con la documentación de las bases de datos, los datos, los esquemas, de dónde provienen los registros, los propietarios de esos registros . Creo que hoy en día es absolutamente crítico, vamos a lograr que este nirvana de datos sea el rey, que las herramientas correctas deben estar en su lugar porque el desafío es demasiado grande ahora para que lo hagamos manualmente, y si las personas entrar y salir de una organización, es demasiado fácil para nosotros no seguir el mismo proceso o metodología que una persona podría establecer que son buenos y no necesariamente transferir esas habilidades y capacidades en el futuro.

Con eso en mente, me dirigiré a nuestro buen amigo en IDERA y escucharé sobre esa herramienta y cómo aborda estas cosas.

Ron Huizenga: Muchas gracias y gracias a Robin y Dez por realmente preparar bien el escenario, y verás un poco de superposición en un par de cosas de las que he hablado. Pero realmente han establecido una base muy sólida para algunos de los conceptos de los que voy a hablar desde una perspectiva de modelado de datos. Y muchas de las cosas que han dicho se hacen eco de mi propia experiencia cuando era consultor trabajando en modelado de datos y arquitectura de datos, junto con equipos, ambos en cascada en los primeros días y evolucionando hacia productos más modernos con proyectos en los que estábamos usando ágil metodologías para entregar soluciones.

Entonces, de lo que voy a hablar hoy se basa en esas experiencias, así como en una vista de las herramientas y algunas de las capacidades de las herramientas que utilizamos para ayudarnos en ese viaje. Lo que voy a cubrir muy brevemente es que no voy a entrar en scrum con mucho detalle; Acabamos de tener una buena visión general de lo que es eso. Voy a hablar sobre esto en términos de, ¿qué es un modelo de datos y qué significa realmente para nosotros? ¿Y cómo habilitamos el concepto del modelador de datos ágil en nuestras organizaciones, en términos de cómo involucramos a los modeladores de datos, cuál es la participación de los modeladores y arquitectos durante el sprint, cuáles son los tipos de actividades en las que deberían participar? y, como telón de fondo, ¿cuáles son algunas de las capacidades importantes de herramientas de modelado que utilizamos para ayudar realmente a facilitar ese trabajo? Luego voy a entrar en un resumen y hablar un poco sobre algunos de los valores comerciales y los beneficios de tener un modelador de datos involucrado, o la forma en que realmente voy a contar la historia es, los problemas de no tener un modelador de datos totalmente involucrado en los proyectos y le mostraré eso en base a la experiencia y una tabla de defectos de una imagen anterior y posterior de un proyecto real en el que estuve involucrado hace muchos años. Y luego resumiremos algunos puntos más y luego tendremos preguntas y respuestas además de eso.

Muy brevemente, ER Studio es una suite muy poderosa que tiene muchos componentes diferentes. El Arquitecto de datos, que es donde los modeladores y arquitectos de datos pasan la mayor parte de su tiempo haciendo su modelado de datos. También hay otros componentes de los que no vamos a hablar hoy, como el Business Architect, donde hacemos modelado de procesos y el Software Architect, para algunos de los modelos UML. Luego está el Repositorio, donde registramos y compartimos los modelos y permitimos que los equipos colaboren en ellos y los publiquen en el servidor del equipo para que las audiencias de múltiples partes interesadas que participan en un proyecto realmente puedan ver los artefactos que 'nosotros' estamos creando desde una perspectiva de datos, así como las otras cosas que estamos haciendo en la entrega del proyecto en sí.

En lo que me voy a centrar hoy será en algunas cosas que veremos en Data Architect y porque es realmente importante que tengamos la colaboración de los aspectos basados ​​en el Repositorio de eso. Particularmente cuando comenzamos a hablar sobre conceptos como la gestión del cambio que son imprescindibles, no solo para proyectos de desarrollo ágiles, sino para cualquier tipo de desarrollo en el futuro.

Entonces, hablemos del Agile Data Modeler por un momento. Como hemos aludido anteriormente en la presentación, es imprescindible que tengamos modeladores de datos y / o arquitectos totalmente comprometidos con los procesos de desarrollo ágiles. Ahora, lo que sucedió históricamente es que sí, realmente hemos pensado en ágil desde una perspectiva de desarrollo, y hay un par de cosas que han sucedido que realmente han provocado que eso ocurra. Parte de esto se debió a la naturaleza de la forma en que se desarrolló el desarrollo en sí. Cuando comenzó el desarrollo ágil y comenzamos con este concepto de equipos autoorganizados, si bebías el Kool-Aid demasiado puro y estabas en el lado de la programación extrema, había una interpretación muy literal de cosas como el equipos autoorganizados, que mucha gente interpretó que significa, todo lo que necesitamos es un grupo de desarrolladores que puedan construir una solución completa. Ya sea que se trate de desarrollar el código, las bases de datos o los almacenes de datos detrás de él y todo fue relegado a los desarrolladores. Pero lo que sucede con eso es que pierdes las habilidades especiales que tienen las personas. He descubierto que los equipos más fuertes son aquellos que están compuestos por personas de diferentes orígenes. Como una combinación de fuertes desarrolladores de software, arquitectos de datos, modeladores de datos, analistas de negocios y partes interesadas de negocios, todos colaborando juntos para sacar una solución final.

De lo que también estoy hablando hoy es de que voy a hacer esto en el contexto de un proyecto de desarrollo en el que estamos desarrollando una aplicación que obviamente también tendrá asociado el componente de datos. Sin embargo, tenemos que dar un paso atrás antes de hacerlo, porque debemos darnos cuenta de que hay muy pocos proyectos de desarrollo de Greenfield en los que tengamos un enfoque total en la creación y el consumo de datos que están limitados solo dentro de ese proyecto de desarrollo. . Necesitamos dar un paso atrás y observar el punto de vista organizacional general desde una perspectiva de datos y una perspectiva de proceso. Porque lo que descubrimos es que la información que estamos utilizando ya puede existir en algún lugar de las organizaciones. Como modeladores y arquitectos, sacamos eso a la luz para que sepamos de dónde obtener esa información en los propios proyectos. También conocemos las estructuras de datos involucradas porque tenemos patrones de diseño al igual que los desarrolladores tienen patrones de diseño para su código. Y también tenemos que tomar esa perspectiva organizacional general. No podemos simplemente mirar los datos en el contexto de la aplicación que estamos creando. Necesitamos modelar los datos y asegurarnos de documentarlos porque dura mucho más que las aplicaciones mismas. Esas aplicaciones van y vienen, pero necesitamos poder ver los datos y asegurarnos de que sean sólidos y bien estructurados, no solo para la aplicación, sino también para las decisiones que informan actividades, informes de BI e integración a otras aplicaciones, internas y externo a nuestras organizaciones también. Por lo tanto, tenemos que ver todo ese panorama general de los datos y cuál es el ciclo de vida de esos datos y comprender el recorrido de los datos en toda la organización desde la cuna hasta la tumba.

Ahora, volviendo a los equipos en sí y cómo realmente necesitamos trabajar, la metodología en cascada se percibió como demasiado lenta para entregar resultados. Porque, como se señaló con el ejemplo del tanque, fue un paso tras otro y, a menudo, tardó demasiado en obtener un resultado final viable. Lo que hacemos ahora es que necesitamos tener un estilo de trabajo iterativo en el que estamos desarrollando gradualmente componentes de él y elaborándolo a través del tiempo donde estamos produciendo código utilizable o artefactos utilizables, voy a decir, para cada sprint. Lo importante es la colaboración entre las partes interesadas técnicas en el equipo y las partes interesadas del negocio, ya que estamos colaborando para llevar esas historias de usuarios a una visión implementable del código y los datos que también admiten ese código. Y el propio Agile Data Modeler a menudo encontrará que no tenemos suficientes modeladores en las organizaciones, por lo que un modelador o arquitecto de datos puede estar apoyando simultáneamente a varios equipos.

Y el otro aspecto de eso es que, incluso si tenemos múltiples modeladores, debemos asegurarnos de que tenemos un conjunto de herramientas que estamos utilizando que permita la colaboración de múltiples proyectos que están en vuelo al mismo tiempo y compartirlos artefactos de datos y las capacidades de entrada y salida. Voy a repasar esto muy rápido porque ya lo cubrimos en la sección anterior. La premisa real de Agile es que estás basando las cosas en el trabajo atrasado, en historias o requisitos. Dentro de las iteraciones estamos colaborando como grupo. Por lo general, un sprint de dos semanas o un mes, dependiendo de la organización, es muy común. Y también reuniones diarias de revisión y standup para eliminar los bloqueadores y asegurarnos de avanzar todos los aspectos sin detenernos en diferentes áreas a medida que avanzamos. Y en esos sprints queremos asegurarnos de que estamos produciendo entregables utilizables como parte de cada sprint.

Solo una versión ligeramente diferente de eso, expandiéndolo aún más, scrum es la metodología de la que voy a hablar más específicamente aquí y básicamente hemos aumentado esa imagen anterior con algunas otras facetas. Por lo general, hay una acumulación de productos y luego hay una acumulación de sprint. Por lo tanto, tenemos un retraso general que, al comienzo de cada reiteración de sprint, reducimos el ritmo para decir: "¿Qué vamos a construir este sprint?" Y eso se hace en una reunión de planificación de sprint. Luego separamos las tareas que están asociadas con eso y ejecutamos en esos sprints de una a cuatro semanas con esas revisiones diarias. A medida que hacemos eso, estamos rastreando nuestro progreso a través de gráficos de quemado y gráficos de quemado para rastrear básicamente lo que queda por construir frente a lo que estamos construyendo para establecer cosas como cuál es nuestra velocidad de desarrollo, vamos a hacer nuestro horario, todo ese tipo de cosas. Todos estos se elaboran continuamente durante el sprint en lugar de pasar unos meses más adelante y descubrir que se quedará corto y que necesita extender el cronograma del proyecto. Y muy importante, como parte de esto, para todos los equipos, hay una revisión de sprint al final y una retrospectiva de sprint, así que antes de comenzar la próxima iteración estás revisando lo que hiciste y estás buscando formas de poder mejorar en la próxima vez.

En términos de entregables, esta es básicamente una diapositiva que resume los tipos típicos de cosas que suceden en los sprints. Y está muy centrado en el desarrollo, por lo que muchas de las cosas que vemos aquí, como diseños funcionales y casos de uso, hacer pruebas de código de diseño, cuando miramos estos cuadros aquí, y no voy a pasar por ellos en cualquier nivel de detalle, están muy orientados al desarrollo. Y oculto debajo está el hecho de que también necesitamos tener esos entregables de datos que van de la mano con esto para respaldar este esfuerzo. Por lo tanto, cada vez que vemos cosas como los retrasos, los requisitos y las historias de usuarios, a medida que avanzamos, debemos analizar cuáles son las piezas de desarrollo que tenemos que hacer, cuáles son las piezas de análisis que debemos hacer, qué tal el diseño de datos o modelo de datos, ¿qué pasa con cosas como los glosarios comerciales para que podamos asociar el significado comercial a todos los artefactos que estamos produciendo? Porque necesitamos producir esos entregables utilizables en cada sprint.

Algunas personas dirán que necesitamos producir código utilizable al final de cada sprint. Ese no es necesariamente el caso, es decir, desde una perspectiva de desarrollo más pura, pero a menudo, especialmente al principio, podemos tener algo así como el sprint cero, donde nos centramos exclusivamente en ponernos de pie, hacer cosas como poner nuestras estrategias de prueba en sitio. Un diseño de alto nivel para comenzar antes de comenzar a completar los detalles y asegurarnos de que tenemos un conjunto limpio de historias o requisitos iniciales antes de comenzar a involucrar a otras audiencias y luego avanzar como equipo a medida que avanzamos. Siempre hay un poco de tiempo de preparación, por lo que a menudo tendremos un sprint cero o incluso un sprint cero y uno. Podría ser un poco una fase de inicio antes de alcanzar el vuelo completo en la entrega de la solución.

Hablemos de los modelos de datos en este contexto muy brevemente. Cuando las personas piensan en modelos de datos, a menudo piensan en un modelo de datos como una imagen de cómo se unen las diferentes piezas de información, eso es solo la punta del iceberg. Para encarnar completamente el espíritu de cómo realmente desea abordar el modelado de datos, ya sea en desarrollo ágil y otras cosas, es necesario darse cuenta de que el modelo de datos, si se realiza correctamente, se convierte en su especificación completa de lo que significan esos datos en la organización y cómo se implementa en las bases de datos de fondo. Cuando digo bases de datos, me refiero no solo a las bases de datos relacionales que podemos estar usando, sino también a las arquitecturas actuales en las que tenemos plataformas de Big Data o NoSQL, como prefiero llamarlas. También esos grandes almacenes de datos porque podemos estar combinando muchos almacenes de datos diferentes en términos de consumir información y llevarla a nuestras soluciones, así como también cómo persistimos o guardamos esa información fuera de nuestras soluciones.

Podemos estar trabajando con múltiples bases de datos o fuentes de datos simultáneamente en el contexto de una aplicación determinada. Lo que es muy importante es que queremos poder tener una especificación completa, por lo que una especificación lógica de lo que esto significa para una perspectiva organizacional rápida, cuáles son las construcciones físicas en términos de cómo definimos realmente los datos, las relaciones entre ellos en sus bases de datos, sus restricciones de integridad referencial, verifique las restricciones, todas esas piezas de validación en las que generalmente piensa. Los metadatos descriptivos son extremadamente importantes. ¿Cómo sabes cómo utilizar los datos en tus aplicaciones? A menos que pueda definirlo y saber lo que significa o saber de dónde proviene para asegurarse de que está consumiendo los datos correctos en esas aplicaciones, asegurándose de que tengamos convenciones de nomenclatura correctas, definiciones completas, lo que significa un diccionario de datos completo para no solo las tablas, pero las columnas que comprenden esas tablas, y las notas detalladas de implementación sobre cómo lo utilizamos porque necesitamos construir esta base de conocimiento porque incluso cuando se realiza esta aplicación, esta información se utilizará para otras iniciativas, por lo que debemos asegurarnos que tenemos todo eso documentado para futuras implementaciones.

Nuevamente, vamos a cosas como tipos de datos, claves, índices, el modelo de datos en sí incorpora muchas de las reglas comerciales que entran en juego. Las relaciones no son solo restricciones entre diferentes tablas; a menudo nos ayudan a describir cuáles son las verdaderas reglas comerciales en torno a cómo se comportan esos datos y cómo funcionan juntos como una unidad cohesiva. Y, por supuesto, las restricciones de valor son muy importantes. Ahora, por supuesto, una de las cosas con las que estamos lidiando constantemente, y cada vez es más frecuente, son cosas como la gobernanza de datos. Entonces, desde la perspectiva de la gobernanza de datos, también debemos analizar qué definimos aquí. Queremos definir cosas como clasificaciones de seguridad. ¿Con qué tipos de datos estamos tratando? ¿Qué se considerará gestión de datos maestros? ¿Cuáles son las tiendas transaccionales que estamos creando? ¿Qué datos de referencia estamos utilizando en estas aplicaciones? Necesitamos asegurarnos de que se capture correctamente en nuestros modelos. Y también consideraciones de calidad de datos, hay ciertos datos que son más importantes para una organización que otros.

He estado involucrado en proyectos en los que reemplazamos más de una docena de sistemas heredados con nuevos procesos comerciales y diseñamos nuevas aplicaciones y almacenes de datos para reemplazarlos. Necesitábamos saber de dónde venía la información. Lo que para la información más importante, desde una perspectiva comercial, si observa esta diapositiva de modelo de datos en particular que tengo aquí, verá que los cuadros inferiores en estas entidades particulares, que es solo un pequeño subconjunto, yo De hecho, he podido capturar el valor comercial. Ya sea alto, medio o bajo para este tipo de cosas para estas diferentes construcciones dentro de la organización. Y también he capturado cosas como las clases de datos maestros, si son tablas maestras, si son de referencia, si eran transaccionales. Por lo tanto, podemos ampliar nuestros metadatos en nuestros modelos para darnos muchas otras características fuera de los datos en sí, lo que realmente nos ayudó con otras iniciativas fuera de los proyectos originales y llevarlos adelante. Ahora que fue mucho en una diapositiva, voy a pasar por el resto de estos bastante rápido.

Ahora voy a hablar muy rápido sobre lo que hace un modelador de datos mientras pasamos por estos diferentes sprints. En primer lugar, un participante completo en las sesiones de planificación del sprint, donde tomamos las historias de los usuarios, nos comprometemos con lo que vamos a entregar en ese sprint y descubrimos cómo vamos a estructurarlo y entregarlo. Lo que también estoy haciendo como modelador de datos es que sé que trabajaré en áreas separadas con diferentes desarrolladores o con diferentes personas. Entonces, una de las características importantes que podemos tener es que cuando hacemos un modelo de datos, podemos dividir ese modelo de datos en diferentes vistas, ya sea que las llame áreas temáticas o submodelos, es nuestra terminología. Entonces, a medida que estamos construyendo el modelo, también lo estamos mostrando en estas diferentes perspectivas de submodelo para que las diferentes audiencias solo vean lo que es relevante para ellos y puedan concentrarse en lo que están desarrollando y presentando. Por lo tanto, podría tener a alguien trabajando en una parte de programación de una aplicación, podría tener a alguien más trabajando en una entrada de orden donde estamos haciendo todas estas cosas en un solo sprint, pero puedo darles los puntos de vista a través de esos submodelos que solo aplicar al área en la que están trabajando. Y luego esos se acumulan en el modelo general y en toda la estructura de los submodelos para dar a las diferentes vistas de la audiencia lo que necesitan ver.

Los fundamentos desde una perspectiva de modelado de datos que queremos tener es siempre tener una línea de base a la que podamos volver porque una de las cosas que debemos poder hacer es, ya sea al final de un sprint o al final de varios sprints, queremos saber dónde comenzamos y siempre tenemos una línea de base para saber cuál fue el delta o la diferencia de lo que produjimos en un sprint dado. También debemos asegurarnos de que podamos tener un cambio rápido. Si entras como modelador de datos pero en el tradicional rol de guardián de decir "No, no, no puedes hacer eso, primero tenemos que hacer todo esto", serás excluido del equipo cuando realmente necesites ser un participante activo en todos esos equipos de desarrollo ágiles. Eso significa que algunas cosas se caen del carro haciendo un sprint dado y las recoges en sprints posteriores.

Como ejemplo, puede enfocarse en las estructuras de datos solo para que el desarrollo comience, por ejemplo, esa pieza de entrada de orden de la que estaba hablando. En un sprint posterior, puede volver y completar los datos como parte de la documentación para el diccionario de datos en torno a algunos de los artefactos que ha creado. No vas a completar esa definición todo en un sprint; continuará avanzando en sus entregas de forma incremental porque habrá momentos en los que podrá completar esa información trabajando con analistas de negocios cuando los desarrolladores estén ocupados creando las aplicaciones y la persistencia en torno a esos almacenes de datos. Desea facilitar y no ser el cuello de botella. Hay diferentes formas de trabajar con los desarrolladores. Para algunas cosas, tenemos patrones de diseño, por lo que somos un participante completo desde el principio, por lo que podemos tener un patrón de diseño en el que diremos que lo pondremos en el modelo, lo enviaremos a las bases de datos de sandbox de los desarrolladores y luego podrán comenzar a trabajar con él y solicitar cambios a eso.

Puede haber otras áreas en las que los desarrolladores han estado trabajando, tienen algo en lo que están trabajando y están creando prototipos de algunas cosas para probarlas en su propio entorno de desarrollo. Tomamos esa base de datos con la que han estado trabajando, la incorporamos a nuestra herramienta de modelado, la comparamos con los modelos que tenemos y luego resolvemos y les enviamos los cambios para que puedan refactorizar sus códigos y seguir las estructuras de datos adecuadas. que necesitamos Debido a que pueden haber creado algunas cosas que ya teníamos en otros lugares, nos aseguramos de que estén trabajando con las fuentes de datos correctas. Seguimos iterando todo el camino hasta nuestro sprint para obtener los entregables de datos completos, la documentación completa y la definición de todas esas estructuras de datos que estamos produciendo.

Los proyectos ágiles más exitosos en los que he estado involucrado en términos de muy buenas entregas son, teníamos una filosofía, modelar todos los cambios a la especificación de la base de datos física completa. En esencia, el modelo de datos se convierte en las bases de datos implementadas con las que está trabajando para cualquier cosa nueva que estamos creando y tiene referencias completas de los otros almacenes de datos si consumimos de otras bases de datos externas. Como parte de eso, estamos produciendo scripts incrementales en lugar de hacer una generación completa cada vez. Y estamos utilizando nuestros patrones de diseño para darnos ese impulso rápido en términos de hacer que las cosas funcionen en sprints con los diferentes equipos de desarrollo con los que estamos trabajando.

También en las actividades de sprint, esta es la línea de base para comparar / fusionar, así que tomemos la idea de modelar cada cambio. Cada vez que hacemos un cambio, lo que queremos hacer es modelar el cambio y lo que es muy importante, lo que faltaba en el modelado de datos hasta hace poco, de hecho, hasta que lo reintroducimos, es la capacidad de asociar el modelado. tareas y sus entregas con las historias de usuario y las tareas que realmente causan esos cambios. Queremos poder registrar los cambios en nuestro modelo, de la misma manera que los desarrolladores registran sus códigos, haciendo referencia a las historias de los usuarios que tenemos para que sepamos por qué hicimos cambios, eso es algo que hacemos. Cuando hacemos eso, generamos nuestros scripts DDL incrementales y los publicamos para que puedan recogerse con los otros entregables de desarrollo y registrarse en nuestra solución de compilación. Nuevamente, podemos tener un modelo o trabajar con varios equipos. Y como he mencionado, algunas cosas son originadas por el modelador de datos, otras cosas son originadas por los desarrolladores y nos reunimos en el medio para encontrar el mejor diseño general y avanzar y asegurarnos de que esté correctamente diseñado en nuestro estructuras de datos generales. Tenemos que mantener la disciplina de garantizar que tengamos todas las construcciones adecuadas en nuestro modelo de datos a medida que avanzamos, incluyendo cosas como valores nulos y no nulos, restricciones referenciales, básicamente restricciones de verificación, todas esas cosas en las que normalmente pensaríamos .

Hablemos ahora de algunas capturas de pantalla de algunas de las herramientas que nos ayudan a hacer esto. Lo que creo que es importante es tener ese repositorio colaborativo, por lo que lo que podemos hacer como modeladores de datos, y esto es un fragmento de parte de un modelo de datos en segundo plano, es cuando estamos trabajando en cosas que queremos asegurarnos de que podamos trabaje solo en los objetos que necesitamos poder cambiar, realice las modificaciones, genere nuestros scripts DDL para los cambios que hemos realizado a medida que revisamos las cosas. Entonces, lo que podemos hacer es, en ER Studio, es un ejemplo, podemos revisar objetos o grupos de objetos para trabajar, no tenemos que revisar un modelo o submodelo completo, podemos revisar solo aquellas cosas que nos interesan. Lo que queremos después de eso es en el momento del check-out o del check-in: lo hacemos en ambos sentidos porque los diferentes equipos de desarrollo trabajan de diferentes maneras. Queremos asegurarnos de asociar eso con la historia o tarea del usuario que impulsa los requisitos para esto y que será la misma historia o tarea del usuario que los desarrolladores desarrollarán y verificarán su código.

Aquí hay un fragmento muy rápido de un par de pantallas de uno de nuestros centros de gestión de cambios. Lo que esto hace, no voy a analizarlo con gran detalle aquí, pero lo que está viendo es la historia o tarea del usuario y una sangría debajo de cada uno de los que está viendo los registros de cambios reales: hemos creado un registro de cambios automatizado cuando hacemos el check-in y el check-out y también podemos poner más descripción en ese registro de cambios. Está asociado con la tarea, podemos tener múltiples cambios por tarea, como es de esperar. Y cuando entramos en ese registro de cambio, podemos verlo y, lo que es más importante, ¿qué cambiamos realmente? Para este particular, la historia destacada allí tuve un tipo de cambio que se realizó y cuando miré el registro de cambio real en sí, identificó las piezas individuales en el modelo que ha cambiado. Cambié un par de atributos aquí, los volví a secuenciar y trajo consigo las vistas que debían modificarse y que también dependían de ellas para que se generaran en la DLL incremental. No solo modela en los objetos base, sino que una herramienta de modelado de alta potencia como esta también detecta los cambios que deben ser ondulados a través de los objetos dependientes en la base de datos o el modelo de datos.

Si estamos trabajando con desarrolladores, y hacemos esto en un par de cosas diferentes, eso es hacer algo en su caja de arena y queremos comparar y ver dónde están las diferencias, usamos capacidades de comparación / fusión en el lado derecho e izquierdo lado. Podemos decir: "Aquí está nuestro modelo en el lado izquierdo, aquí está su base de datos en el lado derecho, muéstrame las diferencias". Luego podemos elegir cómo resolver esas diferencias, ya sea que empujemos cosas a la base de datos o si Hay algunas cosas que tienen en la base de datos que traemos de vuelta al modelo. Podemos ir bidireccionales para que podamos ir en ambas direcciones, actualizando simultáneamente el origen y el destino y luego producir los scripts DDL incrementales para implementar esos cambios en el entorno de la base de datos, lo cual es extremadamente importante. Lo que también podemos hacer es que también podemos usar esta capacidad de comparación y combinación en cualquier momento dado, si estamos tomando instantáneas en el camino, siempre podemos comparar el inicio de un sprint para comenzar o finalizar otro sprint para que podamos ver El cambio incremental completo de lo que se hizo en un sprint de desarrollo dado o en una serie de sprints.

Este es un ejemplo muy rápido de una secuencia de comandos alternativa, cualquiera de ustedes que haya estado trabajando con bases de datos habrá visto este tipo de cosas, esto es lo que podemos sacar del código como una secuencia de comandos alternativa para asegurarnos de que retener cosas aquí. Lo que saqué de aquí, solo para reducir el desorden, es lo que también hacemos con estos scripts alternos, asumimos que también hay datos en esas tablas, por lo que también generaremos el DML que extraerá la información de las tablas temporales y empuje nuevamente a las nuevas estructuras de datos para que no solo veamos las estructuras, sino también los datos que tal vez ya hayamos contenido en esas estructuras.

Vamos a hablar muy rápido sobre los sistemas de compilación automatizados porque, cuando hacemos un proyecto ágil con bastante frecuencia, estamos trabajando con sistemas de compilación automatizados en los que debemos verificar juntos los diferentes entregables para asegurarnos de no romper nuestras compilaciones. Lo que eso significa es que sincronizamos los entregables, esos scripts de cambio de los que hablé con el script DDL deben ser ingresados, el código de la aplicación correspondiente debe ser ingresado al mismo tiempo y muchos desarrolladores de desarrollo ahora, por supuesto, no lo son. se hace con SQL directo contra las bases de datos y ese tipo de cosas. Muy a menudo estamos utilizando marcos de persistencia o construyendo servicios de datos. Necesitamos asegurarnos de que los cambios para esos marcos o servicios se registren exactamente al mismo tiempo. Entran en un sistema de compilación automatizado en algunas organizaciones y, si la compilación se rompe, en una metodología ágil, todo depende de la construcción de la plataforma antes de avanzar para que sepamos que tenemos una solución que funcione antes de continuar. Y uno de los proyectos en los que estuve involucrado, lo llevamos al extremo: si la construcción se rompió, realmente habíamos conectado a varias computadoras en nuestra área donde estábamos ubicados con los usuarios comerciales, solo teníamos luces rojas intermitentes. Como la parte superior de los coches de policía. Y si la construcción se rompió, esas luces intermitentes rojas comenzaron a apagarse y supimos que todo estaba en la cubierta: arregle la construcción y luego continúe con lo que estábamos haciendo.

Quiero hablar sobre otras cosas, y esta es una capacidad única para ER Studio, realmente ayuda cuando estamos tratando de construir estos artefactos como desarrolladores para estos límites de persistencia, tenemos un concepto llamado objetos de datos comerciales y lo que nos permite si observa este modelo de datos muy simplista como ejemplo, nos permite encapsular entidades o grupos de entidades para determinar dónde están los límites de persistencia. Donde nosotros, como modeladores de datos, podemos pensar en algo como un encabezado de orden de compra y la alineación de la orden y otras tablas detalladas que se unirían a eso en la forma en que lo desarrollamos y nuestros desarrolladores de servicios de datos necesitan saber cómo persisten las cosas con esos datos diferentes estructuras Nuestros desarrolladores están pensando en cosas como la orden de compra como un objeto en general y cuál es su contrato con la forma en que crean esos objetos en particular. Podemos exponer ese detalle técnico para que las personas que construyen los servidores de datos puedan ver lo que hay debajo y podemos proteger a los demás públicos de las complejidades para que solo vean los diferentes objetos de nivel superior, que también funciona muy bien para comunicarse con las empresas. analistas y partes interesadas comerciales cuando hablamos de la interacción de diferentes conceptos comerciales también.

Lo bueno de eso también es que los expandimos y colapsamos constructivamente para que podamos mantener las relaciones entre los objetos de orden superior a pesar de que se originan en construcciones contenidas en esos objetos de datos comerciales. Ahora, como modelador, llega al final del sprint, al final de la finalización del sprint, tengo muchas cosas que necesito hacer, que llamo mi limpieza para el próximo sprint. Cada sprint que creo lo que llamo el lanzamiento con nombre, eso me da mi línea de base para lo que ahora tengo al final del lanzamiento. Eso significa que es mi línea de base en el futuro, todas estas líneas de base o lanzamientos con nombre que creo y guardo en mi repositorio que puedo usar para hacer una comparación / combinación para que siempre pueda comparar con cualquier final de sprint de cualquier otro sprint, que Es muy importante saber cuáles fueron sus cambios en su modelo de datos en el camino a través de su viaje.

También creo una secuencia de comandos DDL delta usando la comparación / combinación de nuevo desde el principio hasta el final del sprint. Es posible que haya registrado un montón de secuencias de comandos incrementales, pero si lo necesito, ahora tengo una secuencia de comandos que puedo implementar para poner en pie otras cajas de arena, así que puedo decir que esto es lo que teníamos al comienzo del sprint, presionar a través de él, construya una base de datos como una caja de arena para comenzar con el próximo sprint y también podemos usar esas cosas para hacer cosas como instancias de control de calidad standup y, en última instancia, por supuesto, queremos impulsar nuestros cambios a la producción para que tengamos varias cosas en marcha al mismo tiempo. Una vez más, participamos plenamente en la planificación del sprint y las retrospectivas, las retrospectivas son realmente las lecciones aprendidas y eso es extremadamente importante, ya que puedes comenzar muy rápido durante el ágil, debes detenerte y celebrar los éxitos, como ahora. Averigua qué está mal, hazlo mejor la próxima vez, pero también celebra las cosas que salieron bien y construye sobre ellas a medida que avanzas en los próximos sprints.

Ahora voy a hablar muy rápidamente sobre el valor comercial. Hubo un proyecto en el que me involucré hace muchos años que comenzó como un proyecto ágil, y era un proyecto extremo, por lo que era un equipo puro de autoorganización donde solo los desarrolladores estaban haciendo todo. Para resumir, este proyecto fue demorado y descubrieron que cada vez gastaban más en remediar y reparar los defectos identificados que en impulsar más funcionalidades y, de hecho, cuando lo miraban en función en las listas de quemados tendrían que extender el proyecto seis meses a un costo enorme. Y cuando lo analizamos, la forma de remediar el problema fue utilizar una herramienta de modelado de datos adecuada con un modelador de datos capacitado involucrado en el proyecto mismo.

Si observa esta barra vertical en este gráfico en particular, muestra defectos acumulativos versus objetos acumulativos, y estoy hablando de objetos de datos o construcciones que se crearon, como las tablas con las restricciones y ese tipo de cosas, si observa antes de que se introdujera el modelador de datos, el número de defectos en realidad excedía y comenzaba a crear una brecha sobre el número real de objetos que se produjeron hasta ese momento. Después de la semana 21, que es cuando entró el modelador de datos, refactorizó el modelo de datos en función de lo que había que arreglar varias cosas y luego comenzó a modelar como parte del equipo del proyecto en adelante, los cambios a medida que ese proyecto avanzaba . Y viste un cambio muy rápido que en aproximadamente un sprint y medio, vimos un gran aumento en la cantidad de objetos y construcciones de datos que se generaban y construían porque estábamos generando a partir de una herramienta de modelado de datos en lugar de un palo de desarrollador construyéndolos en un entorno, y fueron correctos porque tenían la integridad referencial adecuada y las otras construcciones que debería tener. El nivel de defectos contra aquellos casi planos. Al tomar las medidas apropiadas y asegurarse de que el modelado de datos estuviera completamente comprometido, el proyecto se entregó a tiempo con un nivel de calidad mucho más alto y, de hecho, no se habría cumplido en absoluto si esos pasos no hubieran tenido lugar. Hay muchas fallas ágiles por ahí, también hay muchos éxitos ágiles si logras involucrar a las personas adecuadas en los roles correctos. Soy un gran defensor de la disciplina operativa ágil, pero debe asegurarse de tener las habilidades de todos los grupos correctos involucrados como equipos de proyecto a medida que avanza en un tipo de esfuerzo ágil.

Para resumir, los arquitectos y modeladores de datos deben participar en todos los proyectos de desarrollo; realmente son el pegamento que mantiene todo unido porque como modeladores de datos y arquitectos entendemos, no solo las construcciones de datos del proyecto de desarrollo dado, sino también dónde existen los datos en la organización y dónde podemos obtener esos datos y también cómo se utilizará y utilizará fuera de la aplicación particular en la que estamos trabajando. Entendemos las complejas relaciones de datos y es primordial poder avanzar y también desde una perspectiva de gobernanza para mapear documentos y comprender cómo se ve su panorama de datos completo.

Es como fabricar; Vengo de un fondo de fabricación. No puede inspeccionar la calidad en algo al final: necesita incorporar calidad en su diseño por adelantado y en el camino, y el modelado de datos es una forma de incorporar esa calidad en el diseño de manera eficiente y rentable en todo momento . Y nuevamente, algo para recordar, y esto no es para ser trivial, pero es la verdad, las aplicaciones van y vienen, los datos son el activo corporativo vital y trascienden todos los límites de las aplicaciones. Cada vez que ingresa una aplicación, es probable que se le solicite preservar los datos de otras aplicaciones anteriores, por lo que solo debemos recordar que es un activo corporativo vital que mantenemos con el tiempo.

¡Y eso es! Desde aquí tomaremos más preguntas.

Eric Kavanagh: Muy bien, bien, déjame entregárselo a Robin primero. Y luego, Dez, estoy seguro de que tienes un par de preguntas. Llévatelo, Robin.

Dr. Robin Bloor: De acuerdo. Para ser sincero, nunca he tenido ningún problema con los métodos de desarrollo ágiles y me parece que lo que estás haciendo aquí tiene mucho sentido. Recuerdo haber visto algo en la década de 1980 que indicaba, realmente, que el problema con el que realmente te encuentras en términos de un proyecto que se sale de control, normalmente es si dejas que un error persista más allá de una etapa particular. Simplemente se vuelve cada vez más difícil de arreglar si no logras esa etapa correcta, así que una de las cosas que estás haciendo aquí, y creo que esta es la diapositiva, pero una de las cosas que estás haciendo aquí en sprint zero, en mi opinión, es absolutamente importante porque realmente estás tratando de fijar los entregables allí. Y si no se entregan los entregables, los entregables cambian de forma.

Esa es, más o menos, mi opinión. También es mi opinión: realmente no tengo ningún argumento con la idea de que tienes que hacer que el modelado de datos tenga un cierto nivel de detalle antes de pasar. Lo que me gustaría que intentaras hacer porque no lo entendí completamente es describir uno de estos proyectos en términos de su tamaño, en términos de cómo fluyó, en términos de quién, ya sabes, donde surgieron los problemas, ¿se resolvieron? Porque creo que esta diapositiva es más o menos el núcleo de la misma y si pudieras elaborar un poco más sobre eso, te estaría muy agradecido.

Ron Huizenga: Claro, y usaré un par de proyectos de ejemplo. El que, más o menos, se salió de los rieles que se reanudó al involucrar realmente a las personas adecuadas y hacer el modelado de datos y todo fue realmente una forma de asegurarse de que el diseño se entendiera mejor y obviamente teníamos un mejor diseño de implementación en el camino modelando. Porque cuando lo modelas, sabes, puedes generar tu DDL y todo desde la parte posterior y fuera de la herramienta en lugar de tener que pegar la construcción como lo haría la gente yendo directamente a un entorno de base de datos. Y las cosas típicas que sucederán con los desarrolladores es que entrarán allí y dirán, está bien, necesito estas tablas. Digamos que estamos haciendo entradas de pedidos. Por lo tanto, podrían crear el encabezado del pedido y las tablas de detalles del pedido, y ese tipo de cosas. Pero a menudo se olvidan o descuidan para asegurarse de que las restricciones están ahí para representar las relaciones de claves externas. Es posible que no tengan las claves correctas. Las convenciones de nomenclatura también pueden ser sospechosas. No sé cuántas veces he entrado en un entorno, por ejemplo, donde ves un montón de tablas diferentes con nombres diferentes, pero luego los nombres de columna en esas tablas son como ID, Nombre o lo que sea, por lo que Realmente he perdido el contexto sin la tabla de exactamente qué es eso.

Por lo tanto, por lo general, cuando estamos modelando datos, nos aseguraremos de aplicar las convenciones de nomenclatura adecuadas a todos los artefactos que también se generan en el DDL. Pero para ser más específico sobre la naturaleza de los proyectos en sí, en general, estoy hablando de iniciativas bastante grandes. Uno de ellos fue el proyecto de transformación empresarial de $ 150 millones donde reemplazamos más de una docena de sistemas heredados. Tuvimos cinco equipos ágiles diferentes funcionando simultáneamente. Tenía un equipo de arquitectura de datos completo, por lo que tenía modeladores de datos de mi equipo integrados en cada uno de los otros equipos de área de aplicaciones, y estábamos trabajando con una combinación de expertos empresariales internos que conocían el tema, que estaban haciendo el historias de usuarios para los requisitos mismos. Contamos con analistas de negocios en cada uno de esos equipos que en realidad modelaban el proceso de negocios, con los diagramas de actividad o diagramas de procesos de negocios, ayudando a desarrollar las historias de los usuarios más con los usuarios antes de que el resto del equipo los consumiera también.

Y luego, por supuesto, los desarrolladores que estaban construyendo el código de la aplicación por encima de eso. Y también trabajamos con, creo que fueron cuatro proveedores diferentes de integración de sistemas los que construyeron diferentes partes de la aplicación, así como un equipo construyó los servicios de datos, el otro construyó la lógica de la aplicación en un área, otro que tenía experiencia en otra área de negocios estaba construyendo la lógica de la aplicación en esa área. Así que tuvimos una colaboración total de personas que estaban trabajando en este proyecto. En ese en particular, teníamos 150 personas en tierra en el equipo y otros 150 recursos en alta mar en el equipo que estaban colaborando en sprints de dos semanas para expulsar esto. Y para hacerlo, debe asegurarse de que está disparando en todos los cilindros, y todos están bien sincronizados en términos de cuáles son sus entregas, y tenía esos reinicios frecuentes para asegurarse de que estábamos completando nuestras entregas de todos los artefactos necesarios al final de cada sprint.

Dr. Robin Bloor: Bueno, eso es impresionante. Y solo por un poco más de detalle sobre eso: ¿terminaron con un mapa MDM completo de lo que yo llamaría de toda el área de datos al final de ese proyecto?

Ron Huizenga: Teníamos un modelo de datos completo que se desglosó con la descomposición entre todas las diferentes áreas de negocios. El diccionario de datos en sí mismo en términos de definiciones completas se quedó un poco corto. Teníamos la mayoría de las tablas definidas; Teníamos la mayoría de las columnas definidas en cuanto a exactamente lo que significaban. Hubo algunos que no estaban allí y, curiosamente, muchos de esos eran piezas de información que provenían de los sistemas heredados donde, después del final del alcance del proyecto, eso todavía se estaba documentando como un conjunto de artefactos, por así decirlo, fuera del proyecto en sí, porque era algo que la organización debía mantener en el futuro. Al mismo tiempo, la organización adoptó un punto de vista mucho mayor sobre la importancia de la gobernanza de datos porque vimos muchas deficiencias en esos sistemas heredados y esas fuentes de datos heredadas que estábamos tratando de consumir porque no estaban documentados. En muchos casos, solo teníamos bases de datos que teníamos que realizar ingeniería inversa e intentar averiguar qué había allí y para qué era la información.

Dr. Robin Bloor: No me sorprende ese aspecto en particular. La gobernanza de datos es, digamos, una preocupación muy moderna y creo que realmente hay mucho trabajo que, digamos, debería haberse hecho históricamente sobre la gobernanza de datos. Nunca fue porque pudieras, de alguna manera, salirte con la tuya sin hacerlo. Pero a medida que el recurso de datos creció y creció, finalmente no pudo.

De todos modos, pasaré a Dez porque creo que he tenido mi tiempo asignado. Dez?

Dez Blanchfield: Sí, gracias. A través de todo esto, estoy observando y pensando para mí mismo que estamos hablando de ver a Agile usado en ira de muchas maneras. Aunque eso tiene connotaciones negativas; Lo dije de manera positiva. ¿Podría darnos un escenario de, quiero decir, hay dos lugares en los que puedo ver que este es un conjunto perfecto: uno son proyectos nuevos que solo deben hacerse desde el primer día, pero creo que invariablemente, en mi experiencia, a menudo el caso de que cuando los proyectos crecen lo suficiente como para que esto sea necesario de muchas maneras, hay un desafío interesante entre pegar los dos mundos, ¿verdad? ¿Puede darnos algún tipo de información sobre algunas historias de éxito que haya visto donde ingresó a una organización? Está claro que tienen un ligero choque de los dos mundos y que ha podido poner con éxito ¿Esto está en su lugar y reúne grandes proyectos donde de otro modo podrían haberse descarrilado? Sé que es una pregunta muy amplia, pero me pregunto si hay un caso de estudio en particular que pueda, de alguna manera, señalar dónde dijo, ya sabes, ponemos todo en su lugar y ha reunido a todo el equipo de desarrollo con ¿el equipo de datos y, de alguna manera, hemos abordado algo que de otra manera podría haber hundido el barco?

Ron Huizenga: Claro, y de hecho, el único proyecto que resultó ser un proyecto de tubería fue el que aludí donde mostré ese gráfico con los defectos antes y después de que el modelador de datos estuviera involucrado. Muy a menudo, y hay nociones preconcebidas, particularmente si las cosas se hacen girar desde una perspectiva puramente de desarrollo, solo los desarrolladores están involucrados en estos proyectos ágiles para entregar las aplicaciones. Entonces, lo que sucedió allí, por supuesto, es que se salieron de los rieles y sus artefactos de datos en particular, o los entregables de datos que estaban produciendo, no alcanzaron la marca en términos de calidad y realmente abordaron las cosas en general. Y a menudo existe esta idea errónea de que los modeladores de datos ralentizarán los proyectos, y lo harán si el modelador de datos no tiene la actitud correcta. Como digo, hay que perder el - a veces hay modeladores de datos que tienen esa actitud tradicional de guardián de puerta donde, "Estamos aquí para controlar cómo se ven las estructuras de datos", y esa mentalidad tiene que desaparecer. Cualquiera que esté involucrado en el desarrollo ágil, y particularmente los modeladores de datos, deben asumir un rol de facilitador para ayudar realmente a los equipos a avanzar. Y la mejor manera de ilustrar eso es mostrar rápidamente a los equipos cuán productivos pueden ser al modelar primero los cambios. Y de nuevo, por eso hablé sobre la colaboración.

Hay algunas cosas que podemos modelar primero y generar el DDL para enviar a los desarrolladores. También queremos asegurarnos de que no sientan que están siendo restringidos. Entonces, si hay cosas en las que están trabajando, permítales seguir trabajando en sus entornos limitados de desarrollo, porque allí es donde los desarrolladores están trabajando en sus propios escritorios u otras bases de datos para hacer algunos cambios donde están probando las cosas. Y colabore con ellos y diga: "Está bien, trabaje con eso". Lo incorporaremos a la herramienta, lo resolveremos y luego lo empujaremos hacia adelante y le daremos los scripts que puede implementar para actualizar su bases de datos para actualizarlas a lo que será la visión de producción real sancionada de lo que será a medida que continuemos avanzando. Y puedes cambiar eso de una manera muy rápida. Descubrí que mis días estaban llenos cuando solo iba y venía iterando con diferentes equipos de desarrollo, observando cambios, comparando, generando scripts, poniéndolos en marcha, y pude mantenerme al día con cuatro equipos de desarrollo con bastante facilidad una vez que logrado un impulso.

Dez Blanchfield: Una de las cosas que me viene a la mente es que, ya sabes, muchas de las conversaciones que mantengo a diario se refieren a este tren de carga que nos llega, más o menos, a la máquina -máquina y IoT. Y si creemos que ahora tenemos muchos datos sobre nuestros entornos actuales en la empresa, ya sabes, si dejamos de lado los unicornios por un momento donde sabemos que los Googles y los Facebook y los Ubers tienen petabytes de datos, pero En una empresa tradicional, todavía estamos hablando de cientos de terabytes y muchos datos. Pero hay un tren de carga que llega a las organizaciones, en mi opinión, y el Dr. Robin Bloor aludió a él antes, del IoT. Sabes, tenemos mucho tráfico web, tenemos tráfico social, ahora tenemos movilidad y dispositivos móviles, la nube ha explotado, pero ahora tenemos infraestructura inteligente, ciudades inteligentes y existe todo este mundo de datos que acaba de explotar.

Para una organización cotidiana, una organización mediana a grande que está sentada allí y ve venir este mundo de dolor y no tiene un plan inmediato en mente, cuáles son algunas de las conclusiones, en solo un par de oraciones, que usted pondría en cuanto a cuándo y dónde deben comenzar a pensar conversacionalmente sobre cómo implementar algunas de estas metodologías. ¿Qué tan temprano necesitan comenzar a planear casi sentarse y prestar atención y decir que este es el momento adecuado para implementar algunas herramientas y capacitar al equipo y tener una conversación de vocabulario sobre este desafío? ¿Qué tan tarde en la historia es demasiado tarde o cuándo es demasiado temprano? ¿Cómo se ve eso para algunas de las organizaciones que estás viendo?

Ron Huizenga: Diría para la mayoría de las organizaciones que si aún no lo han hecho y adaptado el modelado de datos y la arquitectura de datos con herramientas poderosas como esta, el tiempo que necesitan para hacerlo es ayer. Debido a que es interesante que, incluso hoy, cuando observa los datos en las organizaciones, tenemos tantos datos en nuestras organizaciones y, en términos generales, según algunas encuestas que hemos visto, estamos utilizando menos del cinco por ciento de esos datos de manera efectiva cuando miramos a través de las organizaciones. Y con IoT o incluso NoSQL, big data, incluso si no es solo IoT, sino solo big data en general, donde ahora estamos comenzando a consumir aún más información que se origina fuera de nuestras organizaciones, ese desafío es cada vez más grande todo el tiempo. Y la única forma en que tenemos la oportunidad de abordar eso es ayudarnos a comprender de qué se tratan esos datos.

Entonces, el caso de uso es un poco diferente. Lo que nos encontramos haciendo es que cuando miramos esos datos, los estamos capturando, necesitamos hacer ingeniería inversa, ver qué hay en ellos, ya sea en nuestros lagos de datos o incluso en nuestras bases de datos internas, sintetizar qué es decir, aplicarle significados y definiciones para que podamos entender cuáles son los datos. Porque hasta que comprendamos qué es, no podemos asegurarnos de que lo estamos usando de manera correcta o adecuada. Así que realmente necesitamos saber cuáles son esos datos. Y la otra parte de eso es que no lo haga porque puede, en términos de consumir todos estos datos externos, asegurarse de tener un caso de uso que admita el consumo de estos datos externos. Concéntrese en las cosas que necesita en lugar de simplemente tratar de sacar y utilizar las cosas que pueda necesitar más adelante. Concéntrese primero en las cosas importantes y, a medida que avance en ellas, comenzará a consumir e intentar comprender la otra información desde el exterior.

Un ejemplo perfecto de eso es que sé que estamos hablando de IoT y sensores, pero el mismo tipo de problema ha existido en muchas organizaciones durante muchos años, incluso antes de IoT. Cualquiera que tenga un sistema de control de producción, ya sea una compañía de tuberías, fabricación, cualquier compañía basada en procesos que tenga cosas en las que esté haciendo mucha automatización con controles y esté usando flujos de datos y cosas así, tiene Estos datos falsos de datos que están tratando de beber para descubrir, cuáles son los eventos que han ocurrido en mi equipo de producción para señalar: ¿qué sucedió y cuándo? Y entre este gran flujo de datos solo hay piezas específicas de información o etiquetas en las que están interesados ​​y que necesitan tamizar, sintetizar, modelar y comprender. Y pueden ignorar el resto hasta que llegue el momento de entenderlo realmente, y luego pueden expandir su alcance para atraer más y más dentro del alcance, si eso tiene sentido.

Dez Blanchfield: Sí, de hecho. Hay una pregunta que voy a plantear que vino de un caballero llamado Eric, y hemos estado hablando sobre eso en privado. Acabo de pedirle permiso, que me ha dado, para pedírtelo. Porque lleva muy bien a esto, solo para terminar, porque ahora vamos un poco con el tiempo, y se lo devolveré a Eric. Pero la pregunta de otro Eric fue: ¿es razonable suponer que los propietarios de una startup estén familiarizados y comprendan los desafíos únicos en torno a la terminología de modelado y, por lo tanto, o deberían entregarlos a otra persona para que los interprete? Entonces, en otras palabras, ¿una startup debe ser capaz y estar lista y dispuesta a enfocarse y cumplir con esto? ¿O es algo que probablemente deberían comprar y traer expertos a bordo?

Ron Huizenga: Creo que la respuesta corta es que realmente depende. Si se trata de una startup que no tiene a alguien interno que sea un arquitecto o modelador de datos que realmente entienda la base de datos, entonces la forma más rápida de comenzar es traer a alguien con experiencia en consultoría que esté muy versado en este espacio y pueda obtener ellos van. Porque lo que encontrará, y de hecho, hice esto en muchos compromisos que hice antes de pasar al lado oscuro en la gestión de productos, es que iría a las organizaciones como consultor, dirigiría sus equipos de arquitectura de datos, para que pudieran, de alguna manera, reenfocarse y entrenar a su gente sobre cómo hacer este tipo de cosas para que puedan sostenerla y llevar adelante la misión. Y luego continuaría con mi próximo compromiso, si eso tiene sentido. Hay muchas personas por ahí que hacen eso, que tienen una muy buena experiencia en datos que puede hacer que funcionen.

Dez Blanchfield: Ese es un gran punto para llevar y estoy totalmente de acuerdo con él y estoy seguro de que el Dr. Robin Bloor también lo haría. Particularmente en una startup, te enfocas en ser una PYME en el valor particular de la propuesta que estás buscando construir como parte de tu propio negocio de startup y probablemente no necesites ser un experto en todo, por lo que es un gran consejo. Pero muchas gracias, una presentación fantástica. Muy buenas respuestas y preguntas. Eric, te lo devolveré porque sé que probablemente nos hemos ido diez minutos con el tiempo y sé que te gusta quedarte cerca de nuestras ventanas de tiempo.

Eric Kavanagh: Eso está bien. Tenemos al menos un par de buenas preguntas. Déjame arrojarte uno. Creo que has respondido algunas de las otras. Pero una observación y una pregunta muy interesantes de un asistente que escribe, a veces los proyectos ágiles hacen que el modelador de datos no tenga la imagen completa a largo plazo, por lo que terminan diseñando algo en el sprint uno y luego tienen que rediseñar en el sprint tres o cuatro. ¿No parece esto contraproducente? ¿Cómo puedes evitar ese tipo de cosas?

Ron Huizenga: Es solo la naturaleza de ágil que no va a hacer todo absolutamente bien en un sprint dado. Y eso es en realidad parte del espíritu de agile, es: trabajar con él: vas a hacer prototipos donde trabajas en el código en un sprint determinado, y vas a hacer mejoras en él. Y una parte de ese proceso es cuando estás entregando cosas que el usuario final lo ve y dice: "Sí, eso está cerca, pero realmente necesito que haga esto un poco más también". Así que eso no solo impacta el diseño funcional del código en sí, pero a menudo necesitamos modificar o agregar más estructura de datos debajo de estas ciertas cosas para entregar lo que el usuario quiere. Y eso es todo un juego justo y es por eso que realmente quieres usar las herramientas de alta potencia porque puedes modelar y hacer ese cambio muy rápidamente en una herramienta de modelado y luego generar el DDL para la base de datos en la que los desarrolladores pueden trabajar para entregar eso cambia aún más rápido. Está evitando que tengan que hacer esa codificación manual, por así decirlo, de las estructuras de datos y dejándoles concentrarse en la lógica de programación o aplicación en la que son más competentes.

Eric Kavanagh: Eso tiene mucho sentido. Tuvimos un par de otras personas simplemente haciendo preguntas específicas sobre cómo todo esto se relaciona con la herramienta. Sé que pasaste algún tiempo revisando ejemplos y has estado mostrando algunas capturas de pantalla sobre cómo realmente implementas algunas de estas cosas. En términos de todo este proceso de sprint, ¿con qué frecuencia ves eso en juego en las organizaciones versus con qué frecuencia ves procesos más tradicionales en los que las cosas simplemente, más o menos, avanzan y toman más tiempo? ¿Qué tan frecuente es el enfoque estilo sprint desde su perspectiva?

Ron Huizenga: Creo que lo estamos viendo más y más. Sé que, diría, probablemente en los últimos 15 años en particular, he visto mucha más adopción de personas que reconocen que realmente necesitan adoptar una entrega más rápida. Así que he visto a más y más organizaciones subirse al tren ágil. No necesariamente del todo; pueden comenzar con un par de proyectos piloto para demostrar que funciona, pero hay algunos que todavía son muy tradicionales y siguen el método de la cascada. Ahora, la buena noticia es, por supuesto, que las herramientas funcionan muy bien en esas organizaciones también para ese tipo de metodologías, pero tenemos la adaptabilidad en la herramienta para que aquellos que saltan a bordo tengan las herramientas en la caja de herramientas en las yemas de sus dedos Cosas como comparar y fusionar, cosas como las capacidades de ingeniería inversa, para que puedan ver cuáles son las fuentes de datos existentes, para que realmente puedan comparar y generar los scripts incrementales DDL muy rápidamente. Y a medida que comienzan a aceptar eso y ver que pueden tener la productividad, su inclinación a adoptar ágil aumenta aún más.

Eric Kavanagh: Bueno, esto es genial, amigos. Acabo de publicar un enlace a las diapositivas allí en la ventana de chat, así que échale un vistazo; es un poquito Bitly ahí para ti. Tenemos todos estos webcasts para verlos más tarde. Siéntase libre de compartirlos con sus amigos y colegas. Y Ron, muchas gracias por tu tiempo hoy, siempre eres agradable de tener en el programa, un verdadero experto en el campo y es obvio que sabes lo que haces. Entonces, gracias a ti y gracias a IDERA y, por supuesto, a Dez y a nuestro propio Robin Bloor.

Y con eso vamos a despedirnos, amigos. Gracias nuevamente por su tiempo y atención. Apreciamos que te quedes por 75 minutos, es una buena señal. Buen espectáculo chicos, hablaremos la próxima vez. Adiós.