Malla de datos o tejido de datos: la decisión de descentralización que cuesta millones

Elegir la arquitectura de datos adecuada para la organización que realmente tiene

Las decisiones sobre arquitectura de datos han adquirido mayor importancia a medida que las organizaciones intensifican sus esfuerzos en analítica, automatización e inteligencia artificial. La presión es comprensible. Los líderes quieren informes más limpios, información más rápida, una mejor gobernanza y datos más fáciles de utilizar por equipos y sistemas. El problema es que las conversaciones sobre arquitectura de datos moderna suelen quedar atrapadas en el lenguaje de las tendencias antes de que la organización haya respondido a una pregunta más básica: ¿qué modelo operativo podemos respaldar realmente?

En esa conversación aparecen con frecuencia dos enfoques: la malla de datos y el tejido de datos. A menudo se habla de ellos como si fueran tecnologías competidoras. Ese planteamiento es demasiado simple. La malla de datos es principalmente un modelo operativo basado en la propiedad por dominios y en los datos como producto. El tejido de datos es principalmente una arquitectura de integración y gobernanza que utiliza metadatos, automatización y conectividad para facilitar la búsqueda, la gobernanza y el uso de los datos en distintos sistemas.

Ambos enfoques pueden ser valiosos. Ambos también pueden generar problemas costosos cuando se eligen por motivos equivocados. Un proyecto de malla de datos puede fracasar si los equipos de dominio no están preparados para asumir la propiedad de los productos de datos. Un proyecto de tejido de datos puede fracasar si la organización trata la plataforma como una capa mágica que compensará una mala calidad de datos, una propiedad débil o una gobernanza poco clara.

La pregunta adecuada no es «¿Qué arquitectura es mejor?». La pregunta más acertada es «¿Qué modelo encaja con la madurez de la organización, su cultura de gobernanza, la estructura de sus equipos y sus objetivos empresariales a corto plazo?»

Malla de datos: la propiedad como arquitectura

La malla de datos cambia quién es responsable de los datos. En lugar de depender de un equipo central de datos que recopile, limpie, modele, documente y proporcione datos para todos los demás, la malla de datos acerca la responsabilidad a los dominios empresariales que mejor conocen los datos.

En un modelo maduro de malla de datos, los equipos de dominio publican los datos como productos. Esto significa que los datos no se vierten simplemente en un entorno compartido. Tienen una propiedad clara, documentación, expectativas de calidad, patrones de acceso y una audiencia definida. El equipo de dominio es responsable de que los datos resulten útiles para otros, no solo de producirlos para sus propias necesidades operativas.

Esa es la promesa. El desafío es que no se trata solo de un cambio tecnológico, sino también organizativo. Flexera describe la malla de datos como un enfoque descentralizado que permite a los equipos específicos de cada dominio gestionar y asumir la propiedad de sus datos, mientras que Alation la considera útil cuando el problema subyacente incluye una propiedad poco clara, cuellos de botella en un equipo central de datos o una calidad de datos incoherente entre dominios. Son problemas reales, pero resolverlos requiere más que instalar una herramienta. Requiere equipos de dominio con tiempo, habilidades, incentivos y apoyo para convertirse en responsables de los datos.

Aquí es donde muchos proyectos de malla de datos empiezan a tener problemas. Puede que al equipo directivo le atraiga la idea de la descentralización, pero los equipos de dominio quizá no tengan una madurez de datos homogénea. Un grupo puede contar con sólidas habilidades analíticas y sistemas operativos limpios. Otro puede depender de hojas de cálculo, definiciones informales y limpieza manual. Tratar esos dominios como si estuvieran igualmente preparados para asumir la propiedad de productos de datos puede generar más incoherencia, no menos.

Tejido de datos: la automatización y la conectividad como arquitectura

El tejido de datos sigue un camino diferente. En lugar de partir de una propiedad descentralizada, se centra en conectar, gobernar y hacer utilizables los datos en entornos complejos. Un tejido de datos puede utilizar metadatos, catalogación, linaje, políticas de acceso, automatización y capas de integración para ayudar a los equipos a encontrar y utilizar datos en almacenes, lagos de datos, aplicaciones, plataformas en la nube y sistemas operativos.

Esto puede resultar atractivo para organizaciones que necesitan obtener valor más rápidamente o que tienen los datos repartidos entre muchos sistemas, pero aún no están preparadas para un modelo completo de propiedad por dominios. Atlan describe el tejido de datos como un enfoque que requiere menos disrupción cultural que la malla de datos, pero una mayor sofisticación técnica. SAP también describe el tejido de datos como un enfoque centrado en cómo se conectan, gobiernan y hacen utilizables los datos, mientras que la malla de datos se centra en cómo se distribuye la responsabilidad sobre ellos.

El beneficio es práctico. Un tejido de datos puede ayudar a reducir el trabajo manual de integración, mejorar la coherencia de la gobernanza y ofrecer a los equipos una forma más unificada de acceder a los datos, sin obligar a cada dominio a convertirse desde el primer día en una organización plenamente madura de productos de datos.

Pero el tejido de datos también tiene sus riesgos. Si la plataforma se convierte en el lugar donde deben resolverse todos los problemas de acceso a datos, gobernanza, transformación e integración, puede convertirse en un nuevo cuello de botella. La organización puede centralizar la complejidad bajo una etiqueta más moderna. Si los metadatos son deficientes, los sistemas de origen están desordenados o la propiedad no está clara, el tejido puede poner esos problemas de manifiesto en lugar de resolverlos.

Los dos modelos resuelven problemas diferentes

La forma más útil de comparar la malla de datos y el tejido de datos es preguntarse qué problema intenta resolver realmente la organización.

Si el mayor problema es que la propiedad de los datos no está clara, los equipos centrales de datos están sobrecargados, los equipos de dominio no confían en los conjuntos de datos compartidos y los expertos de negocio están demasiado alejados de las decisiones sobre productos de datos, la malla de datos puede ser la mejor dirección a largo plazo.

Si el mayor problema son los sistemas fragmentados, el acceso incoherente, la gobernanza manual, un linaje deficiente, la poca facilidad para descubrir datos y demasiada fricción al mover datos entre entornos, el tejido de datos puede ser el primer paso más práctico.

Muchas organizaciones acabarán necesitando elementos de ambos enfoques. SAP describe ambos como distintos pero complementarios: la malla de datos proporciona a los equipos de dominio un mayor control, mientras que el tejido de datos ofrece una base técnica para conectar y gobernar los datos en toda la empresa. Esta visión híbrida suele ser más realista que tratar la elección como una decisión en la que solo puede haber un ganador.

Aun así, la secuencia importa. Una organización que no esté preparada para la propiedad distribuida puede tener dificultades si se lanza directamente a la malla de datos. Una organización que solo invierta en una capa de tejido puede tener problemas si nadie es responsable del significado, la calidad y la utilidad de los datos que se conectan.

Errores habituales de la malla de datos

Los fracasos de la malla de datos suelen deberse a subestimar el modelo operativo. La arquitectura puede sonar elegante en las sesiones de estrategia, pero el trabajo diario es menos glamuroso.

• Los equipos implementan herramientas antes de que los equipos de dominio entiendan qué significa ser responsables de un producto de datos.
• El liderazgo subestima el cambio organizativo necesario para la toma de decisiones distribuida.
• La organización asume que la madurez de los datos es uniforme en todos los dominios, cuando rara vez lo es.
• La gobernanza se descentraliza solo de nombre, mientras que las aprobaciones y los estándares siguen bloqueándose en un equipo central.
• Los equipos de dominio reciben responsabilidades sin la capacidad, la formación o los incentivos necesarios para mantener productos de datos de alta calidad.

El resultado puede ser frustrante. La organización puede pensar que está descentralizando, pero simplemente ha distribuido la confusión. En lugar de un único cuello de botella central, ahora tiene prácticas de dominio incoherentes, documentación desigual, estándares poco claros y un modelo de gobernanza en el que nadie confía plenamente.

Errores habituales del tejido de datos

Los proyectos de tejido de datos fracasan de otra manera. El riesgo no consiste tanto en distribuir la responsabilidad demasiado pronto como en asumir que la plataforma absorberá todo el desorden subyacente.

• Los equipos tratan el tejido como una solución universal para la mala calidad de los datos de origen.
• Los metadatos, el linaje y la catalogación se consideran tareas técnicas, en lugar de fundamentos de la gobernanza.
• La organización conecta sistemas sin aclarar quién es responsable de las definiciones clave, las métricas y las expectativas de calidad de los datos.
• El acceso resulta más sencillo, pero la confianza no mejora porque los usuarios siguen sin saber qué datos son correctos.
• La plataforma de tejido se convierte en una dependencia que requiere inversión continua, disciplina arquitectónica y responsabilidad operativa.

Un tejido de datos puede facilitar la navegación por el entorno de datos. Por sí solo, no puede convertir los datos malos en buenos. Tampoco puede resolver definiciones contradictorias de ingresos, clientes, inventario, utilización o riesgo. Son cuestiones empresariales y de gobernanza que siguen necesitando responsables humanos.

Criterios de selección que realmente importan

Antes de elegir una dirección, los líderes deben evaluar honestamente la organización. Los criterios más importantes no son abstractos.

• Madurez de los dominios: ¿Pueden los dominios empresariales definir, mantener, documentar y dar soporte a productos de datos con una coherencia razonable?
• Solidez de la gobernanza: ¿Cuenta ya la organización con estándares claros de calidad, acceso, linaje, privacidad y propiedad?
• Capacidad técnica: ¿Pueden los equipos operar la plataforma, la automatización, la integración, la catalogación, la monitorización y los procesos de soporte necesarios?
• Preparación cultural: ¿Se siente cómoda la organización con una responsabilidad distribuida o la toma de decisiones sigue dependiendo en gran medida del control centralizado?
• Objetivos de IA y analítica: ¿Necesita la organización productos de datos gobernados y reutilizables para casos de uso avanzados, o primero necesita mejorar la conectividad y la capacidad de descubrimiento?
• Capacidad de cambio: ¿Cuánto cambio organizativo puede absorber la empresa sin dejar de realizar el trabajo diario?

Estos criterios no pretenden ralentizar el progreso. Ayudan a evitar una puesta en escena costosa. Una estrategia de datos que ignora la madurez suele convertirse en una implementación de herramientas. Una implementación de herramientas que ignora la propiedad suele convertirse en otro proyecto de limpieza de datos con un panel mejor.

Cómo Ridiculous Engineering aborda esta decisión

En Ridiculous Engineering, abordamos la arquitectura de datos como un problema tanto técnico como organizativo. El esquema, la plataforma, las integraciones y la automatización importan. También importan la propiedad, los procesos, la gobernanza, los incentivos y la capacidad de los equipos para mantener lo que se construye.

Esto es especialmente importante cuando las organizaciones se preparan para flujos de trabajo asistidos por IA. Los sistemas de IA solo son tan útiles como el entorno de datos que los rodea. Si los datos están mal gobernados, definidos de forma incoherente, son difíciles de rastrear o están dispersos entre sistemas sin una propiedad clara, la IA no los convertirá mágicamente en inteligencia empresarial fiable. Puede limitarse a producir respuestas más convincentes a partir de datos de entrada deficientes.

Nuestro papel es ayudar a los clientes a ralentizarse lo justo para tomar la decisión arquitectónica adecuada antes de comprometerse con un camino costoso. Esto puede implicar evaluar la madurez actual de los datos, mapear los dominios y la propiedad, identificar carencias de gobernanza, evaluar opciones de plataformas de datos, modernizar las integraciones o diseñar una hoja de ruta incremental que proporcione a la organización mejores datos sin imponerle un modelo de madurez que aún no pueda respaldar.

A veces, la respuesta adecuada es avanzar hacia una malla de datos. Otras veces, es invertir primero en una capa de tejido de datos. En ocasiones, el camino práctico es un enfoque híbrido que mejore la conectividad y la gobernanza mientras prepara gradualmente a los equipos de los dominios para asumir la propiedad de productos de datos de mayor calidad con el tiempo.

La decisión debe ajustarse a la realidad, no a las aspiraciones

Malla de datos y tejido de datos no son palabras mágicas. Son formas diferentes de organizar la responsabilidad, la gobernanza y el acceso en un entorno de datos complejo. Pueden funcionar conjuntamente, pero solo si la organización entiende qué problema debe resolver cada enfoque.

El peligro está en elegir basándose en las aspiraciones. Una empresa puede querer estar descentralizada, pero seguir operando con una toma de decisiones centralizada y una madurez desigual entre dominios. Otra puede querer un tejido de datos sofisticado, pero carecer de la disciplina de metadatos y de la responsabilidad operativa necesarias para mantenerlo fiable. En ambos casos, la arquitectura empieza a alejarse de la realidad.

El mejor enfoque es más honesto. Empiece por la situación real de la organización. Comprenda los problemas de datos que generan más fricción. Identifique las carencias de propiedad. Decida qué capacidades deben mejorar primero. Después, elija una arquitectura que respalde la siguiente etapa de madurez en lugar de fingir que la organización ya ha llegado a ella.

Si su organización está evaluando una malla de datos, un tejido de datos o un esfuerzo más amplio de modernización de datos, Ridiculous Engineering puede ayudarle a evaluar las ventajas y desventajas, diseñar una hoja de ruta realista y construir los sistemas y patrones operativos necesarios para que la arquitectura sea útil en la práctica.

La mejor arquitectura de datos no es la que tiene el nombre más de moda. Es la que su organización puede operar, gobernar, confiar y mejorar con el tiempo.

Fuentes y lecturas adicionales: Flexera: Malla de datos frente a tejido de datos, Alation: Tejido de datos frente a malla de datos, Atlan: Malla de datos frente a tejido de datos, SAP: Tejido de datos frente a malla de datos, Apptad: Malla de datos frente a almacén centralizado