Metodología y técnicas de modelado dimensional de Kimball

Cuando empezamos a trabajar en el desarrollo de soluciones datawarehouse tuvimos que escoger entre innovar y hacer las cosas a nuestra manera creando un estilo propio o hacer seguidismo de las pautas marcadas por otros. Sin dudarlo siquiera, escogimos la segunda opción.

Bromas aparte, si reinventar la rueda no vale la pena en mecánica, tampoco en informática. Así que tras investigar un poco nos inclinamos por seguir los consejos de Ralph Kimball, que se ajustaban bien a nuestra realidad: una empresa pequeña que podía abarcar proyectos más grandes de los que hubiera podido siguiendo otros sistemas (ej. Inmon) y llevarlos a buen fin sin excesivos problemas.

Qué es la Metodología Kimball

Kimball abogaba por una aproximación de abajo hacia arriba primando el contacto con el usuario final sobre el análisis exhaustivo y el desarrollo sucesivo de partes concretas del datawarehouse sobre el desarrollo de toda la solución de una sola vez.

Por otra parte, necesitábamos un sistema de control de nuestros proyectos que no tuviera la rigidez de la gestión de proyectos clásica. Normalmente, las dificultades aparecían a la hora de definir el alcance del proyecto. Las ambigüedades, sobreentendidos y cambios en las necesidades del cliente alteraban una y otra vez los planes tan trabajosamente concretados en nuestro Project. Si quieres formarte en metodologías ágiles no dudes en consultar nuestro Master in Project Management.

Entonces oímos hablar de Agile y, al poco de empezar a conocerlo, nos dimos cuenta de que se complementaba muy bien con Kimball.

Lo que sigue es una comparativa de los puntos en que Agile y Kimball coinciden más claramente.

Hemos tomado como punto de partida el Manifiesto Agile que puede descargarse en su versión castellana de manera gratuita.

Con Kimball, escogimos su libro The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd Edition. Escrito junto con Margy Ross.

Es un libro extenso pero en el que se incluye una lista de diez errores típicos en los que el desarrollador de un datawarehouse no debería caer y que nos han parecido muy representativos del conjunto de su filosofía. 

Qué es un Data Warehouse

Es un repositorio unificado para todos los datos que recogen los diversos sistemas de una empresa. El repositorio puede ser físico o lógico y hace hincapié en la captura de datos de diversas fuentes sobre todo para fines analíticos y de acceso.

Los diez errores que un desarrollador de datawarehouse no debe cometer

• Agile dice: Individuos e interacciones sobre procesos y herramientas.
• Kimball dice: Error 10. Enamorarse excesivamente de los datos y la tecnología en vez de centrarse en las necesidades y objetivos de negocio.

Las necesidades y objetivos de negocio se expresan y traducen a través de los individuos que las han de atender. Ningún negocio nos pedirá jamás «Necesito las ventas de los cinco últimos años por territorios» pero es muy posible que lo haga algún miembro del departamento de marketing o comercial.

• Agile dice: Respuesta ante el cambio sobre seguir un plan.
• Kimball dice: Error 2. Suponer que el negocio, sus necesidades y analíticas, así como los datos subyacentes y la infraestructura tecnológica son estáticos.

La definición de una solución de BI (o de software) no debería ser algo estático y definitivo. No sólo cambian las necesidades de negocio y las personas que las satisfacen sino que lo hace la tecnología empleada. El desarrollo del datawarehouse ha de tener en cuenta los medios que permitan su actualización y modificación sin afectar significativamente al negocio y los usuarios finales.

• Agile dice: Colaboración con el cliente sobre negociación contractual
• Kimball dice: Error 9. No conseguir la colaboración y/o la implicación de una persona de la organización cliente que sea influyente, accesible y razonable, para desempeñar el papel de patrocinador  del datawarehouse.

Ante esta realidad dinámica, un contrato debería ser más un marco de colaboración que marcase los límites de alcance, presupuesto y tiempo dentro de los cuales se ha de crear el datawarehouse.

Un buen contacto en la organización del cliente hace posible los acuerdos de cambio, transmite las nuevas necesidades al equipo de desarrollo, los nuevos acuerdos a los usuarios y nos asegura que todas las partes están trabajando para conseguir los mismos objetivos.

• Agile dice: Software funcionando sobre documentación extensiva.
• Kimball dice: Error 7. Dedicar esfuerzo a construir una estructura de datos  y agotar el presupuesto antes de construir un área de presentación basada en modelos dimensionales.

Quien dice una estructura de datos, dice el sistema de metadatos, de monitorización o las especificaciones detalladas de la solución.

Cuanto antes el usuario pueda empezar a obtener información de sus datos, antes podrá comenzar la colaboración real entre las partes y será más fácil cumplir con los requisitos de negocio a plena satisfacción de los usuarios finales.

• Agile dice: Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
• Kimball dice: Error 8. Abordar un gran proyecto que abarque años en vez de esfuerzos de desarrollo más manejables e iterativos aunque igualmente necesarios e interesantes.

La entrega de nuevas prestaciones regularmente ayuda a mantener el interés del cliente por la solución al presentársela como algo vivo que evoluciona con el tiempo ante sus necesidades. Igualmente la hace ver el valor real de su inversión.

• Agile dice: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.
• Kimball dice: Error 5. Hacer los datos supuestamente consultables en el área de presentación demasiado complejos. Los diseñadores de bases de datos que prefieren una presentación compleja deberían pasar un año dando soporte a los usuarios de la solución; entonces desarrollarían una mejor apreciación de la necesidad de buscar soluciones más simples.

En efecto. El usuario no debería tener que introducir más de uno o dos parámetros para obtener los datos que desea. La tentación de crear el informe o la consulta únicos es absurda, costosa y frustrante.

• Agile dice: El software funcionando es la medida principal de progreso
• Kimball dice: Error 6: Prestar más atención al rendimiento operacional de los procesos en trasfondo y a la facilidad de desarrollo que al de las consultas que se ejecutan a la vista y a la facilidad de uso.

Error 1: Fallar en reconocer que el éxito del DW/BI está ligado directamente a su aceptación por la organización. Si los usuarios aceptan el sistema DW/BI como la base de una mejor toma de decisiones, nuestros esfuerzos habrán sido un ejercicio inútil.

Nuestro comentario: Aquí las palabras clave son «funcionando» y «aceptación».

Según el teorema de Thomas «Si una situación es definida como real, esa situación tiene efectos reales».

Lo que aplicado a nuestro datawarehouse quiere decir que por más que los procesos ETL, de control de calidad o de perfilados de datos sean elegantes y eficientes en extremo, de nada nos servirá si las aplicaciones finales que entregan la información a los usuarios son lentas y/o difíciles de manejar.

Eso hará que los usuarios perciban que el conjunto de nuestra solución datawarehouse no funciona ya que no satisface sus necesidades y sus efectos reales serán el rechazo de nuestro trabajo. No deberíamos pensar entonces que el proyecto progresa por más trabajo que se haya realizado.

Si quieres seguir profundizando en la metodología Agile y cómo ayuda en la optimización de los procesos de trabajo, conoce el Postgrado en Gestión Ágil de Proyectos con Scrum, Kanban, Lean y XP de IEBS.