Thoughtworks ha estado implementando Data Mesh desde que fue presentado por primera vez por Zhamak Dehghani, Thoughtworker en ese momento, en 2019. Desde entonces, hemos implementado Data Mesh con clientes a nivel global.
Lo que sigue es un conjunto de 10 recomendaciones que se basan en las percepciones que hemos obtenido de nuestras experiencias. Para cada una, comentamos los antipatrones observados y el enfoque que recomendamos en su lugar y por qué. Estas recomendaciones se enumeran de arriba abajo por niveles en una organización.
Recomendación nº 1: Los enfoques "sólo de abajo arriba" no funcionan
La aceptación de Data Mesh por parte de la dirección y el nivel C puede ser un reto. Esto a menudo lleva a los evangelistas de Data Mesh a intentar implementar Data Mesh de abajo a arriba construyendo productos de datos dentro de un dominio de Data Mesh que específicamente quiere Data Mesh.
Sin embargo, hemos visto que estos dominios y productos de datos se encuentran con una barrera infranqueable cuando intentan expandir Data Mesh a otros departamentos, que se muestran escépticos ante todo el enfoque. Traspasar las fronteras departamentales y aplicar cambios que modifican las prioridades, la financiación, las funciones y las responsabilidades es muy difícil de hacer de abajo arriba. A veces puede provocar momentos un poco incómodos cuando alguien pregunta "¿quién eres y por qué me dices lo que tengo que hacer?".
Los equipos de plataforma a veces se enfrentan al mismo problema. Deberían ser los facilitadores y entrenadores de las mejores prácticas: sin apoyo de arriba abajo, no pueden cambiar las formas de trabajar de los equipos de productos de datos, las configuraciones de los equipos o incluso implantar un conjunto unificado de políticas de gobernanza de datos. Los equipos de productos de datos se encuentran con un obstáculo similar cuando intentan persuadir a un equipo ajeno a Data Mesh para que les dé acceso a los datos o les ayude a interpretarlos. La ampliación de Data Mesh requiere un mandato descendente para crear un acuerdo y una alineación entre las partes con diferentes agendas e intereses.
Se necesitan tanto la aceptación de arriba abajo como la de abajo arriba: equipos entusiasmados que estén dispuestos a cambiar su forma de trabajar de abajo arriba y un liderazgo en la cúpula que apoye ese cambio.
Recomendación nº 2: Empezar por el modelo operativo
A pesar de que la Data Mesh requiere cambios tanto en el modelo operativo como en la tecnología, a menudo se deja de lado el modelo operativo porque es demasiado difícil de cambiar. Como resultado, las organizaciones a menudo intentan abordar la Data Mesh primero desde el punto de vista tecnológico. Este enfoque, aunque mejora las prácticas tecnológicas, suele fracasar en el primer año. Esto ocurre porque las estructuras necesarias para soportar la ampliación de una Data Mesh no se han modificado adecuadamente para adaptarse a las nuevas formas de trabajar.
Aunque es cierto que cambiar el modelo operativo puede ser difícil, también es fundamental. Debe hacerse el primer día de una iniciativa de Data mesh.
Data mesh no es un proyecto, sino un programa de empresa. Requiere el apoyo de otros miembros de la organización porque afecta al modo en que los equipos colaboran con otros equipos. Esto significa que se necesita un patrocinio de alto nivel y la aceptación de la cúpula para garantizar la alineación de toda la organización. También requiere un cierto nivel de gestión del cambio, como la creación de diversos órganos de gobierno, la redefinición de funciones y responsabilidades y la mejora de las competencias de la organización. Una oficina de transformación puede ayudar en este sentido, ya que reúne a personas con conocimientos y experiencia en el modelo operativo y la tecnología para garantizar el alineamiento organizativo.
En resumen, abordar un cambio de modelo operativo puede resultar desalentador, pero es un aspecto esencial para implantar con éxito Data Mesh en una organización. Hágalo pronto.
Recomendación nº 3: Definir los dominios de forma que representen los objetos de dominio de la organización y optimicen la eficacia y la comunicación
La propiedad del dominio es un principio clave en Data Mesh. Es importante porque garantiza que cada producto de datos de Data Mesh pertenece a alguien que tiene experiencia en esa área específica de la organización. La ventaja es que hace que los productos de datos sean más útiles para quienes quieran utilizarlos: elimina posibles confusiones sobre el significado de ciertos términos en determinados campos de datos y ayuda a mitigar las incoherencias. En otras palabras, si algo no tiene sentido, el propietario del dominio es el más indicado para corregirlo o aportar el contexto necesario.
Por supuesto, esto no está exento de dificultades: definir los límites de los dominios organizativos -y a quién pertenece cada cosa- es difícil. A menudo se debe a la existencia de líneas presupuestarias y jerárquicas predefinidas o a posibles corrientes políticas subyacentes. Por eso, al principio, lo más fácil es definir los ámbitos en función de las funciones existentes. A continuación, puede dividir los límites de los dominios que se vuelvan demasiado complejos o reasignar los límites de los dominios a medida que avance el proyecto y surja nueva información. Mejor aún, empezar con un dominio y luego explorar hacia fuera a medida que pasa el tiempo como un proceso iterativo. A las organizaciones que ya trabajan con un diseño basado en dominios en su modelo operativo les resulta más fácil realizar este cambio operativo.
En definitiva, hay múltiples formas de definir un dominio. Lo importante es que estos dominios tengan sentido en el contexto de la organización, estén documentados y hagan que la comunicación y los procesos sean más rápidos y eficaces. Algunos ejemplos podrían ser:
A lo largo de las unidades de negocio o funciones existentes
- A lo largo de los resultados empresariales (objetivos como "aumentar los beneficios" o "aumentar la satisfacción del cliente").
- A lo largo de flujos de valor (iniciativas que aportan valor o resultados a los clientes).
- Utilizar la maniobra de Conway inversa (los equipos se estructuran en función de la arquitectura deseada, en lugar de dejar que las vías de comunicación y las estructuras existentes le den forma).
- Utilizar el diseño basado en el dominio
En resumen, las definiciones de dominio permiten a las organizaciones identificar a los propietarios y expertos de los datos y optimizar la eficacia de las líneas de comunicación y colaboración. Es algo único en cada organización y, aunque la primera definición de dominio puede resultar difícil, empiece por el método que le resulte más fácil adoptar en su organización y luego hágalo evolucionar cuando se familiarice con las formas de trabajar y las responsabilidades.
Recomendación nº 4: Desarrollar conjuntamente el modelo operativo, la gobernanza de datos y la plataforma
La plataforma da vida a las funciones, responsabilidades y formas de trabajar definidas por el modelo operativo y a las políticas definidas por el gobierno de datos.
Un antipatrón que vemos a menudo es que el modelo operativo y la gobernanza de los datos son proyectos separados y aislados, cada uno de los cuales define una colección de documentación que se lanza por encima de la pared para que un departamento de TI la implemente. En este caso, puede ser útil pensar en la "malla de datos" como un producto, en el que el modelo operativo, la gobernanza de datos y la plataforma tienen los mismos objetivos, hipótesis, iniciativas y plazos subyacentes. Con este enfoque unificado, la aplicación del modelo operativo y los conceptos de gobernanza de datos se prueban y mejoran de forma iterativa a través de productos de datos, que son habilitados por la plataforma.
Recomendamos que los primeros casos de uso elegidos definan políticas de modelo operativo y gobernanza de datos como parte de los requisitos. Un ejemplo de requisito
“Cuando un equipo de productos de datos crea un producto de datos, se registra automáticamente en el catálogo de datos junto con una descripción de sus puertos de entrada, puertos de salida, esquemas, SLO, dominio y propietarios de dominio para aumentar la transparencia del producto de datos dentro de la organización.”
A continuación, la plataforma puede aplicar dicho requisito, tras lo cual las oficinas pertinentes de modelo operativo y gobernanza de datos pueden supervisar el impacto y el rendimiento de dicha política en el ecosistema de Data Mesh (y si su rendimiento está a la altura de las medidas de éxito definidas).
Recomendación nº 5: Establezca pronto una buena plataforma
La noción de una plataforma de datos de autoservicio es uno de los cuatro principios de Data Mesh y es la implementación técnica de las decisiones tomadas sobre las capacidades básicas de los productos de datos, las definiciones de dominio y las políticas de gobernanza. La plataforma ofrece capacidades a los equipos de productos de datos en forma de autoservicio para que no tengan que esperar a que el equipo de la plataforma cree recursos e integraciones ad hoc.
Con el enfoque de Data Mesh, el equipo de la plataforma ya no es responsable de mantener y transformar los datos para que los consuman los analistas, sino de dar forma y crear ofertas de productos de datos (paquetes autocontenidos desplegables) que los equipos de productos de datos pueden solicitar y utilizar para mantener sus datos.
Estas ofertas de productos de datos son lo que se denomina un "quantum arquitectónico" (como se define en Arquitecturas evolutivas). Contienen todo lo que un equipo de producto de datos necesita para construir su producto de datos, como capacidades básicas en torno a la ingestión de datos, almacenamiento, computación distribuida para la transformación de datos, puntos de integración con la herramienta de catálogo de datos, monitores en la herramienta de calidad de datos y políticas de gobernanza. A veces existen múltiples ofertas para distintos tipos de productos de datos. Estos guardarraíles y plantillas facilitan al máximo la entrega de productos de datos por parte de los equipos.
Dado que las plataformas de datos de autoservicio son el principal habilitador de Data Mesh, deben establecerse en una fase temprana. Un error común es que las organizaciones pongan en marcha equipos de productos de datos sin una plataforma básica. Estos equipos iniciales de productos de datos se quedan estancados durante meses, esperando a que la plataforma desarrolle capacidades básicas, lo que supone una carga para las iniciativas en curso. En el otro extremo del espectro, algunas organizaciones pasan años intentando construir la plataforma perfecta, que tarda demasiado en aportar valor y es demasiado difícil de mantener y operar.
La respuesta correcta se encuentra en algún punto intermedio: una "buena plataforma" es la que se construye a partir de requisitos determinados mediante la investigación de lo que los equipos de productos de datos realmente necesitan. Una plataforma de autoservicio bien estudiada desempeña un papel importante en la reducción de la fricción que puede producirse al crear productos de datos.
Para evitar dedicar demasiado tiempo a crear la plataforma perfecta, recomendamos empezar definiendo un conjunto de capacidades básicas de MVP que sean "lo suficientemente buenas" como para que los equipos de productos de datos se muevan rápidamente para ofrecer valor a la organización y continúen construyendo y ampliando de forma iterativa con lo aprendido de los nuevos equipos y dominios de productos de datos.
Recomendación nº 6: Reutilizar las tecnologías existentes en la nueva plataforma Data Mesh
Muchos clientes en la fase inicial de Data Mesh se desmoralizan por el gran número de tecnologías y herramientas necesarias para impulsarla. La verdad es que, aunque hay algunas herramientas que se ajustan mejor que otras a los requisitos de Data Mesh, lo mejor es aprovechar la pila, las licencias y la experiencia existentes donde tenga sentido. A continuación, puede añadir capas personalizadas para mejorar la experiencia de los desarrolladores, y utilizar nuevas herramientas para cubrir las lagunas de capacidad que queden.
Tenga en cuenta que "reutilizar tecnologías existentes" no significa "reutilizar una plataforma existente o más antigua". Las plataformas existentes o más antiguas pueden no ser compatibles con el enfoque Data Mesh porque éste requiere un cambio de paradigma crítico en la forma en que se construye la plataforma. Además, reutilizar plataformas antiguas que no se ajustan al enfoque de Data Mesh puede suponer una complejidad adicional, aumentar los costes y ralentizar el proceso.
Sugerimos hacer un inventario de las tecnologías existentes y compararlas con las capacidades requeridas de una plataforma de autoservicio de datos Data Mesh y los requisitos de sus productos de datos. Reutilice las herramientas que se ajusten a esos requisitos y estén maduras para ser utilizadas a través del autoservicio (por ejemplo, las API están disponibles o la definición declarativa de recursos es posible a efectos de la Infraestructura como Código).
Recomendación nº 7: Ir despacio y empezar poco a poco con los casos de uso
La razón principal por la que fracasan los proyectos de Data Mesh es que intentan escalar demasiado rápido. En su lugar, dé a su organización el tiempo necesario para aprender y adaptarse al cambio. Esta paciencia inicial dará sus frutos a largo plazo.
Recomendamos empezar con un caso de uso que tenga dos o tres productos de datos que abarquen tres dimensiones -modelo operativo, producto y tecnología- en el transcurso de seis meses.
Es comprensible que algunas organizaciones consideren que este enfoque es "demasiado conservador". Es posible que quieran adoptar un enfoque más agresivo para incorporar varios casos de uso a la vez al principio. Hemos comprobado que, por lo general, se necesitan seis meses para poner en marcha los primeros productos de datos en las tres dimensiones mencionadas. Una vez finalizado ese periodo, es necesario formar a los propietarios de los productos de datos y reunir un equipo de plataforma para empezar a crear nuevas capacidades para la plataforma basadas en lo aprendido. También se necesitan nuevas plantillas y formas de trabajar para que la organización pase de un modelo centralizado a otro descentralizado. También habrá que crear una junta de gobierno de Data Mesh con una hoja de ruta para incorporar dominios adicionales.
En pocas palabras: no hay que correr antes de poder andar. Habrá muchas lecciones que aprender durante el viaje. No se las pierda.
Recomendación nº 8: Sea deliberado sobre sus primeros casos de uso
Elegir el primer conjunto de casos de uso puede ser desalentador, pero es importante recordar que no existe una única respuesta correcta. Cada organización es diferente. Las decisiones que tome dependerán de lo que quiera optimizar y del apetito de riesgo de su organización.
Por ejemplo, algunos clientes eligen casos de uso muy urgentes y complejos. Suelen estar ansiosos por abordar la ineficacia y la política interna que están causando dolor en la organización. Otros han optado por la vía más conservadora, eligiendo un caso de uso sencillo y aislado para poner a prueba el apetito organizativo por la Data Mesh.
Otros clientes, mientras tanto, optan por optimizar la creación de un conjunto diverso de capacidades de la plataforma. Una plataforma de datos Data Mesh madura ofrece capacidades de procesamiento de datos por lotes, procesamiento de datos [casi] en tiempo real, análisis, IA/aprendizaje automático (ML) y gobernanza de datos. Elegir casos de uso que aborden cada una de estas capacidades sienta el precedente (o la prioridad) para sentar las bases de todas las capacidades de la plataforma en paralelo.
Otra ventaja de este enfoque es que los casos de uso que requieren más de una capacidad (como las capacidades de ML y batch, una dependencia común) se convierten en candidatos para los primeros casos de uso. Este enfoque, sin embargo, requiere un equipo de plataforma grande y fuerte que pueda manejar el pensamiento de producto y la complejidad de integrar capacidades de forma compatible e interoperable.
Aunque hay muchos enfoques y formas de optimizar, nuestra recomendación es que el primer caso de uso elegido sea:
- Manejable dadas las capacidades existentes de la organización
- Vinculado a los objetivos de negocio con métricas claras de éxito.
- Alcanzable
Es fácil consumirse por la elección de casos de uso debido a la política interna y a la sobreoptimización, pero a menudo no existe un caso de uso perfecto. Un escollo común que hay que evitar es la parálisis por análisis: fijar un calendario para el ejercicio y empezar con un "suficientemente bueno".
Recomendación nº 9: Incorporar los productos de datos a la plataforma Y a las estructuras de gobernanza del modelo operativo
Un antipatrón que vemos en las organizaciones impulsadas por las TI es que la incorporación de los equipos de productos de datos se detiene en la incorporación del equipo a una plataforma. En realidad, también es fundamental incorporarlos a los procesos organizativos establecidos por el modelo operativo.
Una incorporación adecuada al modelo operativo permite que los equipos de productos de datos estén representados en diversos foros para influir en actividades importantes, como la priorización de funciones. La incorporación también implica añadirlos a los canales de comunicación adecuados para que no se pierdan información importante sobre nuevas funciones, versiones y oportunidades de aprendizaje.
A largo plazo, los equipos que no estén integrados en el modelo operativo podrían no estar alineados con los principios del ecosistema de Data Mesh más amplio. Esto podría provocar el descontento y la frustración de todas las partes.
Recomendación nº 10: Comprometerse
La implantación de la Data Mesh en una organización requiere a veces grandes cambios a lo largo del tiempo que afectan a muchas personas, departamentos existentes y procesos de toma de decisiones. Esto puede resultar difícil cuando algunas partes de una organización se resisten al cambio.
Podría argumentarse que los problemas asociados a las organizaciones que cambian con rapidez -como las scale-ups, donde se valora la experimentación y existe una actitud más relajada hacia las políticas de acceso a los datos- y las organizaciones empresariales más establecidas y maduras -con mayor centralización y silos heredados más obstinados- son diferentes y, por tanto, deben tratarse de forma distinta. Aunque hay algo de verdad en todo esto, la realidad es que, en cualquier caso, si la organización quiere tener éxito, tiene que estar dispuesta a comprometerse con el cambio en términos de implantación y recursos.
Nuestros usuarios de Data Mesh más exitosos han hecho lo siguiente:
- Obtuvieron el patrocinio del más alto nivel desde el principio
- Adoptaron Data Mesh como parte de la identidad de la organización, donde todo el mundo estaba dispuesto a participar en la adopción de las prácticas y la mentalidad de Data Mesh a través de una iniciativa en toda la empresa que daba prioridad a los datos
- La gente estaba dispuesta a dedicar tiempo a aprender el nuevo enfoque y cambiar sus procesos
- Se trasladó rápidamente a las personas adecuadas a los lugares adecuados y se invirtió rápidamente donde había lagunas
- La organización estaba dispuesta a aceptar y aplicar un modelo descentralizado.
- La organización estaba preparada para alinearse con los dominios (si no lo estaba ya)
Las organizaciones que se han decidido a ir a por todas, consiguen valor con Data Mesh más rápido (y más barato). Por eso se requiere un compromiso total con Data Mesh para lograr la eficacia y el éxito en el cambio.
Resumen
Una iniciativa de malla de datos podría aportar innovación y un impacto positivo a su organización, pero requiere dedicación y compromiso para aplicarla correctamente. El cambio puede suponer un reto, pero con el enfoque y el proceso adecuados es posible superar los problemas de crecimiento para que la malla de datos sea un éxito.
¿Quiere saber más sobre cómo implantar Data Mesh en su organización o evaluar si está preparado? Póngase en contacto con nosotros.
