Metodologias Agiles en proyectos BI

Partiendo del supuesto de que el trabajo necesario para desarrollar un proyecto de B.I. se puede representar de la siguiente manera:

Donde:

• En un primer momento es necesario realizar un análisis.


• Tras el análisis hay que implementar el Data Warehouse y las ETL necesarias para alimentarlo de datos.


• Una vez hecho esto ya podemos diseñar nuestros Datamarts (si es que los tenemos) y cubos OLAP.


• Esos cubos OLAP y toda la información contenida en el Data Warehouse que acabamos de construir son la base para realizar todos los informes identificados que nos proporcionarán la información identificada en el análisis como deseada.


• Finalmente, una vez que ya tenemos nuestros informes realizados, pasaremos a implementar los cuadros de mando.
  
  

El triangulo representa la repartición del tiempo para obtener los hitos identificados. Así pues hay un gran volumen de trabajo para identificar, extraer y consolidar los datos que además es un trabajo necesariamente previo al trabajo de creación de informes y cuadros de mando que es lo que realmente quiere el destinatario de este proyecto. Por lo que, si afrontamos un proyecto de B.I. siguiendo este planteamiento tendremos grandes probabilidades de FRACASO

Si volvemos a ver la pirámide anterior y le añadimos algún dato mas veremos el motivo de ello:

Todo nuestro trabajo se puede dividir en dos grupos claramente distinguidos por la línea de visibilidad:

• Trabajo invisible: Para realizar informes, Cuadros de mando, Vistas Olap, etc. necesitamos Datos . Los datos son la materia prima de nuestro trabajo y necesitamos cocinarlos antes de poderlos mostrar al ojo de nuestro directivo / cliente.


• Trabajo Visible: Una vez realizado todo el trabajo invisible llega el momento del trabajo Visible. El trabajo visible es el trabajo que podemos mostrar y validar con el usuario final, hasta este momento no tenemos ningún tipo de validación / confirmación de que estamos haciendo bien nuestro trabajo. Hasta este momento no tenemos ningún tipo de seguridad de que lo que estamos haciendo es lo que realmente quiere nuestro cliente / usuario final.
  

Esto sumado al, por lo general, desconocimiento de las capacidades y posibilidades que proporcionan las herramientas analíticas que hacen que, hasta que el usuario no ha visto lo que nos ha pedido no sabe que es lo que realmente quiere y en muchas ocasiones ambas cosas no coinciden.

Normalmente nuestro trabajo es invisible hasta que construimos las primeras vistas OLAP y los primeros informes. Hasta ese momento hemos realizado un gran trabajo subterráneo que es necesario pero que nadie ve. Nadie ve todo el trabajo que comporta:

• Analizar y discernir cuales son las fuentes de datos fiables
  
  
• Limpiar los datos que vamos a mostrar de:
  
  
  • Inconsistencias
  • Duplicados
  • Datos Incompletos
  • etc


• Consolidar los datos en un Data Warehouse.
  
  
• Crear los datamarts pertinentes.
  
  
• Automatizar los procesos ETL y crear los mecanismos de control apropiados


• Validar los procesos ETL. Validar la corrección de la extracción.
  
  

Una buena forma de afrontar un proyecto de BI es hacerlo por partes. Tomando como referencia la Data-Driven Metodology citada por Inmon en Builiding the Data Warehouse y las actuales metodologías Àgiles de desarrollo, como puede ser Srum .

Lo que propone la Data-Driven Metodology (al igual que SCRUM) es afronar los desarrollos “por partes” . Es decir dividir el triangulo verticalmente e ir desarrollando desde abajo hasta arriba sucesivamente dibujando una espiral vertical sobre el triangulo.

Tras realizar el análisis del proyecto, se elige un área a implementar y se implementa toda ella desde el principio hasta el final.

• Se realizan las ETL pero sólo las de ese área, no todas.


• Se crean los cubos OLAP relativos a ese área.


• Se crean los informes relativos a ese área.
  
  
• Se crean los cuadros de mando relativos a ese área.
  
  

Y una vez realizada ese primer área…. SE VALIDA CON EL USUARIO FINAL

Esto nos proporciona:

• Una rápida interacción con el usuario final.
  
  
  • El usuario recuerda las especificaciones que nos proporcionó.
  
  
  • El usuario descubre que lo que nos pidió no es lo que realmente quiere en un estadio inicial del proyecto por lo que podemos corregir, rectificar, modificar todo lo que queramos rápidamente con un coste menor que si lo hiciéramos única y exclusivamente al final.
    
    
  • Validamos especificaciones y le proporcionamos datos para validar al usuario de una forma rápida y constante. La validación de los datos se realiza por fases y no es una tarea tan ardua y aburrida.
    
    
  • El usuario “ve que estamos trabajando” cosa también importante.
    
    


• Podemos aplicar las correcciones al área desarrollada y implementar las nuevas áreas con las nuevas especificaciones.
  
  
• Obtenemos resultados a corto plazo, todo el mundo está implicado y nadie se olvida de que estamos realizando un proyecto y el objeto del mismo.


• Las validaciones empiezan desde un primer momento y se hacen progresivamente. No descubrimos los errores cuando ya tenemos todo el sistema construido.
  

Por lo que, una vez que tenemos ese primer área desarrollada desde el principio hasta el final ya podemos aplicar las correcciones identificadas y acordadas y abordar la siguiente actualizando también la parte del análisis que le afecta.