De vez en cuando aparece una nueva forma de hacer las cosas que lo cambia todo. A veces son las nuevas tecnologías, infraestructuras y servicios los que proporcionan importantes beneficios pero, en este caso, se requiere un esfuerzo colectivo por parte de los “techies” para promover el cambio y hacer comprender a la gente los beneficios que se pueden obtener. En otras situaciones, sin embargo, es el propio mercado el que demanda una solución nueva, más eficaz y eficiente a un problema al que se enfrenta, y este es, sin duda, un “motor de cambio” mucho más poderoso.
Han pasado ya 15 años desde que Clive Humby afirmara que “los datos son el nuevo petróleo”. Las empresas que han comprendido esta lección han creado todo un ecosistema para sus datos con herramientas de gestión, procesamiento, gobernanza, etc… y se han comprometido a crear sistemas de gestión y toma de decisiones basados en los datos, es decir, a convertirse en “data-driven”, demostrando así todo el valor que pueden generar. Esto también les permitió obtener los recursos necesarios para el desarrollo de todas las tecnologías, normas y servicios de Big Data y la Nube que ahora son ampliamente utilizados y conocidos.
Esta primera fase se centró en la centralización de los datos, partiendo de una división en los llamados “silos” para llegar a una plataforma única (a menudo tanto lógica como física), generalmente conocida como “lago de datos”. Al mismo tiempo, la arquitectura del sistema se hizo cada vez más distribuida y se crearon soluciones en la nube “híbridas” (una mezcla de infraestructuras locales, servicios en nubes privadas y/o públicas) y nuevos modelos de negocio en los que el software, las plataformas y toda la infraestructura ya no eran adquiridos o construidos internamente por las empresas, sino que eran “alquilados” como servicios prestados por terceros, según el modelo “como servicio” (abreviado como aaS), que se ha declinado en SaaS, PaaS e IaaS.
Se trataba, por tanto, de una gran inversión en la mejora de las infraestructuras a expensas de la atención a aspectos como la propiedad de los datos, la garantía de la calidad de los datos, la gobernanza escalable, la usabilidad, la confianza consumidor-productor, la disponibilidad de los datos y la accesibilidad: factores clave (y estos son solo algunos) que permiten a los usuarios encontrar, comprender y utilizar con confianza los datos para crear valor empresarial.
Qué es Data Mesh
Es precisamente esta carencia en plataformas monolíticas y lagos de datos lo que ha generado la necesidad de un cambio de paradigma, que ha dado lugar al Data Mes. Esta última puede considerarse a la vez revolucionaria, por los resultados que promete alcanzar, pero también evolutiva, ya que aprovecha las tecnologías existentes y puede adoptarse sin estar atada a una tecnología subyacente específica.
La característica innovadora más relevante es que se trata de un nuevo modelo organizativo y arquitectónico que reconoce la importancia de un enfoque distribuido y basado en el dominio para la organización de los datos, junto con uno centralizado para la gobernanza de los datos. Esto permite pensar en los datos como productos ofrecidos y gestionados por dominios específicos, satisfaciendo así los requisitos empresariales reales de una empresa, en lugar de las necesidades de aplicaciones individuales.
Cuando el Data Lake desemboca en un mar de problemas
Para comprender mejor las principales ventajas del Data Mesh y sus principios arquitectónicos, debemos dar un paso atrás y observar lo que era (y en la mayoría de los casos sigue siendo) el estado del arte en la gestión de datos.
En los últimos años, la principal tendencia en la gestión de datos ha sido crear un único lago de datos centralizado, concentrando así la propiedad técnica, funcional y de gobernanza en una única plataforma. Mientras que el segundo ha demostrado tener éxito, a pesar de la necesidad de importantes inversiones tecnológicas, los dos primeros han sido contraproducentes, tanto desde el punto de vista organizativo como técnico, por varias razones.
Como ya se ha mencionado, al crear los lagos de datos, la primera prioridad era “abrir los silos”. Es decir, llevar los datos de los sistemas externos (propietarios y cerrados) lo antes posible a una única plataforma centralizada, abierta y accesible para todos dentro de la organización.
La tarea de diseñar e implementar los procesos de esta migración de datos se confió generalmente al equipo interno de ingenieros de software del lago de datos, que implementaron una amplia variedad (para hacer frente a todas las fuentes de datos posibles) de procesos ETL (Extraer, Transformar, Cargar), a veces utilizando herramientas CDC (Captura de Datos de Cambios).
Sin embargo, esta opción, que parecía absolutamente lógica, no tenía en cuenta el hecho de que, una vez establecida la integración, la propiedad de los datos pasaría automáticamente a manos de los ingenieros de datos, al menos en lo que respecta a los consumidores posteriores de la cadena.
El equipo informático encargado de la gestión del lago de datos y de sus procesos se vio así obligado a invertir no solo en una formación técnica continua, para estar preparado para afrontar los retos de las innumerables tecnologías que surgían año tras año, sino también en una formación funcional continua y en el conocimiento del dominio (si un dato cambiaba en origen, el equipo de la plataforma se veía obligado a gestionar su evolución garantizando la funcionalidad descendente, del lado del consumidor).
Un esfuerzo demasiado grande y poco escalable, que a menudo llevaba necesariamente a descuidar aspectos, sin embargo, de gran importancia como la documentación de los datos, la garantía de calidad de los mismos, etc. Con el tiempo, sin embargo, estas cuestiones volvieron a surgir -con fuerza-, lo que provocó una reacción ante la necesidad de definir y aplicar controles, métricas y mediciones de la calidad de los datos, con una mayor presión sobre el equipo de ingeniería de datos.
Entonces surgió un problema aún más profundo con el uso a lo largo del tiempo. El enfoque de la integración resulta perjudicial cuando algo cambia en el sistema de origen, como los cambios de esquema, la evolución de las especificaciones del dominio de origen, la introducción del GDPR, etc. De hecho, es un modelo improrrogable, sobre todo para las multinacionales que centralizan los datos de diferentes filiales o países, con sus especificaciones y normativas locales o nacionales.
Además, los sistemas de origen no conocen el proceso de gestión centralizada de datos (almacenamiento de datos), no conocen las necesidades de los usuarios de datos y no se centran en garantizar la calidad de los datos, porque no forma parte de su objetivo empresarial. Esto suele sentar las bases para una desvinculación total en la generación de datos con vistas a la creación de valor para toda la organización.
Otro problema clásico de un lago de datos es su estructura en capas, donde cada capa tiene una característica típicamente técnica (limpieza, normalización, armonización). Cada una de estas capas representa una barrera adicional entre los datos y las necesidades empresariales, lo que ralentiza constantemente el proceso de integración y, por tanto, la creación de valor.
Data Mesh: ¿qué cambia?
El nuevo paradigma de Data Mesh se define actualmente por cuatro principios (según Zhamak Dehghani, que fue el primero en proponerlo)
-La propiedad descentralizada de los datos y la arquitectura organizada en dominios
-Datos como productos
-Infraestructura para datos y servicios de autoservicio y as-a-platform
-Gobierno informático y de datos federado.
Publicar en vez de importar
Para comprender lo que está cambiando en comparación con el pasado, es útil empezar por cambiar el vocabulario. En Data Mesh hablamos más de publicar que de importar, ya que es más importante localizar y utilizar los datos que extraerlos y cargarlos de otro lugar.
Cada movimiento o copia de datos tiene un coste intrínseco, generado principalmente por el desarrollo (hay que desarrollar, probar y distribuir ETL) y, sobre todo, por el mantenimiento. También es necesario supervisar estos procesos, adaptarlos cuando cambien las fuentes, hacer frente a la supresión de datos y a la dispersión de su propiedad.
– A menudo es necesario mover o copiar datos por las siguientes razones (que no existen en un Data Mesh):
– Capas técnicas
Necesidad tecnológica: por ejemplo, los datos residen en S3, pero SAP requiere tener los datos en su propia tabla interna para poder procesarlos. O tiene un enorme conjunto de datos en Redshift y la herramienta de aprendizaje automático para el entrenamiento requiere que los datos estén en S3 en su lugar.
– Falta de funcionalidad de viaje en el tiempo e historial: en este caso, se requiere una instantánea (es decir, una copia que represente el estado actual como una “instantánea”) de una fuente de datos.
– Restricciones de seguridad y propiedad: algunos sistemas no pueden facilitar a terceros el acceso a los datos de producción.
Es importante especificar que mover y copiar datos no implica la desnormalización de los mismos. La desnormalización es bastante habitual cuando se tienen varios usuarios con necesidades diferentes, pero esto no implica una transferencia de la propiedad de los datos. En cambio, cuando los datos se trasladan de un sistema o equipo a otro, se transfiere la propiedad y se crean dependencias que no tienen ningún valor añadido desde el punto de vista empresarial. Por el contrario, Data Mesh solo transfiere la propiedad de los datos si éstos adquieren un nuevo significado funcional y/o empresarial.
Paradigma de Data Mesh
El paradigma de Data Mesh también representa una garantía muy sólida contra el riesgo de obsolescencia tecnológica. En el futuro, cuando surjan nuevas tecnologías, todos los “sistemas fuente” (es decir, donde se crean los datos) podrán adoptarlas sin problemas.
De hecho, la continuidad del funcionamiento de todo el sistema está garantizada por la posibilidad de crear nuevos conectores, específicos para los datos generados por estas nuevas tecnologías, que permiten ponerlos a disposición del resto de la empresa a través de los servicios Mesh (de los que toma su nombre toda la Malla de Datos) mediante lo que se define como un sistema de andamiaje, es decir, un andamiaje que rodea y conecta los datos procedentes de los distintos sistemas fuente.
Producto de Datos
Para entender el concepto de Producto de Datos, es decir, el de pensar en los datos como un producto y una piedra angular de Data Mesh, podemos utilizar una analogía con lo que ocurre, por ejemplo, en Amazon. El vendedor expone su producto en un “escaparate virtual” o catálogo de productos, de forma esencialmente autónoma: Amazon no recibe de hecho ninguna copia para fotografiarlo, redactar una descripción, fijar el precio, etc. El comprador tiene visibilidad inmediata de lo que está disponible y no tiene que interactuar con el vendedor para acordar, por ejemplo, las condiciones de pago, de las que se encarga la plataforma de comercio electrónico.
Además de prestar un servicio, Amazon también establece normas (por ejemplo, no se pueden vender armas ni sustancias ilegales) en cumplimiento de las leyes vigentes en los distintos países; también crea un estándar para la presentación de los productos disponibles que el vendedor debe adoptar para ser encontrado por los compradores potenciales, y proporciona un sistema que permite a los consumidores potenciales evaluar la calidad de los productos ofrecidos (por ejemplo, la evaluación de los mismos por otros consumidores, visible para todos). El valor de un producto viene dado por la cantidad de consumidores (satisfechos) del mismo: el mismo principio se aplica en un ecosistema de datos.
Inversión en Data Mesh
Es bastante evidente que la creación de un mercado como Amazon, capaz de crecer para manejar un volumen cada vez mayor de productos, no es una empresa trivial.
Asimismo, la creación de una Data Mesh requiere una gran inversión inicial en términos de infraestructura, así como el rediseño de todo el sistema de gestión de datos de la empresa. En particular, es necesario implantar una arquitectura de tipo autoservicio para la infraestructura y los servicios, mediante la cual cada dominio sea libre de seguir su propia hoja de ruta tecnológica, utilizando las herramientas que mejor se adapten a las necesidades de sus productos de datos, al tiempo que se mantiene transparente y visible el uso de los recursos para permitir un análisis de costes más preciso en el ámbito de la organización.
El concepto de autoservicio también se expresa en forma de consulta autónoma y “aprovisionamiento” por parte de los consumidores potenciales de datos, a través de un catálogo en el que cada producto de datos muestra su propia oferta (en términos de puertos de salida), dependencias (en términos de linaje de datos), conocimientos sobre los datos mostrados (en términos de documentación), revisiones y comentarios de otros posibles usuarios, todo ello dirigido a fomentar la autonomía, la reutilización, la accesibilidad y la creación de confianza entre las unidades empresariales.
Gobernanza computacional federada
El suministro y la provisión de datos, por tanto, deben realizarse a través de modos y formatos normalizados, o mediante capas de abstracción “normalizadas” en cuanto a políticas de acceso, normas de seguridad, etc. Esta tarea se confía a la “gobernanza computacional federada”, otro pilar del paradigma de Data Mesh. Es importante, en este caso, centrarse en la diferencia entre la gobernanza centralizada/externalizada (como en el ejemplo de Amazon), frente al paradigma federado: en el primer caso, las normas las impone un tercero (frente a los que realmente venden los productos).
La “gobernanza informática federada”, como su propio nombre indica, es en cambio una federación de propietarios de Productos de Datos (por tanto, absolutamente internos a la organización) con la -exigente- tarea de crear reglas, normas, garantizar métricas comunes y transversales, garantizar la monitorización de la plataforma y automatizar (o al menos simplificar) el cumplimiento de estas normas siguiendo, en la medida de lo posible, metodologías DevOps e Infraestructura como código.
De qué debe ser capaz una plataforma de Data Mesh
Por lo tanto, una plataforma de Data Mesh debe ser capaz de proporcionar el andamiaje necesario para implantar conectores (y poner así a disposición los datos del sistema fuente), eligiendo estándares para el acceso a los datos (analíticos y basados en eventos) siempre que sea posible independientemente de la tecnología, es decir, crear interoperabilidad a través de la estandarización global.
Debe facilitar y promover estas normas acordadas internamente pero, al mismo tiempo, nunca encerrar a los equipos de producto en jaulas tecnológicas. La gobernanza informática federada también debe estar muy abierta al cambio, dejando que la plataforma evolucione junto con sus usuarios (equipos de producto) para responder siempre a tiempo a sus necesidades, que cambian con el tiempo, y adaptarse eficazmente a las nuevas tecnologías a medida que surgen.
Por Alberto Firpo, CEO de Agile Lab
