Más allá de la plataforma: Por qué la arquitectura y las herramientas deben ir más allá del data mesh

En los últimos años, muchas empresas han hecho sus deberes: las plataformas de datos modernas están en marcha, la nube está consolidada y las primeras aplicaciones de IA funcionan en producción. Y aun así persiste la sensación de: "No estamos sacando el máximo partido."

La causa rara vez es la falta de tecnología, sino una arquitectura que parece moderna pero que en la práctica del día a día no "funciona" de verdad. Los productos de datos no se utilizan de forma consistente, la gobernanza solo funciona sobre el papel y la interacción entre las plataformas involucradas sigue siendo accidentada.

Estado actual de la arquitectura de datos: buena plataforma, poco impacto

Entre nuestros clientes identificamos patrones recurrentes:

• Existe un potente data warehouse o data lakehouse.
• Hay herramientas de autoservicio para análisis e informes.
• Existen primeros productos de datos como "Customer 360" o "Sales Dashboard".

Nevertheless

• Los departamentos siguen utilizando sus mundos paralelos en Excel.
• Los nuevos productos de datos tardan en ganar tracción.
• El número de "verdades" distintas dentro de la empresa aumenta en lugar de disminuir.

El motivo: la arquitectura se ha entendido con demasiada frecuencia como un proyecto puramente tecnológico, no como un modo de funcionamiento de un ecosistema de datos.

Data mesh: del monolito al ecosistema

La arquitectura de datos moderna consiste hoy en la interacción de plataformas especializadas: analítica, machine learning, IoT, streaming en tiempo real, IA generativa. El paso decisivo es alejarse del "un gran sistema" hacia un ecosistema armonizado que haga tres cosas:

• 1. Integración fluida entre fronteras de sistemas: Los datos fluyen de forma controlada pero sin fricciones entre los sistemas operativos (ERP, CRM, tienda, ticketing) y las plataformas analíticas, y viceversa.
• 2. Responsabilidad orientada al dominio: Los equipos de marketing, ventas, operaciones, etc. se convierten en dominios responsables de sus productos de datos, con esquemas claros, requisitos de calidad y niveles de servicio.
• 3. Gobernanza federada en lugar de un cuello de botella centralizado en IT: Las directrices centrales (seguridad, cumplimiento, estándares) definen el marco dentro del cual los dominios pueden actuar con agilidad sin necesidad de coordinar cada detalle.

Conceptos como el data mesh encapsulan estos principios en una filosofía arquitectónica. En la práctica, sin embargo, la implementación suele fracasar precisamente en dos puntos: la interacción interna y la gobernanza activa.

Desafíos del data mesh: interacción y gobernanza en el día a día

Incluso cuando la plataforma está bien configurada desde el punto de vista técnico, persisten áreas de tensión típicas:

• Interfaces entre plataformas y equipos: Marketing necesita un nuevo segmento con rapidez, Finanzas necesita informes válidos para el consejo de administración, el equipo de data science quiere ejecutar un experimento, y los tres compiten por los mismos datos y recursos.
• Responsabilidades poco claras: ¿Quién es el "propietario" de un producto de datos? ¿Quién decide sobre los cambios en el esquema? ¿Quién prioriza los requisitos de los distintos stakeholders?
• La gobernanza como obstáculo o punto ciego: O bien la gobernanza se implementa demasiado tarde ("ya lo resolveremos cuando seamos más grandes") o se implementa de forma tan rígida que apenas es posible innovar.
• Ausencia de un catálogo de datos o marketplace central: O no existe ninguna herramienta de catálogo de datos, o hay varias que no se comunican entre sí. El resultado son silos y activos inutilizables.

El resultado son nuevos silos basados en tecnología moderna: marketing, ventas, operaciones e IT construyen cada uno sus propias islas de datos, solo que esta vez en la nube.

Configuración estructurada del data mesh: la arquitectura como habilitador de valor

Para que la arquitectura no se convierta en un fin en sí misma, sino que apoye la orientación al valor descrita en el primer artículo del blog, se requiere una configuración estructurada en tres niveles:

1. Infraestructura y plataformas

• Base cloud-native: escalado automático, utilización flexible de recursos, mecanismos de seguridad estandarizados.
• Capacidades de autoservicio: los dominios pueden crear, probar y desplegar productos de datos sin bloquear cada vez a IT central.
• Interfaces estandarizadas: diseño basado en APIs y eventos que proporciona rutas definidas para los flujos de datos, en lugar de integraciones punto a punto individuales.

2. Productos de datos y dominios

Data-as-a-product: Cada producto de datos tiene:

• Un propietario único
• Consumidores definidos
• Criterios de calidad documentados (puntualidad, completitud, latencia)
• Acuerdos de nivel de servicio claros

Orientación al dominio: Equipos como "Ventas y Marketing", "Atención al Cliente" o "Cadena de Suministro" son responsables de sus productos de datos desde una perspectiva técnica, desde la definición hasta el desarrollo continuo

3. Gobernanza y colaboración

Modelos de gobernanza federada:

• Políticas centrales (seguridad, protección de datos, cumplimiento, estándares de nomenclatura)
• Responsabilidad descentralizada para la implementación y el desarrollo en los dominios

Artefactos vivos:

• Catálogos de datos que muestran qué productos de datos existen y cómo pueden utilizarse
• Contratos de datos que especifican qué campos, formatos y estándares de calidad aplican entre productor y consumidor
• Comprobaciones de calidad automatizadas y data lineage que crean transparencia sobre el origen, la transformación y el uso

Esto crea un entorno en el que los productos de datos no solo se construyen, sino que también se utilizan con confianza y seguridad, precisamente donde tienen lugar las "acciones" descritas en el primer artículo: en sistemas CRM, tiendas, automatización de marketing, herramientas de servicio o flujos de trabajo operativos.

La arquitectura de datos al servicio de la cadena "insight-to-action"

Quizás el cambio de perspectiva más importante: una buena arquitectura de datos no es una colección de herramientas modernas, sino la capacidad organizada de traducir datos en valor.

Esto significa que:

• Los casos de uso impulsan la arquitectura, no al revés: En lugar de "necesitamos un nuevo data lake", el punto de partida es "queremos reducir el churn, mejorar el upselling, identificar riesgos con antelación; ¿qué arquitectura nos lo permite?"
• Los sistemas operativos son parte integral de la arquitectura: No basta con extraer datos hacia una plataforma. Los insights relevantes deben fluir de vuelta a los sistemas operativos para que las campañas, los precios, los inventarios o los procesos de servicio puedan alinearse con ellos.
• La gobernanza apoya la implementación en lugar de dificultarla: Las políticas y estándares están diseñados deliberadamente para cumplir los requisitos regulatorios por un lado, y para permitir iteraciones rápidas y experimentación por el otro.

Cómo apoya adesso: del proyecto de plataforma al ecosistema de datos

En proyectos con clientes, vemos repetidamente que el paso de un "stack tecnológico bien desarrollado" a un ecosistema de datos funcional es el decisivo. Componentes típicos de nuestro apoyo:

• Análisis del setup de plataforma existente e identificación de brechas en interacción y gobernanza
• Diseño de una arquitectura de datos orientada a objetivos que estructure claramente dominios temáticos, productos de datos y gobernanza
• Desarrollo de conceptos de autoservicio y data-as-a-product, incluyendo roles, procesos y herramientas
• Introducción de gobernanza federada con responsabilidades claras, contratos de datos y monitorización automatizada de calidad

El objetivo es siempre el mismo: una arquitectura que no solo permita casos de valor y mecanismos de medición de valor, sino que los facilite activamente.

Próximo paso: pasar de la lectura a la acción

Si sientes que tu arquitectura de datos tiene buen aspecto "sobre el papel" pero aún no funciona correctamente en el día a día, tienes dos opciones sencillas:

Pre-call sin compromiso: 30 minutos en los que evaluamos la situación actual y esbozamos los posibles próximos pasos, o discutimos patrones de arquitectura, enfoques de gobernanza y ejemplos prácticos para tu escenario.

Si estás interesado, envía un correo breve o una solicitud de contacto con la palabra clave "ecosistema de datos" y me pondré en contacto contigo.