lunes, marzo 26, 2007

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.

miércoles, marzo 14, 2007

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.