Cómo migrar tu DWH a un Data Lake sin morir en el intento: Parte 2 – data strategy

Continuamos con la serie de «Cómo migrar tu DWH a un Data Lake sin morir en el intento«. En esta parte nos vamos a centrar en la relevancia que tiene disponer de una buena definición de nuestra «Data Strategy» antes de plantearnos un proyecto tan importante como lo es migrar todo nuestros sistema de información.

"Empieza por el principio"

Data Strategy Definition

Antes de plantearnos un proyecto de migración de nuestro DWH a un enfoque de Data Lake, hay que tener muy clara cuál va a ser nuestra estrategia de datos. Por lo tanto, el primer paso es definir la Data Strategy. Su principal objetivo es dotar a la organización de una visión estratégica sobre cómo se va a abordar el proceso de transformación y que consta de 3 fases: Discover, Develop y Delivery.

Los aspectos más importantes a tener en cuenta en cada una de las fases son los siguientes:

Discover

El objetivo principal de esta fase es obtener una foto sobre la situación actual de la arquitectura y los procesos implicados en el sistema informacional actual. Esta fase se caracteriza por la necesidad de mantener varias reuniones con todos los departamentos implicados para conocer el sistema en profundidad. 

Es importante demandar toda documentación disponible de cada área antes de las reuniones con las mismas. De esta manera se agilizará mucho el proceso, permitiéndole al equipo realizar un análisis previo para poder anticipar dudas y preguntas. Habitualmente suele existir poca documentación de los procesos manuales, por lo que se debe poner el foco en detectar estos procesos y documentarlos.

Develop

Una vez analizada profundamente la situación actual es momento de diseñar la foto deseada del sistema informacional. Para ello, habitualmente suele existir una serie de talleres de ideación en los que de manera conjunta los equipos implicados co-diseñan el que sería su sistema perfecto (requisitos funcionales y técnicos) estableciendo una serie de prioridades. Con esta información se debe empezar a diseñar la arquitectura final, manteniendo reuniones periódicas para informar al resto de áreas interesadas de los avances y decisiones tomadas.

Es el momento en el que se analizan los distintos proveedores tecnológicos disponibles (Azure, Cloudera, AWS, GCP, etc.). Normalmente, esta decisión no tiene mucho margen de maniobra pues, por lo general, las grandes empresas tienen acuerdos con algún proveedor que hacen que no exista gran posibilidad de cambio. Sin embargo, el objetivo debe ser siempre tener la infraestructura adecuada para cada caso de uso, por lo que es necesario realizar un estudio detallado de funcionalidad/complejidad/costes de cada uno de los proveedores candidatos y tomar la decisión en base a los datos obtenidos de la comparativa.

Delivery

En esta fase ya tenemos la foto de la situación actual y la deseada. Es momento de establecer las líneas de trabajo necesarias, en forma de proyectos, para llegar de un punto a otro. Para ello, es importante recuperar el resultado de los talleres de ideación de la fase anterior y revisar las prioridades.

Deben existir arquitecturas intermedias que permitan obtener valor en cada una de ellas y construir hacia adelante con el foco en la foto deseada. La definición de esta fase debe alinear perfectamente los desarrollos con las expectativas de negocio, de manera que cada foto intermedia aporte valor de manera incremental y exista una respuesta positiva de integración en los sistemas de la empresa.

Otro factor de vital importancia es elegir bien el primer proyecto o proyecto piloto, ya que va a ser el primer entregable del proceso de transformación y debe servir como ejemplo de éxito. Se debe elegir un caso de uso sencillo, con poca complejidad, en el que el riesgo esté muy acotado y se pueda establecer una línea end-to-end en todo el sistema informacional de manera clara y sencilla. El proceso de conciliación de resultados del sistema deseado contra el legacy puede resultar pesado en esta primera iteración. Lo importante es establecer una metodología de validación que permita escalar para las siguientes iteraciones.

Esperamos que este artículo te haya resultado útil para entender mejor la Data Strategy a seguir para  abordar la migración de un DWH a un Data Lake. Ante cualquier duda o sugerencia no dudéis en poneros en contacto con nosotros, estaremos encantados de responderlas.

En este otro enlace tenéis un artículo en el que os contamos la relevancia que tiene un sistema de información en las compañías y cómo plantear los primeros pasos para disponer de uno. Otro enfoque sobre todo lo contado en esta entrada.

En BI Geek, consultora de Analítica Avanzada y Big Data, apostamos por un modelo de consultoría orientado a hacer accesibles este tipo de soluciones para cualquier tipo de empresa.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*
*

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.