¿Qué es un Data Mesh y cómo saber si tu empresa lo necesita?

Los principios del Data Mesh

El paradigma Data Mesh se apoya en cuatro grandes principios que lo definen y hacen posible su aplicación dentro de una plataforma de datos:

1. El dominio como dueño de los datos. El principal objetivo del paradigma Data Mesh consiste en la descentralización de la propiedad y la responsabilidad sobre los datos aplicando patrones organizativos y de arquitectura basados en Domain-Driven Design. De esta manera, se busca liberar al equipo de infraestructura.
2. Los datos como producto. Aplicando procesos de product thinking que identifiquen a los consumidores de datos y establezcan estrategias alineadas a sus dominios, distribuyendo así la responsabilidad. Según Dehghani debemos abandonar la concepción de los datos como recurso. Al ligar los datos con un recurso tendemos a almacenarlos, aumentar las cantidades y dificultamos su compartición. Dehghani propone cambiar este concepto por el de producto, alineando los datos con un proceso de creación y entrega de valor procurando siempre la satisfacción de nuestros consumidores.
3. Plataforma como autoservicio. Uno de los principales problemas de arquitecturas pasadas era la dependencia de los consumidores de datos para con ciertos perfiles técnicos de la infraestructura. Aplicando el concepto de Self-Service empoderamos a los consumidores permitiéndoles encontrar las respuestas a sus propias preguntas y evitando cuellos de botella en la entrega de valor de la plataforma.
4. Gobierno de datos federado. Para gobernar una plataforma descentralizada se necesita un modelo de gobierno basado en decisiones federadas, en el que sus miembros formen parte de la infraestructura y de los dominios de los productos de datos, junto a perfiles expertos en la materia de gobernanza de datos, legal, seguridad, etc.

¿Cómo saber si las empresas necesitan migrar al Data Mesh?

El paradigma Data Mesh es reciente y difícil de implementar debido a su naturaleza descentralizada, pero se convierte en un requisito indispensable para resolver problemas de escalabilidad a los que muchas compañías se enfrentan hoy en día. Las arquitecturas centralizadas sirven mejor a compañías pequeñas y/o medianas que no son data-driven o, dicho de otra manera, que no basan sus decisiones estratégicas en el análisis de datos.

Entonces, ¿cómo saber si una compañía necesita migrar a un Data Mesh? La respuesta a esta pregunta depende de las resistencias que tenga actualmente una organización. Si encuentra problemas de escalabilidad, dependencias complejas entre equipos, problemas con la calidad del dato, cuellos de botella en flujos de datos o problemas de gobernanza y seguridad, probablemente necesite plantear una posible migración al paradigma Data Mesh.

Hay muchos factores, como los mencionados anteriormente, que se deben analizar antes de dar este paso. Dicho esto, cuando se pretenda responder a esta pregunta se deberán tener en cuenta principalmente tres factores:

• El número de fuentes de datos de la compañía.
• El tamaño del equipo dedicado a los datos.
• El número de dominios de negocio que tiene la compañía.

Queremos construir un Data Mesh: ¿Por dónde empezar?

Si observamos algunas de las implementaciones de Data Mesh en el mercado, veremos que sus soluciones difieren mucho unas de otras. Esto se debe a que partimos únicamente de unos principios definidos a alto nivel y cada compañía los interpreta e implementa según su infraestructura y sus necesidades. Por ello, no existe una metodología específica para construir un Data Mesh, aunque sí podemos seguir estos pasos en la aplicación de los principios:

1. Definir el estado Data Mesh “Ready”

Como hemos podido ver, el paradigma Data Mesh impacta principalmente en la forma de organizarse dentro de una plataforma de datos. El primer paso será mapear los procesos AS IS / TO BE de nuestra plataforma para eliminar las limitaciones técnicas que se puedan encontrar a la hora de empezar a aplicar los principios. El TO BE deberá contemplar las capacidades que permitan aplicar el principio de plataforma como autoservicio. Este estado de “Ready” permitirá iniciar un proceso de transición en cualquier momento sin necesidad de grandes cambios.

2. Definir los dominios de producto

Una buena forma de comenzar es ir introduciendo el principio del dominio de datos, seleccionando aquellos dominios con casos de uso cercanos a los orígenes donde sus datos son producidos (pedidos, clientes, proveedores, productos, etc.). A continuación, liberar estos casos de uso proporcionándoles una dirección y un directorio que permita su descubrimiento. No importa que haya datos duplicados en diferentes zonas de la plataforma, lo importante es la definición de los datos en su dominio.

3. Migrar la responsabilidad

Llegados a este punto ya se empieza a descentralizar la plataforma, cuyo objetivo es asegurarse de que la propiedad de los datos sea transferida a los dominios. Esto se puede conseguir aplicando metodologías product thinking a los procesos y migrando parte de los equipos de infraestructura o del servicio que genera los datos a un nuevo equipo transversal y funcional, responsable del dominio.

4. Gobernar la descentralización

En este paso es muy importante asegurar la calidad de los datos a través de los dominios y permitir que los propios dominios sean autodescriptivos e interoperables. De esta manera, los dominios compartirán una sintaxis y un control de acceso y serán gobernados por unos estándares globales.

En este paso se debe recordar que los responsables de los diferentes dominios de la plataforma forman parte de la visión federada y, en definitiva, de su gobierno.

Data Mesh no es un concepto estático, no se trata de un tipo de plataforma ni de una arquitectura, se trata de una solución que evoluciona constantemente y que admite diferentes interpretaciones. Los principios del Data mesh son los que fijan los cimientos del paradigma y los que siempre permanecerán inmutables. El dominio como base del diseño, los datos como producto, la plataforma como autoservicio y el gobierno federado.

La nueva manera de pensar los datos debe abandonar el concepto de datos como recurso y empezar a pensar en datos como un producto. Se debe mudar el foco del productor como colector de datos, al productor como servidor de los datos. En el momento en el que la organización consiga  transformar el concepto, se conseguirá mejorar la experiencia de los consumidores de nuestros datos.