Agile BI Governance

Feliz 2008
Últimamente he estado muy liado con mis temas profesionales, y con la propuesta de proyecto de tesis. He estado redactando y escribiendo mucho orientado para poder defender mi propuesta de tesis y ver si el tribunal que evalúa los PT da su aprobación para que pueda dedicar dos años mas a desarrollar la tesis doctoral. De momento, hoy he hecho el depósito y espero que pueda defenderlo a principios de febrero y obtener el DEA (Diploma de estudios avanzados). En fin esas cosas de los doctorados. :-D. El caso es que despues de 4 años de esfuerzo, al final estoy en el primer checkpoint. Como dice mi codirector de tesis y amigo el Dr. Enric Mayol... "Jorge.....ya has puesto el huevo".

¿De que vá?, pues de lo que todos ya sabeis, de mezclar metodologías ágiles y gestión de proyectos de BI, de aplicar los principios ágiles al BI Governance.

Fruto de este trabajo, voy a publicar dos artículos, uno en Novatica y el otro en GdR.

El primero habla de BI Governance desde el punto de vista mas formal, ligado a las metodologías de IT Governance, gracias a la influencia de Antonio Valle. mi gran mentor en estos temas.

El segundo habla de mí visión del BI Governance, lo que he llamado Agile BI Governance y que en una primera definición del concepto ha quedado mas o menos así.

Agile BI Governance es el proceso de definición y ejecución de la infraestructura que prestará apoyo a los objetivos de empresa. Es propiedad conjunta de Tecnologías de la Información y de las diferentes unidades de negocio, y se encarga de dirigir el proceso estratégico de obtención de valor del Business Intelligence en la empresa a través de los valores y principios del Manifiesto Ágil.

Una vez definida, hay que construir un Framework de referencia, y de eso es de lo que hablo en el próximo número de GdR de enero-febrero'08, que os pondre en cuanto este online.

No pagueis el rescate que me he escapado

Sigo vivo.
Como cada final de año, la verdad es que se me acumula la faena y no he tenido tiempo para dedicar al blog, y me sabe muy mal, porque queda muy mal lanzar preguntas al aire y no dar la respuesta.
Eso no significa no haya estado escribiendo, he estado liado con:

• GdR en el ultimo número del año, en el que ademas de mi sección he escrito un articulo sobre " Madurez del BI en las organizaciones" que espero poneros on line en breve.
• Novatica escribiendo un articulo sobre "BI Governance" que aparecera en el especial de febrero sobre IT Governance y entre cuyos editores invitados esta Antonio Valle.
• Proyecto de Tesis Doctoral. Que si todo va bien tendre que defender en enero y si me lo aceptan ya podré por fin escribir mi tesis doctoral titulada "Agile BI Governance".

Pero aparte de al blog le debo varias cosas.

• Felicitaros a todos por el éxito de BI Beers, ya somos 70 personas vinculadas al grupo. Yo no pensé que pasariamos de 30, estoy gratamente sorprendido. Ahora tendriamos que organizarnos por grupos geográficos, si alguien se quiere responsabilizar de una zona, que me lo diga y lo haré administrador del grupo.
• Agradeceros el éxito y el nivel de las respuestas a la pregunta al aire "Que debe almacenar un datawarehouse", tengo pendiente hacer mi post de respuesta, os lo prometo.
• Mirarme a fondo el Triadic Continuum, Jane me ha enviado documentación para poderlo hacer y en cuanto acabe con lo del proyecto de tesis, me pongo.
• Exponeros mi proyecto de tesis, como va a ser y que podais ver en que trabajo y que podais indicarme en que me estoy equivocando, pero eso ya será mas adelante.
  

En fin muchas cosas que quiero compartir con vosotros en cuanto me sea posible.
Ademas veo que ya no soy el único que empieza a defender la relación de metodologias ágiles con BI, os adjunto unos links del blog de Karthikeyan Sankaran que va por mi mismo camino.

BI Implementation Enabler: Agile Framework for Data Warehousing – Part 1

BI Implementation Enabler: Agile Framework for Data Warehousing–Part 2

Pair Thinking para DWH

En una de las metodología ágiles mas extendida la XP ,una de las formas de trabajo que se recomienda es el Pair Programming, en la que un programador codifica y el otro "mira". Algu muy Typical Spanish (:-D).
La verdad es que inicialmente puede chocar, la programación siempre se ha visto como algo solitario, y tener dos personas delante de un solo teclado y de un solo monitor sorprende en un inicio.

La semana pasada estuve en varios de mis clientes, supervisando a los equipos e intentando ayudar en algunos puntos del desarrollo en el que se estaban teniendo algunas dificultades, al final de la semana, cuando volvía a casa reflexionando de como me había ido, me di cuenta de que lo que habia estado haciendo en la mayoria de casos es Pair Thinking y que habia funcionado muy bien.

Si lo pensais las ventajas son muchas; y mucho mas en entornos decisionales, en los que no solamente hay que ver como estructuras los datos, sino en como los interpretará el usuario final.

Pensad en como funciona la mente humana, nos he muy complicado pensar a nivel abstracto y luego pasar a pensar a nivel concreto. Nos es difícil pasar de alto nivel a bajo nivel y si lo hacemos de forma continua acabamos desconcentrados y cometemos errores.

Es por esto que cuando estamos estructurando un DWH primero pensamos la estrategia de estructuración de datos que vamos a seguir y luego nos ponemos a codificar cada una de lso procesos ETL, sin pensar de nuevo a nivel estratégico hasta que no finalizamos alguno de los datamarts o a veces la totalidad del data warehouse, y entonces cuando nos lanzamos con el reporting vemos los errores o las cosas que nos hemos dejado en la estrategia de codificación original.

Pensar a lo grande y en detalle a la vez nos es imposible con un solo cerebro. Pues pongamos dos.

En el Pair Thinking uno de los miembros debe esta pensando a nivel táctico y el otro a nivel estratégico de manera de que esos dos procesos siempre estén activos reduciendo así los errores y mejorando la calidad de la información resultante.

Si utilizamos la gran experiencia de XP en sus roles de Pair Programming y los plagiamos sin ningún tipo de rubor, podemos decir que estos dos roles deberian intercambiarse cada poco tiempo entre los miembros de la pareja para abarcar todas las posibilidades tácticas y estratégicas del diseño del DWH.

El nivel de los miembros de la pareja ha de ser equivalente, no sirve que uno sepa mucho y otro no tenga ni idea, deben de estar equilibrados y obviamente llevarse bien para que tenga éxito. Pero no solamente entre ellos sino también con el usuario final. En el Pair Thinking el usuario final ha de ser contantemente consultado para saber "que espera" y los conocimientos del área de negocios de ambos diseñadores del DWH deben de ser muy amplios o les será totalmente imposible pensar a nivel estratégico.

Así pues, para aplicarlo correctamente necesitariamos dos "Arquitectos DWH" con mucha experiencia en negocio, cosa que es dificil de justificar en un proyecto de diseño a tiempo completo por lo que supone en costes. (si fuera Pair programming sería mas facilmente justificable)

Por eso quizas la mejor aproximación sería la de realizar sesiones rutinarias de Pair Thinking, dentro del ciclo de la metodología de diseño del DWH.

Y esto es lo que, sin darme cuenta, he ido haciendo en los últimos años.

Mirando el Model Driven Approach

Uno de los articulos que ha caido entre mis manos es este de P. Chowdhary, K. Bhaskaran et Al: Model Driven Development for Business Performance Management. IBM SYSTEMS JOURNAL, VOL 45, NO 3, 2006: 587- 605 que lo podeis descargar de aquí.

El MDD es una metodología que pretende tender un puente entre el negocio y el departamento de IT, intentando proporcionar la base para desarrollar soluciones rápidas, que evolucionen fácilmente y flexibles. Es pues una buena candidata para los entornos de BI tal y como los entendemos.

La idea esta en el desarrollo de un "modelo conceptual" que ayuda a simplificar la complejidad
de la realidad y que después puedan desplegarse en diversas arquitecturas, preferentemente en SOA.

Debido a su alto nivel de la reutilización de la abstracción y del código, la metodología de MDD se ha aplicado extensamente en las áreas relacionadas tales como reutilización del software, reingeniería inversa, diseño del interfaces de usuario.


Las ventajas de adoptar MDD incluyen tiempo de desarrollo reducido, mejora de la calidad y del mantenimiento de la solución.


El MDD no es mas que una evolución del simple prototipaje de toda la vida, pero con modelos conceptuales y dirigido a SOA, cosa que le da muchas posibilidades de cara al futuro. Yo seguiré mirandolo con mas detenimiento a ver como se puede aplicar.


¿Alguien ha trabajado con este modelo?.

Starting Area (Orígenes: Primera Parte)

Bueno, me lanzo al final. Llevo varios dias intentando ver como explico lo de la starting area, lo he explicado muchas veces y lo he puesto en marcha varias mas, y funciona, pero no se porque, escribirlo, me da un poco de respeto y lo he estado evitando. Pero en fin allá voy.

La Starting Área (STA) tiene dos carácterísticas principales, la primera es que está ligada intrínsecamente al concepto de metodologías ágiles y la segunda es que tiene fecha de caducidad.


El concepto es el siguiente: La idea de la Starting Area la empecé a madurar al encontrarme "malas" implementaciones de la Staging Area. La Staging Area (STG) por definición es el área donde se ejecutan los procesos ETL y que tiene un caracter volatil, es decir al finalizar el proceso, la Staging debe de quedar vacia, sin contenido. Sin embargo, me encontraba que muchas implementaciones, tanto propias, como de otros arquitectos de DWH, acababan dejando información en la STG. En mi época más purista blasfemaba cada vez que me encontraba una STG con datos, pero a medida que trabajaba con estas arquitecturas me daba cuenta que si bien en algunos casos era pura negligencia, en otros casos incluso yo mismo estaba dejando esos datos "permanentes" de forma deliberada. Esto siempre ocurría en implantaciones con mucha limpieza de ETL, al final decidia no borrar la STG para poder ir haciendo pruebas en desarrollo y no tener que esperar a cargar de nuevo los origenes. Al final, tenía un proceso ETL en el que en lugar de finalizar con el borrado de la tabla, dejaba los datos hasta la siguiente ejecución , con lo que cada proceso se iniciaba borrando los datos que habían sido utilizados en la anterior ejecución.

Obviamente esto solo lo hacía durante el desarrollo del DWH y una vez lo ponía en marcha cambiaba el modelo a la ejecución normal dejando la STG totalmente vacia. Y así lo estube haciendo hasta que cierto día en uno de mis clientes, alguien cambió un elemento de una jerarquía en el operacional por error, una operación que el ERP validó pero que no tenia sentido lógico, error que se propagó a la información que daba el DWH, y que nadie comprobó hasta al cabo de varios dias. Con lo que teníamos que rehacer el DWH y con urgencia, porque al dia siguiente había la reunión del comité de dirección. Me avisaron a las 9:00 de la mañana, tardé en borrar la información erronea unos 20 minutos y tube que esperarme hasta las 20:00 horas que cerraban el turno para poder conectarme al operacional y lanzar la carga del DWH. A las 21:00 ya estaba cargado y solventado, y a las 21:30 cogia el tren hacia mi casa pensando "esto no tiene sentido, tiene que haber una manera mejor de hacer las cosas". Y ahí fué cuando empecé a crear mi idea de la Starting Area.

Su primera versión consistió en no borrar el primer estadio de todos los procesos ETL del DWH, dejarlo como en el modo de desarrollo, es decir borrando al iniciar, pero solo en el primer paso de cada proceso ETL, con el que "todo empieza", de ahí su nombre "Starting Área". Eso me daba la ventaja de poder ejecutar el proceso anterior de nuevo sin necesidad de esperar a la ventana de tiempo del proceso de carga, sin embargo no me solucionaba nada cuando tenía que rehacer varias ejecuciones anteriores del proceso ETL, o si tenia que recargar TODO el DWH.

Así que di paso a mi segunda versión que solamente utilizaba en desarrollo y que consistía en hacerme una copia exacta de las fuentes de datos en un repositorio diferente. Y cuando estaba haciendo esto me di cuenta que estaba volviendo a los origenes del DWH, en los que haciendo una copia "exacta" del operacional se construían los sistemas decisionales. Y entonces me dí cuenta que algo se me estaba escapando y que así no iba bien, que tendría que volver a los origenes y ver que estaba pasando. Fué así como empecé a descubrir a Inmon y como me replanteé las funciones que debería tener la Starting Area.

Obviamente la Starting Area (STA) no se ha quedado en simplemente eso, ha evolucionado mucho mas, dando soporte a otras necesidades que me he encontrado, como la hetorogeneidad de fuentes que comentaba en el post anterior, el reporting operacional (funcionalidades de ODS) y mejoras en los procesos de calidad del dato, siempre desde la perspectiva de las metodologías ágiles, en el que el tiempo de desarrollo y de entrega ha de ser de ciclo corto.

Pero ya se me ha hecho muy tarde y eso lo dejaré para el próximo post.

Green Lantern Methods for Redesign (GLMR)

Despues de darle muchas vueltas, esta tarde he pasado a la accióm. Junto con mi amigo Marti Ibarz, nos hemos puesto a darle forma a una posible metodología ágil de rediseño de data warehouse. El porqué me he decidido finalmente a hacer una metodología propia para este proyecto y no reutilizar ninguna de las existentes, es principalmente el hecho de que la casuística de un proyecto de rediseño no ha de ser la misma que la de un proyecto que empieza desde cero. También me da la oportunidad de probar una metodologia ágil en un proyecto de menor riesgo.

El esqueleto resultante es este que os comento a continuación, y que a partir de ahora voy a llamar Green Lantern Methods for Redesign o acronizando un poco GLMR.

GLMR será un conjunto de métodos que podrán aplicarse a cualquier proyecto de rediseño de aplicaciones, la primera versión, claro esta, será (porque aún no la tengo hecha) la versión para Data Warehousing (GLMR for Data Warehousing) pero animo a cualquiera a que realice su propia versión para proyectos de rediseño en otros ámbitos.

El esquema principal se compone de una primera fase lineal en la que nos haremos una idea de la vision global y de como la evolución del negocio ha hecho que nuestro sistema sea insuficiente para las necesidades de la organización, a esta fase le sigue un ciclo iterativo en el que se rediseñan los datamarts y en el que se obtiene check list de implementacion de funcionalidades y optimizaciones para cada datamart. El proceso finaliza con otra fase lineal en la que se ponen los cambios en marcha y se planifica los criterios que harán que en un futuro se desencadene de nuevo otra reingenieria.


Es una version muy simplificada sobre la que seguiré trabajando, los siguientes pasos que voy a dar implican la definicion de las tareas de cada fase, la documentación resultante (que será la mínima necesaria) , los roles que han de intervenir (donde el usuario final ha de formar parte del equipo con un papel destacado) y las reuniones e hitos de control.

Si, ya lo se, TODAVÍA ESTA MUY VERDE.... je je je (no he podido resistirlo), pero creo que va a dar un buen resultado.

Como siempre admito sugeriencias, aunque ya estoy perdiendo la esperanza :-(

¿Dynamic Systems Development Method para DWH?

Después de descartar SCRUM mi siguiente metodología candidata es DSDM, y creo firmemente que dentro de las metodologías ágiles puede ser la adecuada, a ello me ha llevado mi gran intuición y el white paper llamado "DSDM and Data Warehousing" que yo con pocas pistas enseguida pillo el concepto. ;-D

Veamos un poco de que se trata esto de DSDM

DSDM se ha desarrollado teniendo como ideas fundamentales:

· Nada es construido a la perfección a la primera.

· La vieja regla del 80-20 es cierta ( el 80% de las funcionalidades del proyecto se realizan con el 20% del tiempo, y el 20% restante, los detalles, consumen el 80% del tiempo restante)

· Es improbable que alguien conozca todos los requisitos del sistema desde el primer día.

De estas ideas nace una metodología cuyas principales características son:

· Un proceso iterativo e incremental

· Un equipo de desarrollo con el que el usuario final trabaja conjuntamente.

Este principio me puede ser util para la reingenieria de data warehouse que os comentaba en el anterior post. La idea dominante en DSDM es que tiempo y recursos se mantienen como constantes y se ajusta la funcionalidad de acuerdo con ello. Es decir, la idea no es “¿cuánto me va a costar desarrollar este sistema?” sino que mas bien es “Con este tiempo y estos recursos ¿cuántas de las funcionalidades del sistema puedo hacer. Si hablamos de reingeniria de Data warehousing, seguramente deberiamos preguntarnos: ¿Cuanto podemos optimizar y cuantos nuevos enfoques decisionales podemos añadir a los existentes?

Entiendo que la naturaleza de las preguntas necesariamenta ha de ser específica para el proyeco, pero las dos características princiapels encajan a la perfección en el proyecto que quiero desarrollar.

Sigamos pues por este camino.

DSMD propone cinco fases, las tres últimas son iterativas:

· Estudio de la viabilidad. Lo primero que se evalúa es si DSDM se puede o no aplicar al proyecto.

· Estudio del negocio. Se estudia el negocio, sus características y la tecnología. Debe crearse el Plan de Prototipado (base del DSDM).

· Modelado funcional. En cada iteración se planea se refinan los procesos funcionales del negocio sobre el prototipo

· Diseño y construcción. Aquí es donde se construye la mayor parte del sistema. El prototipo se vuelve apto para su utilización por parte de los usuarios

· Implementación. Pasamos de un prototipo a un sistema de producción. Se entrena a los usuarios para que lo usen..

En el gráfico queda mas claro (pulsad sobre el para ver mas grande)

Ahora el siguiente paso que tengo que dar es estructurar una metodología de reingenieria de DWH basada en DSDM y probarla.

¿Alguna sugerencia de por donde empezar?

¿SCRUM para DWH?

El término SCRUM tiene su origen en el ámbito del rugby, se trata de una posi-ción entrelazada en círculo que toman los integrantes de ambos equipos. El pro-pósito del scrum es el de reiniciar el juego, rápida, segura e imparcialmente, después de una infracción menor o de una detención.

SCRUM es una metodología que nace ajena al desarrollo del software, de hecho sus principios fundamentales fueron desarrollados en procesos de reingeniería por Goldratt, Takeuchi y Nonaka en la década de 1980 y no fueron aplicados al proceso de desarrollo de software hasta 1993 por Jeff Sutherland, siendo formalizada con la colaboración de Ken Schwaber en una presentación en OOSPLA 96.

Eso lo hace muy versatil para desarrollar proyectos de workflow por ejemplo, pero mi duda es si se puede aplicar de forma eficiente a un proyecto de datawarehouse.

A priori, un buen proyecto para aplicarlo sería el de una "reingenieria de un dwh existente", y tengo precisamente tengo una entre manos, asi que voy a decicar este post a "refrescar" los principios sobre los que se basa SCRUM a ver si lo puedo aplicar o no a este proyecto

El Scrum se ha desarrollado teniendo como principios fundamentales:

• Principio de requisitos indefinidos de Humphrey: para un nuevo aplicativo, los requerimientos no serán totalmente conocidos hasta que el usuario no lo haya usado.
• Lema de Wegner: es imposible definir completamente un sistema iterativo.
• El principio de incertidumbre de Ziv en la ingeniería del software: la incertidumbre es inherente e inevitable en el proceso de desarrollo de aplicaciones.

Podríamos decir que Scrum se basa en cierto “caos controlado”, el proceso del ciclo de desarrollo de Scrum parte del conocimiento de que el proceso de desarrollo fundamental del producto esta totalmente indefinido, es incluso caótico, pero establece ciertos mecanismos para controlar esta indeterminación, manipular lo impredecible y controlar la flexibilidad.

Y aqui nos encontramos con la primera pega, SCRUM es segun sus propios autores un.... "Modelo de desarrollo ágil de productos"

"Producto", un dwh NO es un producto que se pueda acabar como ya dije en el post anterior, asi que quizás no sea tan buena idea lo de SCRUM. Pero los principios me parecen muy adecuados. Claro si pensamos en el origen de la metodología es obvio que esta orientada a producto así que no se yo hasta que punto voy a poder aprovecharla.

Pero sigamos viendo, ahora me centraré en el ciclo de vida de Scrum. Este es una analogía de la jugada de rugby de la que recibe su nombre. En Scrum el balón ha de disputarse entre ambos equipos, los jugadores de un equipo se reúnen en circulo y deciden que es lo que van ha hacer, luego se posicionan enfrente del otro equipo de forma entrelazada, con el balón en medio, y comienza la jugada en la que no se sabe que va a pasar, ni quien tendrá el balón ni hacia donde se atacará. El equipo ha de adaptarse rápidamente hacia una jugada ofensiva o defensiva según quien se haya hecho con el balón.

¿Eso me sirve para el rediseño de un DWH? Uy que pinta un poco mal. Si yo ya tengo claro hacia donde tengo que ir, que estructura tengo que optimizar, que usuarios utilizan el sistema y como lo utilizan. ¿necesito esa adaptabilidad tan extrema?. Empiezo a ver que no, pero quiero darle una oportunidad antes de descartarla

En la metodología Scrum se establecen tres fases : pre-juego, juego y post-juego.

En el pre-juego se definen y/o revisan las funcionalidades que ha de tener el sistema, haciendo la lista de funcionalidades que cuando estén completadas podremos decir que el desarrollo del sistema. Dicha lista recibe el nombre de Release Backlog .Una vez hecho esto se elige un subconjunto de estas funcionalidades con el que se va a trabajar el próximo mes, llamado Sprint Backlog y entonces comienza la siguiente fase.

En el juego es donde se desarrolla el Sprint, las reglas de esta fase son sencillas, se distribuyen las tareas para cada miembro del equipo, se trabaja duro y se intentan conseguir el objetivo. Todos los miembros del equipo han de participar en una reunión diaria que en ningún caso deberá exceder los 30 minutos, llamada Sprint-meeting. En esta reunión cada desarrollador debe dar respuesta a tres preguntas:

• Que hizo desde la última reunión.
• Que dificultades se estan teniendo en el desarrollo de la tarea.
• Que va a hacer hasta la próxima reunión diaria.

Al finalizar el Sprint, pasamos a la fase de post-juego, en ella se evalúa la entrega de funcionalidades del Sprint , se ven las tareas pendientes, se evalúa el progreso del proyecto y se redefine el tiempo de entrega del mismo si fuera necesario. En este paso se compara las funcionalidades actuales con el Release Backlog y en el caso de no cumplirse se vuelve a la fase de pre-juego para realizar una nueva iteración. Si por el contrario, sí se cumplen entonces pasamos la creación de la versión final y a la creación de la documentación pertinente.


Pues creo que yo ya lo tengo claro, no me aporta demasiado para una reingenieria de DWH, quizás para un proyecto de DWH nuevo desde cero si que me podría ser útil, pero para una reingeniera de DWH claramente no, porque ya se que funcionalidades ha de dar, y porque no tengo que ir dando pequeñas funcionalidades cada semana, ya que lo tengo bastante mas simple, cuando acabe la reingenieria, desactivaré el antiguo data y conectaré el nuevo data. Y si todo va bien los usuarios no se darán ni cuenta.



Bueno, para finalizar explicaré los roles básicos de SCRUM así os haceis a una idea, os pongo los 4 principales.

• Scrum Master: Es el responsable de asegurar que el proyecto se es-tá desarrollando según las reglas de la metodología Scrum.
• Product Owner. Es el responsable de la lista de funcionalidades (Re-lease Backlog).
• Scrum Team: Es el equipo responsable la organización y ejecución de cada uno de los Sprints.
• User/Customer: Participan en la creación y revisión de la Release Backlog.

Pero a mi me sigue gustando SCRUM, ya que la forma de trabajar que se adopta es muy colaborativa, un equipo de Scrum tiene entre 7 y 9 miembros, a los que se les incentivará para que adopten soluciones ingeniosas y que aprendan de forma conjunta en un ambiente totalmente cambiable pero controlado parcialmente.

A mi, la verdad, me gusta trabajar así. :-D

¿Qué debe cumplir una metodología de data warehousing.?

Empezaremos el 2007 mirando un articulo de TDWI llamado "Ten Mistakes to Avoid for Data Warehouse Project Managers" realizado en el segundo trimestres de 2005, vale es un poco antiguo pero me sirve para ilustrar dos conceptos sobre la necesidad de un metodología diferente para los sistemas de dwh.

Los 10 errores que podemos evitar que se comentan en el articulo son:

1) Failing to Use a Methodology (uy que bien me viene para el post de hoy)
2) Ineffective Team Project Structure
3) Failing to involve the business people
4) Failing to have application releases
5) Failing to have an active Project Charter
6) Lack of a readiness assessment
7) Inadequate testing
8) Underestimating Dara Cleansing Efforts
9) Ignoring Metadata
10) Being a Slave to Project Management Tools (uy esta tambien me va bien)


La autora es Larissa Moss del Cutter Consortium , que entre otras cosas ha escrito BI Roadmap: The Complete Lifecycle., vamos que sabe de lo que habla.

En el post de voy a comentar los puntos 1 y 10, el primero y el ultimo
Larissa comenta en estos dos puntos cosas como esta:

" (...) They are often surprised to learn that project managers and project teams must consider approximately 920 tasks when developing a data warehouse. Who can rememner 920 tasks?. No one. But everyone can look up 920 tasks in a methodology!"

920 tareas diferentes, intendad poner eso en una metodología rígida y formal o en una de las tradicionales en cascada que hemos estado utilizando para los grandes proyectos operacionales, sin duda solo con la gestión nos ocuparía la mayor parte del tiempo del proyecto.pero eso no es motivo para que no funcione, nos iremos de plazos seguro, pero no funcionar, eso es decir mucho ¿no?... pues no, no va a funcionar por estos dos motivos:

"(...) a traditional methodology does not include cross-organizational business integration tasks"

"(...) a traditional methodology (...) assumes you are building a product and will not evolve or expand over time"

Ok, no podemos utilizar las tradicionales, pero debemos tener una metodología.

¿Que debe cumplir esa metodologia para que sea util en la creación de un datawarehouse?

1) Que este orientada al cambio y no a la consecución de un producto final.
2) Que gestione el proyecto como cross-funcional a la empresa, una data warehouse no es de un departamento ,es de una empresa, y todos tienen que estar implicados.
3) Debe poder manejar multiples subproyectos a la vez y en paralelo (Etl, data cleasing, reports, querys, KPIs, cubos, etc..)
4) Que posea TODAS las tareas a tener en cuenta, no se trata de que se ejecuten todas, seguramente muchas no serán necesarias, pero no tenerlas incluidas lo único que te asegura es que te olvidarás de una critica y luego tendrás que rehacer el trabjo o algo mucho peor
5) Que utilice los caminos críticos, para su gestión. Es decir que tenga sentido común, centrate en las tareas criticas que puden hacer cambiar la planificación, solo replanifica cuando estas se vean afectadas

¿No os parece que una metodología ágil encajaría perfectamente?

La metodología como caballo de troya

Uno de los problemas que nos podemos encontrar en las organizaciones es que no estén lo suficientemente maduras para la agilidad como ya comenté en ¿Cuando puedo aplicar una metodología ágil? y en 7 Paradigmas a romper para ser ágiles

Si a esto le unimos la semiestructuración de los procesos decisionales, nos encontramos que para aplicar una metodología ágil en un proyecto de Business Intelligence, tenemos que tener muy claro a que nos estamos enfrentando. Para ello el primer proyecto que se haga de estas características en la organización tiene que tener no solo el caracter de una metodología rigurosa y seria, sino también la característica de "evangelizar", de ser un caballo de Troya que infecte a todos los ambitos de desarrollo de la organización.

Un metodología (que desgraciadamente su autor no ha seguido desarrollando) es el Adaptative Software Development, esta metodología parte de la idea de que las necesidades del cliente son siempre cambiantes durante el desarrollo del proyecto (y posteriormente a su entrega). Cosa que nos viene que ni pintada para los sistemas decisionales

Su impulsor es Jim Highsmith, la novedad de esta metodología es que en realidad no es una metodología de desarrollo de software, sino un método (como un caballo de troya) a través del cual inculcar una cultura adaptativa a la empresa ya que su velocidad de adaptación a los cambios marcará la diferencia entre una empresa próspera y una en declive.

La incertidumbre y el cambio continuo son el estado natural de los sistemas de información, pero parece ser que muchas organizaciones aún no son conscientes de ellos. La idea de “finalizar” un proyecto carece de sentido porque debe seguir adaptándose y con mas razón si se trata de un sistema decisional. Siempre estamos cambiando nuestros puntos de vista.

Así pues tenemos una metodología (mas bien un metodito) con 4 objetivos claros (independientemente de que el proyecto sea un éxito)

1. Concienciar a la organización de que debe esperar cambio e incertidumbre y no orden y estabilidad.
2. Desarrollar procesos iterativos de gestión del cambio.
3. Facilitar la colaboración y la interacción de las personas a nivel interpersonal, cultural y estructural.
4. Marcar una estrategia de desarrollo rápido de aplicaciones pero con rigor y disciplina.El ciclo de vida que propone se basa en tres fases

El ciclo de vida que propone se basa en tres fases

Fase 1: Especulación. Se inicia el proyecto y se planifican las características del aplicativo a desarrollar.

Fase 2: Colaboración. en esta el equipo de desarrollo se encarga de implementar las características

Fase 3: Aprendizaje. En ella se revisa su calidad, se aprende de los errores y se vuelve a iniciar el ciclo de desarrollo y/o se entrega al cliente.

Pero lo importante no son las fases ni nada por el estilo, lo realmente importante es que cambia la semántica de la creación de sistemas de información:

En lugar de analizar, diseñar, implementar, etc.. que es el lenguaje habitual con una semántica de infalibilidad y definitud (creo que me he inventado esta palabra) algo jactante, pasamos a especular, colaborar y aprender juntos y eso creo que es una buena característica para una metodología, sea cual sea su ámbito de actuación.


Por favor no me pongais ningún comentario a esta entrada (estoy probando la psicología inversa a ver si consigo mas colaboración) :-D

Tres enfoques para una metodología DWH

Buscando metodologías de BI, me he encontrado con el siguiente artículo:

Data Warehouse Methodology:A Process Driven Approach
Claus Kaldeich and Jorge Oliveira e Sá
Universidade do Minho, Escola de Engenharia
Departamento de Sistemas de Informação, Campus de Azurém
4800-058 Guimarães, Portugal

No es precisamente lo que estaba buscando pero en la introducción hace referencia a los tres enfoques que puede tener una metodología para datawarehouse.
La idea es que el enfoque de toma de requisitos (requeriment-driven approach) no sirve para este tipo de proyectos ya que este enfoque no satisfará las demandas futuras de los usuarios, y los usuarios dificilmente son capaces de definir y explicar como toman sus decisiones.

Así pues, nos brinda tres alternativas, para que nos hagamos nuestra propia metodología.

• Data-Driven approach: Este enfoque deja de lado a priori a los usuarios, los objetivos de la organización y se centra en los datos. En como están estructuraros, en quien los usa, en la forma en que los usan. Se fija en los datos con mayor tasa de acceso, aquellos que se consultan con mayor frecuencia, como se relacionan entre ellos, que consultas suelen venir asociadas. Son los datos los que dirigen el proceso. Es un poco como el doctor House, los usuarios mienten, pero los datos no.

• Goal-Driven approach: Este enfoque se centra en el objetivo de los procesos de la organización y se basa en el análisis de la interación de tanto clientes como usuarios hacen para conseguir dicho objetivo. A partir de ahí establece necesidades de información e interrelaciones entre ellas que darán lugar a la estructura del datawarehouse. Fijaos que este método da lugar una estructura quizás no del todo estructurada, mas al estilo de Inmon que de Kimball.

• Demand-Driven (or user-driven) approach: Este enfoque asume que todos los usuarios conocen la estrategia empresarial y se comportan de forma coherente con ella. Si realmente son ellos los que van a tomar las decisiones, son ellos los que deben dirigir el proceso de creación del datawarehouse. Se empieza con un primer prototipo muy rudimentario basado en los objetivos empresariales y a partir de ahí los usuarios definen las necesidades de información, las preguntas que le van a hacer al DWH, etc.. .......¿no os recuerda de forma clara a las metodologías ágiles?
  

Pero aquí solo estamos hablando de DWH, con lo que hago la siguiente reflexión ....
¿que pasaría si utilizasemos estos tres enfoques en cada uno de los ámbitos de toma de decisiones?

Conclusión:

• Seguramente nos encontraríamos que en las decisiones operacionales el Data-Driven Approach será el mas adecuado, mientras que en las tácticas un Demand-Driven Approach nos dará mas beneficio y obviamente en las decisiones estratégicas el Goal-Driven Approach será el mas útil.