Agile DW / BI en Acción

Muchas veces la construcción de un sistema de Data Warehousing / Business Intelligence (DW / BI) se
realiza siguiendo el flujo de ingeniería tradicional: análisis, diseño, construcción, pruebas e implantación.
La comunicación entre los desarrolladores y la gente interesada del negocio es casi nula, los
desarrolladores están interesados en las tecnologías para trabajar con los datos pero descuidan lo más
importante de este tipo de sistemas: ¿Qué preguntas del negocio queremos responder con los datos
que se dispone para apoyar al proceso de toma de decisiones?

En este artículo hablaré sobre como construir sistemas de DW / BI siguiendo muchas de las prácticas y
principios ágiles mencionados en el libro de Ken Collier: Agile Analytics: A Value-Driven Approach to
Business Intelligence and Data Warehousing.

Sistema de Data Warehousing / Business Intelligence (DW / BI)

Como es conocido un sistema tiene entradas, procesos y salidas.

Considerando este enfoque, las entradas constituyen todas las fuentes de las que requerimos extraer
datos. En la gráfica se pueden observar: bases de datos relacionales (RDBMS), archivos CSV, archivos
Excel, archivos planos y servicios web (REST/SOAP).

Los procesos de extracción de datos, transformación y carga en un repositorio se conocen como ETLs
(Extract, Transform and Load). Permiten mover los datos a un repositorio temporal conocido como
Staging y finalmente llevarlos al Data Warehouse.

Un Data Warehouse es un repositorio de datos históricos que constituye la principal fuente para hacer
actividades de análisis de datos. El conjunto de actividades que se realizan para mover los datos desde
las fuentes hasta el Data Warehouse se conoce como Data Warehousing.

Finalmente, la salida constituye toda la información que se puede obtener del Data Warehouse a través
de las diferentes actividades de Business Intelligence.
Un sistema de DW / BI es el resultado de orquestar las actividades de Data Warehousing y Business
Intelligence para responder preguntas del negocio y apoyar al proceso de toma de decisiones en una
organización.

Manifiesto para Desarrollo de Sistemas de DW / BI

Estamos descubriendo mejores formas de construir sistemas de DW / BI, haciéndolo y ayudando a otros
a hacerlo. A través de esto, hemos llegado a valorar:

Individuos e interacciones sobre procesos y herramientas

Sistemas de DW / BI funcionando sobre documentación exhaustiva
Colaboración con los usuarios finales y stakeholders sobre negociación de contratos
Respuesta al cambio sobre seguir un plan detallado

Aunque sabemos que los elementos de la derecha tienen valor, valoramos más los de la izquierda.

Las prácticas ágiles no son prescriptivas, deben ser adaptativas y nos ayudan a cumplir con el objetivo
principal de construir sistemas de DW / BI que funcionen, agreguen valor a la organización y sean de alta
calidad.

Individuos, interacciones y colaboración

En ocasiones el área de tecnología adquiere herramientas o plataformas para construir sistemas de DW

/ BI y decide sobre las tecnologías a utilizar, dejando de lado la comprensión del valor de negocio que se
quiere conseguir con este tipo de sistemas por parte de los usuarios finales.

El agilismo hace énfasis en la estrecha colaboración entre todos los interesados: administradores,
expertos del negocio, desarrolladores, gerentes de proyecto, auspiciantes, consultores, entre otros. Esto
permite que se logre un entendimiento común entre todos los interesados, pero ¿cómo lo logramos
cuando tenemos restricciones de tiempo y presupuesto?

El desarrollar una incepción antes de comenzar este tipo de proyectos nos puede ayudar a:

1. Comprender las preguntas de negocio que se quieren responder con el sistema de DW / BI

2. Descubrir las fuentes de datos con las que se cuenta

3. Comprender los mecanismos de entrega de información esperados: reportes, tableros de

mando, reporteo ad hoc, infografías, etc.

4. Capacitar a los interesados del proyecto en fundamentos de ágil y la forma de trabajo

Con el entendimiento de lo que se busca en el sistema de DW / BI, el siguiente paso es priorizar para
ajustarnos a las restricciones de tiempo y presupuesto.

Una técnica que se puede usar es escribir historias de usuario con las preguntas de negocio y usar un
cuadrante de frecuencia vs. dificultad para priorizarlas.
El cuadrante de mayor frecuencia y mayor dificultad tendrá las historias de usuario con las preguntas de
negocio más frecuentes y más complicadas de responder con los datos que se cuenta, éstas historias se
las puede considerar como de mayor prioridad y se podrá comenzar a trabajar sobre estas.

El entendimiento común entre todos los involucrados del proyecto requiere de una continua
interacción, una excelente comunicación, empoderamiento y sobre todo una estrecha colaboración.

Sistema de DW / BI funcionando

Dentro del agilismo la mejor medida de progreso es ver el sistema de DW / BI funcionando lo más
temprano posible, esto se logra dividiendo el trabajo en iteraciones.

Las iteraciones suelen ser de 2 a 4 semanas, y al final de cada iteración se realiza una demostración con
los resultados logrados conocida como showcase, pero ¿cómo construimos un sistema de DW / BI
usando muchas de las prácticas ágiles?

Antes de comenzar a trabajar en las historias de usuario del sistema de DW / BI, resulta de mucha ayuda
comenzar con lo que se conoce como la iteración 0. Esta iteración puede durar de 1 a 2 semanas y tiene
como objetivo principal crear todo lo necesario desde el punto de vista técnico para comenzar a
construir el sistema de DW / BI, esto incluye:

 Sistema de control de versiones (SCM)

 Aprovisionamiento de ambientes de trabajo: desarrollador (developer sandbox), staging,

preproducción y producción con su respectiva instalación y configuración de software base,
RDBMS, plataformas y herramientas con las que se trabajará

 Instalación y configuración de un servidor de integración continua

 Instalación y configuración de herramientas de gestión de proyectos ágiles y colaboración

Versionamiento
Es común que en los sistemas de DW / BI se versione muy poco o casi nada, es de muchísima
importancia usar un sistema de control de versiones (SCM) para versionar todos los artefactos creados
durante el proyecto. Algunos de los SCM Open Source más usados son git, SVN, CVS.

La siguiente estructura base, puede usarse como referencia para versionar los artefactos del proyecto:

Aprovisionamiento de Ambientes

Uno de los factores de éxito del agilismo consiste en la automatización de tareas repetitivas, para que
los equipos de desarrollo puedan enfocarse en los temas que agregan valor al sistema de DW / BI.

Con respecto a los ambientes en donde se ejecutará el sistema de DW / BI, consiste en crear código que
permite provisionar el sistema operativo, software base, servidor de base de datos, configuraciones,
herramientas, etc. Esto usualmente se conoce como IAC(Infrastructure as Code). Ansible es una
plataforma que permite crear código en YAML para provisionar los ambientes y trabaja en conjunto
con Vagrant que es un gestor de ambientes virtuales.

Para un sistema de DW / BI se pueden manejar 4 ambientes:

 Ambiente del Desarrollador (Developer Sandbox): sobre este ambiente se hace el desarrollo
del sistema de DW / BI

 Ambiente de Control de Calidad (QA): sobre este ambiente se integran todos los cambios de los
desarrolladores y se hace control de calidad del sistema de DW / BI

 Ambiente de Pre-Producción (PRE-PROD): es un ambiente similar al de Producción, sobre este

ambiente se hacen pruebas y demostraciones a los usuarios finales

 Ambiente de Producción (PROD): ambiente de producción del sistema de DW / BI

Una característica importante de Ansible es que el mismo código de infraestructura puede ser usado
para provisionar cualquiera de los ambientes (DEV, QA, PRE-PROD, PROD). Además, se logra mantener
consistencia de versiones del software usado en todos los ambientes.

El código de infraestructura se lo versiona en el directorio /provisioning mencionado en la sección de

versionamiento.
En el siguiente repositorio de GitHub se puede encontrar el código de aprovisionamiento para la
plataforma Pentaho CE v5.4 usando el RDBMS PostgreSQL v9.4 y corriendo sobre el sistema operativo
CentOS v7.1.

Desarrollo Iterativo / Incremental

Modelamiento Dimensional Evolutivo

Una historia de usuario bien escrita constituye la unidad de trabajo para comenzar a construir y
evolucionar el sistema de DW / BI. Suponiendo que se tiene la siguiente historia de usuario:

Como Analista Financiero

Necesito la capacidad de ver el margen de beneficio por año
Para identificar los años menos rentables

En la historia de usuario se puede identificar datos cuantitativos como el margen de beneficio y datos
cualitativos como la fecha (año) y se podría tener una primera versión del modelo dimensional, como se
muestra a continuación:

Cómo se puede observar, es importante construir el mínimo modelo que satisface la historia de usuario.
Una segunda historia de usuario podría decir:

Como Analista Financiero

Necesito la capacidad de ver el margen de beneficio por sucursal y año
Para identificar las sucursales menos rentables

La segunda versión del modelo dimensional incluiría a la dimensión Sucursal, como se muestra a
continuación:
Como se puede observar en cada historia de usuario que se trabaja el modelo dimensional evoluciona,
ésto se lo conoce como Modelamiento Dimensional Evolutivo.

Para llevar un control de los cambios incrementales en la estructura del modelo dimensional es
conveniente usar una herramienta de gestión de cambios de la base de datos. Algunas de las
herramientas Open Source más conocidas son Flyway, Liquibase o DBDeploy.

Cada nuevo cambio en la estructura del modelo dimensional es versionado a través de lo que se conoce
como un delta o migración, una migración es un archivo con instrucciones SQL nombrado en el formato
requerido por la herramienta de gestión de cambios de la base de datos.

Los archivos de migraciones se los versiona en el directorio /db_migrations mencionado en la sección de

versionamiento.

La principal ventaja de una herramienta de gestión de cambios de bases de datos es que permite
versionar todos los cambios a nivel de estructura, algo que muy pocas veces o casi nunca se hace en este
tipo de proyectos. Además, con las migraciones se puede crear el modelo dimensional hasta la última
versión en cualquiera de los ambientes: DEV, QA, PRE-PROD, PROD.

Procesos de carga del modelo dimensional

Una vez que se tenga una primera versión del modelo dimensional e identificadas las fuentes de
orígenes de datos, se comienza a construir los procesos para cargar el modelo dimensional. Estos
procesos comúnmente se los conoce como ETL (Extracción, Transformación y Carga) o de ingesta de
datos.

Los procesos ETLs permiten mover, transformar y cargar los datos hacia el repositorio temporal (Staging)
y luego hacia el modelo dimensional. Estos procesos pueden ser programados usando algún lenguaje de
programación o ser construidos en una herramienta de integración de datos. Algunas herramientas
Open Source para construir procesos ETL y realizar actividades de Data Warehousing conocidas
son: Pentaho Data Integration, Talend, Jaspersoft ETL.

Es importante que la metadata de los procesos ETLs que se construyan esté basada en archivos para
poder versionarlos en el directorio /etls mencionado en la sección de versionamiento.

En los procesos ETL es importante realizar pruebas unitarias para garantizar que cumplan con su
propósito y que los datos estén consistentes entre cada repositorio que se los va moviendo y
transformando. Para generar datos de prueba (fake data) se puede usar herramientas como Mockaroo.

Integración Continua

La integración continua usada en el contexto de un sistema de DW / BI permite realizar dos actividades

principales:

1. Aprovisionamiento de ambientes

2. Ejecución y calendarización de procesos de carga de datos (ETLs)

Existen varios servidores de integración continua, algunos Open Source conocidos

son: go.cd, Jenkins, TravisCI. En la siguiente imagen muestro dos pipelines configurados en la
herramienta go.cd para un sistema de DW / BI:

En el pipeline de Provisioning se puede lanzar la ejecución del código de aprovisionamiento y

aprovisionar los ambientes de QA, PRE-PROD y PROD.

En el pipeline de Deployment se puede calendarizar la ejecución de los procesos ETL principales para
que corran primero en el ambiente de QA, sí todo está exitoso se ejecuten en el ambiente de PRE-PROD
y finalmente en el ambiente de PROD.

Mecanismos de entrega de información

Una vez que se tenga poblado de datos el modelo dimensional con los procesos ETLs, se construye las
diferentes soluciones para realizar actividades de Business Intelligence. Estas soluciones se las puede
categorizar en:
 1. Reporteo: reportes institucionales, reportes a demanda (ad hoc), tableros de mando

2. Soluciones OLAP: cubos de análisis de datos y tablas pivot

3. Personalizadas: portales web, aplicaciones de visualización, infografía

El mecanismo de entrega que decidan los usuarios del negocio tiene que agregar el máximo valor para
responder a sus preguntas de negocio y apoyar a su proceso de toma de decisiones.

Pensamientos Finales

El construir un sistema de DW / BI usando las prácticas ágiles trae beneficios visibles en cada iteración.
La estrecha interacción y colaboración con los usuarios de negocio, la priorización de las preguntas a
responder y la aplicación correcta de las prácticas de ingeniería como automatización del
aprovisionamiento de ambientes, modelamiento dimensional evolutivo e integración continua permiten
entregar resultados tempranamente, minimizar los riesgos a través del aprendizaje continuo, evitar
inversiones innecesarias, evolucionar y satisfacer los requerimientos cambiantes que toda organización
posee.