martes, octubre 30, 2007

The Triadic Continuum, el fin del Datawarehouse

La verdad es que este post es absolutamente fruto de la casualidad, no lo tenía planificado como la continuación de mi anterior post pero me viene que ni caido del cielo.

No lo digo yo, lo dicen en DM REVIEW

The Best New BI Invention You’ve Never Heard Of

Este fantambuloso invento viene a jubilar definitivamente a los Datawarehouse y a la estructuras de Inmon y Kimball. La nueva "padre" de los sistemas decisionales es Jane Mazzagatti. y su nuevo invento tiene nombre de capítulo de Star Trek NG:

THE TRIADIC CONTINUUM.



¿Que es lo que han hecho Mazzagatti y su equipo de la empresa Unisys? Pues han inventado una estructura de autoaprendizaje en tiempo real, que se "alimenta" de querys de las que "aprende" a dar respuestas, a medida que se va alimentando de datos las respuestas a las preguntas que se hacen al Triadic Continuum pueden ir variando, al igual que funciona el conocimiento en los humanos.
La idea principal del TC es que mientras que en una Base de Datos tradicional (ya sea relacional o multidimensional) nos centramos en la busqueda de datos e información , el centro de atención del TC esta en la adquisición de conocimiento útil y con un proposito decisional determinado. El TC no solamente se centra en el dato, sino en las relaciones que hay entre ellos, sobre estas relaciones, el sistema "aprende" y crea los métodos de explotación y acceso a la información.

Es una estructura que mezcla conceptos de modelado de datos con mineria de datos, en una única herramienta. ¿no os suena de algo? los que habeis seguido el debate del post anterior os resultará esta conclusión muy pero que muy familiar.

La estructura física de este Triadic Continuum la verdad es que se me ha escapado un poco, según el artículo de referencia de DM REVIEW

"El modelo conceptual de la estructura de la Triadic Continuum es bastante simple. Mazzagatti y colegas utilizan el término "simple y elegante" en la explicación de la forma en que está organizada. En pocas palabras, se trata de una estructura de tipo arborea con nodos llamados "tríadas." Estos nodos están conectados entre sí por ramas o caminos. Las tríadas que conforman la Triadic Continuum puede ser visualizadas como tres nodos organizados de forma triangular, en cierta formación. El primer nodo se conecta al segundo nodo mediante un puntero bidireccional, y el segundo se conecta al tercero tambien con otro puntero bidireccional. Los punteros identifican a que nodeo y desde que nodo se conectan , lo que permitirá a todos los nodos a saber siempre su relación dentro de la continuidad de las estructura consultando sólo dos punteros."


Vamos que no me he enterado de nada, pero eso sí, parece que no soy el único que se esta dando cuenta que el Datawarehouse y los sistemas de BI deben de dar un paso evolutivo hacia el "conocimiento", dejando atras los "datos"

Prometo buscar mas info sobre THE TRIADIC CONTINUUM.

MODIFICACION 2-Nov-2007

Ayer recibí un email que me ha dejado patidifuso, un mail muy corto pero a la vez sorprendente y que me ha recordado que estamos realmente es un mundo conectado y que esto de la blogosfera realmente es algo increible.

El contenido del mail es este:

I have read your blog and sent it to my team – I love the TNG picture – the team members were excited to see that someone really grasped the ideas - Jane

Y si señores, es la Jane que sospechais,... ¡¡¡¡Jane Mazzagatti!!!!.

domingo, octubre 14, 2007

Pregunta al aire: ¿Qué debe "almacenar" un DataWarehouse?

Yo cada vez tengo mas claro que debe almacenar todo menos datos, de hecho empiezo a sospechar que el concepto de DataWarehouse está llegando a su fin.

(SILENCIO)
(SILENCIO)
(SILENCIO)

Este silencio es para causar estupor :-D.



No me he vuelto loco, simplemente cae por su propio peso .
Si recordamos la metodología User-Driven , en ella el punto de partida es que los requisitos no son suficientes con lo que se busca mostrar al usuario un prototipo funcional para intentar captarlos lo mejor posible. Esta metodología buscan tener muy bien definido la interfaz de usuario y que la calidad del dato mostrado sea muy buena, el objetivo es conocer al usuario y las cuestiones que se tienen que responder de cara al negocio, sobre todo las de caracter estratégico.


Afolabi y Thiery, es su articulo "Using Users’ Expectations to Adapt Business Intelligence Systems", nos hablan de la importancia de usuario en este tipo de sistemas, no solo a la hora de definirlo, sino basado en sus propias fases cognitivas: observación; abstracción elemental; razonamiento y simbolización; y creatividad. A través de estos estudios podremos adaptar nuestro sistema de BI al tipo de consultas que nos hará el usuario final (Query Adaptation) y al tipo de respuestas que le tenemos que devolver (Response Adaptation).

Conocer como los usuarios "entienden" la información nos permitirá que los sistemas de BI se entronquen directamente con la gestión del conocimiento creando nuevos sistemas que algunos autores ya estan denominado Knowledge Datawarehouse.

Así pues la pregunta esta clara:

¿Que debe almacenar un Datawarehouse?
a) Datos
b) Información
c) Conocimiento.
d) Todas las anteriores
e) Ninguna de las anteriores


Os pongo una encuesta para que interactueis, pero el debate esta abierto.

lunes, octubre 08, 2007

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.