Muchas empresas, a la hora de abordar la gestión del big data, han invertido en entornos tecnológicos que pasan por elementos como un data lake central y un equipo de datos. Todo ello con la expectativa de fomentar el crecimiento del negocio en función de los datos que de su actividad se obtiene. Sin embargo, es un problema común que, después de un alto rendimiento inicial, acabe convirtiéndose todo procedimiento data en un cuello de botella en el que quizás no se vea comprometida la calidad de los datos, pero sí la agilidad y la eficacia con la que se pone a disposición la información final a sus usuarios.

Es en torno a esta problemática donde ha surgido en los últimos años con fuerza un término: data mesh, que promete agilizar todos estos procesos en base a romper la tradicional arquitectura monolítica de los entornos data fabric, hacia una arquitectura basada en los microservicios pero, ¿podemos aplicar por igual a todos los entornos el data mesh?, ¿qué diferencias concretas existen con data fabric?, ¿cómo diseñamos un proceso data-mesh?, ¿cuándo conviene aplicarlo? Estas son algunas preguntas cuya respuesta os queremos ofrecer desde elternativa.

¿Qué es la arquitectura data mesh y cómo aborda los cuellos de botella?

Tal como hemos introducido, una arquitectura data-mesh ofrece un enfoque descentralizado frente al enfoque monolítico de otros procesos tradicionales, lo cual permite a los equipos de dominio realizar los análisis de datos por su propia cuenta, sin dependencias del equipo de datos. Eliminando estas dependencias, se reducen notablemente los cuellos de botella que puedan producir en este equipo peticiones desde diferentes departamentos no técnicos, como las que puedan solicitar marketing, ventas, RRHH, finanzas, etc.

Para una mayor profundidad del término Data Mesh y sus aplicaciones prácticas, visita nuestro artículo “Data Mesh: qué es, ventajas y cómo implementar esta arquitectura de datos”

Este hecho no quiere decir que ante un enfoque data-mesh, los equipos técnicos centrados en los datos sean innecesarios o reduzcan su carga de trabajo: aplicar una arquitectura data-mesh requerirá un mayor compromiso con la transformación digital, tal como veremos posteriormente, así como la reparación de los data pipelines tras cambios en la base de datos operativa.

Diferencias entre Data Mesh y Data Fabric

Tal como ocurre con otros términos que forman parte de nuestro vocabulario (ETL vs ELT; datalake vs data warehouse, etc.), entre ambos procesos el fin es el mismo (obtener la máxima información de los datos a través de la incorporación de tecnología), pero con matices que hacen que cada uno sea la opción preferente para diferentes entornos, sobre todo a la hora de cómo presentamos los datos.

Por ello, es muy importante que antes de decidirnos por un proceso data mesh, data fabric o incluso ambos (veremos más adelante como no son excluyentes), auditemos nuestro entorno data y nos guiemos por profesionales que determinen cuál es la solución más adecuada para nuestra empresa.

Esto se debe a que tal como mencionábamos en el anterior apartado, es un error querer aplicar un proceso data mesh por el simple hecho de reducir la dependencia de los departamentos con el equipo IT con el fin de reducir sus funcionalidades, ya que precisamente puede sernos contraproducente si no reforzamos la inversión en el equipo data, que debe en todo momento garantizar la correcta calidad del dato.

Por este motivo y por otros tantos, conviene que conozcamos en detalle las diferencias entre data mesh y data fabric más allá de cómo se presentan los datos, centrándonos en otros aspectos como el cómo manejan los datos, sus mecanismos de almacenaje y su forma de gobernarlos.

Enfoque de datos como productos vs enfoque automatizado

Cada paso en el proceso de tratamiento de los datos de un Data Mesh se enfoca a reducir la fricción que pueda producir el acceso a éstos para quienes lo necesiten sin importar la experiencia técnica, mientras que en el caso de los procesos Data Fabric se centran en la automatización a través de múltiples herramientas con la finalidad de conectar datos disponibles desde varias ubicaciones, extrayendo la información de este entramado tecnológico mediante conexiones.

La descentralización frente a la centralización

Lo destacábamos como el primero de los principios del Data Mesh: la creación de múltiples dominios dedicado cada uno de ellos a una especialidad según el uso que se le de y la función que tenga según el consumidor a quien se dirige. Esto supone un enfoque descentralizado frente a la centralización que propone Data Fabric, que plantea la gestión y el gobierno de los datos desde una única fuente de datos. Ambos ofrecen datos de calidad en los puntos finales de cada una de sus redes, pero la diferencia radica en la procedencia más variada del Data Mesh frente a la procedencia unificada del Data Fabric.

Acceso a los datos

Esa descentralización vs centralización en cuanto a la gestión y gobierno cambia las tornas a la hora de hablar de puntos de acceso y control: el Data Mesh emplea conjuntos de datos controlados por los equipos especializados para ello (IT, Data Engineers, etc.), mientras que Data Fabric emplea el control a través de distintas APIs basadas en objetivos previamente configurados.

Arquitectura data

A la hora de hablar de arquitectura data en el caso de Data Fabric hay un concepto clave: metadatos, que son impulsados por la tecnología basada en herramientas para establecer conexiones entre las diferentes fuentes de datos para ponerlas a disposición a los usuarios finales a través de sistemas de entrega. En el caso de Data Mesh, usa un patrón organizativo y distribuido que crea diferentes dominios especializados, de menor tamaño dentro de una organización según la tipología de usuarios de estos datos.

Enfoque bottom up frente a top down en el gobierno del dato

Nos centramos ahora en el cuarto de los principios definidos para el Data Mesh: su enfoque bottom-up, que dista del enfoque top-down del Data Fabric. Esto es que mientras Data Mesh implica la entrada de todos los dominios a la hora de considerar las reglas y pautas que definirán la calidad y correcta gestión del dato, Data Fabric “impone” estas reglas y pautas desde los máximos responsables de los datos (equipos técnicos, ingenieros del dato, etc.) hasta los equipos que harán uso de su información.

Factores determinantes de la arquitectura Data Mesh vs arquitectura tradicional

Simplificando, la arquitectura data mesh es el equivalente a lo que hasta ahora hemos conocido como microservicios de data. Es decir, pasar de las aplicaciones monolíticas (una aplicación software en la que la capa de interfaz de usuario, lógica de negocios y la capa de acceso a datos están combinadas en un mismo programa y sobre una misma plataforma) a las arquitecturas de microservicios (una aplicación software construida mediante un conjunto de pequeños servicios, independientes entre sí y en la que cada uno de ellos se encarga de implementar una funcionalidad completa del negocio).

Con ello, lo que el Data Mesh nos permite es asociar la estructura y el lenguaje de código (territorio de los departamentos técnicos de la empresa), con el resto de campos en los que se trabaja una empresa (departamentos ejecutivos). Es decir, tal como apuntábamos en la introducción del término Data Mesh: democratizar y descentralizar los datos para que cualquiera con necesidades sobre ellos, pueda usarlos según su propio contexto y no según se presentan de forma generalizada.

Este cambio de paradigma supone dentro de la cultura big data pasar de una visión data-driven (enfoque en el que los datos se ponen al servicio del usuario a través de equipos técnicos) a una visión domain-driven (los datos al servicio del usuario a través de la tecnología).

En cuanto a la arquitectura seguida para el almacenaje de los datos, una metodología data fabric se sirve de un data lake único y centralizado desde donde parte la transformación de los datos, mientras que la metodología data mesh descentraliza este proceso y pone a cargo de cada sector su propio circuito de datos. Cada uno de estos circuitos tendrán sus propios data owners, compartiéndose la propiedad entre todos los que hacen uso de los datos.

Este hecho permite que no se requiera conocimientos técnicos a la hora de tratar los datos, teniendo el foco cada equipo en cómo debe hacer uso de aquellos que necesita para su analítica.

¿Y qué ocurre con los datos cruzados, aquellos que se hacen servir para diferentes sectores de la empresa? Data Mesh garantiza la interoperabilidad mediante la aplicación de estándares universales que permiten la colaboración. Tanto los formatos, la gobernanza, la disponibilidad y los metadatos se deben concretar para impedir caos entre los datos que afecten a su calidad.

Cuando aplicar procesos Data Mesh y cuando procesos Data Fabric

De forma muy resumida, basándonos en el anterior punto donde hemos tratado las diferencias entre ambos procesos, podríamos decir que, en el caso de Data Mesh, el fin es un cambio organizacional, mientras que en el caso de Data Fabric, el cambio es más tecnológico. Es decir, lo que se pretende con el Data Mesh es que toda la plantilla participe y tenga presente la producción de datos como fin máximo, aunque con el gobierno en manos de un equipo altamente especializado, mientras que con Data Fabric lo que se pretende es hacer el dato accesible a cualquier miembro de la plantilla a través de tecnología capacitada para ello.

Con estos puntos sobre la mesa, ¿es mejor un proceso Data Mesh que un proceso Data Fabric o viceversa? Para responder a esta pregunta tenemos que considerar dos aspectos. El primero de ellos el que hemos insistido a lo largo de este artículo: cada situación, cada empresa, cada contexto, requiere su propia solución, por lo que sería un error que indicáramos a priori que un proceso es mejor que otro basándonos en la generalidad, ya que la generalidad no existe en el mundo de los datos.

El segundo de los aspectos es que un proceso no es excluyente del otro:  de hecho, es útil a la hora de hablar de arquitectura de datos incluir tanto procesos de Data Fabric como Data Mesh. No son mutuamente exclusivos en cuanto deben ser tratados como marcos arquitectónicos, no arquitecturas sólidas de por sí. No tienes arquitectura de datos hasta que los marcos se adapten y personalicen a tus necesidades, tus datos, tus procesos y tu terminología, y para ello, tanto Data Mesh como Data Fabric tienen cabida en el tratamiento del big data.

De hecho, puede ser muy recomendable aprovechar las automatizaciones implícitas en los procesos de Data Fabric introduciéndolas en etapas concretas del Data Mesh, sobre todo en empresas que avanzan en su proceso de digitalización introduciendo nuevas tecnologías como las aplicaciones de aprendizaje automático o machine learning.

Siguiendo con este ejemplo, veríamos una mejora evidente de incluir ambos procesos en el uso de machine learning si lo acercamos a los usuarios finales (ventas, marketing, RRHH… fin que persigue el Data Mesh) mediante la automatización de las etapas que involucran la preparación de datos para el ML (fin que persigue Data Fabric). De esta forma se mejora la velocidad, la precisión y la disponibilidad mediante conjunto de datos controlados, a la par que los usuarios del dominio conocen qué hacer con los datos sin la necesidad de que tenga que intervenir IT, que por otra parte no requerirá la necesidad de conocer para qué se van a usar los datos para adaptar los procesos a cada fin.

No obstante, conviene destacar a la hora de inclinarnos por una opción, otra o ambas, aspectos como que un proceso Data Mesh requiere un compromiso con la digitalización más elevado, en el que se crean o se mantienen como personal indispensable equipos técnicos en data, mientras que un proceso Data Fabric puede ser abordado desde diferentes niveles de complejidad.

Este hecho se resume en que un proceso Data Fabric no requiere de ningún proceso Data Mesh si así lo solicitan las circunstancias. Sin embargo, un proceso Data Mesh sí requiere procesos Data Fabric, sea cual sea el contexto.

Cuando construir una arquitectura data mesh

Insistimos: no debemos basarnos en la aleatoriedad de “esta arquitectura puede funcionar en mi proceso digitalizador”, sino en el “esta arquitectura resuelve mis problemas con el tratamiento del dato de mi empresa”.

Esos problemas, en el caso del data mesh, los podemos identificar como resistencia a la hora de abordar la escalabilidad, dependencias complejas entre diferentes departamentos de la empresa, los mencionados cuellos de botella producidos por una desmedida solicitud de peticiones al equipo data o problemas de gobierno y seguridad del dato.

Problemas que, por otra parte, también aborda data fabric, pero que pueden inclinarse a favor de data mesh acorde a tres factores principalmente:

• Numero de fuentes de datos de la empresa
• Tamaño del equipo que trabaja con los datos
• Cantidad de departamentos o dominios de negocio

Cuanto mayor sea la suma de estos tres factores en conjunto, más nos podría beneficiar la aplicación de un proceso data mesh.

Soluciones data mesh a nuestro alcance

La arquitectura data mesh se basa en abordar cuatro principios muy definidos: orientación específica de dominio, datos tratados como productos, infraestructura de autoservicio y enfoque bottom-up en el gobierno del dato.

Toda solución que permita un desarrollo óptimo de cada uno de estos cuatro principios será a priori apta para aplicar una arquitectura data mesh, lo cual no quiere decir que no existan diferencias entre ellas que nos puedan beneficiar en según qué entorno de datos nos movamos.

Nuevamente, será la asesoría y la auditoría de nuestros sistemas quienes mejor determinen qué solución es la más adecuada, pero sí podemos señalar como óptimas plataformas como Snowflake, Talend o Informatica al abordar estos principios en su totalidad y contar con herramientas y funcionalidades que responden al sentido de aplicar data mesh en nuestra empresa.

Así, como arquitectura distribuida, la composición básica recomendable de cualquier data mesh a aplicar desde cero o dispuesto para migrar, consiste en un data lake o data warehouse ya alojado en cloud, donde los datos se almacenen y transformen en una plataforma que permita estándares centralizados y propiedades descentralizadas a la par.

Snowflake Data Mesh

Una de las mayores ventajas que ofrece Snowflake a la hora de construir un data mesh en su considerable variedad de capacidades bajo un mismo paraguas. Capacidades que, con otras soluciones, requerirían la adición de diferentes colecciones de servicios, lo cual requeriría un mayor tiempo de adopción, una mayor complejidad y, en definitiva, un mayor número de profesionales del dato que adecuen las herramientas.

Tratando casos particulares, los usuarios de Snowflake pueden crear y automatizar la transformación de datos en pipelines para convertirlos en datos tratados como productos y gobernados, destacando un amplio tratamiento de diferentes formatos de archivo que van desde JSON, XML, Parquet, AVRO, Delta Lake2, Apache, Iceberg3 hasta otros menos comunes. Además, Snowflake da soporte a datos no estructurados como pudieran ser imágenes, videos u otros formatos binarios. Datos que pueden ser manipulados en la propia plataforma Snowflake usando SQL, Python4, Scala, Java y Javascript, o a través de funciones externas más amplias compatibles en su plataforma cloud.

Talend Data Mesh

El data Fabric de Talend es una de las soluciones más completas y flexibles a la hora de gestionar datos. Teniendo en cuenta esta flexibilidad como uno de sus puntos fuertes, esta arquitectura de Talend nos permite tanto integrar un data mesh como facilitar el gobierno y la calidad del dato, dos aspectos que son los puntos débiles de toda arquitectura de microservicios.

Así, contando con las necesidades previas que requiere tu empresa, se puede montar el data mesh sobre la arquitectura que ofrece Talend para atender el proceso de datos de cada dominio sin perder gobernanza, siendo altamente recomendable en este caso, la herramienta Talend Data Catalog, que permite a los dueños de cada dominio una gestión ágil basada en búsqueda por facetas, muestreo de datos y descubrimiento semántico, así como una categorización y perfilado automático de los datos.

Informatica Data Mesh

El punto fuerte de Informatica a la hora de montar un data mesh basado en su arquitectura es la excelente integración de datos que ofrece, admitiendo la analítica desde múltiples arquitecturas. Este hecho, sumado a una no menos potente escalabilidad, permite admitir situaciones de integración de datos complejas como las que el data mesh ofrece.

Por otra parte, la solución de Informatica es de las más avanzadas en el uso de inteligencia artificial y machine learning, lo cual faculta el uso de estas dos metodologías avanzadas para una integración de datos adicional y tratamiento de la calidad del dato.

¿Cuál es la mejor solución Data Mesh?

Insistimos una vez más: que el data mesh de Snowflake resulte mejor que el de Talend, o que el de Talend resulte mejor que el de Informatica o cualquier otra solución compatible del mercado, va a depender del entorno en el que se construya el data mesh y para las necesidades que se vayan a cubrir con él.

Sí que se pueden dar ciertas generalidades que inclinen la balanza hacia un producto u otro, como el grado de madurez digital en el que se encuentre tu empresa, su compromiso con los procesos de transformación digital, el entorno del que se parta (cloud, on premise o híbrido), el tiempo en el que se quiera cubrir la integración, etc.

Así, por ejemplo, podríamos recomendar el data mesh de Informatica en procesos de transformación digital en los que se incluya involucrar IA, con el hándicap de que este tipo de implementaciones y adopciones son complejas, requieren semanas y un presupuesto elevado, lo cual lo hace menos conveniente para digitalizaciones en primeras fases de adopción.

Esto último lo puede resolver la flexibilidad de Talend en cuanto a su variedad de opciones, lo cual abre un amplio abanico de entrada y compromiso con la arquitectura data mesh, siendo otro de sus puntos fuertes la analítica, indispensable para no perder gobierno sobre los datos. Sin embargo, podría perder la batalla en casos en los que se necesite un uso operativo de alto volumen por sus capacidades más limitadas de producción de datos.

Conocimiento y auditoria del entorno en el que trabajan nuestros datos, compromiso con el alto valor que ofrecen a los equipos que forman nuestra organización y herramientas adaptativas a cómo queremos tratar, transformar y organizar nuestras fuentes de información son tres claves que nos ayudarán a decidir si es mejor un data mesh, un data fabric o la combinación de ambos. Deja que desde elternativa te ayudemos con estos tres pilares para que juntos consigamos el único fin posible: devolver el valor de los datos a tu negocio.

Uno de los problemas más recurrentes que se encuentra una organización que invierte en la gestión del big data es cómo responden los diferentes equipos a la búsqueda y obtención de información dentro de los almacenes de datos dispuestos, sin que ello suponga sobrecargar a IT. De esta premisa parte la naturaleza del término Data Mesh, que de forma muy resumida supone “la democratización de los datos”: ofrecer a cualquiera de los usuarios de la información de empresa su acceso de forma rápida, así como una colaboración entre equipos más fluida.

En el siguiente artículo definiremos el término, diferenciándolos de otros conceptos similares e indicando cómo y cuándo conviene implementarlo, incidiendo sobre todo en los problemas que resuelve en el día a día de una empresa a la hora de trabajar con sus propios datos.

¿Qué es Data mesh?

Un primer acercamiento al término data mesh sería el uso de un enfoque centrado en los usuarios y en el producto a la hora de obtener información de fuentes de datos numerosas y heterogéneas, o de forma más técnica, el término que se ha adoptado para el proceso de descentralización de datos analíticos en un entorno big data dentro de una organización, con la finalidad de que cualquiera dentro de la estructura de la empresa, pueda compartir, acceder y gestionar la información de forma independiente y sin afectar al resto de la organización.

Todo ello supone un cambio en el tradicional rol que la gestión del dato había tenido hasta ahora en las organizaciones, donde los “dueños de los datos” residen en una parte de la empresa (normalmente ingenieros de datos o data scientists) para controlarlos y solo hacerlos accesibles al resto mediante la creación de data lakes o data warehouses.

“Acceso a datos más rápidamente y colaboración sencilla entre equipos en la era big data: los dos factores clave que persigue el Data Mesh”

Así, el data mesh lo que permite es la construcción de una infraestructura de autoservicio que valida a cualquier equipo (sea técnico o no) utilizar recursos y herramientas bajo demanda, para acceder a los datos correctos, procesarlos, prepararlos y analizarlos sin necesidad de formación previa o conocimiento de cómo se han producido.

El término Data Mesh (malla de datos), fue introducido por primera vez en 2019, mediante la ingeniera, arquitecta de software, emprendedora y especialista en datos, Zhamak Dehghani a través de su artículo “Cómo pasar de un data lake monolítico a una malla de datos distribuida”. En él proponía un cambio de paradigma en el tratamiento de los datos a través de la enumeración de las características que debería tener una plataforma de datos moderna.  Estas características formarían la naturaleza de lo que hoy conocemos como Data Mesh.

Problemáticas que resuelve el uso de Data Mesh

Invertimos en gestión del big data porque nos damos cuenta de que el valor de los datos se pierde a medida que crece su tamaño si no se canaliza adecuadamente. Pero esa canalización, que llevamos a cabo mediante el uso de herramientas y la creación de equipos profesionales del dato, requiere de altos conocimientos técnicos y una alta disposición a resolver diferentes cuestiones, de diferente naturaleza y proveniente de diferentes fuentes.

Este hecho crea la paradoja de que la solución a una saturación de flujos de datos, pasa por una saturación del equipo técnico que los gestiona, que no solo se ven inmersos en la ya costosa a nivel de tiempo de dedicación, tarea de reparar canalizaciones de datos rotas, sino que también se deben preocupar de atender a las diferentes peticiones de información provenientes de diferentes departamentos, cada uno con unas necesidades diferentes y un lenguaje a la hora de trabajar los datos también heterogéneo. Peticiones que incluso se pueden llegar a cruzar e involucrar a diferentes estamentos de la empresa.

Es lo que ocurre por ejemplo con casos cotidianos en una empresa de venta de retail, la cual puede tener los deberes bien hechos a la hora de tener toda la información de productos, clientes y transacciones bien organizada y clasificada dentro de cada departamento implicado, pero que a la hora de responder a cuestiones interdepartamentales, la fluidez de la información se limita.

Así, el fin máximo (la calidad del dato) no se verá comprometido, pero sí la velocidad, la agilidad y la practicidad del tratamiento al encontrarse plenamente centralizada. Es este “el punto débil” de la gestión big data que aborda Data Mesh, resolviéndolo de la forma más evidente posible: si el problema viene de un dato centralizado, la solución viene de descentralizarlo.

Cómo facilitar la fluidez de datos en una empresa: los 4 principios del Data Mesh

Esa descentralización del dato que propone una gestión basada en Data Mesh no significa prescindir de los data lakes, que siguen siendo necesarios para garantizar el gobierno de los datos. Para posibilitar su aplicación dentro de una plataforma de datos, el Data Mesh establece cuatro principios que a su vez definen su naturaleza:

Orientación específica de dominio

En vez de usar una única capa virtual para administrar fuentes heterogéneas, el Data Mesh usa múltiples dominios, dedicado cada uno de ellos a las necesidades que se requieren específicamente. Es decir, en vez de tomar la información bruta de un único espacio común, un proceso Data Mesh trata previamente la información según su naturaleza y los separa para hacerlos disponibles de forma más rápida y eficaz a quienes lo necesitan.

De esta forma, en un Data Mesh quedarían separados por dominios los datos de ventas, finanzas, RRHH y marketing. Todos ellos tendrían accesibles los datos de unos y otros si así lo requieren, pero de forma instantánea, cada departamento podría acceder a su información y satisfacer necesidades inmediatas de forma mucho más ágil que mediante otro proceso data.

Denominamos dominio en arquitectura data a una colección independiente de clústeres implementables, que a su vez contienen múltiples microservicios que interactúan con usuarios u otros dominios a través de interfaces

Datos tratados como productos

El dato como centro de todo proceso, ese es el tratamiento que da el Data Mesh a cada información que entra en su flujo. Así, nos encontramos con que cada etapa o cada herramienta dentro de los procesos data mesh, clasifica claramente a los usuarios como productores y como consumidores, y según esta clasificación, el conjunto de datos resultante suele ser ampliamente controlado, que actúa como una API y es accesible para diferentes dominios y el público que lo requiera.

Data Mesh cambia la concepción tradicional de tratar los datos como recursos. Este tratamiento hace que se tienda a su almacenamiento como algo valioso, pero obviando su  utilidad. Al ser tratados como producto, una concepción Data Mesh alinea los datos con un proceso de creación y entrega de valor específico, procurando siempre la satisfacción del consumidor.

Infraestructura de autoservicio

Al igual que no prescinde de elementos como un data lake, Data Mesh no sustituye el trabajo de los ingenieros data, sino que reduce la dependencia que el resto de equipos tiene con estos profesionales a la hora de tratar datos, de forma que los encargados de la ingeniería de datos se pueden dedicar a otras tareas más productivas.

Para ello, Data Mesh facilita una infraestructura que de inicio es creada y mantenida por los data engineers, que ayudan a garantizar operaciones sencillas por parte de los miembros de cada dominio específico sin necesidad de poseer o necesitar conocimientos técnicos sobre el tratamiento de cada dato.

Enfoque bottom-up en el gobierno del dato

Hablamos desde el comienzo de “democratización de los datos”. Dentro de esta prosa es necesario para ello que sean los miembros de cada dominio quienes definan las reglas sobre las políticas, los accesos y el tratamiento que se le dan a los datos que consumen y producen, de forma que no solo tengan la disponibilidad de los datos, sino también su control.

Con este enfoque (denominado bottom-up porque determina el funcionamiento de abajo hacia arriba, es decir, a partir del consumidor final) que hace plenamente partícipe a cada consumidor de datos, se ayuda a garantizar los estándares de calidad del dato al apoyarse la guía creada por ellos con sistemas de verificación y control a lo largo de los flujos de trabajo.

Para saber más sobre las implicaciones técnicas y a nivel de arquitectura que tiene la aplicación de los procesos Data Mesh, consulta nuestro artículo: Data Mesh vs Data Fabric: buscando la mejor arquitectura de datos

Cómo implementar una arquitectura data mesh: primeros pasos

Data mesh parte de una concepción y de los principios que hemos definido como parte igualitaria. A partir de ahí, cada solución del mercado adapta sus productos a la arquitectura data mesh según la infraestructura que se disponga y las necesidades de cada compañía. Es por ello que la construcción no responde a una hoja de ruta concreta y replicable, aunque sí podemos marcar cuatro pasos como claves a la hora de implementar data mesh:

Mapear los procesos

Como todo proyecto ambicioso de gestión de big data, antes de implementar data mesh es imprescindible que marquemos nuestra hoja de ruta como empresa data. Es decir, los procesos AS IS / TO BE de la plataforma que queremos mejorar con la finalidad de reducir las limitaciones técnicas y que, en el caso de existir, podamos tenerlas resueltas previamente o de forma ágil cuando surjan.

Marcar los dominios de producto   

El tratamiento de los datos como producto es parte de la naturaleza del data mesh. Por tanto, un proceso fundamental previo sería definir los dominios: los clústeres en los que se producen los datos (clientes, contactos, productos, proveedores, etc.). De esta forma podremos proporcionarles una dirección y un directorio que permita su procesado.

Transferir los dominios de producto  

Con los diferentes dominios localizados, ya se ha llevado a cabo gran parte de la descentralización con la que trabajará la plataforma data mesh. Para que esta descentralización no produzca problemas con la calidad del dato y el hecho de que existan posibles duplicados, no afecte a su tratamiento y gobierno, debemos organizar los dominios y transferirles la propiedad de los datos, creando equipos data dentro de éstos y propietarios que se responsabilicen de su gestión y sepan transmitir reglas adecuadas y apropiadas para evitar caos.

Asegurar el gobierno de datos descentralizado

Para ello, los dominios deben ser autodescriptivos e interoperables. Descentralización no debe ser sinónimo de aislamiento: que cada dominio pueda actuar con independencia solo es posible si se hace bajo unas reglas comunes que permitan la interoperabilidad y el entendimiento entre ellos. Para ello son necesarios glosarios, controles de accesos y unos estándares previos globales para todos.

Con todo ello no estamos modificando toda la estructura, toda la arquitectura data de la empresa, sino implementando una concepción, la del productor como servidor de los datos frente a su anterior papel como simple colector, que nos permitirá un uso más cercano y práctico en el día a día de los datos que permiten el crecimiento como empresa. ¿Sabes por dónde empezar a transformar cómo se interpretan los datos en tu empresa? Nosotros te guiamos en el viaje de ganar competitividad a partir de tus bases.