Tips para adoptar Data Mesh

Todo aquel que siga con atención los cambios que se llevan produciendo en lo últimos años en el ámbito de los datos, sabrá o al menos le sonará el paradigma Data Mesh. En mi blog ya he dedicado varias entradas a hablar de él y en el de hoy, lo que pretendo es sentar algunas bases que deben tenerse presentes cuando una organización vaya a planificar la adopción de dicho paradigma, porque como todo en la vida, el hacerlo es más difícil que el teorizarlo. Cuando te arremangas, es cuando realmente se pone a prueba el diseño realizado,… algo que, como ha sido a alto nivel, en ocasiones se comporta, «como un huevo a una castaña». Pero bueno, eso daría para otra entrada 😉

En mi caso, como farmacéutico con algunos años de experiencia en la industria farmacéutica, estoy muy alineado con la mejora continua o Lean Manufacturing. Menciono ésto, porque una de las cosas que más me gusta en analizar las arquitecturas de referencia propuestas y comenzar a darlas una o dos vueltas. Es un proceso enriquecedor como pocos, pues ahí se ha plasmado el conocimiento de un buen conjunto de personas y siempre, aprendo algo nuevo. Si bien, es rara la ocasión en la que no tengo oportunidad de añadir valor con aproximaciones que no se habían considerado y que pueden hacer la solución más eficiente, hablando de costes por ejemplo o incluso más reutilizable. El primer punto se cubre fácilmente con conocimiento técnico, por contra, el segundo parte de la experiencia de haberme «pegado» en el pasado con planteamientos que requieren un elevado grado de parametrizaciones en el orquestador. Por ejemplo, de cara a satisfacer el cumplimiento de reglamentos dentro del ámbito de los datos, como es el caso HIPAA respecto de los datos de pacientes, evitando el movimiento de los mismos entre regiones Azure de una misma organización.

Bueno, aterrizando el caso y los tips. Es básico que en el diseño de la plataforma de procesamiento de los datos se considere:

  • Que los sistemas productores de datos disponen de versiones y que no siempre en todos los países, el ritmo de adopción es siempre el mismo. Por ello, el equipo del dominio de datos y el de la plataforma deben «idear» una solución que habilite la posibilidad de trabajar en tantas versiones como soporte la plataforma global de datos.
  • Que el modelo de la capa Silver, es decir, aquel donde se integra la información procedente de los distintos sistemas fuente (donde ocurre la magia y se enriquecen las entidades) también dispone de versionado. Así que, volvemos a estar en la misma situación que en el caso anterior, la plataforma debe soportar distintas versiones de los modelos destino o estarás obligando a correr a países que quizás están empezando a andar.
  • Que la propia plataforma del mismo modo que veíamos anteriormente, también debe disponer de versionado. Pues del mismo modo que hablábamos de versionado de sistema fuente y destino, el equipo Global estará trabajando sobre los distintos módulos o piezas de la plataforma de datos, sin embargo puede que un país no haya adoptado aún la última versión estable o incluso que esté «customizando» una parte de la misma. De este modo, no se pisarán las posibles adaptaciones que una Unidad quiera explorar y que incluso quizás, a posteriori sea incorporada como mejora en el producto final.
  • Y finalmente, uno de lo puntos que observo como más importante. Hay que abstraer la capa lógica de las transformaciones, y que su ejecución se realice a través del orquestador mediante el uso de parámetros que definan el path de trabajo en función de valores como: el identificador de país (vendor), la versión de cada uno de los sistemas fuentes, la propia de la plataforma sobre la que ejecutarse y por supuesto, la versión del modelo sobre el que se va a realizar la integración. Por supuesto, esto tiene sentido realizarse mediante una tabla o conjunto de tablas de metadata que nutran a la propia plataforma analítica.

Las organizaciones multinacionales son organismos complejos, en los que muchas veces, cada Business Unit (o país) va a un ritmo distinto, por ello, es fundamental que los propietarios del dominio faciliten la labor completando el proceso de transformación lógica desde el sistema fuente hasta el modelo Silver, pues además de ser los verdaderos conocedores del dominio, ayudan a reducir el tiempo de adopción y si encima, permites seleccionar la velocidad por Unidad de Negocio, el éxito en la puesta en marcha de este tipo de soluciones estará un poco más cerca.

CONCLUSIÓN
Cambiemos el «Mindset» hacia una cultura de máxima colaboración que redunde en el beneficio global y no queramos reinventar la rueda constantemente. Parémonos a pensar antes de meternos en faena y tengamos los ojos y la orejas bien abiertos, para desde una posición de escucha activa, entender las ventajas que nos aportan los distintos actores implicados.

Foto de portada gracias a cottonbro: https://www.pexels.com/es-es/foto/mano-rico-dinero-papel-3943739/

Publicado por alb3rtoalonso

Soy un enamorado del poder de los datos. Entusiasta de la mejora y formación continua.

Deja una respuesta

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Salir /  Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Salir /  Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Salir /  Cambiar )

Conectando a %s

A %d blogueros les gusta esto: