El Cedazo

En las dos entradas anteriores os hablé, en primer lugar de cómo fueron apareciendo y siendo progresivamente ofrecidas al mercado empresarial las máquinas de proceso masivo en paralelo, mientras que en la entrada anterior os hablé, sobre todo, de los fundamentos teóricos necesarios para poder construir Data Warehouses con éxito.

Vimos allí cómo el trabajo de Bill Inmon, definiendo las características que debería tener un Sistema de este tipo, y el de Ralph Kimball, formalizando el Diseño de un Data Warehouse, mediante el Modelo Dimensional, fueron decisivos para que los pobres mortales pudiéramos construir los primeros Data Warehouses… o al menos intentarlo, porque la mayoría de estos primeros Sistemas acabaron, a pesar de todo, fracasando.

Las cifras de fracaso que graciosamente nos daban las consultoras (sobre todo, ésas que de todo hablan y nada solucionan) eran abrumadoras: más del 80% de los proyectos de Data Warehouse iniciados aquellos años (segunda mitad de la década de los noventa), o bien se cancelaban sin implantar nada, o bien, en el caso de que sí que acabaran con un sistema funcionando, era con mucha menos funcionalidad de la prevista, y a mucho mayor coste del inicialmente planeado.

El mensaje comercial evidente era que, si no les contratábamos a ellos, precisamente a ellos para construir nuestro Data Warehouse… el trompazo estaba garantizado. Aunque lo más probable es que, si les contratabas a ellos… pues también te dieras el trompazo.

En una palabra, que no sabíamos aún cómo demonios construir un Data Warehouse y terminar el proyecto en tiempo y coste, y con la funcionalidad esperada. Ya lo he dicho.

Como esto lo sabíamos hacer ya (bueno, más o menos) en los proyectos de construcción de aplicaciones tradicionales (online, batch, en fin, las Operacionales de toda la vida), pues nos frustraba. Nos frustraba a nosotros, los informáticos… y les frustraba enormemente a nuestros Usuarios y/o Clientes, con toda la razón.

De cómo evolucionó el asunto hasta convertir la construcción de un Data Warehouse en algo trivial y sencillo como es hoy en día (bueno, más o menos, de nuevo), os hablaré en esta entrada. Repito lo que he dicho ya muchas veces: esto no es una historia oficial de nada, es un extracto de mis recuerdos y sensaciones durante esos primeros y vertiginosos años de los comienzos del Data Warehouse, época que viví trabajando en una consultora que, entre otras cosas, vendía proyectos de estos…

La serie ya tiene bastantes capítulos; así que aquí tenéis el enlace donde están todos ellos referenciados.

¿Por qué fracasaba tanto proyecto de construcción de Data Warehouses, en todos los países y en todos los sectores? Bueno, no sé exactamente por qué fracasaban todos los que lo hicieron (y fueron muchos), pero sí de algunos que ocurrieron aquí en España, de los que fueron involuntarios protagonistas algunos compañeros míos, y de algunos otros de los que fueron protagonistas otros profesionales, pero que llegué a conocer bastante bien. Así que creo que me puedo permitir el lujo de extrapolar las razones principales de esos fracasos, con bastante probabilidad de que el diagnóstico sea correcto, y compartirlas con vosotros.

En mi opinión, la principal causa de los fiascos fue no tanto la falta de estándares o de teoría, sino el propio desconocimiento sobre cómo enfrentarse a estos proyectos.

Me explico: La construcción de los primeros Data Warehouses se le encargó generalmente a magníficos profesionales, con muchos años de experiencia en el desarrollo de proyectos informáticos, y en la gestión de proyectos complicados. La razón era evidente: en aquel tiempo, se trataba de los proyectos estrella en muchas empresas… y para muchos fabricantes y consultores: las máquinas eran muy costosas (aunque lo fueran menos que un buen mainframe, aún costaban un cerro de millones), y precisaban de muchos servicios especializados y, por tanto, caros. Así que los suministradores eligieron para dirigir estos proyectos a los mejores profesionales que tenían disponibles, para intentar garantizar en la medida de lo posible su éxito.

Loable intento. Pero contraproducente, aunque, desde luego, ninguno de nosotros lo podíamos sospechar en la época.

Quizá os preguntéis… Pero, vamos a ver, si los suministradores y los propios clientes utilizaron para estos proyectos a la flor y la nata de sus profesionales… ¿Dónde está el problema?

Pues… en que estos profesionales (entre los que creo que yo mismo me contaba) atacaron el proyecto de la misma manera con que habían atacado con éxito tantos proyectos complicados anteriormente… y ése no es el método adecuado para atacar la realización de estos proyectos.

En primer lugar, porque se gastaron muchos meses en intentar definir con precisión los requerimientos de negocio que debía cumplir el Sistema… Y no había forma de fijarlos… Cambiaban continuamente; cuando parecía que se había llegado a un consenso definitivo, aparecían nuevas necesidades no contadas… era el proyecto de nunca acabar. Esto acabó con la paciencia y la salud de bastantes Clientes, Usuarios y, sobre todo, Jefes de Proyecto que, simplemente, no entendían cómo era posible que un Usuario no supiera qué era lo que necesitaba… Estaban acostumbrados a diseñar y construir Sistemas Operacionales muy complejos… pero en todos ellos había quedado relativamente claro, desde el principio, cuál era su objetivo y sus requerimientos fundamentales. Pues aquí, no.

Un día parecía que lo más importante que debía contemplar el Sistema era el acceso a la información de venta, desglosada ad infinitum, y al día siguiente, eran los ratios por sucursal el punto clave que de verdad, de verdad, debería resolver el sistema… para cambiar a cualquier otra cosa una semana después. Los pobres Jefes de Proyecto no entendían nada… ¡y los Usuarios no entendían cómo era posible que tan selectos profesionales no les entendieran a ellos!

La razón de todos estos malentendidos seguramente la sabéis ya: Es imposible que un Usuario sepa qué aspecto del Negocio necesitará verificar, o qué tipo de información necesitará mañana para responder a las cambiantes necesidades de las compañías en el competitivo mundo que vivimos. Sólo que esto lo sabemos ahora, entonces no. Y los proyectos se convirtieron en un perfecto Diálogo para Besugos, en el que cada cuál se encastilló en sus posiciones… y acabaron mal, como no podía ser de otro modo.

Todo esto ya, de por sí, sería más que suficiente para condenar al fracaso a multitud de proyectos… Pero aún hay más, que tiene que ver esta vez, no tanto con el método, aunque un poco, sí, sino con el uso con la tecnología en sí.

Hay que tener en cuenta que casi todos los proyectos de construcción de Data Warehouses que se vendieron a mediados y finales de los noventa, fueron vendidos, bien por fabricantes (del hardware, mayormente), o bien por consultores de todo pelaje, que se apoyaban en todo lo que tiene que ver con la tecnología en los propios fabricantes, del hardware y de la Base de Datos, aportando ellos la mayor parte de los servicios profesionales (Diseño, Desarrollo, Dirección del Proyecto…).

Y de esta manera, todos los planteamientos de proyectos que vi aquellos años hacían un enorme énfasis en las sublimes capacidades de las máquinas y las Bases de Datos (si vemos ahora esas “sublimes” capacidades de entonces y las comparamos con las de ahora, nos daría la risa, pero entonces ciertamente eran eso, sublimes)… y obviaban todo los demás, que se solucionaría más adelante, ya inventaremos algo, a base de servicios profesionales a mansalva (programando, para que se me entienda) o buscando algún productito por ahí para solucionar algún tema puntual, como por ejemplo acceder a los datos, y otras tonterías parecidas, que no eran importantes en absoluto, puesto que lo realmente importante era el Recojoservidor y la SuperBase de Datos Paralela… (que, tontamente, suponían juntos quizá el 85% del coste total del proyecto, mire Vd. qué casualidad)… Uff!

En una palabra, se magnificaba el papel del Servidor y de la Base de Datos, y se minimizaba y trivializaba todo lo que hay alrededor. Pues, vaya por Dios, resulta que justo esas menudencias que hay alrededor del Servidor y su Base de Datos es lo que verdaderamente es importante para que un Sistema de Data Warehouse funcione.

Me explico nuevamente: Para tener un Data Warehouse funcionando es preciso un Servidor dedicado, de cuanta más capacidad, mejor, y una Base de Datos con capacidad de ejecutar procesos en paralelo (por cierto, configurada de una forma bastante distinta de la que es óptima en un Sistema Operacional, pero ésa es otra historia, y será contada en otro momento). Pero esa Base de Datos, para que valga para algo, debe ser, antes que nada, cargada con los datos precisos… datos que han sido capturados en algún momento por los Sistemas Operacionales, y que están allí, tan ricamente guardados en algún sitio, organizados para dar servicio a esas aplicaciones transaccionales, y por tanto, son transaction oriented.

Como en el Data Warehouse los datos deben ser business oriented, que ya lo dijo Mr. Inmon, no queda más remedio que extraerlos de los Operacionales, cambiarlos de formato, transformarlos, acumularlos o desagregarlos, según el caso, y cargarlos después, con su nuevo formato orientado al negocio, en el Data Warehouse. Porque, sufridos lectores, resulta que no sirven tal y como están en los Sistemas Transaccionales. No hay caso: No Sirven. Punto.

En esos primeros proyectos, en todos sin excepción, esta parte de extracción, transformación y carga de los datos fue sistemáticamente minusvalorada. Se pensaban los Jefes de Proyecto, Analistas, etc que con unos cuantos programas, o SQL’s bien paridos, sería suficiente para resolver el problema, y que ya se abordaría el problema con los medios tradicionales (o sea, programando) cuando llegara el momento. Entonces no lo sabíamos, desde luego, pero resulta que resolver esta fase, en realidad cuesta alrededor del 80% de todo el tiempo que cuesta el proyecto.

Quizá merezca una breve explicación (porque es muy posible que os extrañe esta cifra tan elevada). El diseño fundamental de cualquier Sistema de Data Warehouse, como vimos en la entrada anterior, es el de una única, y gigantesca, Tabla de Hechos, y una serie de Dimensiones explicativas, mucho más pequeñas. En la tabla de hechos se representan, juntos, todas las métricas (o indicadores) valiosos para el negocio.

Por ejemplo, tratándose de un normalito Sistema de Venta, típico de cualquier gran empresa de distribución, hipermercado o similar, la tabla de hechos contendrá todas las operaciones individuales de venta (o devoluciones) que se hayan producido en un cierto periodo temporal (un año, dos o más, según). Esta tabla de hechos contiene dos métricas evidentes: el número de unidades adquiridas, y el importe, que se pueden encontrar fácilmente en la aplicación actual de venta, pues siempre van juntos.

Supongamos que, además de la venta pura y dura, queremos ir más allá, y conocer algo sobre, por ejemplo, la rentabilidad que obtenemos con nuestros productos o nuestros suministradores. Para ello, bastaría con introducir una nueva métrica en la tabla de hechos: el precio de coste del producto que hemos vendido ese día a esa hora. De este modo es sencillo averiguar, no sólo lo que hemos vendido, sino con qué margen bruto se ha realizado esa venta.

Pero hay un problema con esto: ningún minorista que yo conozca tiene estos datos en la misma aplicación que los datos de venta; están en otra aplicación, en otras tablas diferentes y con ciclos de creación de la información distintos. O sea, hay que añadir, a los datos de venta que provienen de nuestros terminales de punto de venta, datos de otra aplicación, con problemática diferente y, por qué no, codificación diferente, dado que las reglas de negocio seguidas en el diseño de una y otra aplicación pueden ser muy distintas (y de hecho, por lo poco que yo sé, lo son). Es decir, que añadir una simple métrica a nuestra tabla de hechos, una métrica evidente desde el punto de vista del negocio (eso es justamente lo que quiere decir eso de business oriented) puede ser una pesadilla desde el punto de vista de la realización informática.

Quizá los productos, por ejemplo una tableta de chocolate, estén codificados de forma diferente (con su EAN en la Aplicación de Venta, pero con el código del fabricante, en la de Pedidos, porque así se facilita mucho la realización de éstos); quizá la tableta de chocolate que estamos vendiendo en el híper de Monforte de Lemos se la podemos comprar físicamente a diferentes proveedores, cada uno de ellos con sus condiciones de precios, y sea difícil determinar quién nos sirvió el producto que estamos realmente vendiendo ese día a esa hora; es posible que tabletas de chocolate servidas en diferentes momentos a lo largo de los meses, lo hayan sido a diferentes precios, incluso por el mismo fabricante (a veces los precios cambian, ¿sabéis?), por lo que no sabemos qué coste concreto asignar a cada tableta vendida; además, es muy habitual que las cadenas de hipermercados tengan acuerdos con sus proveedores por los que, según las cantidades que se consigan vender a lo largo del año, se apliquen descuentos adicionales por parte del proveedor (lo que en el sector llaman “rappel”; ese nombre debe ser porque es difícil de averiguar a priori cuál será ese rappel finalmente, así que los de Compras necesitan de un adivino para poder estimarlo…).

Y más problemas adicionales, que os ahorro. ¡Y todo, para introducir una simple, escuálida y sencillota métrica en nuestra tabla de hechos! Espero haber sido capaz de daros idea, con este sencillo ejemplo, del alcance real del problema.

Y claro, todo esto se hacía inicialmente a base de hacer programas, al modo usual de los días: Análisis Funcional, Diseño Técnico, Programación, Pruebas… Un berenjenal de mucho cuidado. Y muy, muy minusvalorado en aquellos primeros proyectos. El choque con la dura realidad se llevó por delante multitud de proyectos, que no fueron capaces de solventar la problemática con que se encontraron.

Y los pocos que, sorprendentemente, lo consiguieron, se toparon de bruces con el mantenimiento: cada vez que se necesitaba un dato nuevo, había que bucear por la maraña de programas para, primero, localizar dónde rayos estaba ese nuevo dato en las tablas del Sistema Transaccional, y luego integrarlo en lo existente… lo que era mucho, pero que mucho trabajo. El tiempo de respuesta a una nueva petición era enorme, igual de enorme que era el de modificar una aplicación transaccional, puesto que en definitiva estaban hechas de la misma manera.

.

Pero, queridos lectores, ahí no queda la cosa: aún hay más. Suponiendo que todo esto fuera realizado convenientemente y en plazo y coste (que va a ser que no), y que la información fluya sin problemas desde nuestros Sistemas Operacionales hasta el Data Warehouse de alguna manera, aún quedaba otro problema espinoso que resolver: el acceso de los usuarios a los datos.

Todo este montaje lo hacíamos para dar acceso a los usuarios (o clientes) a sus datos, y permitirles obtener información como nunca antes lo habían podido hacer. Maravilloso. Pero es que para poder hacer esto, de algún modo esos usuarios finales deberían ser capaces de solicitar al Sistema la información que deseaban obtener, el Sistema debería enterarse de la petición, traducirla a una serie de instrucciones comprensibles por las Bases de Datos, obtener los datos y devolvérselos al peticionario de una forma que éste pudiera comprender y usar.

Proyectos hubo que laboriosamente consiguieron cargar las tablas del Data Warehouse con la información solicitada… y no hubo luego quien pudiera acceder a ella.

Quizá se suponía por los responsables del proyecto que los usuarios deberían aprender SQL, y lanzar sus queries, quizá desde Excel, Access o algo así, igual que en el mainframe se hacía con el QMF… y que encima las hicieran correctamente, con todos sus joins bien puestos… Pues no, otra vez no.

Pocos sabían SQL, y pocos entre ellos sabían cómo montar las complicadas queries necesarias, con join, subselect, group by, etc. Los pocos que eran capaces de hacerlo, aún debían recoger las filas en bruto que devuelve una query a pelo, y manejarlas para que sus resultados fueran visibles. Y los que no sabían… esos no tenían el menor interés en aprender SQL, lo que es perfectamente lógico: a ellos les pagan por obtener información del negocio, para mejorarlo, no para programar nada.

O quizá se pensaba programar una sencilla aplicación cliente/servidor, en Visual Basic o C, o lo que fuera, para que enviara su query y representara los datos obtenidos en bonito… Pero, desde luego, para que esto pudiera ser viable, no se trataría para nada de una aplicación sencilla… sino de las más complicadas que se podían hacer en la época. Como veis, también este aspecto fue clarísimamente minusvalorado por los vendedores de estos primeros Data Warehouses, que, recuerdo, basaban su mensaje comercial en la potencia nominal de sus máquinas y la excelencia de las Bases de Datos para tratar montañas de datos, y descuidaron tanto la entrada de datos al sistema, como luego la salida.

Si me permitís la analogía, es como que alguien te venda un extraordinario amplificador de sonido de audiófilo, con lámparas de vacío, una sensibilidad estratosférica y un precio en consonancia, con el que podrías apreciar hasta el último armónico de cada acorde del allegretto de la Sonata Waldstein, tocada por Richard Goode… y que luego este amplificador maravilloso no tenga clavijas para poder conectar ninguna fuente de música, ni tampoco enchufes para conectar altavoces… o sí que los tiene, pero te venden como entrada un micrófono monoaural para que tomes el sonido del altavoz de tu radio portátil a transistores, y como altavoces, unos buenísimos de cartón que has reciclado de tu viejo Seat Panda…

.

Naturalmente que aprendimos de todos estos fracasos; algunos los sufrieron en carne propia, y les costó dinero y salud… y los demás, que, por pura suerte, nos escapamos por poco, procuramos escarmentar en cabeza ajena… dentro de lo posible.

¿Cuáles fueron las medidas que fuimos tomando paulatinamente? Unas tuvieron que ver con las herramientas software a utilizar, otras con el método y otras, por fin, con la propia forma de concebir un Data Warehouse… Vayamos por partes (como se decía a sí mismo Jack el Destripador…). Pero, antes, centremos cuál es el esquema de funcionamiento un Data Warehouse, que es, con variantes más comerciales que otra cosa (con o sin Staging Area, con o sin ODS, etc), el que sigue a continuación.

Los datos de origen están en los diferentes Sistemas Operacionales, a la izquierda del esquema. Mediante ciertos programas, se Extraen de allí, se Transforman para hacerlos coherentes unos con otros, y por fin se Cargan en las Bases de Datos que componen el Data Warehouse.

Una vez éste cargado, se puede replicar parte de la información para cargarla en otras tablas más pequeñas y especializadas, orientadas generalmente a un Departamento o Área concreto de la empresa (Finanzas, Contabilidad, Marketing, etc), y que proveen ni más ni menos que una vista parcial del Data Warehouse. A estos “mini-Data-Warehouses” se les conoce como Data Marts, y suelen ser más pequeños en tamaño, y más manejables, que los Data Warehouses de los que proceden… aunque yo conozco empresas que tienen Data Marts de 8 ó 10 Teras…

Por fin, los sufridos usuarios, a la derecha del todo, acceden a los datos del uno o de los otros, en función de su conveniencia, bien para obtener información de algo que preguntan (Query&Reporting), donde se consigue como salida un informe o gráfico con la información solicitada, bien para navegar por la información contenida allí, mediante la técnica conocida como OLAP, de OnLine Analytical Processing, que es como el online de toda la vida (OLTP), pero sobre la información de negocio contenida en los Data Warehouses o Data Marts. La idea es que, una vez hecho cierto informe en el que se detecta que pasa algo interesante en una o varias líneas del mismo, se pueda navegar jerárquicamente, para obtener más detalles de ese interesante hecho encontrado, hasta poder determinar sus causas últimas…

La primera vez que vi este gráfico, pensé que era algo obvio… pero que la dificultad estaba en dar a la cosa el dinamismo que requiere; si nos ponemos a programar como sabemos (o, por lo menos, como sabíamos, no estoy yo muy seguro de que ahora sigamos sabiendo), estos sistemas jamás llegarían a buen puerto.
.

En primer lugar, se comenzó a dar soluciones para el proceso de Extracción, Transformación y Carga de la información (ETL en sus siglas inglesas), para hacerlo más sencillo y, sobre todo, facilitar el mantenimiento. Algunos se dieron cuenta de que los programas que había que hacer eran casi siempre Sota-Caballo-y-Rey, o sea, muy parecidos entre sí, así que se les ocurrió que se podía automatizar en todo o en parte ese proceso. Tenían razón.

El proceso normal de carga de datos en el Data Warehouse implica, conocidas las estructuras de las tablas de entrada y las de salida, trazar el camino que deben seguir los datos en su viaje desde los sistemas operacionales hasta el Data Warehouse. Entonces, buena parte del proceso podría describirse de manera visual, identificando cómo calcular, uno a uno, cada dato de las tablas de salida, es decir, las del Data Warehouse (¿recordáis que ya Jackson había especificado en su JSD que el diseño debería comenzar a partir de las salidas? Lo expliqué como mejor pude en esta entrada).

Pues bien, imaginemos una pantalla como la que tenéis a continuación, donde a la derecha están todos los campos de las tablas del Data Warehouse (que se obtienen directamente del catálogo, las copies, o donde sea), y a la izquierda, todas las tablas que serán origen en el Sistema Operacional.

Ahora, vamos tomando campo a campo de la tabla de salida, y vamos encontrando en las tablas de entrada de dónde proceden. Muchos vendrán sin cambio alguno: Código de Cliente, Nombre, Dirección, etc, se traspasarán sin cambios, con un movimiento simple. Otros sufrirán algún tipo de proceso: por ejemplo, para calcular el número de cuentas que posee ese cliente se especificará que se deben contar las ocurrencias de ese Código de Cliente en la tabla de Cuentas. Algunos serán simples cálculos elementales: el porcentaje de recibos devueltos de ese Cliente se calculará en base a los recibos devueltos sobre los totales, mientras que otros necesitarán cálculos complejos… y así con todo. Naturalmente, siempre había algún campo cuyo endemoniado proceso de obtención no estaba entre las posibilidades de los productos; en esos casos, se prepara una EXIT con el código necesario, programado ad hoc para la ocasión… pero deberían ser los menos casos (y realmente lo eran).

Estos productos almacenaban las definiciones que visualmente se introducían en un fichero (los metadatos), y una vez terminado de definir cada campo de cada tabla de nuestro Data Warehouse, se ejecuta un proceso que genera, por un lado, los programas, en el lenguaje adecuado, que deberían servir para extraer los datos del servidor origen (por ejemplo, en Cobol y DB2, si era un mainframe, que era lo normal); los programas para realizar la consolidación y cálculos intermedios (la transformación), que podían ejecutarse en la plataforma origen o en la de destino, a conveniencia del diseñador, y por fin, los programas para cargar la información resultante en las tablas (las de hechos o las dimensionales) del Data Warehouse (por ejemplo, en C con Oracle, si era un servidor UNIX con Oracle).

Además, generan los scripts, JCL’s, etc necesarios para ejecutar dichos programas en sus entornos. Luego se compilan estos programas, exactamente igual que si los hubiese escrito nuestro programador favorito, se usan los scripts, y… voilà, ¡nuestro Data Warehouse cargado en un pis-pas!.

La gran ventaja es evidente: que los programas funcionan. Siempre, y a la primera. Y además, como la definición se encuentra en los metadatos, si se incluye un nuevo campo en el Data Warehouse, o debe calcularse alguno de una forma diferente, basta con especificar cómo debe ser cargado, y al generar nuevamente el código completo, queda integrado con el resto de forma inmediata y fiable. Eso sí, puede ocurrir que, ante un cambio aparentemente menor, el pequeño demonio que lleva dentro el producto decida hacer un proceso completamente distinto al que hacía hasta entonces… para desconcierto de diseñadores y, sobre todo, de Operación… Pero funciona, siempre funciona.

El primer producto ETL en salir al mercado fue Prism, seguido al poco tiempo por ETI Extract y Carleton; todos ellos seguían este esquema de generar programas que debían ser compilados para ser ejecutados. No, no es que Prism y Carleton me caigan mal, para nada. Es que no he encontrado nada de ellos en la Wikipedia ni en otras fuentes… las cosas que pasan continuamente cuando de productos antiguos, o no tan antiguos, se trata.

Algunos años después comenzaron a aparecer otros productos diferentes, que una vez hecha la definición de forma similar, hacían el movimiento de los datos en tiempo real, sin necesidad de generar, compilar y ejecutar programas. Es decir, una vez cargados los metadatos de forma similar a la descrita antes, lo que se hace es arrancar procesos residentes en ambos lados (el mainframe y el servidor UNIX, para que me entendáis), coordinados entre sí, y realizan el proceso interpretando el contenido del metadata, y de forma desasistida. Su ventaja: mucho más sencillo de operar, al no requerir los pasos adicionales de compilación, creación de scripts, etc. Y es más sencillo conseguir que paralelicen el proceso, si tenemos problemas de ventana batch… a cambio de requerir muchísima más CPU y recursos que en el otro caso.

DataStage, recientemente adquirido por IBM, y Powercenter, de Informatica (sí, hay una compañía norteamericana denominada “Informatica”, sin acento; muy creativos con el nombre no lo son, no), son algunos productos ETL de este tipo, pero ahora hay muchos, pero muchos, así…

.

Bueno, pues mal que bien teníamos resuelta la parte más problemática, el movimiento de datos (muchos datos) entre sistemas, modificando, transformando, y cargando de forma efectiva estos datos en nuestro Data Warehouse. Pero… ¿qué pasaba con el acceso a la información?

Pues también había compañías que estaban dando soluciones para facilitar el acceso a los datos de un Data Warehouse por parte de sus usuarios, es decir, para permitirles crear sus informes, ejecutarlos, incluso navegar por él, sin necesidad ni de saber programar nada, ni del apoyo de Informática.

Hubo varios pioneros, algunos de los cuales ya no existen, pero los que mayor presencia comercial tuvieron en España esos años, finales de los noventa, fueron:

Business Objects, compañía francesa, pero que rápidamente dio el salto al otro lado del charco, y que fue probablemente la primera en entrar en estas lides. Especializada en Query&Reporting (o sea, realizar informes de calidad, de forma sencilla y con un buen aspecto visual, aunque con escasa capacidad de navegación), se convirtió rápidamente en el líder mundial por licencias vendidas. En 2007 fue adquirida por SAP (de hecho, SAP ofrecía desde hacía años Business Objects como su herramienta principal para acceder a su “SAP Warehouse”, el pseudo-Data-Warehouse que SAP ofrecía, de nombre SAP Business Information Warehouse, y que supongo que sigue ofreciendo para explotar la información contenida en sus tripas…).

Cognos, una compañía canadiense que cubría con su producto básicamente el mismo espectro que Business Objects; de hecho fue su mayor competencia esos años, entre otros muchos más productos… En 2008 fue adquirida por IBM… para mí que esta fue una adquisición forzada para intentar compensar la adquisición de Business Objects por SAP un año antes, y poder competir con la compañía alemana en todos los frentes. Ignoro qué tal les irá ahora, al uno o al otro.

Microstrategy, compañía estadounidense que, a diferencia de los anteriores, mostraba su fuerza en la navegación a través de las dimensiones, usando muy eficientemente la técnica del drill-down, en lo que se vino a llamar ROLAP, una más de las tropecientas siglas que aparecieron aquellos años… Sus informes eran más feos y sus gráficos, correctos aunque bastante espartanos, pero su capacidad de generar un excelente SQL en navegación le hizo posicionarse claramente como el líder de este segmento.

Y, con una concepción radicalmente distinta, pero con un gran éxito, SAS Institute, originalmente una compañía especializada en el tratamiento estadístico y matemático de los datos (de hecho, SAS quiere decir Statistycal Analysis System, o sea, que el nombre lo dice todo), a lo largo de los años fue incorporando a su corazón, su extraordinario motor estadístico, un caparazón de software que permitía acceder a los datos, manipularlos, gestionarlos, procesarlos e imprimirlos con agilidad, obteniendo, casi sin querer, un potente lenguaje de cuarta generación… que es, digan lo que digan, quien le ha reportado la mayoría de las ventas desde entonces. Aunque no era exactamente igual que los anteriores, pues exigía una cierta programación (bueno, no: programación en toda regla) por parte de los usuarios para obtener sus informes, tuvo también bastante éxito como herramienta de acceso a los Data Warehouses de aquellos años.

.

Por lo que yo sé, la mayoría de estos productos tienen un origen similar, verbigracia: Una Compañía de consultoría tradicional es contratada por una empresa para que haga no sé qué Sistema de Información, y en esa compañía hay, entre varios otros, dos tipos cruciales: el ingeniero listo, al que se le ocurre que, en vez de programar seiscientos informes todos parecidos, pero todos diferentes, si escriben un generador de informes se quitan el problema de una tacada (y, además, lo escribe y funciona, el tío), y un visionario del negocio, que se da cuenta de que esa cosa se puede vender bien, y monta una compañía para empaquetar ese mismo software que ya tienen hecho y venderlo… Por ejemplo, en Microstrategy, el gurú es Sanju Bansal, un indio (de la India, quiero decir) que es un genio de la tecnología, y que fue quien parió el motor de generación de SQL, y Mike Saylor, el listo visionario y genio del marketing… Muchas de estas iniciativas fracasaron, antes o después, y tras la “consolidación del mercado”, la forma eufemística de llamar al baile de adquisiciones de los últimos años, casi no quedan ya compañías independientes en este mercado.

Por fin, todos estos productos solucionan el acceso por los usuarios a la información contenida en el Data Warehouse de forma parecida (en la ilustración que sigue se ve cómo se diseñaría un proyecto en Microstrategy Architect):

1 El Diseñador define la información del proyecto contenida en el Data Warehouse, con su modelo en estrella o en copo de nieve, especificando las tablas físicas, con sus atributos, y asociándolos a los conceptos de negocio que necesitará el usuario para pedir la información. Así, se le informa al sistema de que la tabla ATY07RWD, por ejemplo, es en realidad la Tabla de Hechos del Sistema, donde el atributo CODOFIGG es el código de oficina… Como también le diremos que la tabla ATY08RGL es la que representa la dimensión “Oficina”, donde el atributo CODOFIWK es el código de oficina y NOMOFIWK, por ejemplo, es la denominación de esa oficina… ahora el Sistema sabe que, si le pedimos alguna información de la tablas de hechos (los saldos totales de un tipo de producto, por ejemplo) por oficina, basta con hacer un join entre ambas tablas usando los campos que contiene el código de oficina en cada tabla, y poder así añadir el nombre de la oficina, además del código, en el informe.

2 Terminada esta definición básica, el producto la almacena generalmente en tablas relacionales, en el propio sistema donde reside el Data Warehouse: son sus metadatos (o Universos, según la nomenclatura de Business Objects). Ahora es el momento de definir las métricas derivadas (porcentajes de incremento o de participación, fórmulas aritméticas, etc), que quedan almacenadas también en los metadatos. Se definen también filtros o condiciones a aplicar a los datos, agregaciones… toda la información queda almacenada en los metadatos. Lo bueno de toda esta fase es que, si se han diseñado bien las tablas, es un proceso muy rápido: en una semana o así se puede tener completamente modelizado un Data Warehouse de tamaño medio… y eso es muy rápido para nuestras ancestrales costumbres.

3 Ahora, cuando el usuario desea una cierta información, selecciona qué métricas desea, con qué dimensiones, y con qué condiciones, y ejecuta el informe. El producto genera el SQL (se supone que optimizado para la Base de Datos concreta que contiene los datos… se supone, al menos), que lanza al Data Warehouse, probablemente vía ODBC… y cuando recibe la respuesta, la formatea, para dejarla con la pinta solicitada por el usuario, y se la muestra por fin. Así de fácil… o no.

Por ejemplo, si el usuario desea conocer la Venta por Sección de los Supermercados de Madrid, selecciona un sólo indicador: “Venta (Importe)”, dos datos dimensionales: el “Nombre de Sección”, y el “Nombre de Supermercado”, y define un filtro: que los Supermercados sean de la Región “MAD”. Y ya está. Rápido y sencillo, y el producto obtiene un informe que podría ser parecido a este que tenemos al lado… Y además, nos permite navegar dimensionalmente, por ejemplo, seleccionando la Sección “Fish”, y pidiendo al sistema que nos muestre ahora la Venta de los Departamentos de la Sección de Pescado (Lubinas, Doradas, Meros,…) de los Supermercados de Madrid… y así hasta poder alcanzar las operaciones de venta individuales, si fuera preciso.

Todas estas herramientas eran ya entonces de gran calidad (ahora son, obviamente, de más calidad y mejor tecnología, hacen más cosas, mejor y… más caro), y la decisión de compra de una u otra tenía que ver más con las filias o fobias de cada uno que con su utilidad. Mi recomendación, y las de mis compañeros, era que se debería comprar la herramienta adecuada a la función que el cliente deseaba… ¡aunque fueran dos distintas! (claro que nosotros, los consultores, cobrábamos comisión de todas ellas, je, je…). Era bastante normal que hubiera que dar servicio a una serie de usuarios livianos, que básicamente consultarían informes preparados de antemano (cambiando, eso sí, las condiciones, los filtros, en función de sus necesidades), mientras que otros necesitarían hurgar en las tripas del negocio para encontrar información relevante… Business Objects o Cognos eran perfectos para los primeros, mientras que Microstrategy lo era para los segundos.

Pero esto, que era muy evidente para casi todos los que conocíamos de cerca la tecnología… casi nunca lo era nada para el Director de Informática, que prefería mil veces tener un solo proveedor en vez de dos, vaya Vd. a saber por qué. Esto, además, era muy normal en la Administración Pública (Ministerios, Organismos, Ayuntamientos…), cuando publicaban un concurso en el que sólo cabría una única herramienta de cada clase… Y me constan algunos fracasos precisamente por seleccionar la herramienta inadecuada; además, luego nadie daba su brazo a torcer (y los comerciales de la herramienta seleccionada aseguraban que si las cosas no iban bien, era debido a que los humanos no éramos capaces de hacer que su maravilloso software funcionara como era debido, e incluso en algunas ocasiones… ¡hasta tenían razón!).

En España unas vendieron más que otras, debido no sólo a la tecnología, sino también al soporte postventa, es decir, a la calidad de los profesionales de cada empresa para poner a funcionar su producto en los clientes reales, formar a los responsables de cada empresa, dar soporte en caso de problemas… y ser flexibles ante la inevitable negociación con el cuchillo en la boca que acontecía siempre con los responsables de pagar el proyecto. Y es que estos proyectos eran, aquellos años, bastante caros.

.

Bueno. Ya teníamos los servidores con muchos procesadores y capacidad de proceso en paralelo, las Bases de Datos que eran capaces de sacar partido de estas máquinas sofisticadas, así como las técnicas de modelización dimensional requeridas, teníamos también el software que nos ayudaría a realizar la extracción de los datos, su transformación y carga en el destino, y, por fin, las herramientas de acceso a la información por el usuario final… Ahora sí que podíamos construir por fin Data Warehouses de excelente rendimiento, acabando el proyecto en tiempo y con los costes presupuestados…

… Eeh… Los que habéis seguido la serie, imagináis quizá la respuesta:  Pues no.

Todavía nos faltaba encontrar un par de puntos definitivos, los detalles finales un tanto sorprendentes que nos permitirían, ahora sí, poder comenzar a construir Data Warehouses con celeridad, bajo coste y expectativas cumplidas… pero encontrarlos nos costó aún algún batacazo más.

En primer lugar, e importantísimo (pero importantísimo), es que nunca, nunca se le debe preguntar a un usuario “qué información desea consultar” (los famosos Requerimientos de Negocio imposibles de fijar), sino de qué información dispone. Atentos, porque esto que acabo de contaros no lo oiréis seguramente en parte alguna.

Esto elimina de un plumazo cualquier interminable discusión sobre requerimientos que no hay forma de cerrar, ahorrando muchísimo tiempo… y problemas; ahora es muchísimo más sencillo quemar esa etapa.

Ante la inevitable pregunta de los usuarios de ¿y qué información podré obtener?, la respuesta es: TODA, toda la que tengas: Tomaremos TODA la información contenida en tus Sistemas Operacionales, la modelizaremos, la extraeremos, la cargaremos en el Data Warehouse, y allí (si lo hemos hecho bien, claro), cualquier pregunta es posible: cualquier cruce de información, cualquier agregación a cualquier nivel, cualquier métrica derivada… unas consultas tardarán poco, otras mucho… aquéllas que tarden en exceso se aligeran mediante las diferentes técnicas usuales en Data Warehouse (creación de agregadas, cambio en los índices, partición de tablas, etc) que no voy a detallar aquí.

Me he cansado de deciros (y os he cansado a vosotros, seguro) que el usuario no sabe qué necesitará mañana, es más, es que ¡no puede saberlo! ¿Para qué vamos, entonces, a preguntarle lo que desea, si no lo sabe? ¡No le preguntamos, y listo!

No os podéis hacer una idea de lo que engrasa el desarrollo del proyecto este sutil (bueno, no tan sutil) cambio en la orientación del proyecto de construcción de un Data Warehouse.

Y el segundo punto crucial es que el diseño debe hacerse pensando en la idiosincrasia y las necesidades de la herramienta utilizada para acceder a la información; en caso de tener más de una, de la más restrictiva (ésa era, casi siempre, Microstrategy). Cuando tanto el diseño de la Base de Datos como la nomenclatura de métricas, atributos, índices, etc se adaptaba como un guante a las necesidades de ella… el proyecto iba bien, y funcionaba a la primera… bueno, a la segunda, que a la primera no funciona nunca nada.

Recuerdo un colega al que le tocó en suerte dirigir el tercer o cuarto intento de poner a funcionar el Data Warehouse de un gran Banco español; los anteriores habían acabado en sonoros fracasos, y habían costado la defenestración sucesiva de la Consultora de turno… Coincidimos en una de las mil presentaciones, congresos o charlas que había por doquier, me contó su problema (su patata caliente, quiero decir…) y se me iluminó el cacumen, cosa rara, para poder darle un solo consejo: “Ficha a un auténtico experto en Microstrategy (era ésa la herramienta que había seleccionado aquél Banco), págale lo que pida, y deja que sea él quien haga el diseño físico de las tablas… ¡no permitas que metan las narices en el diseño los especialistas de Base de Datos, o tendrás serios problemas!”. Varios meses después, coincidimos de nuevo en otro evento; el hombre estaba feliz como una perdiz: aunque había tenido poco menos que llegar a las manos con los responsables de administrar las Bases de Datos, al final se salió con la suya… ¡y el proyecto iba viento en popa! De hecho, que yo sepa ese banco sigue explotando el mismo Data Warehouse, corregido y aumentado a lo largo del tiempo… pero con el mismo diseño básico de entonces. ¡Por una vez, mis consejos habían servido de algo! Mi colega fue promovido en su empresa, incrementado su salario, y, pocos años después, despedido… pero ésa es otra historia, y será contada en otro momento.

Además, simultáneamente a todo esto, y liándolo todo, también se estaba promocionando, por los gurús de la cosa, otra tecnología similar… o no, según se mire, aunque en todo caso, relacionada: el Data Mining. Consiste en “hacer descubrimientos de información no trivial oculta dentro de los datos”, a base de pico y pala (de ahí lo de Minería de Datos), utilizando algoritmos estadísticos o provenientes de la inteligencia artificial.

A este tema concreto dedicaré la próxima entrada, así que no digo aquí nada más sobre el tema… paciencia, queridos lectores.

.

Bueno, pues el caso es que entonces los expertos de marketing volvieron a hacer su trabajo. Había que buscar un término marketiniano poderoso, pegadizo… que permitiera aumentar las ventas de toda esta serie de productos, y de los jugosos servicios que conllevaban… y el término elegido fue: Business Intelligence.

Bajo el paraguas del Business Intelligence caben todo tipo de productos hardware, software, de diseño, de acceso a la información, de seguridad, de control… vamos, que tiene tantos componentes (¡o más!) que el resto de disciplinas informáticas. Es el leit motiv básico de venta de todas las consultoras actuales, los fabricantes de hardware y servicios, las compañías de servicios profesionales… es el último pico por escalar para informatizar las empresas hasta el último nivel… y, queridos lectores, ya sabéis lo que pasa en estas circunstancias, porque muchas veces antes ha pasado: “Si no pones un Business Intelligence en tu vida… eres un neanderthal”.

Aún se podría hablar sobre estos apasionantes temas, de la máxima actualidad en nuestros azarosos tiempos, unos pocos de miles de palabras… pero voy a parar aquí. Repito: hay muchísima información disponible y no creo que mis pobres palabras puedan aportar mucho más.

.

¿Mi conclusión? Igual queréis, sorprendentemente, escucharla…

Después de unos comienzos titubeantes, grandes fracasos y algunos éxitos, mucha jerga nueva y muchas tecnologías enfrentadas a muerte unas con otras (por ejemplo: MOLAP vs. ROLAP vs. HOLAP, de lo que no he hablado nada, pero que hizo correr ríos de tinta en su día; por cierto, en nuestros tiempos ya quedó claro que la tecnología ganadora de las tres es la ROLAP), tras muchos fracasos y algunos éxitos, repito, poco a poco los éxitos fueron siendo mayoría… y yo creo que ahora es difícil fallar en un proyecto normal de creación de un Data Warehouse. Realmente es más sencillo de diseñar y construir que un Sistema Transaccional, y en general tienen rendimientos aceptables a costes razonables, y una gran utilidad.

Y esto ha llevado a que se usen en muchísimas ocasiones de forma espuria, falsa, no natural: como meros emisores de las consultas que nunca se programan en los Sistemas Online normales y corrientes. Es decir, se escribe una aplicación tradicional, con sus actualizaciones, sus informes preimpresos y cartas, sus altas, bajas y modificaciones… pero sólo se codifican unas pocas consultas básicas… resulta más barato construir un Data Warehouse y permitir que los usuarios hagan las consultas que les de la real gana… sin molestarnos a nosotros, los informáticos, que así podemos dedicarnos a cumplir escrupulosamente el ISO-doscientos-millones de cada día…No, no era para eso para lo que se pensaron estos sistemas, ni para lo que tantos pasamos tantos sudores… pero si funcionan y la gente los usa… bienvenidos sean.

Lo que sí que ocurre es que todas, todas las grandes empresas y, por supuesto, todas las Agencias Sí Gubernamentales de todos los países del mundo mundial tienen Data Warehouses de tropecientos Teras de tamaño… o Petas… o Exas, donde almacenan todo lo que acontece en su negocio, con sus productos, sus empleados, sobre sus clientes… en definitiva, todo lo que saben sobre nosotros. En la duda, se guarda hoy en día todo. Pero todo, todo. No sabes qué será lo que el día de mañana te hará falta, así que mejor guardar hasta el último retazo de información que caiga en tus manos…

Lo saben todo sobre nosotros. O, al menos, lo podrían saber… Saben por qué páginas navegamos, qué nos descargamos, lo que pagamos por ello y cómo lo hacemos, lo que comemos y lo que vestimos, a quién llamamos por teléfono y lo que le contamos, cuánto dinero debemos y a quién, dónde vamos de vacaciones y por qué medios, nuestros hábitos nocturnos…

Pero que no cunda el pánico… aún. El que la información, Teras y Teras de información, esté almacenada en algún gigantesco ordenador en algún antiguo silo de misiles nucleares no quiere decir que de verdad sepan mucho… Como bien decía Johann Wolfgang von Goethe a principios del siglo XIX, lo importante no es tener grandes cantidades de información a nuestra disposición, sino poder aprovecharla para aumentar nuestro conocimiento… y eso está todavía lejos, por más que las técnicas de Data Mining (de las que hablaré en la próxima entrada) hayan adelantado como las ciencias en La Verbena de la Paloma: ¡una barbaridad!. Hasta que no despierte el Tecnonúcleo, los humildes mortales podemos estar tranquilos… o eso espero… No. En realidad, eso anhelo…

.

En la próxima entrada hablaré sobre qué es eso de la Minería de Datos que ha salido de tapadillo un par de veces en este artículo, pero no esperéis un curso… os contaré, como siempre, lo que yo sé y a mí me parece de todo ese batiburrillo de técnicas y productos… y, entretanto…

Disfrutad de la vida, mientras podáis.