Metodología Agile y las técnicas de desarrollo del Kimball Group
La metodología Agile no es privativa del desarrollo de software sino que puede emplearse con data warehouses y Business Intelligence. Las principales nociones de Agile han estado subyacentes en una de las principales metodologías DW/BI desde su origen.
En el momento de iniciar nuestro primer proyecto sobre desarrollo de datawarehouse nos enfrentamos a la decisión crucial que debe tomar cualquier empresa en un momento así: arriesgar, crear escuela y desarrollar un estilo propio o seguir el camino trillado por otros. No lo dudamos ni un instante y… escogimos la segunda opción.
El párrafo anterior no por estar escrito en clave de humor deja de ser cierto. Una decisión así es fruto del sentido común que nos dice que si reinventar la rueda no vale la pena en mecánica, tampoco en informática y, como “sentido común” es un concepto muy antiguo, los informáticos hablamos de reusabilidad.
Buscamos, pues, investigamos y decidimos adoptar la metodología del Kimball Group que se adaptaba perfectamente a nuestras circunstancias: una empresa pequeña que no quería limitarse a proyectos igual de pequeños.
El Kimball Group siempre ha abogado por un enfoque del proyecto de abajo hacia arriba priorizando la colaboración con el usuario final sobre la planificación y documentación exhaustivas, así como el desarrollo paulatino de partes concretas del datawarehouse sobre el desarrollo de toda la solución de una sola vez.
Además, nos era necesario gestionar nuestros proyectos sin la rigidez de la gestión de proyectos clásica. Nuestra experiencia en otros tipos de desarrollo nos indicaba que, con frecuencia, las complicaciones afloraban en algo tan básico como la definición del alcance del proyecto. Las ambigüedades, sobreentendidos y cambios en las necesidades del cliente obligaban a modificar una y otra vez los planes tan trabajosamente concretados en nuestro Project. Y ahí es donde entró en juego Agile y, tras estudiarlo un poco, nos dimos cuenta de que las coincidencias y similitudes entre sus propuestas y las del Kimball Group eran muchas.
A continuación vamos a hacer una comparación de las similitudes entre Agile y el Kimball Group. Para ello hemos usado el Manifiesto Agile cuya versión en castellano puede descargarse gratuitamente.
Para el Kimball Group hemos tomado su libro The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd Edition. No es un manifiesto, sino un libro propiamente dicho en el que se incluye una lista de tentaciones en las que un equipo encargado de desarrollar un datawarehouse no debería caer y que nos han parecido muy representativos del conjunto de su filosofía.
Agile dice: Individuos e interacciones sobre procesos y herramientas
Kimball dice: Debe evitarse enamorarse excesivamente de los datos y la tecnología en vez de centrarse en las necesidades y objetivos de negocio.
Nuestro comentario: 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: No se debe suponer que el negocio, sus necesidades y analíticas, así como los datos subyacentes y la infraestructura tecnológica son estáticos.
Nuestro comentario: 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: Es un error 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.
Nuestro comentario: 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: Es un error común dedicar esfuerzo a construir una estructura de datos y agotar el presupuesto antes de construir un área de presentación basada en modelos dimensionales.
Nuestro comentario: 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: No se debería abordar un gran proyecto que abarque años en vez de esfuerzos de desarrollo más manejables e iterativos aunque igualmente necesarios e interesantes.
Nuestro comentario: 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: No han de hacerse 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.
Nuestro comentario: 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: 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 es un error como igualmente lo es no 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.
El mundo del Business Intelligence no es estático, y siendo la fuente principal de información empresarial van surgiendo en este mundo nuevas tecnologías y herramientas que profundizan y mejoran esta información. Además, como cada empresa tiene su propia casuística, una solución completamente válida para unas empresas puede no serlo para otras; como símil automovilístico, mientras para una empresa su solución idónea será un utilitario pues utiliza el vehículo mayoritariamente por ciudad, para otra será un 4×4, para otra un monovolumen, para otra un autocar, etc., y normalmente se necesitarán diversos tipos de vehículos para ofrecer a cada tipo de usuario el más oportuno.
Hay fabricantes de software de Business Intelligence que ofrecen un rango de soluciones más o menos amplio, mientras que hay otros muy especializados en algunos nichos en concreto: elegir entre unos y otros es cuestión de que las empresas sean conscientes de sus requerimientos de información, y contrastarlos con los costes económicos que conllevan las diferentes soluciones para así acabar implantando aquellas que les sean más convenientes. De hecho, en muchos casos el uso de estas soluciones hace que se empiece por algunas y se vayan incluyendo otras con el paso del tiempo. Las soluciones de Business Intelligence más completas son aquellas que contemplan los dos principales pilares de estas soluciones: dicho rápidamente, la preparación de los datos y la creación de los objetos que los usuarios acabarán utilizando.
Comencemos por este último: para empezar es fundamental que los usuarios interactúen con la información de forma fácil y agradable, y dependiendo del rol de estos usuarios se les deberá facilitar unas cosas u otras. En cualquier caso las opciones más habituales son las basadas en la creación de informes tanto predefinidos como a medida y su distribución de forma automatizada (reporting o corporative reporting), la previsión de resultados (forecasting), las herramientas de consultas para usuarios avanzados (query) incluyendo el acceso a cubos multidimensionales (OLAP), y los cuadros de mando (dashboards o scorecards).
Y las últimas tendencias son las herramientas denominadas navegación de datos o descubrimiento de datos (Data Discovery), que pueden incluir también el apartado de BI de autoservicio (Self-Service BI); estas soluciones persiguen ir un paso más allá de las herramientas de consultas existentes hasta ahora, y así especialmente mediante visualizaciones gráficas avanzadas de los cruces de datos necesarios dar respuestas y proporcionar oportunidades de futuro. Y si contemplan las funcionalidades de BI de autoservicio entonces usuarios avanzados podrán ser autosuficientes en la generación de sus modelos de BI.
Vayamos ahora por la preparación de datos: hay diferentes filosofías al respecto, desde las que consideran que puede llegar a ser una pérdida de tiempo y atacan directamente los datos de los sistemas en producción (los ERPs, CRMs, etc.), pasando por las que atacando una copia o subconjunto de sus datos preparada en otra infraestructura para no perturbar los sistemas en producción proporcionan una fuente en la que basarse, o las soluciones basadas en metadatos, que son abstracciones de las bases de datos que pueden aportar un lenguaje inteligible para el usuario, cálculos predefinidos, u otros, hasta aquellas que utilizan un proceso de Datawarehouse (almacén de datos, o DW, aunque existen soluciones parciales como los Datamarts, DM) completo donde se almacenan los datos que se requieren, se limpian (como ejemplos simples, son habituales errores tan chocantes como fechas de otros siglos, zonas geográficas mal escritas, etc.), consolidan, agregan (por variables temporales, geográficas, de tipo de negocio, otras) y, en definitiva, se preparan mediante herramientas ETL (Extract, Transform, Load) como se requieran para su posterior uso por parte de cualquiera de las opciones de visualización de datos comentada.
En Certia siempre hemos apostado por preparar los datos tanto como sea posible y lógico; siempre puede haber algún informe que visualice datos rabiosamente actuales (¿Cuánto hemos vendido durante esta mañana?) y para el que no tenga sentido nutrirse del DW, o que durante el proceso de construcción de una solución global de Business Intelligence a muy corto plazo se cree algo muy necesario que ataque directamente los sistemas de producción hasta que se pueda atacar el DW, pero la creación del DW proporciona muchas ventajas a diferentes niveles. Permite validar los datos que vamos a utilizar, y rechazar aquellos que no cumplan lo que se requiera e incluso crear procesos para su corrección y posterior inclusión en el DW, filtrarlos y agregarlos como consideremos oportuno con lo que las prestaciones serán mucho mejores, y dejarlos disponibles en una infraestructura pensada para ser consultada y no para incluir datos, tal como están preparados los sistemas en producción, con lo que se obtienen todavía más prestaciones.
Tal como comentaba anteriormente van surgiendo nuevas tecnologías y hay que resaltar las últimas tecnologías de diferentes fabricantes a la hora de preparar datos basadas en conceptos como el “Big Data“, “In Memory“, y otros, muy interesantes aunque ahora por ahora con costes elevados.
Pongamos un ejemplo para ver cómo se utilizan estas tecnologías que servirá para entender dónde encajan en nuestros negocios. Imaginémonos una empresa que tiene diferentes programas de software en uso: un ERP, un programa desarrollado especialmente para controlar sus sistemas de producción, un CRM, etc. Muchas veces encontramos que para preparar información basada en uno o en varios de esos programas de software hay que hacerlo manualmente (caso típico de las hojas de cálculo, donde usuarios avanzados recogen datos de los diferentes sistemas y los cruzan. Es un sistema muy proclive a errores aparte de caro pues necesita siempre personal disponible, y lento, pues este personal ha de preparar en cada caso el tipo de información requerida), o como permiten las soluciones BI, prepararlo anticipadamente como hemos comentado antes, por lo que luego cualquier informe, cuadro de mando, etc, que los requiera, será mucho más eficiente. Estos almacenes de datos especiales tienen muchas más funcionalidades interesantes, aunque también para algunos casos concretos pueden no ser la solución perfecta (este post no pretende ser un tratado al respecto…): como siempre, dependerá de cada caso y para eso están los especialistas en estas tecnologías.
Con los datos preparados podremos utilizar nuestros diferentes objetos de información: habrá usuarios que sólo requerirán recibir informes predefinidos con una cierta cadencia (por ejemplo, las visitas que han de hacer cada semana los comerciales con las ventas de los clientes a visitar). Otros (por ejemplo, responsables de ventas), requerirán datos agregados de ventas de productos por vendedores, zonas geográficas, etc., para el seguimiento correcto de los presupuestos y las previsiones de ventas. Roles más altos (directivos, responsables de objetivos), necesitarán cuadros de mando para seguir la evolución de los indicadores claves de la empresa (o KPIs, Key Performance Indicators); y siempre está el rol de usuarios avanzados informáticamente hablando, que en conjunción con su conocimiento del negocio deberán poder cruzar datos para proporcionar información y entonces descubrir patrones que nos permitan modificar o crear nuevas formas de trabajar.