Data Mesh, ¿qué y por qué?

Data Mesh es principalmente una propuesta para cambiar la forma en que se gestionan los proyectos de datos dentro de las organizaciones. Por sobre todas las cosas es un cambio cultural.

Ya nos había ocurrido esto mismo cuando vimos DataOps. Por lo tanto, en este artículo no vamos a ver ninguna cuestión técnica, si bien obviamente para poder llevar a cabo este paradigma, tenemos que tener el soporte tecnológico correspondiente.

Algo estamos haciendo mal

No es casual que, números más, números menos, la mayoría de los proyectos de datos fallen 😣. Las predicciones para este 2022, señalaban qué sólo el 20% de los proyectos iban a generar algún tipo de accionable para el negocio y que el 80% serían proyectos aislados que sólo podrían entender y gestionar los equipos de ingeniería o de ciencia de datos que los llevaron a cabo.

Si bien podríamos enumerar un sinfín de causas técnicas — por ejemplo, la mala calidad de datos o los pipelines de datos no robustos — y no técnicas — como podría ser no resolver el problema indicado — , lo que nos indica la realidad es que la génesis de los fracasos es la desconexión 🔌 que existe entre las áreas de datos y las de negocio. El problema es tan profundo que, podemos encontrar concursos de machine learning en los que estudiantes de secundaria llegan a mejores resultados que profesionales de datos😲.

Desde hace ya más de 30 años, cuando surge el Data Warehouse, las organizaciones ejecutan sus proyectos de datos con un área que los centraliza actuando como un hub que ofrece servicios al resto de la organización.

Si bien esto no tiene nada de malo, hoy en día cuando decimos que los datos son el nuevo petróleo, dado que su valor y utilidad los convierten en un activo crítico, no podemos esperar que esa forma de trabajar pueda dar respuesta a los nuevos desafíos con los que nos encontramos.

Los datos atraviesan cada una de las operaciones de cualquier compañía y son indispensables para tomar mejores decisiones y obtener ventajas competitivas. Sobran ejemplos de empresas que están reinventándose para organizarse en torno a una cultura data-driven 📈.

La malla de datos como propuesta de solución

En este contexto dinámico y complejo, Data Mesh aparece en 2018 desde una consultora llamada ThoughtWorks. Su autora, Zhamak Dehghani, lo propone como una respuesta a las problemáticas recurrentes en proyectos de datos asociados a la desconexión que mencionamos. Entre las más destacadas podemos listar:

• La centralización de los desarrollos en un equipo de datos, independiente del resto de la organización, a la larga lleva a que sean un cuello de botella y el problema en la cadena de entrega de valor.
• El conocimiento sobre los dominios (más sobre esto a continuación) queda en manos de ingenieros e ingenieras de datos que luego pasarán a trabajar sobre otro dominio.
• Relacionado a lo anterior, le estamos pidiendo a un/a ingeniero/a de datos, que, mientras pasa de proyecto en proyecto, aprenda los pormenores de cada área de la organización, convirtiéndose en especialista en todo y nada al mismo tiempo 😕.
• Mega plataformas analíticas en las cuales se vuelca el conocimiento de toda la compañía, con multiplicidad de equipos y áreas utilizando los mismos recursos al mismo tiempo. Esto da lugar a ineficiencias en las que problemas puntuales pueden terminar en problemas generales.
• Falta de agilidad asociada a soluciones monolíticas, no sólo en cuanto a arquitectura sino más que nada asociado a la rigidez de los procesos que se tienen que llevar adelante para que los consumidores de los datos tengan información disponible en el tiempo y lugar exactos.
• Una brecha muy grande entre el plano operacional y analítico de los datos. Mientras que los datos que se generan al operar un negocio están bajo control y conocimiento del área que los opera, el plano analítico depende de actores externos al área dando lugar a situaciones como la mala interpretación del negocio o suposiciones incorrectas, por mencionar algunas.
• Múltiples copias de los mismos datos, en el mejor escenario con coherencia entre las mismas, en el peor, con diferencias conceptuales y cuantitativas de cosas que deberían significar lo mismo.
• Datos no utilizables por problemas de calidad o por pérdida de oportunidad, es decir, el dato está disponible mucho tiempo después de cuando más valor tenía. Bien sabemos que el valor del dato decrece a medida que crece su antigüedad ⏱.
• Oscuridad de datos, esto lo observamos cuando existe un impedimento a la hora de navegar o descubrir lo que hay disponible por falta de metadata.
• Imposibilidad de llegar al ideal en el que los usuarios finales que necesitan los datos para tomar mejores acciones y decisiones puedan hacerlo de manera autónoma (la utopía del self-service).

Sobre dominios y productos de datos

Para entender la Data Mesh, tenemos que ahondar en estos dos conceptos.

Los dominios representan una unidad en una compañía asociada a una temática en particular. Por ejemplo, en su libro, la autora plantea el caso de una empresa de streaming digital. En la que podríamos encontrar áreas como producto y finanzas que, a su vez, podrían estar conformadas por dominios como Podcasts y Artistas la primera, o Pagos y Suscripciones la segunda.

La propuesta es que estos dominios trabajen sobre sus datos de manera autónoma, independiente a los otros, con su propio equipo de datos que formará parte del área, respondiendo a los responsables de ésta.

El justificativo detrás de esto es que las personas que están más cerca de donde se genera y trabaja con el dato, son las que mejor van a poder entenderlos, interpretarlos y decidir qué tipo de analítica ejecutar sobre ellos.

Luego, para conformar la malla, los dominios se comunicarán entre sí mediante productos de datos. Son unidades atómicas y funcionalmente cohesivas, resultado del trabajo de un equipo dentro de un dominio en particular para resolver una problemática. Siguiendo el ejemplo, el dominio Podcasts, podría hacer uso de los datos demográficos de las personas que los escuchan para poner a disposición una tabla en la cual figure información que indique las temáticas más populares por grupo etario. Es importante tener en cuenta que, si bien lo que el dominio va a compartir para consumo de otros dominios es esta tabla, todos los componentes necesarios para llegar al resultado final, también forman parte del producto: código (ETL y orquestación), datos utilizados para el desarrollo junto con sus pruebas de calidad, infraestructura y políticas de acceso.

Imagen de Zhamak Dehghani en martinfowler.com

Otros ejemplos de producto podrían ser un modelo de machine learning o una API. Más allá del activo definido, lo fundamental es pensarlos como productos, de manera tal que tendrán asociado un ciclo de vida y que su construcción esté siempre enfocada en otorgar una mejor experiencia para el usuario final, tal como pasa en cualquier industria con los productos que elabora.

Para lograr este objetivo, podemos contemplar que los productos cumplan con determinadas características:

• Autodescribible: toda la metadata asociada al producto debe poder definirlo claramente, sin ambigüedades para que el consumidor entienda exactamente en qué consiste.
• Direccionable: identificación que indique desde dónde y de qué manera se consume el producto.
• Descubrible: debe formar parte de un catálogo en el que los usuarios puedan encontrarlo con facilidad 🔎.
• Seguro: el acceso debe estar gobernado y auditado. Si contiene información personal o sensible debe estar claramente identificado.
• Confiable: tiene que haber métricas cuantificables para determinar la confiabilidad, y los valores tienen que estar publicados. Por ejemplo, podemos establecer que los datos se actualizan diariamente y, en caso de que haya alguna demora, en el catálogo debe figurar la cantidad de días desde la última actualización.
• Interoperable: para poder compartir información entre dominios, tiene que haber una manera estandarizada de hacerlo, por ende, los productos deben cumplir con esto.

Una última cuestión fundamental asociada a dominios y productos es la del adueñamiento. Tradicionalmente, el responsable final y fuente de consulta sobre un activo de datos ha sido el área de datos, o en última instancia, el ingeniero o la ingeniera que trabajó en su construcción. Al trabajar orientados a dominios y con productos bien definidos, eso debe cambiar a un enfoque en el que cada producto tenga asociado un dueño o dueña, con conocimiento del dominio y de las decisiones que se tomaron para llegar al producto final.

¿Hay algo más?

Sí, además de los dominios y productos de datos, Data Mesh se basa en dos principios adicionales:

• Infraestructura de datos como plataforma, lo que se busca es que los dominios puedan consumir una infraestructura estandarizada en modo self-service para facilitar el despliegue de las herramientas que conforman una plataforma analítica. De esta manera, además de agilizar las implementaciones, se evitan diferencias en el stack tecnológico de cada área, lo que muchas veces lleva a que no sea posible compartir información porque las herramientas no pueden “hablar entre sí”.
• Gobernanza federada computacional, para entender esto tenemos que hacer foco en cada uno de los términos que componen el principio:
• Gobernanza: hace referencia a tener control de los datos desde distintas aristas. Por un lado, la seguridad para garantizar que sólo las personas autorizadas tengan acceso según se haya definido. Luego se debe asegurar que se cumplan con las normativas legales y organizacionales, esto cobra especial relevancia con las regulaciones como GDPR. También forma parte del gobierno el verificar que se cumplan las políticas que aplican a cada una de las características de los data products que mencionamos anteriormente.
• Federación: si bien la descentralización del trabajo por dominios suena muy linda, es fácil imaginar cómo todo puede transformarse en caos en 3️⃣2️⃣1️⃣. Para que el gobierno sea posible sin caer en el extremo de una centralización total, se propone federar algunas cuestiones y centralizar otras. Entonces, para las políticas que comentamos en el punto anterior, seguramente tenga sentido que se definan y auditen de manera centralizada, al igual que cuestiones tales como la gestión de los accesos o la definición de los protocolos que van a permitir la interoperabilidad de los data products. Luego, se puede delegar en los dominios la manera en cómo llegar a cumplir con todas las políticas centrales, aquí es donde pueden surgir roles tales como el de Data Steward.
• Computacional: para que lo anterior funcione de la manera más fluida posible, será fundamental poder automatizar la mayor cantidad de tareas asociadas a todo lo que detallamos. Por ejemplo, si se define como norma que no pueden publicarse productos con datos sensibles, debería haber algún proceso basado en machine learning que pueda identificar productos que no cumplan con esto sin necesidad de una revisión humana.

En conclusión

Como vimos, Data Mesh no es algo que vayamos a tomar e implementar sin más, tal como haríamos con una arquitectura de datos, es una invitación a realizar una introspección profunda en torno a cómo trabajamos y cuál es nuestro norte como profesionales de datos.

Si tomamos conciencia de que hoy no estamos aprovechando todo el potencial que tienen los datos, entonces la discusión no será “Data Mesh sí, Data Mesh no”, sino que tendrá que ver con identificar qué es lo que nos impide entregar valor al negocio en tiempo y forma para luego actuar en consecuencia.

Puede que un cambio de paradigma como el que nos propone Data Mesh, en el que el trabajo se organice de forma descentralizada nos resulte una alternativa interesante para resolver nuestros puntos de dolor, de ser así, lo importante será desandar ese camino teniendo claro el por qué y a dónde queremos llegar.

Dado que hablamos principalmente de un cambio cultural, es probable que lo mejor sea dar pasos 👣 pequeños, involucrando en un principio a algunas áreas y actores de la organización para ir escalando en forma incremental e iterativa, ajustando y adaptando lo que sea que hayamos pensado y planificado a lo que observemos en la vida real.