Nace la revista GdR (Gestión del Rendimiento)

En estos dias he estado muy liado entre otras cosas ayudando a llevar a cabo un proyecto muy interesante, una revista en papel, de esas antiguas que se leían antes de que existieran los blogs, pues de esas. Se trata de la revista GdR (Gestión del Rendimiento) Al final me he involucrado tanto que hasta tengo sección propia y todo, con un título bastante críptico "Gap de Oxímoron".

El artífice de esta experiencia es Paco Marín, que no solo ha conseguido enredarme a mi, sino tambien a otro conocido blogger del BI Jose Maria Arce.

El caso es que el primer número ya esta en la calle, este año serán 4 números y para aquellos que llegueis tarde al primer número os podreis subscribir GRATIS a los 3 siguientes.

Os pongo el índice del primer número para que podais ver de que trata.

Espero que os guste.

Starting Area (Características: Tercera Parte)

_{(Nota: Este post lo estoy haciendo desde los Docs de Google a ver como queda. Es que desde que perdí todos los datos de mi agenda, me he pasado a las aplicaciones de google y la verdad me están sorprendiendo gratamente.)}

Con este post acabo la trilogía de la STA, lo prometo ;-D.
Por cierto dejad de comentad tanto que no me da tiempo a leerlo todo
_{(ostras, no veo como se pone la letra en "irónica", solo he encontrado "cursiva", je je)}

Características:

1) Responder de forma ágil cualquier petición decisional que nos surja.

Si mezclamos información de detalle, con estructuras de Inmon, podemos responder de forma ágil a cualquier petición de información decisional.
Luego si vemos que es necesaria entonces ya crearemos una estructura de análisis de tipo dimensional (Kimball) si es necesario. Pero muchas de estas peticiones suelen morir al cabo de pocas semanas, de esta manera podremos ver el uso que se hace y si debemos incorporarla definitivamente a la estructura estable del DWH. Siempre que nos pidan algo muy específico, podemos poner la información en "cuarentena" en la Starting Area antes de decidir si es lo suficientemente madura para formar parte del DWH.

Así en la Starting Area tendremos información de detalle (operacional), información agregada (operacional) al estilo ODS, información agregada decisional (Inmon) que esta esperando la "madurez" para pasar al DWH e información unificada de diferentes modelos que sirve de embrión al Masterdata.

¿Que información almaceno entonces en la STA?
Pues en la Starting Area tendremos 4 tipos de información diferente:

1. Información de detalle (operacional) inicio de los procesos ETL.
2. Información agregada (operacional) al estilo ODS.
3. Información agregada decisional (tipo Inmon) que esta esperando la "madurez" para pasar al DWH.
4. Información unificada de diferentes modelos que sirve de embrión al Masterdata..

2) Diluirse a medida que la estructura decisional madura.

Obviamente mucha de esta información que ahora estamos poniendo en la STA, tiene que seguir si propia evolución hacia un sistema decisional mas completo, la información de tipo 2 y 3 deberían ir migrando hacia un DWH estilo Inmon de forma gradual, la información de tipo 4 evolucionar hacia un proyecto de Masterdata y la de tipo 1 ir desapareciendo a medida que se consolidan en otros sistemas los otros tres tipos de información.

Por eso la Starting Area tiene una fecha de caducidad.

Starting Area (Funcionalidades: Segunda Parte)

En el anterior Post introduje como nació la Starting Area (STA de ahora en adelante).

Esta idea ha ido evolucionado y la STA cumple actualmente 4 funcionalidades y posee 2 características (que ya avancé en el anterior post)

1) Relanzar los procesos de ETL cuando los necesites.

La primera de ellas la pudimos ver en el anterior post. Se trata de tener siempre "llenos" los primeros pasos de los procesos ETL, y no borrar esa información. Para ello cogemos el último nivel de agregación desde el que construimos el DWH. Obviamente como vamos a dejar la información de forma permanente la STA debe estar obligatoriamente en una base de datos relacional diferente a la Staging Area (STG) para poder optimizarla y realizar tunning de forma separada en el caso de que el volumen de datos así lo hiciera recomendable.

2) Ser el embrión del MasterData

Obviamente todos estos procesos necesitan de una unificación del modelo cuando las fuentes de datos son heterogeneas. Por ejemplo si estamos unificando el concepto "Cliente" podemos tener un modelo E-R de Cliente en el ERP que nada tenga que ver con el "Cliente" del CRM y que en la aplicación de gestión comercial tenga otro significado muy distinto. Obviamente desde el punto de vista decisional nosotros tenemos un único "Cliente" así pues en la STA, cuando las fuentes de datos son heterogeneas ,nos quedamos con el último nivel de detalle pera una vez unificado el modelo. Así esta tabla puede ser unificada no solo en la parte decisional sino que cualquier otra aplicación que quiera hacer uso de "Clientes" puede intorducirla como su fuente de datos operacional, de esta manera tenemos el embrión de un MasterData de la organización que mas adelante pueda servirnos tanto para la parte de sistemas de información transaccionales, como para los sistemas de información decisionales. Es una buena manera de empezar a difundir el concepto de MasterData en aquella empresas que no están maduras.

3) Proveer de Reporting para la trazabilidad decisional a nivel de detalle.

Muchas veces desde el DWH necesitamos vincular con información de detalle cuyo detalle tenemos que ir a buscarlo al operacional, por eso nos puede llegar a interesar tener algún repositorio con esa información ya almacenada (siempre que no estemos tratando de información a tiempo real). Por ejemplo, si queremos saber el número de incidencias de producción la semana pasada lo tenemos fácil, pero si queremos buscar una descripción de los incidentes de gravedad 1 de esa misma semana para ponerlo en el Informe, entonces deberíamos ir al operacional. Para facilitar esto lo que podemos hacer es traernos un nivel de detalle mas bajo que el que estamos utilizando en el DWH y vincularlo con la base de la estrella al mas puro estilo Inmon, como Reporting. Alguien podría decir que esto no es mas que un ODS (Operational Data Storage) y le daría la razón pero con un matiz, y es que los ODS carga información operacional agregada y yo cargo información de detalle muy bajo, ya que la información típicamente agregada del ODS para mí es parte del modelo del DWH al combinar Inmon y Kimball en la base de la estrella.

Este nivel de detalle bajo nos puede ayudar también a crear el MasterData y nos da esa capacidad de reporting complementaria al DWH sin que tengamos que molestar a los operacionales.

4) Realizar mejora de la calidad de forma "continua"

La STA como he dicho tiene un repositorio diferente de la STG y obviamente del DWH, así que podemos lanzar los procesos de carga de la STA con una periodicidad mucho mas pequeña que no la del DWH limpiando y puliendo los datos antes de hacer la carga definitiva del DWH. Esto nos da la posibilidad de detectar los errores antes de lanzar los procesos definitivos y mas costosos, mejorando la calidad del dato y los tiempos de los procesos de carga.
De esta manera podemos construir escenarios en los que la STA se cargue diariamente y el DWH mensualmente. La mayoría de los posibles problemas de calidad del dato tienen 30 oportunidades de ser detectados antes de cargar el DWH.

Estas son las funcionalidades de la Starting Area, en el próximo (el último de esta trilogía) comentaré como construirla y sus dos características:

1) Responder de forma ágil cualquier petición decisional que nos surja.

2) Diluirse a medida que la estructura decisional madura.

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.

La heterogeneidad de fuentes complica la toma de decisiones

Comunmente nos encontramos con entornos empresariales en los que el ERP es de un fabricante, el CRM de otro, el SCM es un desarrollo a medida, ninguna de las aplicaciones se ejecuta en el mismo sistema operativo, casi todas están desarrolladas en diferente lenguajes de programación, y para diferentes plataformas, tenemos múltiples bases de datos con información crucial y no contrastada, y en los que el CIO se tira de los pelos día si y día también.

Son generalmente sistemas de información con una larga evolución histórica y que se han visto abocados sin remedio a convivir con multitud de subsistemas. Citaré cuatro ejemplos de cómo se puede haber originado, y seguro que alguno de vosotros se encuentra en esa misma situación:

* Heterogeneidad originada por el paso del tiempo. Nuestra empresa inicialmente comenzó con un ERP sobre un AS400, con el paso del tiempo vió la necesidad de un SCM, pero como las tecnologías habían cambiado decidió hacer una aplicación a medida en un entorno cliente/servidor. Pasaron unos años más y la web era lo último y se decidió poner un sistema CRM estándar y basado en J2EE, etc, etc.

* Heterogeneidad originada en departamentos. Algunos departamentos de nuestra organización tienen necesidades diferentes y/o muy específicas, que les han hecho optar por SI departamentales, en los que existe un alto grado de independencia con respecto al SI organizacional.

* Heterogeneidad originada por fusiones. Nuestra empresa, se ha fusionado con otra empresa heredando todos sus SI y duplicando funcionalidades. Son entornos en los que nos podemos encontrar con dos ERPs conviviendo a la vez.

* Heterogeneidad originada por descentralización. Tenemos muchas filiales distribuidas geográficamente y es difícil controlar la evolución de los SI en cada una de ellas debido a que poseen un alto grado de independencia necesario para adaptarse a las características especiales de su zona geográfica en concreto.

¿Cómo podemos implementar un sistema que nos ayude a tomar decisiones en estos entornos tan caóticos?.
¿Cuales son las pautas metodológicas que nos harán crear un sistema decisional que no tenga los pies de barro?.

Mi solución mezcla ingredientes de Masterdata, ODS y Staging Area, claro esta sazonada con un pizca de Inmon, es lo que llamo la Starting Area y a la que pienso dedicar el próximo post.

Antonio Valle, la disfunción cromática y la disonancia cognoscitiva

La ventaja de poder colaborar con Antonio Valle es que siempre se saca algo de la chistera que te deja con la boca abierta y con cara de tonto. El martes fue uno de esos dias y hasta hoy no te tenido tiempo de "novelar" lo ocurrido.

Estabamos en una charla animada, en una consultoría, evaluando los posibles escenarios finales y los resultados que se podrían derivar de que un determinado KPI /Métrica, apareciera en rojo en el cuadro de mando. A lo que yo argumenté que si sucedia ese hecho, era un claro indicador de que estaba pasando en hecho X y que teníamos obligatoriamente que tomar la decisión Y.

A lo que Antonio, se me quedó mirando, hizo una pausa de esas que tanto le gustan y nos espetó a todos los presentes en la reunión : "Bueno, eso será así siempre y cuando el analísta no tenga disonancia cognoscitiva o disfunción cromática".

Y ahí se me quedó la cara de tonto, pero es verdad, todo sistema decisional muestra la información de la manera objetiva y nos creemos que con eso es suficiente que ya esta hecho el trabajo, pero aún faltan dos procesos:

• La recepción de la información en el cerebro del análista
  

Casi todas las herramientas de BI, muestran la información o a través de reports o cuadros de mando o complejas anílíticas interactivas....¿pero llega esta información de forma correcta al receptor? ¿Que pasa si muestras gráficos de barras, tendencias, diagramas de pareto, alarmas, códigos semáforicos y el analista sufre disfunción cromáticamas conocida como daltonismo?

Imaginaos que teneis esta gráfica triple y simplemente teneis que explicar porque no se ha conseguido el objetivo (en azul) y las discrepancias entre lo planificado (en verde) y lo ejecutado (en rojo).

• La ejecución del proceso físico de toma de decisiones en el analista.
  

Que pasa si la información que recibes entra en frontal conflicto con tu paradigma decisinal, que pasa si esa información hace que tengas que tomar una decisión que está en total disonancia con lo que tú realmente piensas. ¿la tomarás igualmente o cambirás el peso que esta información tiene en tu toma de decisiones?. Eso es lo que se llama disonancia cognitiva y que en el artículo que os linko se resume como:

"Es el conflicto mental que abunda en la experiencia cuando se presentan evidencias de que una creencia propia o asunción personal es incorrecta. La teoría de la disonancia cognoscitiva afirma que hay una tendencia en la gente a reaccionar para reducir tal disonancia. Una persona puede evitar la nueva información o convertirse manipulador de argumentos para mantener su creencia o juicios.
Por ejemplo, Erlich, Guttman, Schopenbach y Mills (1957) mostraron que los nuevos compradores del coche evitan selectivamente los anuncios de la lectura para los modelos del coche que no eligieron, mientras que por otra parte los atrajeron a los anuncios para el coche ellas eligieron. "

Ambos procesos pueden sufrir fallos que nos hagan tomar una decisión erronea, y eso no hay sistema decisional que lo pueda solventar.

Así que mantened vuestras mentes abiertas :-D

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?

Feliz Navidad (un clásico)

Os deseo a todos una Ágil Navidad y que en este Metodológico 2007 tomeis buenas decisiones ;-D

¡¡¡¡FELIZ NAVIDAD Y PRÓSPERO AÑO 2007!!!!

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

Kimball 1 - Inmon 1 (Usabilidad vs Representación)

La "lucha" Kimball vs Inmon es ya de todos conocida, pero quizás no lo sea tanto las aseveraciones y mensajitos que ambos se han lanzado.

Kimball aseguró en 1997 su modelo multidimensional era "la única manera viable de diseñar bases de datos destinadas a su uso directo por parte de un usuario final".

Casi todos le siguieron la corriente, pero obviamente algunos valientes se le tiraron a la yugular entre ellos Inmon en 2000 cuando dijo que si diseñas un DWH desde el punto de vista de análisis de un solo individuo condenas al resto a su mismo punto de vista y que dificilmente en el modelo dimensional puedes incluir información no incluida en el foco original del análisis.

Pero no solo Inmon cuestiona este punto de vista, tambien Haughey en el 2004 comenta que "el mundo no es una estrella" y que el modelo multidimentional no puede representar de forma efectiva escenarios complejos de negocio.

Con lo que el primer gol de lo asigno a Inmon, así pues Kimball 0 - Inmon 1.

Pero mira por donde este grupo de investigadores decide mirar si la aseveración un poco prepotente de Kimball con la que hemos empezado era cierta o no y publican el siguiente artículo:

Comparing the Effect of Alternative Data Warehouse Schemas on End User Comprehension Level
David Schuff
209F Speakman Hall, Fox School of Business, Temple University
Karen Corral
BA297L, W.P. Carey School of Business, Arizona State University
Ozgur Turetken
209G Speakman Hall, Fox School of Business, Temple University

En el que hacen un estudio de como ambos modelos son vistos por los usuarios finales y como afectan ambos modelos a la usabilidad decisional.
La conclusión del artículo (que lo podeis descargar entero) hace que el marcador se iguale a 1, ya que concluye que para usuarios con poca experiencia el modelo dimensional es mucho mas usable y productivo.

Así pues por un lado ganamos capacidad para representar escenarios complejos pero necesitamos usuarios listos y expertos, mientras que por el otro perdemos capacidad de representación pero ganamos que cualquiera pueda usuarlo.

De momento 1-1.

¿Alguien se anima a meter algún gol mas?
¿Creeis que es lícito sacrificar esa capacidad de representación en pro de la usabilidad?.

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.

¿Cuando puedo aplicar una metodología ágil?

He hablado mucho de metodologías ágiles, y parece que se pueden adaptar fácilmente a las necesidades del datawarehouse, pero aún no hemos visto cuando debemos utilizar un metodología ágil, independientemente de que el proyecto sea o no de Business Intelligence. Cada proyecto necesita de una metodología adecuada a él que le garantice el éxito. Necesita que se adecue no solo a sus funcionalidades a desarrollar, sino además al equipo de desarrollo, a los recursos disponibles, al plazo de entrega, al entorno socio-cultural, la cultura empresarial, etc…

Un buen profesional no debería cerrarse en una metodología de forma ciega, siempre se ha de cuestionar si es la apropiada antes de empezar el proyecto. Pero aún así existen algunas reglas básicas, de “sentido común”, que voy a tratar de resumir en .....



Las Siete preguntas que nos darán la llave de la agilidad.
(No sé que me pasa con el siete, se admite debate) :-D



Pregunta 1 ¿Cómo es de grande tu proyecto?.

Si se trata de un proyecto pequeño y/o con un equipo reducido de desarrollo, de tres a ocho personas, tienes una oportunidad de experimentar con los métodos ágiles

Pregunta 2 ¿Son tus requisitos dinámicos?.

Si te encuentras ante un ámbito de actuación los puntos de vista de análisis estan constantemente cambaindo como podría ser un datamart de fuerza de ventas, entonces la metodología ágil te ayudará a responder a esta variabilidad
Si estas en un ámbito en el que el dinamismo es poco, por ejemplo el análisis de los estados financieros y contables, en el que los KPI son casis siempre los mismos para todas las empresas, quizás no te sea tan útil.

Pregunta 3 ¿Qué pasa si tu sistema falla?.

Si te encuentras en un sistema crítico en el que cualquier fallo involucre grandes pérdidas humanas o grandes cantidades de dinero, por favor no utilices las metodologías ágiles.
Si nuestro Datamart involucra decisiones operacionales a corto plazo por ejemplo en la creacion de un Business Activity Monitoring, mejor asegurarnos el éxito con una metodología orientada al plan.

Pregunta 4 ¿ Tu cliente tiene tiempo para dedicarlo al proyecto?.

Si la respuesta es no olvidate de la metodología ágil haz el tipico contrato legal o mejor no aceptes el proyecto

Pregunta 5 ¿Cuantos perfiles juniors tienes en tu equipo de desarrollo?.

Las metodologías ágiles requieren de una gran madurez, experiencia y una dosis de talento. Deben de ser equipos con gente seniors o semi-seniors. Si tu equipo lo constituyen principalmente novatos lo mejor es que no lo intentes con las metodologías ágiles.

Pregunta 6 ¿Cuál es la cultura empresarial de la empresa en la que se va a desarrollar el proyecto?.

Las metodologías ágiles requieren de cierto ambiente “informal”, que fomente la comunicación de igual a igual. Si la organización en la que se quiere desarrollar el proyecto tiene un alto grado de ceremonia, pomposidad y jerarquías estrictas, no deberías utilizar las metodologías ágiles.

Pregunta 7 ¿Te apetece?
Realmente tienes ganas de probar una metodología ágil, aprender cosas nuevas supone casi siempre un nuevo sacrificio.

Si tu equipo es pequeño y esta formado mayoritariamente por gente con talento y experiencia, si el cliente final está involucrado y no impone barreras de comunicación, si los requisitos son altamente cambiantes, si no es proyecto crítico y no es demasiado grande, y te apetece probar una metodología ágil, no lo dudes, es el momento de experimentar con las metodologías ágiles.

Si no eres de Vulcano necesitas Fuzzy OLAP

Como bien dice Angel Agueda en un blog "Inactivad es sinonimo de mucho trabajo"
Así que voy a hacer una pequeña anotación para recordaros que sigo en la brecha, a pesar de que el ritmo no es que yo desearía.

¿Recordamos todos Star Trek? Supongo que si, sabreis entonces que Spock( y todos los de Vulcano), regían sus acciones sobre la más estricta de las lógicas, sin inmutarse ni pestañear, refrexionaba todo cuantitativamente y daba la respuesta más lógica. Mítica es la frase "el bienestar de la mayoria supera al de la minoria y de a uno solo" con el que Spock decide que es más lógico sacrificarse él por salvar a toda la tripulación del Enterprise.

El caso es que su contrapunto en la serie era el Capitán Kirk que tomaba las decisiones sin meditarlas demasiado, con el estómago como quien dice, al mas puro estilo "humano".

Así pues, si fueramos de Vulcano nos serviría perfectamente la estructura OLAP tradicional (como ya comenté en el post Mi cerebro ... ¿un producto cartesiano?), pero obviamente no tenemos esa capacidad y el cosquilleo en el estómago y la intuición a veces tienen un peso más que específico dentro de nuestra toma de decisiones. Eso me recordó que quizás la lógica difusa (fuzzy logic) podría ayudarnos mas que la lógica pura, y que quizás un análisis cualitativo fuera mas adecuado para la toma de decisiones. Sin muchas esperanzas me puse a buscar y ¡oh! ¡Sorpresa! alguien ya estaba investigando en esa linea.

El articulo con el que he topado es

	Fuzzy OLAP cube for qualitative analysis Pavan Kumar, K.V.N.N.; Radha Krishna, P.; Kumar De, S.; Intelligent Sensing and Information Processing, 2005. Proceedings of 2005 International Conference on 4-7 Jan. 2005 Page(s):290 - 295 Digital Object Identifier 10.1109/ICISIP.2005.1529464 Summary: Data warehouse systems enable decision-makers to acquire and integrate information from heterogeneous sources and query very large databases efficiently. Data warehouse provides the users with an online analytical processing (OLAP) facility by which .....

Como siempre de investigadores de la India que cada vez están mas fuertes (o tienen más tiempo libre). El artículo tiene la bondad de no solo teorizar sino de implementar un ejemplo práctico con un cubo de ventas, que si bien es muy limitado si que nos da una idea de como utilizar la lógica difusa en la consulta de cubos OLAP.

El ejemplo con el que juegan es ¿cuando un cliente/vendedor se puede calificar de Bueno, o Medio o Malo? ¿Lo tenemos claro? ¿Es totalmente estricto o dejamos cierto margen de variabilidad?. Pare ello utiliza algoritmos de lógica difusa mezclados con algoritmos de mineria de datos sobre un cubo OLAP. Es una buena aproximación sobre la que seguiré reflexionando.

¿Inmon o Kimball? o cuanto apreciamos la trazabilidad decisional

Despues de un tiempo de silencio (la entrada en septiembre ha sido un poco dura) y tras hablar de ontologías, vamos a bajar de nuevo a la parte de decisiones operacionales y tácticas.
En este ambito la creación de los Datawarehouse tienen dos grandes gurús, por un lado el archiconocido Kimball con su modelo multidimensional, y por el otro el quizás menos conocido pero no menos importante Inmon.

Me he estado leyendo este artículo que la verdad aporta poco y no es mas que una revisión de todos los conceptos de un datawarehouse, pero que me ha servido para reflexionar cual es mi propio de creación de datawarehouse y cual sería el más apropiado para una metodología ágil

MODELING STRATEGIES AND ALTERNATIVES FOR DATA WAREHOUSING

Articulo de Nenad Jukic publicado en communications of ACM en abril de este año.

Y me ha sorprendido comprobar que estoy mas de acuerdo con las tesis de Inmon que con las de Kimball, yo que he sido un fiel seguidor del primero

Aquí podemos ver dos típicas arquitecturas al "estilo Kimball"


El primer modelo es el utilizado en algunas implementaciones MOLAP puras en las que tenemos varios procesos ETL, que se conecta a diferentes fuentes de datos y generamos los diferentes datamarts dimensionales. Son generalmente datamarts independientes entre ellos para el uso de un solo departamento o incluso de una sola persona.


El segundo modelo es el Kimball mas corporativo en el que un proceso ETL nutre un espacio datawarehouse en el que se comparten las dimensiones entre diferentes puntos de vista y en el que los datamarts de cada departamento forman utilizando los hechos y las dimensiones ya establecidas para toda la compañia.



Todo normal hasta aquí y perfectamente de acuerdo con ello, yo mismo he hecho decenas de dwh utilizando el dogma Kimball


Pero miremos ahora el "estilo Inmon"
Coincide con Kimbal en un único proceso ETL que nutra un DWH corporativo, pero el que él nutre no es dimensional es un DWH basado en el modelo Entidad-Relación.
La idea de Inmon es que el modelo E-E mucho mas rico y adaptable que el multidimensional.

Una vez tenemos el DWH E-R corporativo generamos los datamarts dimensionales que queramos, y no solo eso, nos puede servir para crear cualquier otra extracción para cualquier otro sistema decisional, como puede ser para mineria de datos o para sistemas expertos, por ejemplo.

Lo que me gusta de Inmon es que no se cierra a un solo modelo y no solo eso, además su arquitectura mejora la trazabilidad decisional. Con ella podemos desgranar un valor en un KPI hasta una serie de análisis y reports que lo expliquen en detalle, tan en detalle como nos permiten los modelos E-R que tenemos en nuestros sistemas operacionales.

Parece maravilloso, pero el problema es que es mas costoso de mantener y de implementar. El de Inmon es un modelo que mira a largo plazo y para una metodología ágil el largo plazo es secundario. Para adaptarlo y no perder la agilidad de por ejemplo el primer modelo de Kimball, yo he utilizado a veces lo que he llamado la "Starting Area".

Si el proyecto necesita de una trazabilidad que llegue hasta el ultimo nivel de detalle, lo mejor es crear un capa que sea una copia exacta de los diferentes modelos relacionales de los que se nutre el modelo dimensional. Una simple BULK COPY nos servirá inicialmente, no hace falta unificar el modelo E-R de las diferentes fuentes origen en uno solo, eso es demasiado trabajo. La idea es dejar la semilla de una capa relacional por debajo del dimensional y que ambas crezcan de forma conjunta alo largo del proyecto.

Creo que esta sería la mejor opción para una metodología ágil, nos permitirá tener la rapidez del modelo Kimball y la visión de futuro del modelo Inmon.

De la Web Semántica a la Ontología Decisional (2ª parte)

Todo Ontología se compone de tres partes:
1) Clases e instancias de los objetos que la componen
2) Propiedades que establecen relaciones
3) Reglas para modelar el conocimiento y los comportamientos complejos ( Creación, Restricción y Reacción).

Si no aplicamos el último componente (las reglas) obtendremos o bien una ontología ligera o bien una Taxonomia que no es el objetivo que buscamos en principio.

Así pues ,si queremos tener una ontología decisional, ¿debemos utilizar reglas?.

La utilización de reglas nos origina el problema de la capacidad del motor de inferencia, cuando la base de conocimiento sobre la que se intenta inferir es muy grande, los motores tienen graves problemas de escalabilidad, siendo inviables hoy en dia.

• RuleML (http://www.ruleml.org/)es un ejemplo de lenguaje de reglas basado en XML, si la base de conocimiento no es demasiado extensa, funciona perfectamente. Pero...
• ........¿que tipo de toma de decisiones tiene una base de conocimiento relativamente pequeña?. Desde luego las decisiones estratégicas no, con lo que una de mis primeras intuiciones, aplicar reglas basadas en conocimiento en los sistemas estratégicos, parece que se va limitar a ambitos de actuación muy especializados. Mi gozo en un pozo.

La no utilización de reglas nos origina el problema de la poca capacidad expresiva del conocimiento. Hay varias alternativas una de ellas es utilizar lenguajes lógicos que alternen capacidad expresiva y posibilidades computacionales reales, ya que la lógica de predicados de primer orden es intrinsecamente indecidible.

• OWL-DL, reduce las posiblidades expresivas de la lógica de predicados de primer order obteniendo un lenguaje de razonamiento de capacidad exponencial pero que puede ser procesado (ya no es indecidible, aunque es exponencial). OWL-DL tiene la potencia suficiente como para representar un modelo de Entidad-Relacion (E-R) (OWL-DL can represent E-R Models). Actualmente se esta investigando como mapear modelos OWL-DL sobre diagramas UML. Con lo que se nos abriría una via importante para su utilizacion en entornos decisionales operacionales.

La otra alternativa es la utilizacion de ontologías lígeras (sin reglas) pero fortalecidas con "razonadores" que expanden las consultas utilizando una base de datos relacional y por lo tanto todas las capacidades de ejecución y optimización que poseen en la actualidad. Esta alternativa no plantea problemas de escalabilidad, y aunque no es tan purista, posiblemente sea mas fácil de implantar para entornos tácticos y estratégicos.

Así pues ya tenemos una idea de como crear nuestras ontologias decisionales, pero lo que no sabemos es lo fundamental... ¿como le hago una pregunta? ¿me sirve el SQL de toda la vida?. Obviamente no. Existen lenguajes de consulta específicos para atacar a las ontologías, uno de ellos es SPARQL( Un lenguaje de consulta para RDF ). No es el único, exiten otros como RDQL y RQL, pero es el que parece que se convertirá en estándar de la W3C.

Así que ya podemos pensar en que al SQL le ha salido un nuevo compañero de viaje. Sin duda en el futuro los sistemas decisionales hablaran SPARQL.

De la Web Semántica a la Ontología Decisional (1ª parte)

El auge de estudios que se están produciendo entorno a la Web Semántica está disparando hacia la madurez a la Ingeniería Ontológica a pasos agigantados y en el camino se están sembrando una gran cantidad de conceptos que nos pueden servir para definir una nueva forma de entender los sistemas decisionales.

Así que pensando que cualquier analogía es buena, me lancé a leer mas sobre el tema, de entre los articulos que he ido hojeando, dos son los que mas idea me han ido dando y que por suerte os podeis descargar desde la web de Novatica.

Son estos:

1. La Web Semántica: fundamentos y breve "estado del arte" , Luis Sánchez Fernández, Norberto Fernández García [resumen][contenido completo en formato PDF - 285 KB]
2. Recuperación de información en la Web Semántica . David Vallet Weadon, Miriam Fernández Sánchez, Pablo Castells Azpilicueta [resumen][contenido completo en formato PDF - 340 KB]

Si os gusta el tema os recomiendo que os los leais detenidamente y los complementeis con los articulos que Javier Urrutia esta publicando recientemente en su blog con respecto a la aplicacion empresarial de ontologias

El primer paso que tenemos que dar para pasar de la sintaxis a la semántica es dotar a los usuarios de un vocabulario común en el que todos utilicemos las misma palabras con los mismos significados semánticos, eso o bien pedirle peras al olmo. Cualquier de las dos nos vale como utopía.

Eso es imposible y ademas no deseable, para obtener un sistema decisional orientado hacia la semántica, lo primero que debemos pedirle es precisamente que los diferentes tipos de usuarios utilicen su propio vocabulario con sus propias connotaciones de negocio.

Como en la web semántica este requisito es idéntico, la W3C ha creado un lenguaje para representar (y anotar) conocimiento en la web, es el RDF (Resource Description Framework) pensado para anotar documentos web y xml.

Ahora bien, yo me pregunto: ¿como trabajan la mayoria de los Suites de Business Intelligence actualmente? ... pues en entorno web. Todos los informes generados son presentados a través de un navegador, ¿que pasaría si los propios usuarios pudieran dotar de anotaciones que aportasen significado a estos informes?. Y no solo eso, ¿qué pasa con todos esos informes que circulan en documentos word, powerpoints y excel por las empresas (a veces el 80% de la información de caracter analítico y decisional) que pueden ser exportados a xml?. ¿Qué pasaría si el MS Office (por decir uno) te dotase de la capacidad de hacer anotaciones semánticas en tus presentaciones de resultados?. Como veis la capacidad de dotar de semántica a todos nuestros actuales sistemas de análisis esta a punto de ser realidad aprovechándonos de la web semántica.

Existen algunas herramientas que estan saliendo que facilitan la anotación manual (por ejemplo SHOE KnowledgeAnnotator ), pero.... ¿me sirve de algo?. Si tengo que ir informe por informe anotando manualmente, posiblemente me canse o las anotaciones sean de menor valor o rutinarias. Para ello existen sistemas de anotación semiautomáticos como puede ser PANKOW que exploran el documento buscando referencias a conceptos descritos en ontologías.

Con lo que llegamos a mi primera conclusión: La anotación semántica decisional debe tener un caracter semi-automático

Vale, ya tengo anotados todos mis informes y análisis, pero para anotarlos necesito hacer referencia implícita o explícitamente a una ontología, quiera yo o no quiera, y esa ontología si quiero hacer algo con ella debo procesarla y compartirla con el resto de usuarios de mi organización.

Aunque parezca una perogrullada, para tener una ontología debo especificarla antes, pero ¿como las especifico?, yo nunca he creado ninguna y las que utilizo están implitas en mi cerebro, ¿que tengo que poner? ¿por donde empiezo?. No os preocupeis, por suerte hay gente muy lista en todo el mundo y algunos de ellos estan pensando en una metodología para el desarrollo de ontologías. Una de las inciativas mas conocidas es METHONTOLOGY . La siguiente pregunta que me viene a la cabeza es ¿será una metodología ágil o el armatoste de siempre?. La respuesta es.....que es el armatoste de siempre, es del año 1997 y el ciclo que proponen no es que sea demasiado ágil. Así que seguiré buscando por si hay alguna.

Con lo que llegamos a mi segunda conclusión: Necesitamos de una metodología agil para crear ontologías decisionales que puedan ser aplicables al negocio

Tambien necesitaremos herramientas de creación de ontologías decisionales, pero con el tiempo estarán integrads dentro de las suites de BI, Por ahora existen varias en el desarrollo, pero quizás la que esta teniendo mas éxito es Protegé realizado en la Universidad de Stanford

Pero sigamos explorando las caracteristicas que podemos aprovechar de la Web Semántica.

En un sistema decisional, un grupo de usuarios, posiblemente del mismo departamento, deberán compartir una ontología común, pero el resto de usuarios de otros departamentos posiblemente tengan las suyas. El concepto Margen para un departamento es posible que sea diferente del que tiene otro, por ejemplo si incluimos o no incluimos los abonos o los impuestos, pero en el informe se utiliza la misma palabra y cada uno entiende el concepto según su ontología.

Obviamente, si no queremos nichos de información aislados y pequeños Reinos de Taifas Reinos de Taifas , estas ontologías deben poder relacionarse. para ello nace una linea de investigación llamada onthology mapping que trata de resolver el problema de detectar qué dos conceptos definidos en dos ontologías se relacionan entre si de alguna manera o si son el mismo concepto.

Con lo que llegamos a mi tercera conclusión: Necesitamos mapear las diferentes ontologías decisionales, no solo por departamentos sino también por tipología de decisión (operacional, táctica, estratégica) aunque esto último es mas una intuición que una conclusión sólida.

Y como se me esta haciendo muy largo, dejaré para otro el siguiente post los motores de inferencia y las reglas decisionales.