seminario en línea Datos, explorados n.º 1 – El gran debate sobre la arquitectura del medallón

Gracias a todos por participar. Para mí es un placer ser el anfitrión.

Soy el evangelista jefe de Actian. Me llamo Ole Olesen-Bagneux y, en este gran debate sobre medallones que tenemos, entrevistaré a Piethein Strengholt, autor de a ver si lo encuentro aquí, Building Medallion Architectures. Y también nos acompaña Martin, que nos planteará algunos retos.

Chesbrough, ¿se pronuncia correctamente Chesbro? Sí, perfecto. Chesbrough Chesbrough Y, de hecho, él fue en parte el motivo por el que estamos teniendo este debate ahora mismo, porque yo estaba escribiendo sobre arquitecturas medallón en LinkedIn y la publicación se volvió viral porque toqué un punto sensible al decir que no creo que las arquitecturas medallón vayan a desaparecer nunca.

Independientemente de lo modernas que sean nuestras arquitecturas de datos, dispondremos de arquitecturas por capas para preparar los datos para su consumo analítico. Así que, sin más preámbulos, el orden del día de esta reunión, o de este evento, es que voy a entrevistar a Piethein. He preparado algunas preguntas detalladas sobre su nuevo libro, recién publicado por O'Reilly, Building Medallion Architectures.

Es un gran libro y eso llevará aproximadamente entre 20 y 25 minutos , en los que aprenderás todo sobre la arquitectura de medallones. Y haré algunas preguntas críticas. Pero la idea es que Martin se una al debate en unos 20 o 25 minutos.

Ha preparado una serie muy detallada y precisa de puntos críticos que le gustaría examinar sobre la arquitectura del medallón y los pros y los contras de esta arquitectura. Así que entraremos más en un debate más adelante en la conversación. Y, obviamente, todos los participantes en la llamada son bienvenidos a hacer preguntas.

Bueno, sin más preámbulos, Martin, creo que en este momento... Sí, solo iba a decir que las instrucciones para los participantes son que deben enviar sus preguntas a través del cuadro de preguntas y respuestas que hay en la parte inferior de la ventana de Zoom, y luego las recogeremos cuando entremos en el debate. ¿Es esa la idea? Exactamente.

Sí. Perfecto. Gracias.

En ese momento, apagaré mi vídeo, os dejaré hacer vuestra entrevista y volveré más tarde, a menos que me vaya a dormir. Por favor, manteneos despiertos. Tomad un café caliente.

Buen café, fuerte, buen café, fuerte, por allí. Ya tengo mi café. Lo siento.

Perfecto. Muchísimas gracias. De verdad que quiero, por cierto, la razón de la broma es que para mí es muy temprano y acabo de bajar del avión.

No es por aburrimiento ni nada por el estilo, de hecho me fascina esta conversación, así que adelante. No sé cómo agradecerte que estés aquí, Martin, muchas gracias. Y por favor, no te duermas.

Te necesitaremos para el debate de más tarde. De acuerdo Peter, he preparado muchas preguntas. Como viste en la preparación de esta reunión, he vuelto a leer tu libro, lo he leído con mucho, mucho cuidado.

Así que preparé muchas preguntas diferentes, pero quiero mantener un nivel relativamente alto. Algunas de ellas entrarán en un nivel de detalle que también coincide con el nivel de detalle de su magnífico libro. Pero para las personas que están en la llamada, en el seminario en línea, comencemos con la pregunta más obvia.

¿Por qué quisiste escribir este libro, Peter? ¿Qué te motivó a escribirlo y por qué? Sí, tal vez antes de responder, permíteme primero presentarme rápidamente.

Sí, obviamente. Soy el autor, por supuesto, de este libro estaba construyendo arquitecturas de medallones y seguía toda la conversación. También escribí otro libro titulado Gestión de datos a escala.

Algunas personas que veo en el chat quizá me conozcan de Microsoft, donde trabajé como director de datos en los Países Bajos. Trabajé durante mucho tiempo para ABN AMRO. Recientemente me incorporé a otra empresa llamada NN Group, una gran organización aseguradora nacional.

Volviendo a tu pregunta, ¿por qué escribir un libro sobre arquitecturas medallianas? Este tema me fascinaba cuando trabajaba en Microsoft. Muchos clientes acuden a Microsoft porque desean sacar más partido a los datos, ¿verdad?

Um, y entonces la respuesta suele ser, bueno, si quieres empezar con los datos y generar valor, lo primero que tienes que hacer es crear una plataforma. Es decir, un servicio de datos, un servicio de plataforma. Y entonces surge la siguiente pregunta.

Entonces, ¿qué debo hacer? Bueno, desarrollar esa arquitectura. Y luego, la mejor práctica que se suele proporcionar es, bueno, deberías plantearte desarrollar una arquitectura medalliana.

Pero, sinceramente, a menudo ahí se acaba la orientación. Se ofrece a las empresas una orientación de alto nivel sobre en qué consisten estas capas. Hay bronce, plata y oro, y hay una orientación prescriptiva de alto nivel.

Pero, en esencia, todo se reduce a crear los matices adecuados. Y sí, también hay empatía, y a la gente le cuesta mucho interpretar estos patrones de diseño de forma precisa. Al ver que faltaba orientación en este ámbito, me animé a escribir un libro.

Y al escribir ese libro, antes de empezar a escribir, entrevisté a muchos lectores potenciales para saber qué querían que les contara. Y la diferencia, la dificultad, es que hay muchas expectativas diferentes. Y también es una arquitectura muy subjetiva.

Así que lo hice de esta manera. Hay una parte más teórica. ¿Qué es el medallón y de dónde viene exactamente, las capas, etcétera?

Luego hay un tutorial, un manual que te guía de manera prescriptiva a través del diseño real con fragmentos de código, capturas de pantalla, instrucciones y cómo construir exactamente esta arquitectura de medallón. Luego hay estudios de casos, y allí trabajo con diferentes clientes de diferentes industrias y tamaños. Así que aprenderás por qué lo han implementado y cómo han diseñado sus arquitecturas de medallón.

Y, por último, avanzo rápidamente e intento conectar los puntos con otras áreas de la gestión de datos y la IA. Así es, a grandes rasgos, cómo se ha estructurado el libro. Sí, me encanta esa estructura.

Al leer el libro, es como si te dieran una introducción sobre cómo se debe hacer, y luego pasáramos a la práctica. A continuación, ves cómo lo han hecho otros. Y, finalmente, el libro se disuelve en un patrón más complicado, con múltiples arquitecturas de medallones que hacen cosas diferentes y se escalan de manera diferente.

Y yo, yo prefiero totalmente esa última parte. Y supongo, ya sabes. Además, obviamente Piethein, siento no haberte dado una presentación más formal.

Doy por hecho que todos los que están en la llamada lo conocen.

Obviamente, no todo el mundo te conoce, pero eres un autor muy conocido, autor de O'Rielly, con muchos lectores. Bien, profundicemos un poco en la arquitectura del medallón en sí. ¿Cuáles son las tres capas, bronce, plata y oro, explicadas brevemente?

Sí, brevemente, es importante dejar claro desde el principio que estas capas deben interpretarse como capas lógicas. Es un patrón de diseño lógico. A menudo veo un error entre las empresas con las que he trabajado, que las ven como capas físicas.

Entonces esto está mal. Estas son capas lógicas, cómo organizar lógicamente tus datos. Así que supervisan una arquitectura de extremo a extremo, pero luego, dentro de estos límites lógicos, se alinean con ciertas responsabilidades y preocupaciones.

En la primera capa, veo que se trata principalmente de capturar los datos, los datos sin procesar, validar los datos, archivarlos en la siguiente capa, en plata, principalmente. Así que se trata de estandarizar los datos, limpiar los datos, corregir los datos, ajustar ligeramente los datos. Pero ahí ya empiezan a surgir muchos debates.

¿Necesita combinar y unir esos datos de sistemas de origen ya existentes? ¿Crea productos de datos, por ejemplo, en esa capa? Por lo tanto, depende en gran medida.

Sí. Y luego, en oro, esa capa que veo ahí, es donde se adaptan los datos al propósito. Es decir, para su consumo final.

En cuanto al uso comercial de los datos, ahí, de nuevo, bueno, hay mucho debate. ¿Se necesita una capa de integración clásica? Si hay intereses que se solapan en diferentes grupos de usuarios, ¿o se mantienen separados?

¿Cuál es el papel de los productos de datos y cuáles son estos densos? Una vez más, hay muchos debates en estas capas. Pero así es más o menos como yo lo veo.

Sí, sí, por supuesto. También queda muy claro cuando lees el libro. Para aquellos que no conocen en profundidad la arquitectura medallón, solo para contextualizar, cuando hablas de que estas capas son lógicas y no físicas, ¿qué significa eso concretamente?

¿Qué tipo de arquitectura es el resultado de eso? ¿Está clara la pregunta? Sí, la pregunta está clara.

Por lo tanto, la implementación física podría diferir mucho en comparación con la abstracción lógica, por así decirlo, de cómo organizar los datos en estas tres capas. Así que, por ejemplo, se podría optar por un patrón, digamos que se han implementado tres capas físicas. ¿Verdad?

Otro patrón de diseño podría ser, por ejemplo, ahora tengo más capas físicas y desacoplo dentro de estas capas, de nuevo, ciertas preocupaciones. Así que la primera etapa es, por ejemplo, para el bronce, capturar esos archivos sin procesar y mantenerlos en el formato de archivo original.

Luego, todavía dentro del bronce, se copia a otra capa interna y se transforma la información al formato de datos. Quizá entonces, de nuevo, se copie a otra capa donde se fusiona con datos ya preexistentes, que todavía son crudos y técnicos, pero en esa etapa. Así que este es un ejemplo de tres capas físicas dentro de una capa vertical.

Sí. Gracias por señalarlo. Eso es exactamente lo que estaba pidiendo, porque creo que al menos parte de la arquitectura del medallón se calienta mucho porque la gente realmente no piensa en esa distinción entre la capa lógica y la física.

Porque si tú, si tú pones, y yo debería hacerte preguntas, pero yo solo dije, ¿no crees que, hasta qué punto estarías de acuerdo con esa suposición de que la gente malinterpreta esa parte, pero entonces, sí, Para mí, la motivación para escribir ese libro, participé en muchísimas conversaciones con clientes, mientras trabajaba en Microsoft, en las que la gente interpretaba la arquitectura medalliana como simplemente tres capas físicas. Sí, realmente tuve que abrirles los ojos. Bueno, no, se trata de desacoplar las preocupaciones.

Y, por lo tanto, puedes tener tantas capas como quieras. Déjame hacerte un par de preguntas sobre las capas en sí. En primer lugar, ¿por qué?, tengo una pregunta para cada capa.

¿Por qué no deberías consultar la capa de bronce? ¿Por qué no deberías consultarla? Quiero decir, mucha gente lo está pensando, pero ¿por qué no deberías hacerlo?

Podría hacerlo, pero es algo rudimentario y, por lo tanto, quedaría muy ligado a la estructura original de los sistemas fuente que tiene, digamos, a la izquierda de su arquitectura. Así que, si estas estructuras del lado del sistema fuente cambian repentinamente, eso podría causar efectos disruptivos en la estructura de esa capa de bronce. Si empieza a poner en práctica informes y agentes en su capa de bronce, le resultará difícil mantenerse al día con todos esos cambios.

De nuevo, una buena práctica sería desvincularse de la estructura de los sistemas de origen y pasar a la siguiente capa que se ocupa de este asunto. Así que dos preguntas sobre la capa plateada se fusionaron. En primer lugar, ¿por qué la capa plateada es sencilla?

Usted lo llama simple a lo largo del libro. Y en segundo lugar, ¿por qué principalmente a los ingenieros de ML e IA les gusta, por qué quieren consultar la capa plateada? Yo digo simple porque recomiendo no empezar a combinar, mezclar e integrar sistemas de código abierto.

Por lo tanto, las preocupaciones deben adaptarse en gran medida a lo que se encuentra en el nivel del sistema de origen. En mi opinión, hay que limpiar y corregir los datos en ese nivel. Es decir, en el nivel del sistema de origen.

Porque sigue conservando el contexto auténtico. Es ideal para crear agentes operativos que construyan puertos B operativos, ya que el contexto es muy similar al que se vería en el sistema de origen. En mi opinión, si en esa fase ya se empieza a combinar e integrar datos de distintos sistemas de origen, es necesario ajustar el contexto.

Y sí, perderás el contexto auténtico o el contexto original tal y como lo esperarías del lado del sistema fuente. Y eso lo hace difícil. Entonces, sí, si quieres poner en práctica o crear un informe operativo, necesitas revertirlo al contexto original, por así decirlo.

No es lo ideal. Por lo tanto, recomendaría a los oyentes que dejen esa preocupación para más adelante. Sí.

Y, de nuevo, aquí es donde se ven muchos También comento, Adelante, por favor. Lo siento. Sí, algunas personas abogan, por ejemplo, por aplicar fallos de datos dentro de esa capa plateada, o ya en ese momento, combinar y los sistemas de fuentes cruzadas comienzan a integrar sus datos.

Sí, depende, de nuevo, así que fíjate en tus propios requisitos, en tus propias necesidades. No está mal. No está bien.

Pero sí, estoy a favor del patrón de diseño que hemos discutido. Así que sí, aparca la integración de sistemas de código cruzado y aplázala hasta el último enlace al oro. Sí.

De acuerdo. De acuerdo. Bueno, no quiero decir que estoy de acuerdo, porque no estoy seguro de estarlo, pero, en cualquier caso, estoy de acuerdo con lo que argumentas en el libro.

Um, entonces, sobre la capa dorada, mi pregunta sobre la capa dorada es que dices que es extremadamente complicada, especialmente en comparación con la capa plateada. ¿Por qué es tan complicada la capa dorada? Sí, porque a menudo veo que hay preocupaciones contradictorias.

Entonces, usted querría armonizar los datos, tal vez a nivel empresarial o para un ámbito determinado, a fin de garantizar la coherencia de los datos en los diferentes casos de uso. Luego está la necesidad de hacer que los datos sean altamente específicos para lo que requiere el caso de uso. Así que, sí, de nuevo, se encuentra ante un dilema.

Esas preocupaciones no son fáciles de conciliar. Luego está la necesidad de distribuir datos a través de diferentes dominios, diferentes equipos y consumidores de datos externos. Dependen de datos estables y altamente reutilizables.

Una vez más, se observa esa preocupación. Por lo tanto, cuando se tiene un caso de uso y se desea ser flexible y realizar muchos cambios de forma espontánea, eso contrasta con la necesidad de proporcionar datos reutilizables y altamente fiables a diferentes consumidores. Por lo tanto, a menudo veo que, dentro de Gold, se empieza a separar de nuevo estas diferentes preocupaciones y, por lo tanto, se pueden ver, una vez más, diferentes capas físicas dentro de esa única capa Gold.

Por supuesto. Pasemos ahora a la parte del libro que más me gustó, y creo que tendremos tiempo para hablar de ello, que es la cuarta parte del libro, y ahí es donde realmente te abres y porque creo que otra cosa que a la gente no le gusta de la arquitectura de medallones es que la ven como una especie de autopista de transporte de datos para toda la empresa a la que todos los casos de uso tienen que ajustarse y pasar por ella para proporcionar casos de uso para el análisis, ¿verdad? Y lo que realmente me gusta de la cuarta parte de tu libro es que realmente te abres y dices, al igual que en tu primer libro, Data Management at Scale, que proporcionas esta perspectiva de flexibilidad y escalabilidad, que son realmente fundamentales para cualquier arquitectura de datos moderna, incluso para la arquitectura de software, ¿verdad?

Así que realmente te abres y dices: «Vale, podemos tener múltiples arquitecturas de medallones en una empresa». Y, de hecho, incluso admites que la mayoría de las empresas tienen múltiples arquitecturas de medallones. Por lo tanto, una de las capas que más me interesa en ese contexto es la capa de diseño y distribución de productos, como tú la llamas.

Así que voy a hacerte preguntas muy detalladas. Espero que puedas recordar todo esto, Piethein. ¿Podrías darme más detalles sobre esa capa?

Porque creo que es una capa muy prometedora. Sí. Volviendo a tu punto anterior, creo que no es una suposición.

Cuando seas grande, seguro que tendrás muchas de estas arquitecturas medallón. Y el diseño de estas arquitecturas variará según el tamaño, la cantidad de sistemas de origen y si te enfocas más en los proveedores o en los consumidores. Por eso, en el libro defino diferentes arquetipos según el tipo de dominio y la mejor forma de organizarte y alinearte, incluso con estas diferentes capas.

Pero en esta arquitectura multimedallón, cuando se empieza a compartir datos de forma fluida, se quiere contar con datos de alta calidad, reutilizables y estables. Y por lo tanto, en mi opinión, el modelo de datos se convierte en un modelo de interfaz. Y ahí es donde entra en juego la capa de productos de datos.

Por lo tanto, para proporcionar datos sólidos y estables, entran en juego muchas directrices de diseño de modelos de datos, como la forma de tratar los datos de referencia. Por poner un ejemplo sencillo, imagina que tienes varios dominios, varias de estas arquitecturas Medallian, y que todas ellas, de forma aislada, reestructuran sus estructuras de datos y plantean estos problemas de datos. Pero no te ajustas a ningún estándar de datos ni a ningún dato de referencia.

Al final, a los consumidores les resultará muy difícil combinar los datos fácilmente , ya que tendrán que lidiar con diferentes valores de referencia locales y tipos de datos no conformes, por ejemplo. Por lo tanto, en mi campo, se debe proporcionar mucha orientación sobre el modelado de datos a todos estos equipos diferentes. Así, modelan y reformulan sus datos de una manera determinada.

Todos estos equipos diferentes pueden interpretar fácilmente esos datos, utilizarlos, combinarlos, etc. Sí, como has aprendido en el libro, es bastante extenso. Por lo tanto, debería haber mucha orientación al respecto.

No, pero, de hecho, yo considero que esta capa es realmente importante para las personas que desean impulsar enfoques más descentralizados para las arquitecturas de datos en su conjunto. ¿Verdad? Sí.

Quizás, quizás, creo que tenemos tiempo para una pregunta más, porque antes de que le pase el micrófono a Martin, mantendré mi cámara encendida y tal vez diga una o dos palabras, pero realmente quiero dejar que Martin responda a sus preguntas. Son excelentes. Así que una última pregunta para mí es esta: tienes un concepto que llamas «malla medallón».

Podemos hablar brevemente de eso antes de que le pase el micrófono a Martin. ¿Qué es la malla medallón? ¿Conoces la malla de datos?

Eh, ¿verdad? Entonces, y la arquitectura federada distribuida, diferentes equipos, todos ellos operan sus propias, digamos, pequeñas arquitecturas de datos, y distribuyen los datos a través de cuando se estratifican los datos según la estratificación de medallones que acabamos de comentar. Y todos estos equipos lo hacen de forma similar.

Esto es lo que yo llamo una arquitectura de malla medallón. Pero lo importante aquí, y creo que es que no se trata tanto de la estratificación en sí misma. Creo que es más a nivel empresarial que de estratificación.

Es un patrón de comunicación. Y a menudo veo que las cosas salen mal porque los equipos interpretan entre sí cómo se realiza la estratificación dentro de estas diferentes arquitecturas. Por lo tanto, es mejor recomendar utilizar la estratificación de medallones como patrón de comunicación.

Así que todos estos equipos se adhieren más o menos a la misma forma de organizar sus datos dentro de estas diferentes arquitecturas, lo que facilita la distribución y el intercambio de datos entre estas pequeñas arquitecturas. Creo que es una declaración maravillosa para pasarle el micrófono a Martin. Martin y yo seguimos despiertos.

¿Ha funcionado el café? Sí, sí, estoy aquí. Maravilloso, Martin.

Solo acechando en segundo plano. Bueno, pues eso fue, fue una serie de entrevistas estupenda. Una serie de preguntas estupendas.

En primer lugar, quería decir: «Sí, Ole, muchas gracias por invitarme». A modo de introducción, permítanme decir que es un honor para mí estar aquí en presencia de dos autores de O'Reilly. Como saben, es un gran honor y todos ustedes son personalidades destacadas en el mundo de los datos.

Eh, supongo que, ya sabes, estoy aquí como arquitecto de datos trabajando para una pequeña consultoría de ingeniería en Melbourne, Australia. Y voy a asumir el papel de representar al arquitecto de datos profano en todo esto. Sí.

Espero poder responder adecuadamente a las preguntas que puedan surgir. Para contextualizar, quería comenzar mi intervención diciendo que, cuando Ole elogió el libro de Piethein en LinkedIn, le dije medio en broma en un comentario: «Creo que tengo que tener una conversación seria contigo. Ole, respeto tu opinión y espero que puedas convencerme de lo contrario».

Pero las arquitecturas de medallón han sido mi mayor frustración como arquitecto de datos durante unos 20 años. Así que eso es para poner esto en perspectiva. Y había un punto serio en esto, así como una especie de, ya sabes, un empujón para espero poder llamarte amigo, ¿sabes?

Eh... y supongo que aquí es donde creo que entra el libro de Piethein, porque entonces envié eso sin haber leído el libro de Piethein, ¿verdad? Así que pensé que sería mejor leer el libro para que, ya sabes, una vez que empezaras a morder el anzuelo y dijeras: «Sí, será mejor que debatamos sobre esto». Eh... y me pareció un libro excelente.

En realidad, como tú dices, no creo que haya muchos libros que expliquen las arquitecturas de medallón. Y, efectivamente, surgió del mundo de Databricks y del mundo de Lakehouse. O, en realidad, probablemente, hablando más estrictamente, del mundo de los lagos de datos.

Y creo que ese ha sido uno de los retos, que cada persona lo interpreta de manera diferente . Y realmente no hay un foro para debatirlo. Y este libro nos ofrece un foro para debatirlo.

Ahora, mientras te escucho, Ole Piethein, se me ocurre que, en realidad, otra posible mejora del libro sería, ya sabes, incorporar algunas de las diferentes formas en que se utiliza el medallón y casi como tener un enfoque de, ¿cómo se llama?, patrones y antipatrones. Sí. Sí.

Porque estoy seguro de que probablemente podríamos estar de acuerdo en algunos de los antipatrones que vemos. Sí. Pero, en fin, iba a centrar mi intervención, a modo de introducción, en tres áreas de debate.

Y, sobre todo, se trata más de mirar hacia adelante que de mirar hacia atrás. ¿Verdad? Por lo tanto, en lugar de explicar cómo hemos llegado hasta aquí, algo que, en mi opinión, Piethein hace muy bien en su libro, vamos a empezar a pensar en hacia dónde vamos a partir de ahora.

Sí. Teniendo en cuenta que, como sabemos, las organizaciones se enfrentan, en mi opinión, a retos mayores que nunca para intentar encontrar la manera de hacer avanzar sus arquitecturas. Y creo que parte de esos retos son, curiosamente, que la palabra «datos» ha cobrado más importancia porque se asocia con la IA.

Incluso lo veo en mi pequeña consultoría de ingeniería, donde de repente tengo un montón de ingenieros de software o ingenieros que quieren crear aplicaciones de IA y luego se preguntan: «Vale, ¿cómo voy a conseguir los datos para ello?». Así que necesitan alguna fuente. Permítanme resumir mis tres argumentos para empezar.

Así que mi primer argumento fue una crítica general a los arquitectos por capas, a las arquitecturas por capas en general, no tenía nada que ver con Medallion. Y, de hecho, estoy de acuerdo contigo, Ole, en el sentido de que creo que la arquitectura por capas nunca pasará de moda. Pero supongo que lo que quiero decir es que, si nos fijamos en el espacio de las aplicaciones, recuerdo, ya sabes, tengo la edad suficiente para recordar las arquitecturas cliente-servidor, y luego pasamos a tres capas.

Ya sabes, tienes una interfaz de usuario, una lógica de negocio y una capa de almacenamiento de datos o algo así. Y eso sigue existiendo. Si miro los proyectos de GitHub de la mayoría de la gente, o los proyectos de Git que creamos como Everest, probablemente habrá tres capas dentro de la estructura de archivos.

Sí. Y puedes verlos, claramente te llaman la atención. Pero curiosamente, a pesar de eso, aunque ya está integrado, creo que como desarrolladores de aplicaciones, hemos ido más allá.

Hemos dicho, vale, sí, sí, mira, tenemos las tres capas. Um, ya sabes, no nos importan porque lo que nos importa es quizá la arquitectura hexagonal, la arquitectura limpia, quizá, ya sabes, estamos más interesados en algunas de, digamos, las patentes de aplicaciones empresariales de Martin Fowler, las patentes de aplicaciones de arquitectura empresarial, o estamos mirando un estilo de arquitectura de aplicaciones bien diseñado de AWS o Azure. Y luego hay un debate sobre, ya sabes, todos estos matices del patrón de arquitectura, que luego, para resolver el problema, donde las conversaciones, en cierto modo, han ido más allá de la capa.

¿Verdad? No es una conversación de «o esto o lo otro». Es un «sí y», ¿verdad?

Y esta es, creo, la conversación que debemos mantener en el ámbito de los datos, que es ser y creo que usted lo insinúa en su libro, Piethein, donde aborda el primero de los tres ejemplos, que son ejemplos realmente buenos. Creo que vale la pena que cualquiera que lea el libro repase los casos prácticos, porque son ejemplos reales de empresas que están utilizando la arquitectura de medallones. Sí.

Pero creo que detrás de esos casos prácticos hay una especie de debate sobre el «sí» y el «no». Sí. Sí, tenemos la medalla, pero, perdón, no «pero», queremos hacer más y queremos aportar más valor, ¿y cómo lo vamos a hacer? Sí.

Así que ese es más o menos el número de mercado. Fue muy agradable. Lo que más me gustó de entrevistarlos fue que utilizaban la arquitectura mendeliana, pero también se dieron cuenta rápidamente de que necesitábamos complementarla con muchas más cosas. Así que está la arquitectura basada en eventos.

Nos gustaría realizar la integración de aplicaciones y crear aplicaciones con un uso intensivo de datos. ¿Cómo se conciliaría eso con la arquitectura de Medallian? ¿Dónde trazamos los límites entre una aplicación y la distribución de datos entre diferentes equipos?

Sí, fue una conversación muy agradable la que tuve con ellos. Sí, perfecta. Quiero decir, y esa es precisamente la aplicación que yo, esa es la conversación que tengo con las empresas, que es, vale, puede que tengas configurado Databricks o Snowflake o Azure, pero entonces, ya sabes, ¿cómo vas a integrar eso de nuevo en la capa de aplicación?

Porque ahí es donde se obtiene valor de los datos, porque se han tomado decisiones y se están llevando a cabo esas decisiones. Sí. Y sí, tengo un favorito, como el patrón inverso.

Bueno, sí, a veces es ETL inverso, pero es solo la integración, por así decirlo, de la toma de decisiones, llamémosla la parte de la toma de decisiones y la parte de la acción. Sí. Sí.

Eh, ese fue mi primer argumento. El segundo argumento era en realidad el argumento de la IA. Y esto nos lleva a lo que estábamos hablando un poco al principio.

Y esto se debe al hecho de que creo que, en muchas empresas que veo ahora, los responsables de datos están ganando protagonismo en el ámbito tecnológico, porque, de repente, el director ejecutivo quiere que se haga algo desde el punto de vista de la inteligencia artificial. Quieren, no sé, agentes de inteligencia artificial o algo así, ¿verdad? Y ahí es donde surge la primera pregunta, de hecho, lo dije antes, ya sabes, el desarrollador de aplicaciones dice: ¿de dónde saco los datos?

¿Verdad? ¿Cómo puedo, ya sabes, me has dicho que tengo que hacer un estante. ¿Cómo construyo ese estante?

¿Verdad? ¿De dónde viene el contexto de la organización? ¿Verdad?

El contexto se almacena en algún lugar dentro de la capa de datos. Así que, en lugar de tener esto, ya sabes, digamos, un monolito situado en el sitio y gestionado por un número seleccionado de equipos de datos, parece que se está integrando en la arquitectura de aplicaciones de la empresa. Y creo que eso nos aleja de una estructura puramente medallón y nos lleva a pensar más en cómo los planos operativos y analíticos de una empresa comienzan a integrarse para servir a la IA.

Y luego, el tercer argumento es, ya sabes, el viejo argumento de la alineación de productos de datos de malla de datos. Y, de hecho, tú abordaste esto en el libro cuando finalmente me decidí a leerlo. Así que, en la cuarta parte del libro, tienes un creo que es el capítulo, ¿cuál es?, ¿el 12, el 13 o algo así?

Eh, 12, no, creo que es 13. No, no, 13 es la IA generativa, y quizá 11 es la escalable, donde se empieza a hablar de la malla de datos. Y creo que empiezas a poner el dominio y la estructura federada en primer plano y la estructura en capas en segundo plano, en cierta medida, en realidad estás respondiendo a mi pregunta, porque de repente estás diciendo, ya sabes, estás diciendo, bueno, tal vez uno de los futuros que podemos contemplar es donde el producto de datos y un tipo políglota de arquitectura de modelado de datos empiezan a dominar dentro de las organizaciones.

Y, de hecho, hasta cierto punto, eso es lo que se ve prácticamente en muchas grandes organizaciones. Sí. Así que esos son mis tres argumentos y están centrados principalmente en el futuro, ya sabes, así que es casi como, ya sabes, vale, queremos aprender sobre medallones porque creo que es una parte importante de nuestra historia, pero no creo que queramos excedernos con los medallones.

Por supuesto. Sí. Creo que, reflexionando, en el último capítulo, donde introduje la parte sobre la IA, probablemente ahora lo reescribiría completamente de una manera diferente, sabiendo que las cosas cambian a una velocidad vertiginosa.

Pero uno de los descubrimientos que hice, y ya hablamos brevemente sobre esto, es que aquí, en la organización en la que trabajo actualmente, ya estamos experimentando con agentes. Tenemos un buen número de agentes en producción, pero vemos dos tipos de agentes, agentes que están más orientados a los datos, yo los llamo así. Por lo tanto, bots de chat comunes o un agente que, no sé, rastrea una base de datos o realiza búsquedas o analiza un perfil histórico, por ejemplo, o hace Customer 360.

Allí, creo que la arquitectura medalliana podría tener sentido. Así que hemos establecido una dirección en la que prevemos agentes y alrededor del tiempo que se sitúan cerca de la arquitectura mendeliana, pero también vemos agentes que probablemente se sitúan cerca de los sistemas fuente operativos, con el, dentro del dominio de la aplicación. Y a estos los llamamos agentes alineados operativamente.

Y esas son sensibles al contexto y operan con baja latencia y altos volúmenes. Y ahí, creo que necesitamos tener un tipo diferente de arquitectura. Así que probablemente necesites tener almacenes de datos operativos o aplicaciones intensivas en datos.

Entonces, otros patrones y este es un riesgo que veo. Y, y tal vez sea bueno que hayas mencionado esto y deberíamos quitar esto que tal vez los lectores o oyentes podrían interpretar. Bueno, la arquitectura del medallón lo hace todo, y creo que este es un argumento falso.

Cubre un cierto ámbito, pero hay que complementarlo con las cosas que ya has mencionado. Sí. De acuerdo.

No, eso tiene mucho sentido. Bueno, una de las cosas de las que también me di cuenta mientras pasabas por esto es que, ya sabes, la mayoría de la gente, la mayoría de las implementaciones que he visto es que dentro de la capa plateada, hay una combinación de contextos. Quiero decir, tal vez tú lo llames un antipatrón, pero yo he visto más a menudo, ya sabes, la combinación de diferentes contextos.

¿Y dirías que eso es un antipatrón? Sí, creo que es una oportunidad perdida si no se conserva el contexto auténtico en forma historizada. Muchos casos de uso requieren que los datos auténticos se historicen en una dimensión que cambia lentamente porque se desea entrenarlos para el aprendizaje automático operativo, por ejemplo, o para informes operativos.

Si empiezas a combinar e integrar demasiado rápido, pierdes esa oportunidad, lo cual, por supuesto, se puede solucionar con un almacén de datos operativos adicional. Descargas los datos a otra arquitectura. Pero creo que ahí hay una oportunidad, y no, seguro que no satisfará todas estas necesidades orientadas a las operaciones, pero podrías utilizarlo, eh, en ese sentido, y por lo tanto propongo aplazar esa acción de combinar e integrar sistemas de fuentes cruzadas a la última capa.

Pero tienes razón, veo que muchas organizaciones que ya están en Silver empiezan a combinarlo, fusionarlo e integrarlo. También se pueden hacer ambas cosas, ¿verdad? Así que puedes crear ese tipo de conjunto de datos más operativo y conservarlos en tu Silver, y además de eso tienes esa integración, la integración clásica.

Está bien. Al menos te lo llevas y abordas estas preocupaciones. Así es.

Hace que parezca que es especialmente, ya sabes, creo que antes se mencionó o tú mencionaste el almacén de datos, ya sabes, parece que la capa plateada es donde el almacén de datos, o al menos la parte principal del almacén de datos establecería quizás el almacén empresarial. ¿Dirías que el almacén empresarial es entonces la capa dorada? Sí.

Es más bien la capa de oro, y la bóveda de roles o la capa de integración es lo que se ve a menudo en la plata. Um, sinceramente, no soy muy fan de la bóveda de datos. No por la metodología o los principios de diseño.

Sin duda, te ofrecen mucha flexibilidad, pero es la arquitectura tecnológica subyacente la que realmente no facilita ese tipo de modelado de datos. Por eso, en Lakehouse, operamos en una arquitectura distribuida almacenada, y el cálculo está desacoplado entre sí. Así que si creas miles, millones de pequeños archivos parquet que se distribuyen por todos estos servidores en el centro de datos, sin duda tendrás que lidiar con la red.

En mi anterior puesto trabajé con muchas empresas que se decantaron, u optaron inicialmente, por el diseño basado en datos, pero tuvieron que dejarlo porque no pudieron superar los retos de la red. Claro. Es interesante.

Quiero decir, sí, ¿quieres intervenir con algunas de las preguntas que estás viendo, Ole? Um, solo, eh, disculpas. Creo que solo hay un segundo o dos de retraso.

Eh, lo siento. Disculpa por interrumpirte, Martin. Eh, por favor, continúa.

He estado mirando las preguntas en el chat, y son increíbles. Gracias a todos por sus discusiones tan detalladas, consejos y puntos de vista. Obviamente, no todos aquí están de acuerdo, algo que me alegra mucho.

Creo que deberíamos dejarlo, pero Martin, no quería interrumpirte. Entonces, ¿quieres hacer más preguntas o tomamos una pregunta? ¿Estás bien?

No, no. Tú, tú ocúpate de Ole. Vale.

De acuerdo. Entonces, siguiendo con esto, creo que tengo una pregunta que me gustaría hacer como conclusión de tu conversación, Martin, con Piethein. Me gustaría saber cuáles son los límites de la arquitectura del medallón, es decir, qué hay fuera de la arquitectura del medallón. Me gustaría que eso quedara más claramente definido, pero quizá terminemos con esa pregunta.

Creo que algunos de los participantes en la llamada merecen formular sus preguntas. Por ejemplo, Anyana, espero estar pronunciando correctamente su nombre, pregunta si realmente necesitamos una zona de aterrizaje antes de la capa de bronce. ¿Cuáles son los escenarios?

Podría ser que debamos pensar en la zona de aterrizaje antes de entrar siquiera en bronce. Sí. Tú haz esto.

Usted destaca este punto en su libro, lo analiza. Sí, por supuesto. Incluso hay muchas páginas en las que describe los matices y las ventajas e inconvenientes de esto.

Primero, más cuestiones de interpretación. A veces, para algunas personas, la zona de aterrizaje formaba parte de la arquitectura de su medallón. Otros claramente la dibujan y sitúan fuera.

Por lo tanto, primero hay que ponerse de acuerdo sobre cómo interpretar la entrega de la arquitectura del medallón, pero en algunos casos que he visto, si no se dispone de patrones de ingestión robustos o seguros, puede ser conveniente almacenar temporalmente esos datos en algún lugar antes de introducirlos en la capa de bronce formal. Una vez más, depende de cómo se diseñe la capa de bronce, pero esta es una motivación para muchas organizaciones que conozco. Tener esa zona de aterrizaje intermedia adicional.

No es obligatorio. Es más bien algo opcional. Así que también es bueno mencionarlo.

Por supuesto. Sí. Sigamos adelante.

Hay una pregunta de John O'Gorman que se ha incluido en la sesión de preguntas y respuestas. Me pregunto si deberíamos priorizar lo que se incluye en la sesión de preguntas y respuestas o si usted prefiere No, no, por favor. Tomémoslas en función del interés que susciten.

Veamos, veamos, la pregunta de John O. Es estupendo que esté aquí. Dice: «¿La existencia de la arquitectura medallón depende del uso continuado de los procesos ETL?».

Dicho de otro modo, ¿será un factor determinante una arquitectura alternativa como la centrada en los datos, combinada con el uso de la IA para crear aplicaciones? Debo decir que no estoy muy seguro de entender la pregunta, pero no yo. Lo mismo.

¿Quieres tomarlo, Piethein? Creo que tal vez la estratificación, en mi opinión, siempre estará ahí, y esto no es nuevo. Correcto.

También expliqué al principio del libro que procedemos de los almacenes de datos empresariales clásicos tradicionales. La estratificación existe por buenas razones, y eso no va a cambiar, esa parte no va a desaparecer. Por supuesto, se podría preguntar: ¿se podría hacer de forma virtual, en tiempo real?

¿Qué significará la IA en algún momento para la estratificación?

¿Se puede omitir una parte determinada? No lo sé. Pero lo que es seguro es que las cosas cambiarán.

Quizás esa sea mi opinión sobre la respuesta a esa pregunta. Quiero decir, tu trabajo actual con los agentes, con los agentes de IA, es, creo, responder a la segunda parte de la pregunta de John. Sí.

Lo cual, en realidad, no es así, ya que considero que los agentes son como muchas aplicaciones, ya sabes, son muchos fragmentos de código que pueden extraer datos de una arquitectura medallón, pero también pueden extraer datos directamente de una aplicación o un sistema fuente. Si necesitas los datos más precisos, sí, sin duda irás directamente al sistema fuente, ¿verdad? Llamarás a un punto final de API y no consumirás datos de la arquitectura medallion.

Pero quizá para casos de uso de tipo asíncrono, se podría considerar perfectamente el uso de esos datos. Así que, de nuevo, eso conlleva muchos matices. Pero esa parte no se ha descrito muy bien en el libro.

Tuve que limitarme y ajustarme a un máximo de 300 páginas. Sí, sí.

300 En realidad, bueno, esa fue la otra conversación que tuvimos justo antes de que se unieran los demás, y es que si realmente quisieras abordar todo lo relacionado con Medallion, tendrías que escribir un libro de unas 600 páginas. Sí. Sí.

Y eso no es práctico para O'Reilly publicar. Sí. No, no.

Hay tantas cosas que también... Supongo que es un reto escribir un libro sobre tecnología que no pase de moda, que no se quede obsoleto muy rápido. Y supongo que cuanto más largo es, más difícil resulta.

Pero hay una pregunta de Tia, espero pronunciarlo correctamente otra vez. Como propietarios de productos de datos en una organización que se está formando, construyendo un medallón, nos vimos obligados a empezar desde el bronce porque no había plata. Luego lanzaron la plata y cambiaron los nombres de las cosas por nombres más adecuados para los negocios.

Tras dos años desarrollando nuestro producto de datos, descubrimos algo muy importante para refactorizar la tienda de propósitos a plata. ¿Merecería la pena? ¿Copias la pregunta, Piethein?

Es una pregunta difícil de nuevo, pero Sí, lo es. Siento oír eso. Um, sí, espero que las cosas hayan sido más fáciles para ti, pero, sí, de nuevo, por favor, mira la guía e intenta seguir lo más que puedas las mejores prácticas y recomendaciones que hay allí.

Pero, sí, usar el oro como una capa directa para la entrada directa de productos de datos, personalmente no me gusta, porque vuelves a estar muy vinculado a las estructuras del sistema fuente, la aplicación que encontrarás a la izquierda como entrada. Por eso, estoy mucho más a favor de desvincular las cosas. Así que, de nuevo, tener una capa extra y luego extraer los datos de la capa plateada.

Y en cuanto a los productos de datos, de nuevo, tal y como he escrito en el libro, hay diferentes tipos de productos de datos. Así que distingo que hay más productos de datos alineados con las operaciones. Creo que Silver es un candidato perfecto para eso.

Y hay más productos de datos de tipo analítico en los que los datos se combinan y se obtienen, se seleccionan y probablemente sean los candidatos a capas de oro para eso.

Sí, creo que la pregunta de Tia es muy buena. Yo añadiría que, si estuviera trabajando con Tia, intentaría centrarme en la colaboración en toda la organización, en lugar de ser estricto con las medallas de oro, plata y bronce. Simplemente porque, ya sabes, parece que el reto no es tanto adherirse a una arquitectura, sino más bien conseguir valor empresarial para las partes interesadas.

Al menos tal vez esté leyendo entre líneas aquí, pero esa es la sensación que tengo. Sí. Y también es esto: ese es el dilema.

Esto también lo considero un dilema. Empecé con esto también en el primer capítulo, que hay una presión continua por parte de la empresa para que estas cosas se entreguen rápidamente. Y, por el contrario, nos gustaría diseñar adecuadamente, documentar nuestros modelos y hacerlo bien, desacoplar, etcétera.

Y sí, esas dos cosas no van de la mano. Por eso, a menudo veo que los equipos toman atajos para facilitar el negocio con sus altas exigencias. Y siguiendo con eso, Piethein, hay una pregunta de Floris que realmente amplía lo que acabas de decir.

¿Cómo afrontarías los retos organizativos, especialmente los cambios a nivel directivo, a la hora de aplicar una arquitectura de medallón? ¿Cómo lo venderías? Sé que a veces se considera demasiado simplista, simplemente marketing.

En cierto modo sí, pero lo que he aprendido con el tiempo es que realmente funciona. Así que, en ese sentido, creo que se podría hablar de forma abstracta sobre diferentes niveles, preocupaciones, se podrían desarrollar perfiles, argumentar bien los administradores, por ejemplo, trabajar más con plata, quizá con oro. Mientras que los analistas de negocio se fijarían en el oro, por ejemplo.

Entonces, son etiquetas favorables para los negocios, ¿verdad? Bronce, plata, oro. Es un sustituto de todas estas diferentes convenciones de nomenclatura que teníamos para las capas clásicas, como el entorno de ensayo, la zona de aterrizaje, la capa curada, la capa de integración.

Es más favorable para las empresas. Esa es exactamente la otra pregunta que tenía, ¿verdad? Porque hay algo que vi en el texto que quería preguntar.

Eh, ¿dónde está?

Eh, eh, sí, eso es de Heni. Soy un firme defensor del patrón de arquitectura, pero estoy tratando de comprender el creciente interés por la arquitectura medallón y en qué se diferencia de las capas convencionales de almacenamiento de datos, como la capa de preparación, la capa fundamental y el modelado de datos. Así que quizá podrías ampliar un poco lo que ya estabas diciendo, Piethein.

Es una pregunta excelente. Sinceramente, no es muy diferente de lo que hacíamos antes con el almacenamiento de datos empresariales o de cómo lo gestionábamos en un lago de datos. Es más bien que estos proveedores promueven el uso de estas etiquetas tan atractivas para las empresas.

Y trabajan con los ejecutivos y a nivel directivo. Y eso, visto desde la distancia, parece resolverlo todo, porque ahora tenemos etiquetas favorables para los negocios y estas preocupaciones están bien alineadas. Pero en la práctica, no es diferente del trabajo realmente duro que había que realizar para construir un fantástico almacén de datos, por ejemplo.

Sí. Por favor, Martin, adelante. Iba a intervenir porque he visto que esto ocurre en la práctica cuando llega un proveedor y dice: «No, ¿sabes qué?».

Todos sus arquitectos de datos lo están haciendo mal. Tienen estas capas de ensayo y esas cosas, todo debería ser medallón, bronce, plata, oro, ¿verdad? Déjenos enviar a nuestros consultores para que se hagan cargo.

Y, ya sabes, al menos en el ejemplo concreto en el que estoy pensando, me pareció muy irrespetuoso hacia las personas de la organización que eran, yo era por cierto, un consultor externo, ¿verdad? Así que, ya sabes, juzgar de esa manera, pero no estaba muy contento con ese proveedor en particular. Ahora también combinamos lo que veo, por ejemplo, en mi organización, tenemos muchas arquitecturas Medallian diferentes.

Así que utilizamos las etiquetas más adecuadas para el negocio, de manera abstracta, para describir el tipo de preocupaciones y lo que ocurre. Y luego, debajo, hay más capas físicas, y tienen nombres diferentes. Hay una zona sin procesar, una zona curada, una zona enriquecida, una zona integrada, lo que se te ocurra.

Y dejamos eso a los ingenieros técnicos, cómo describir esas preocupaciones más a nivel físico. Sí. Veo que se nos está haciendo tarde, otra vez, el tiempo ha pasado más rápido de lo que esperaba.

Quiero decir, obviamente se trata de una discusión técnica, y pensaba que tendríamos tiempo para debatir más cosas de las que ya hemos debatido. Pero el tiempo se ha acabado. Quiero decir, vaya, antes de que des por concluida la sesión, Ole, hay una pregunta que me gustaría abordar brevemente, que en realidad no es una pregunta sobre medallones, sino que es de Juan Cecada, que dice: urgente frente a importante, corto plazo frente a largo plazo.

Este es el gran dilema, cómo expresarlo, cómo aplicarlo correctamente, en las estructuras de incentivos. ¿Cómo conseguimos que la gente coma verduras y vaya al gimnasio? Y yo iba a sugerir, ya sabes, una respuesta a eso.

Una especie de enfoque basado en pequeños hábitos. Sí. Y la idea de que no se pueden perder 20 kilos de la noche a la mañana.

Puedes perder 20 kilos si cada día aumentas o, ya sabes, practicas buenos hábitos, buenos hábitos alimenticios, buenos hábitos de ejercicio, etcétera, y casi todos los días empiezas de nuevo. Y así, ya sabes, creo que es la respuesta a muchas de las preguntas, cosas como una respuesta genérica para decir vale, no resuelves tu problema con la medalla simplemente tirándolo todo. Y empezar de nuevo y decir, ahora vamos a ponernos una nueva dieta para estar en forma.

¿Verdad? Resuelve los problemas con pequeños hábitos cada día. Intenta mejorar en la forma de explicar y mejora en la disciplina de cómo haces las cosas.

Mejorar la forma de pensar sobre cómo se va a adaptar al futuro.

Al menos ese iba a ser mi argumento para intentar cerrar este debate. Muchas gracias. De acuerdo.

Gracias a todos. Hay un poco de retraso. Siento mucho no cortarte, Piethein, y esto es solo un poco de hoy.

Gracias, Juan, por ese último comentario. Muy bueno. Y gracias, Martin, por esperar para unirte tan tarde por la noche allí donde estás.

Es usted muy, muy amable. Muchas gracias por sus preguntas tan detalladas. Y, por supuesto, Piethein, muchas gracias por dedicarnos su tiempo hoy y responder a nuestras preguntas.

Espero que se haya calentado lo suficiente. Si no es así, la gente puede continuar en línea. Eh, Jano, por favor, continúa con tu pregunta.

Me alegra saber de ti de nuevo. Y a todos los que estáis en el chat, siempre sois bienvenidos a poneros en contacto con nosotros. Estamos en LinkedIn, Medium, Substack, tanto Piethein como yo, Martin, obviamente.

Muchas gracias, Piethein. Gracias, Ole, por organizar esto, muchas gracias. De nada.

Gracias. Gracias a ustedes dos y a todos los participantes en la llamada. Gracias.

Salud. Muchas gracias. Salud.

Adiós. Ánimo, tómate.