Dehghani (ThoughtWorks / O'Reilly) + Skelton & Pais (Team Topologies)
El problema que resuelve
Cuando una organización necesita datos para potenciar IA agéntica, el camino de menor resistencia es ir directo al core de negocio — la fuente más completa, más autoritativa. El problema es que ese camino crea acoplamiento directo entre los sistemas de IA y los sistemas más críticos de la organización, sin capa de protección, sin ownership claro de los datos, y sin una arquitectura que pueda crecer con la demanda. El resultado es exactamente lo que se quería evitar: fragilidad disfrazada de solidez.
Qué es
Data Mesh es un paradigma arquitectónico de datos que trata los datos como un producto, considera los dominios como primera preocupación, aplica pensamiento de plataforma para crear infraestructura de datos self-serve, e introduce un modelo federado de gobernanza computacional. No es una tecnología — es una forma de organizar la responsabilidad sobre los datos alineada con los dominios de negocio que los generan. Amazon
Platform as Product es el principio de diseño que determina cómo se construye y opera esa plataforma. El trabajo del Platform Team habilita a los Stream-Aligned Teams a entregar valor más rápidamente, proveyéndoles los sistemas que necesitan. Una plataforma sin usuarios satisfechos no es una plataforma — es infraestructura abandonada. Port
Cómo lo resuelven — y el link con outcomes
Aquí está el argumento central: Data Mesh define qué construir — la arquitectura que permite que los datos correctos lleguen a quien los necesita, con ownership claro por dominio, sin centralizar todo antes de poder usar nada. Platform as Product define cómo construirlo — como un producto interno con usuarios reales, criterio de éxito externo, y entrega incremental.
El desplazamiento es de output a outcome: el criterio de éxito deja de ser "¿está completa la arquitectura?" y pasa a ser "¿los equipos de IA agéntica pueden acceder a datos valiosos hoy?" Eso convierte la Plataforma de Capacidades Digitales en un habilitador de negocio medible desde el primer building block — no cuando esté "terminada".
Tres principios centrales
1. Domain Ownership — los equipos de dominio más cercanos al origen de los datos crean y gestionan sus data products. Un mesh de productos de datos emerge cuando los dominios los consumen entre sí. Esto justifica exactamente por qué no hay que ir directo al core: el core es un dominio más, y la plataforma es la capa que permite que los dominios se conecten sin acoplarse. arXiv
2. Thinnest Viable Platform — Team Topologies introduce la noción de Thinnest Viable Platform como equivalente al concepto de MVP: el conjunto mínimo de APIs, documentación y herramientas necesarias para acelerar el desarrollo de los servicios de la plataforma. Ese es el nombre técnico del primer building block: no el mínimo posible, sino el mínimo suficiente para que otros equipos entreguen valor. Kratix
3. La plataforma se gana su adopción — la plataforma debe ganar por mérito. Si los desarrolladores la usan solo porque las alternativas están bloqueadas o porque el liderazgo lo impone, no hay un producto real. Eso obliga a construir con orientación al usuario desde el inicio — no después de que la arquitectura esté completa. Jellyfish