El concepto de Data Mesh no es tan nuevo como parece, surgió alrededor de 2019 de la mano de Zhamak Dehghani, a quien se puede identificar como la fundadora de Data Mesh (como ella misma se define).
La idea de este concepto es, de alguna manera, eliminar, o al menos minimizar, las limitaciones de los enfoques monolíticos y centralizados que se han utilizado en las Arquitecturas de Plataformas de Datos, en la Gestión de Datos y en los equipos de datos, es decir, los Data Warehouses y Data Lakes gestionados por un equipo central. Data Mesh propone la adopción de un modelo descentralizado basado en una arquitectura distribuida y en la responsabilidad de las áreas de negocio (dominios) sobre sus datos (descentralización de los roles de gobierno). Esencialmente, se refiere al concepto de descomponer los Data Lakes y los almacenes de datos en partes más pequeñas y descentralizadas.
Data Mesh se desarrolla sobre cuatro principios:
- El primer principio se basa en una arquitectura y propiedad de los datos descentralizada y orientada al dominio, lo que significa que las funciones de la organización/negocio deben ser dueñas de sus datos. El diseño orientado al dominio (DDD) es el elemento central de esta idea.
- El segundo es pensar en los datos como un producto y exponer los productos del dominio de forma que sean utilizables por otros.
- El tercer principio define la infraestructura de datos como una plataforma que ofrece diferentes capacidades en forma de autoservicio.
- El cuarto se centra en la gobernanza computacional federada, equilibrando el hecho de tener el suficiente control centralizado para facilitar el trabajo, pero manteniendo la toma de decisiones lo más localizada posible.
En una visión simple, con Data Mesh organizas los datos como organizas tu negocio y a tu gente, lo cual es maravilloso en lo que a la responsabilidad se refiere.
Desde el punto de vista técnico, el Data Mesh es capaz de subsanar las deficiencias de los Data Warehouses y Data Lakes al facilitar una mayor flexibilidad y autonomía en la propiedad de los datos. Esto se traduce en un mayor margen para la experimentación y la innovación en materia de datos, ya que la responsabilidad se quita de las manos de unos pocos expertos. La infraestructura de autoservicio como plataforma abre vías para un enfoque mucho más universal y a la vez automatizado hacia la estandarización de los datos, así como la recopilación y el intercambio de los mismos. Así que, potencialmente, pueden darse más contribuciones para la estrategia de datos incentivando una mentalidad de compartir.
Detengámonos aquí por un momento. Hasta este punto Data Mesh parece genial, pero no lo es para todo
Las empresas tienen que darse cuenta de que no es una receta que sirva para todas las situaciones. Data Mesh no debe aplicarse sólo porque sea tendencia, sino porque se ha tomado una decisión fundamentada y se van a obtener ciertos beneficios.
Una estrategia de Data Mesh podría beneficiar a las organizaciones que tienen un modelo descentralizado con varios dominios y complejidad de fuentes. Puede ayudar a organizaciones que están muy descentralizadas, ya que la estructura de Data Mesh permite a los diferentes equipos gestionar sus propios datos y solo poner aquellos de calidad a disposición del resto de la organización como producto.
Aquí se aplica la ley de Conway. La ley de Conway establece que: «Las organizaciones que diseñan sistemas están obligadas a producir diseños que repliquen las estructuras de comunicación de estas organizaciones».
En organizaciones más grandes, con estructuras de comunicación más complejas, un enfoque centralizado contradice la ley de Conway. De ahí que necesitemos una arquitectura de gestión de datos descentralizada como Data Mesh.
En este punto, hay cuatro aspectos que analizar para considerar un enfoque Data Mesh:
- Estabilidad organizativa.
- Preparación cultural de la empresa.
- Tener un caso empresarial sólido para un enfoque de Data Mesh.
- Y, obviamente, un presupuesto para invertir en el cambio.
Desde una perspectiva de entender cuándo una organización no está preparada para el enfoque Data Mesh, recomiendo la lectura de un artículo de Thinh Ha en Medium: «10 razones por las que no estás preparado para adoptar el Data Mesh«. Las 10 razones son:
- No estás operando a una escala en la que la descentralización tenga sentido.
- No tienes un caso de negocio sólido al que la adopción de Data Mesh aportará un valor a las distintas unidades de negocio.
- Tratas el Data Mesh como una solución técnica con un objetivo fijo en lugar de un modelo operativo que evoluciona continuamente en el tiempo.
- Tu cultura organizativa no permite una toma de decisiones ascendente.
- No se han establecido claramente las funciones y responsabilidades ni la estructura de incentivos para los equipos de datos distribuidos.
- No cuentas con el suficiente talento en materia de datos.
- Tus equipos de datos tienen una baja madurez de ingeniería.
- Esperas encontrar un software estándar que te ayude a adoptar el Data Mesh.
- No estás de acuerdo con la seguridad, la privacidad y el cumplimiento de la normativa.
- No consideras que el gobierno del dato sea una actividad fundamental a la que haya que dar prioridad frente a otras actividades en la cartera de trabajo de cada equipo de datos.
Principales retos de la implantación de Data Mesh
Supongamos que estamos hablando de una organización que se ajusta a las características mencionadas anteriormente para un enfoque Data Mesh. Aquí resumimos los principales retos que tendría que abordar:
- El ajuste tecnológico es una de las principales consideraciones para los esfuerzos de cualquier organización por adoptar e implementar una estrategia basada en Data Mesh para la gestión de datos. Para poder implantar con éxito la arquitectura Data Mesh, las organizaciones deben reestructurar sus plataformas de datos, redefinir las funciones de los propietarios de los dominios de datos y revisar las estructuras para hacer viable la propiedad de los productos de datos y la transición para desarrollar sus datos analíticos como un producto.
- La implantación de un modelo de Gobierno del Dato Federado: La interoperabilidad y estandarización de las comunicaciones, gobernadas globalmente, es uno de los pilares fundamentales para construir sistemas distribuidos. Una parte crucial para avanzar hacia una arquitectura de datos descentralizada es entender que la federación tiene que ver con la propiedad descentralizada, que requiere disciplinas bien entendidas.
- Equipos interfuncionales de datos de dominio: Los dominios que proporcionan datos como productos necesitan ser aumentados con nuevos conjuntos de habilidades: (a) el propietario del producto de datos y (b) los ingenieros de datos. Necesitamos data skills en todos los dominios para construir y operar los pipelines de datos internos de los dominios, los equipos deben incluir ingenieros de datos.
- Construir un diseño convergente de plataforma de datos y autoservicio que soporte y proporcione la tecnología necesaria que los dominios necesitan para capturar, procesar, almacenar y servir sus productos de datos. Esta plataforma debe ocultar toda la complejidad subyacente y proporcionar los componentes de la infraestructura de datos en régimen de autoservicio.
- Un nivel significativo de gestión del cambio: Para adaptarse a las operaciones de datos descentralizadas de Data Mesh, es necesario un importante esfuerzo de cambio.
- Análisis de dominios cruzados: Es un reto garantizar todas las normas que permitan la analítica de dominios cruzados. Este cambio hacia la propiedad distribuida de los datos sólo funciona si aplicamos una amplia gama de normas a nuestros productos de datos. Sin normas empresariales, reglas de distribución y conectividad, se crea un ecosistema de caos, desorganización e incompatibilidad y las iniciativas de dominio cruzado son imposibles.
Eh, ¡espera! Ya tengo una estrategia de datos, ¿significa que hay que cambiarla?
No creemos que sea necesario un cambio en la estrategia de datos (¡suponiendo que exista una!). El objetivo principal de ser una compañía data-driven es el mismo. Probablemente podamos reescribir esto y utilizar “Data Product Driven Company”.
Si el Data Mesh se convierte en un camino a seguir para una compañía, entonces es necesario replantearse las estrategias de organización, gestión de datos, gobierno del dato y arquitectura de datos. ¿Y por qué?
La empresa debe diseñar un road map para pasar de estar basada en un equipo de datos centralizado, que gestiona el almacén de datos y el Data Lake (plataformas monolíticas) y un gobierno del dato centralizado, a un nuevo paradigma descentralizado.
Mientras que el modelo centralizado funciona para las organizaciones que tienen unos pocos dominios con un número menor de casos de consumo diversos, falla para las empresas con dominios ricos, gran número de fuentes y un conjunto diverso de consumidores de negocio.
Por ejemplo, yo estaba a cargo de un equipo central de datos en una empresa de telecomunicaciones (varias fuentes y dominios) que hacía todo el ETL para el almacén de datos y las ingestas para el Data Lake para que el negocio pudiera explorar los datos. Rápidamente nos convertimos en un cuello de botella y, «políticamente», en el objetivo a derribar. Aunque el número de ingenieros de datos aumentó, siempre existía el problema de conocer la fuente desde la perspectiva del negocio e interpretar los conceptos… Pero el negocio no tenía ninguna motivación para hacerlo. ¿Por qué iban a tenerla? Desde su perspectiva, ¡es el equipo central de datos quien debe ocuparse de este asunto!
Por lo tanto, para el Data Mesh, todo este cambio y la responsabilidad de las fuentes y los conductos asociados para alimentar los productos de datos de los dominios, son responsabilidad de los dominios. Esto tiene un impacto en la organización, ya que los dominios necesitarán personas capacitadas en datos (roles de datos en los dominios).
¿Y qué ocurre con los Data Lakes y los Data Warehouses que existen actualmente (el impacto arquitectónico)? Lo más probable es que se conviertan en nodos de la malla y sean utilizados por un dominio concreto.
Seamos claros, esta es nuestra visión del tema
Desde el punto de vista de Keepler, tener una estrategia de datos implica la definición de cómo aprovechar los datos utilizando los principios FAIR (encontrabilidad, accesibilidad, interoperabilidad y reutilización) para defender que los Productos de Datos sean utilizables, comprensibles, accesibles e interoperables con otros Productos de Datos. Al final, los productos de datos aportan valor a la empresa y son una forma de monetizar los datos.
El aprovechamiento de los datos implica la existencia de un ecosistema que permita su exploración y utilización: Una plataforma de datos.
Creemos que el mejor enfoque es disponer de una plataforma de datos en la nube pública aprovechando la variedad de servicios que ponen a disposición sus proveedores. La flexibilidad, escalabilidad, elasticidad, modularidad y el pago por uso son ventajas de las plataformas de datos en la nube, que se ajustan a las características de una arquitectura de datos distribuida. En el contexto del artículo, estas ventajas se aplican a las plataformas de los nodos de dominio y a la plataforma de datos central de autoservicio que conecta los dominios.
Principal Business Development at Keepler: "Passionate about Data Management and the design of data ecosystems operating models’ enablers of the Digital & Analytics. Driven by added value to the business, operational efficiency and in building bridges between experts and the client to pursue the best data cloud solutions."
0 comentarios