El Cedazo

En la entrada anterior, donde terminamos los dos capítulos dedicados a las convulsiones de todo tipo que acontecieron en los tormentosos años noventa, que acabaron con el cambio del foco de la rentabilidad, que pasó del hardware (que tradicionalmente había sido el máximo generador de beneficios) al software y los Servicios Profesionales, donde hoy sigue.

Pero lo más importante quizá de esa década tan movida fue que se vivió un enorme crecimiento de las aplicaciones informáticas instaladas en todas las empresas. Si a principios de la década podían existir empresas (no muy grandes, desde luego) sin apenas ninguna aplicación informatizada, a finales era ya imposible: o tenías tus aplicaciones principales soportadas en sistemas informáticos, o estabas muerto (más bien cerrado…).

Así que la cantidad de información de que se disponía almacenada en los ordenadores de las empresas e instituciones era cada vez mayor, y creciendo de forma exponencial. Centenares de millones de registros, miles de millones… Y claro, los usuarios querían acceder a toda esa información para aprender cada vez más sobre sus clientes, sus productos, sus proveedores, sus empleados… su negocio, en definitiva. Y parte de esta información era fácilmente accesible, y otra, no tanto. Y otra más, la gran mayoría, era totalmente inaccesible: estaba enterrada entre decenas de bases de datos, con estructuras en buena medida incompatibles entre sí… así que la información, estar, lo que se dice estar, estaba… pero estar, lo que se dice estar… pues no estaba. Se me entiende, ¿no?

De las causas de esta situación, de cómo la tecnología comenzó a encontrar soluciones, o mejor, a aplicar soluciones que ya había para otras cosas a estos problemas, y de cómo empezamos a resolverlo trata este artículo…

La serie va ya teniendo un buen número de capítulos, así que aquí os dejo el enlace, donde podéis encontrar un acceso directo a cualquiera de ellos.

Efectivamente, a principios de los años noventa había ya en Producción muchísimas de las aplicaciones básicas de las empresas e instituciones. Y durante esa década, mientras pasaban todas esas cosas que os contaba en las dos entradas anteriores, se estaban escribiendo muchas aplicaciones nuevas, y también reescribiendo las que se habían quedado obsoletas, bien con las mismas tecnologías que sus predecesoras (es decir, casi siempre en mainframe: Cobol, CICS o IMS y DB2), o bien en otro tipo de servidores, casi siempre UNIX y con la tecnología Cliente/Servidor de la época.

Pero todas ellas, sin excepción, estaban orientadas a la transacción. Es decir, su principal objetivo era (y sigue siendo, en realidad) atender a las operaciones de los usuarios con precisión, rapidez y fiabilidad, en una palabra, debían ser aplicaciones eficientes. Y ser eficientes quiere decir que deben ser capaces de tratar las transacciones de muchos usuarios simultáneos, y darles servicio con el menor tiempo de respuesta posible.

Por ejemplo, muchos cajeros y administrativos de un banco cualquiera, incluso desde cajeros automáticos, están haciendo simultáneamente operaciones: abonos o adeudos en cuenta, consultas de movimientos, altas de contratos, etc. Son todas ellas operaciones relativamente sencillas, desde el punto de vista de que necesitan pocos datos para cumplir su objetivo, aunque el proceso interno que deban realizar, por ejemplo, para autorizar un pago de cheque, no sea sencillo de programar, debido al tratamiento que hay que hacer de todas las posibles alternativas que puede encontrar la operación.

Si bien esa operación requiere acceder a bastantes tablas diferentes, no tiene que acceder a muchas filas de cada tabla; hay un cierto consumo de CPU por transacción, pero con pocos datos involucrados. En una palabra, son aplicaciones donde cada transacción accede a pocos datos y con un consumo moderado-bajo de CPU, y donde lo más importante es su capacidad de atender simultáneamente a muchas transacciones.

Las máquinas en que se desarrollaron estas aplicaciones (las máquinas de la época, los ochenta y noventa) no tenían mucha capacidad, comparada con la que hoy en día tenemos a nuestra disposición, de hecho era algunos órdenes de magnitud menor. Así que, para conseguir esa eficiencia en las aplicaciones, éstas estaban diseñadas cuidadosamente para agilizar este acceso transaccional.

El diseño de las Bases de Datos, el lenguaje de programación elegido, los gestores de teleproceso, toda la arquitectura hardware y software, en definitiva, estaba orientada siempre a tal fin: que las transacciones fueran rápidas y el rendimiento fuera siempre bueno.

Así, la parte mollar de las aplicaciones eran siempre los procesos de actualización, las entradas de datos, los cálculos… y luego estaban los flecos, las tonterías, lo accesorio, lo que siempre se deja para el final: las consultas y los listados.

Todo programador que empezaba su carrera se tiraba unos meses escribiendo sólo listados y consultas, hasta que se curtía lo suficiente como para  dejarle programar las cosas importantes…y lo sé por experiencia: yo fui uno de ellos.

Naturalmente que todas las aplicaciones permitían a los usuarios obtener datos contenidos en las Bases de Datos, mediante consultas programadas (como unas transacciones más… eeh, no, como unas transacciones de segunda categoría, más bien), que mostraban a los usuarios una cierta información predeterminada (negociada con los usuarios en el análisis de la Aplicación), y también se emitían ciertos listados, durante los procesos batch, con resúmenes de la información, datos contables, relaciones de excepciones, etc.

Estos listados (que se pretendía fueran los menos posibles, para minimizar el consumo de papel… porque sí, se imprimían físicamente en papel, que había que cortar, separar y enviar físicamente a sus destinatarios, incluidas las oficinas, con un coste tremendo) se consensuaban, al igual que las transacciones, durante el Análisis, y luego procurábamos que nunca más se modificaran.

En realidad, el nirvana del informático es no tocar nunca jamás una aplicación, aplicando el conocido (aunque nunca publicado) Teorema Fundamental de la Informática: “Si funciona, ¡NO LO TOQUES!”.

Todo esto estaba muy bien al comienzo de la historia, porque las primeras que se mecanizaron fueron las aplicaciones contables más duras, es decir, aquellas que consumían mayor tiempo y más cantidad de recursos, haciendo labores, en gran parte, mecánicas (de ahí lo de mecanizar un Departamento, que decíamos mucho en la época).

Aplicaciones como las Cuentas Corrientes, la Contabilidad, la Facturación, la Nómina, etc fueron las primeras que se atacaron.

Todas ellas tienen una gran cantidad de operaciones al día, pero con una lógica sencilla y fácilmente reproducible por un programa (bueno, hay veces que es difícil de creerlo, viendo las especificaciones funcionales…).

Y todas ellas, sin excepción, consiguieron importantes incrementos de eficacia en las empresas casi desde el día siguiente al de su implantación.

Recuerdo que, en el primer banco en el que trabajé (finales de los setenta), había una sala enorme de administrativos, seleccionados por su buena letra (sí, sí, es cierto, por su buena letra, seguid leyendo…), escribiendo a mano los títulos del propio banco: sus acciones.

Cada vez que alguien compraba acciones de aquél banco, alguien escribía con una perfecta redondilla que “D. Fulano de Tal  posee 27 acciones del banco Tal y Cual, adquiridas el día tal del año tal, y que le han costado tantas y cuántas pesetas, firmado y rubricado, etc”. No creo que tenga que decir que lo del “Mercado Continuo” no existía, ni los “Apuntes en Cuenta”, ni nada de nada.

En una palabra, si tenías tal documento, tenías las acciones, y si no… pues no las tenías.

Bueno, pues escribimos la nueva  Aplicación de Accionistas (bastante sencillita en cuanto a su lógica, como podéis suponer), que mantenía un fichero de Accionistas, con los movimientos del día se daban las altas y bajas pertinentes, y se imprimían los títulos escritos por la impresora del ordenador, con una letra no tan bonita como la redondilla, pero perfectamente legible.

No sólo se ganó muchísimo tiempo en el proceso, pues ahora todas las operaciones del día se imprimían durante la noche y se enviaban a los accionistas el día siguiente, sino que de la noche a la mañana, los setenta u ochenta amanuenses expertos en redondilla pudieron ser asignados a otros Departamentos u Oficinas… A eso me refiero cuando hablo de mecanizar un Sistema.

Pues bien, durante los setenta, ochenta y primeros noventa se habían mecanizado todas las aplicaciones mecánicas susceptibles de ser mecanizadas (y las que no, estaban en el proceso de serlo), y se estaban escribiendo ya algunas aplicaciones que llevaban bastante más “inteligencia” incorporada en ellas. Un buen ejemplo de ellas es el del acceso al Mercado Continuo Bursátil: ahora no sólo se trata de realizar y apuntar mecánicamente las transacciones, sino que los programas tienen que tomar ciertas decisiones, en función de las condiciones del mercado, el número de peticiones existentes, etc. Se trata de programas muy complejos, tanto los que hay en la propia Bolsa, como los de los Intermediarios Financieros que operan en ella.

Y lo mismo pasa con el Departamento de Riesgos… con el incremento tremendo de tarjetas de crédito en manos de clientes esos años, y de las operaciones realizadas diariamente, también se incrementó el fraude, así que hubo que escribir programas que autorizaran las operaciones sin intervención humana… y esos programas tenían que tomar decisiones, decisiones que, si son erróneas, cuestan dinero constante y sonante.

Este tipo de aplicaciones tienen unos requerimientos de obtención de información por parte de los usuarios que van bastante más allá de consultar cuántas operaciones se han hecho, cuántas se han denegado y cuántas se han concedido… Ahora no sólo hay que saber el qué ha pasado, sino que es imprescindible saber por qué ha pasado. Y este sutil cambio tiene una consecuencia inmediata: es virtualmente imposible anticiparse a las necesidades de información que tendrán los usuarios de este tipo de información en el futuro.

Pero es que ¡eso es exactamente lo que tradicionalmente pedíamos a nuestros usuarios!, que se mojaran, que nos dijeran, en periodo de Análisis Funcional (seis meses, o un año… o dos… antes de que la Aplicación estuviera disponible para su uso), qué listados y consultas debía obtener dicha aplicación, y además le pedíamos que firmara las especificaciones con sangre, porque cualquier cambio posterior le llevaría de cabeza al Infierno…(Eh, bueno, en realidad eso es exactamente lo que seguimos haciendo veinte años más tarde, pero en fin).

Y claro, la pura y simple realidad es que ningún usuario de estos sabe qué va a necesitar dentro de seis meses para averiguar por qué una Oficina vende más créditos que otra… (de hecho, tampoco sabe qué es lo que va a necesitar mañana), así que piden lo primero que se les pasa por la cabeza, lo firman… y a la postre, no les sirve de nada.

En realidad, a los informáticos se nos entrena desde el principio para este proceder ante nuestro usuario, que podemos resumir en la máxima: “Habla ahora o calla para siempre”, sólo que eso se lo decimos muchos meses antes de entregarle la aplicación funcionando. Y todas las Metodologías de Desarrollo habidas y por haber, Orientadas a Objetos, al Norte, al Sur o a donde sea, hacen hincapié, pero que mucho hincapié, en esta cuestión: las Especificaciones deben estar congeladas antes de comenzar a escribir el software. Como decía un insigne consultor que yo conozco, “Escribir software es como andar sobre el agua: es mucho más sencillo si está congelada…”.

Os voy a contar un secreto: hay muchas ocasiones en que es imposible que un usuario te pueda decir tales cosas, ni siquiera una semana antes de poner la aplicación en marcha. Y es más, cada semana necesitará nueva información que no se le había ocurrido, o que no había necesitado, con anterioridad. Cuando nos toca en suerte un usuario de este jaez, los informáticos tendemos a, primero enfadarnos con él, y luego catalogarle con frases como “Este Usuario es un cretino; no sabe lo que quiere”, y empezamos a ningunearle, ponerle excusas, marearle… con tal de que nos deje en paz. Pues, siguiendo con ese secreto a voces que os estaba desvelando, no es que ese usuario no sepa lo que quiere… ¡es que no puede saberlo de antemano! Es así de sencillo; duro para nosotros, los informáticos, pero sencillo.

Mi primer encontronazo con esta cruda realidad (aunque he de reconocer que entonces yo también llegué a la sesuda conclusión de que el usuario no sabía lo que quería; sólo años después reconocí los hechos), ocurrió a fines de los setenta, en ese primer banco en el que velé mis armas informáticas. Mi Jefe me pidió que atendiera al Responsable de Marketing del Banco, que necesitaba no sé qué listado. Entonces toda la información que se pedía al ordenador había que emitirla en papel, pues era la única manera de sacar información legible por los humanos de las tripas del Sistema.

He de decir que el Departamento de Marketing en ese Banco en 1979 era pequeño. Muy pequeño. En realidad, atendí al Responsable del Departamento, que se componía de una única persona: él mismo (por cierto, en todos los bancos de la época los Departamentos de Marketing tenían más o menos los mismos recursos… no como unos años después, o como ahora mismo, sin ir más lejos).

Bueno, pues lo que quería este hombre era un listado de clientes que cumplieran ciertas condiciones, para hacerles una promoción, ofertarles algo o no sé qué (tampoco me enteré muy bien para qué lo quería, por entonces trabajaba en el banco, pero no sabía nada de banca… después aprendí). Tomé cuidadosa nota de las condiciones, y me puse a escribir los programas para extraer la información y listarla, según el procedimiento que os conté en esta entrada. Como los ficheros estaban en cinta magnética, no era nada sencillo recuperar esa información: un programa de extracción, un buen Sort, un fantástico Padre-Hijo (otra vez sale a relucir el Padre-Hijo…) con el fichero maestro y, por fin, otro más de listado.

Uno o dos meses después, según cómo de cargados estuviéramos todos, los programas funcionaban y se ejecutaron. El listado resultante tenía metro y medio de altura. Lo prometo… Y estaba niquelado, de acuerdo a los requisitos solicitados y firmados por el susodicho Usuario de Marketing.

Le avisamos: “Tu listado está listo, ¿qué hacemos con él?”  “¡Uy, qué bien! Pero espera, que voy a comprobar cómo está la información…” Va y, según ve el volumen del listado, y antes siquiera de hojearlo, dice:

“Ah, pero no me vale, porque necesitaba como máximo diez o quince mil clientes y ahí debe haber muchos más…”  “Ehh… Sí, exactamente 368.476 clientes, que el programa los ha contado…” “Buff, son muchísimos, no, no me sirve… A ver, podríamos eliminar a los que cumplan esta y esta otra condición, pero añadir además a los nuevos clientes que tengan saldo mayor que tal y cual, y bla, bla, bla”.

Respuesta evidente e inmediata: “Pero… vamos a ver… ¿por qué demonios no me lo has dicho antes?” “Eeer, pues es que pensaba que habría muchos menos clientes que cumplieran las condiciones…”  “Ah, pero… ¡¡¿no lo sabías?!!! #$&@#!!” “Nooo…”.

Modifiqué los programas, bastante mosqueado, por cierto, puse un contador para contar de antemano, antes de listar nada, cuántos clientes habría… un mes más tarde y siete llamadas telefónicas después, para afinar la extracción (y asegurar que esta vez sí que valía), el nuevo listado estaba impoluto (y de sólo quince centímetros de alto) encima de mi mesa. Nueva llamada, y nueva conversación: Ahora no servía tampoco, porque habría que incluir a los que teniendo Depósito de Valores no tuvieran Depósitos pero sí más de una cuenta corriente, y bla, bla, bla…

No recuerdo si llegué a modificar de nuevo los programas, o se tuvo que apañar con el listado que tenía, o simplemente al final no usó el listado… Nosotros le catalogamos como persona non grata en Proceso de Datos, le relegamos al olvido, y él no volvió nunca a pedirnos nada (al menos mientras estuve yo trabajando allí).

Muchos años, y varias empresas después, comprendí por fin lo que ocurría: por un lado, su falta absoluta de información sobre datos tan básicos como cuántos clientes cumplen ciertas condiciones sencillas (el hombre realmente no sabía si había 10.000 ó 300.000 clientes que las cumplieran, lo que supone un rango de error realmente considerable), y por otro, las cambiantes condiciones de un mercado cada vez más competitivo hacen que la información que hoy es absolutamente prioritaria… mañana sencillamente no vale nada.

Nuestros estupendos programas eran capaces de abonar un dividendo con perfección matemática, calcular los intereses de forma exacta, y renovar los depósitos con precisión cronométrica… pero en realidad, no sabían nada sobre el negocio, sobre lo que de verdad mueve el negocio de la empresa. Así eran las cosas, amigos, y así siguen siendo en muchísimos casos.

Pues bien, después de todo este speech, resulta que los Usuarios de verdad, los que toman las Decisiones Realmente Importantes para la empresa, necesitaban una información de gestión de mucha mayor calidad (para la toma de decisiones de negocio) que la puramente transaccional. Y ya a finales de los ochenta, esto era tremendamente evidente.

Habíamos mecanizado las aplicaciones susceptibles de ser mecanizadas, sí, pero teníamos grandes carencias en aquéllas que requieren elaborar la información de manera diferente, acumular, extrapolar, obtener estadísticas que permitan a los usuarios oler las tendencias del  negocio, para anticiparse a posibles problemas… o a la competencia. Por ejemplo, los responsables de Riesgos necesitan continuamente conocer qué ocurre, pero sobre todo por qué ocurren las cosas, para adaptar los criterios de concesión o denegación de crédito a las cambiantes condiciones del mercado, o a la habilidad de los defraudadores para encontrar los puntos débiles del Sistema para sacar partido de ellos.
El resumen de todo esto: Las aplicaciones informáticas tradicionales no servían para estos menesteres; y aún peor, el propio método de creación de aplicaciones informáticas no servía para resolver estos problemas.

Ya desde temprano los fabricantes y consultores intentaron dar solución a esta problemática: a fines de los ochenta se puso de moda el concepto de Centro de Información. La idea era de dotar de así llamadas “Herramientas de Usuario Final” a los usuarios que tenían tales necesidades, y permitirles el acceso a las Bases de Datos corporativas a su albedrío. Esas herramientas eran productos microinformáticos con acceso a la información contenida en los ordenadores centrales, aunque había también alguna que funcionaba directamente en mainframe (como QMF, de IBM y herramientas similares de otros competidores, como SAS). Fue una mala idea.

Primero, porque si las Bases de Datos no eran Relacionales (y esos años había muchísimas), la cosa se ponía realmente fea; pero aunque se pudiera acceder, las herramientas usadas (Bases de Datos Microinformáticas, como Dbase II o III, por ejemplo), no eran ni muy potentes ni muy eficaces accediendo a la información contenida en, por ejemplo, un mainframe.

Pero además es que había un problema de base, puramente tecnológico, que desaconsejaba acceder directamente a las Bases de Datos de Producción: tal acceso no sólo tenía un rendimiento penoso, sino que además destrozaba literalmente el rendimiento de las aplicaciones transaccionales, que, cuidadas y mimadas como estaban, tan bien iban y tan buenos tiempos de respuesta proporcionaban… con las máquinas de la época.

Así que IBM comenzó a promocionar, dentro de su concepto de “Centro de Información”, que los clientes se compraran otro mainframe, y diariamente (o semanalmente…) duplicaran sus bases de datos corporativas, para que luego los usuarios finales pudieran acceder a ellas y manipularlas a su antojo sin comprometer el rendimiento del sistema transaccional. Una política muy interesante… para IBM, claro.

Incluso vendieron alguno; yo mismo, de hecho, estuve en Alemania, viendo cómo BASF había duplicado su parque de mainframes para dar acceso a sus usuarios finales con QMF… En España no coló. No conozco ninguna empresa que comprara nuevos mainframes exclusivamente para esto, aunque igual hubo alguna.

En cualquier caso, quizá os preguntéis que por qué no es bueno que a un mainframe (u otra máquina cualquiera) le venga tan mal que, mientras hace su trabajo normal, sus transacciones y su batch, alguien esté accediendo a las Bases de Datos con queries libres… Como la razón última de todo esto tiene muchísimo que ver con la propia filosofía de diseño de los sistemas, creo que es importante explicarlo bien.

Y para ello, me temo que no me queda más remedio que daros una conferencia… pero que será útil: en ningún sitio podréis encontrar lo que viene a continuación: es invento de este humilde informático vejestorio y pelmazo. Quizás sea una chorrada, sí, pero es mi chorrada… y a mí me parece que es importante fijar bien estos conceptos para que comprendáis todo lo que sigue. Empezamos…

Bien, un Sistema Informático cualquiera, entendido como el conjunto de un determinado hardware y un cierto software, configurado de alguna manera para sacar el máximo partido al hardware, tiene una cierta potencia agregada, definida como bien os plazca. Y por otra parte, cualquier Sistema Informático debe lidiar, simultáneamente, con tres tipos de cargas de trabajo:

1) El número simultáneo de usuarios a los que da servicio. Un ordenador monotarea sólo hace una cosa a la vez; mientras que un sistema diseñado para ser online deberá ser capaz de dar servicio a muchos usuarios simultáneos.

2) La complejidad de cada petición individual. Es decir, la potencia de cálculo requerida para dar servicio a cada transacción, programa batch, etc, a cada unidad de trabajo que se le solicite, en definitiva.

3) La cantidad de datos a los que acceder por cada petición individual. Una transacción online no debería necesitar acceder a muchos datos, mientras un trabajo batch suele necesitar acceder a muchísimos.

Si ahora representamos estas tres características en un sistema de coordenadas, obtendremos un espacio tridimensional como el de la imagen siguiente, con cada una de las cargas de trabajo en un eje, y es en ese espacio tridimensional donde debemos acoplar la potencia agregada del Sistema inherente a sus capacidades físicas, que podemos imaginarnos como un saco de arena que debemos distribuir en nuestro rinconcito particular definido por los tres ejes.

Pues bien, la configuración del sistema (sobre todo su software, aunque también su hardware) permitirá diferentes soluciones, dependiendo del tipo de trabajo al que queremos dedicar nuestro sistema. Es decir, cuando se configura la máquina estamos, de alguna manera, decidiendo cómo repartir la potencia intrínseca del sistema entre los tres ejes (o sea, cómo distribuir los granos de arena a lo largo de los tres ejes de nuestro rinconcito).

Así, un Sistema de Propósito General (un mainframe típico es el ejemplo más evidente) debe ser capaz de resolver bien un ambiente de cargas mixtas: por una parte será capaz de dar servicio a un sistema transaccional con muchos usuarios simultáneos online, pero en el mismo momento también estará ejecutando trabajos batch, todo con una cierta complejidad de cálculo. Es decir, en el caso de un Sistema de Propósito General, nos interesa que nuestra potencia esté regularmente distribuida a lo largo de los tres ejes, como muestra la siguiente imagen.

El pequeño cubo del centro (con su vértice, el punto más grueso, en la superficie de la figura mostrada) representa una posible distribución, con un cierto número de usuarios simultáneos, una determinada complejidad de cada transacción individual y un cierto volumen de datos accedido por cada una.

Evidentemente, si queremos dar servicio a más usuarios simultáneos, no hay más remedio que reducir la complejidad de cada transacción individual y/o la cantidad de datos necesarios para cumplimentar cada transacción; si deseamos, en cambio, ejecutar un proceso que requiera un considerable volumen de datos para completarse, habrá que reducir el número de usuarios simultáneos y/o la complejidad, etc. Y todo, claro está, hasta un cierto límite: los puntos de los ejes hasta los que alcanza la figura triangular que representa los granos de arena de la potencia agregada: no es posible llegar más allá.

Si necesitamos llegar más allá del límite (más usuarios, más complejidad o más datos a acceder), hay que tomar una medida radical: El sistema con esta configuración no nos sirve, y tenemos que conseguir otro que sea capaz de llegar más allá. Una solución obvia es incrementar la potencia del sistema en todos sus ejes de forma regular, o sea, echar, regularmente, más arena al rinconcito. Ésta es una solución muy utilizada en nuestros días: se pone más memoria, más disco y más rápido, se pone un procesador más potente, o más procesadores… y ¡hala!

El abaratamiento del hardware nos ha hecho vagos, más de lo mucho que ya éramos. Pero cuando el hardware era caro, había que estrujarse las meninges para obtener más rendimiento para problemas concretos, sin necesidad de adquirir más y más hardware… lo que además, en ocasiones, directamente no era posible.

Efectivamente, hay otra solución, también evidente (aunque mucho más difícil de conseguir): distribuir la arena de nuestro saco de otra forma a lo largo del rinconcito, echando más arena en uno de los ejes, a costa de dejar los otros dos con mucha menos, es decir: reconfigurar el Sistema para potenciar uno de los ejes, a cambio, obviamente, de reducir la capacidad del sistema en los otros dos.

Un ejemplo evidente son los Sistemas Científicos, diseñados para resolver complejísimos problemas científicos, como son la predicción del clima, la investigación genética, la simulación nuclear, etc. Requieren una potencia de cálculo enorme para cada tarea…  aunque con una relativamente escasa necesidad de acceso a datos, y donde apenas hay usuarios simultáneos; es más, es muy normal que haya solamente uno: muchos de estos sistemas de miles de procesadores son dedicados, y por tanto, monousuario.

En una palabra, un sistema de tal tipo necesita que nuestro proverbial saco de arena se distribuya a lo largo del eje de la potencia de cálculo, como podemos ver en la imagen siguiente.

Como sabéis, en realidad buena parte de los avances en la creación de los ordenadores fueron debidos a la necesidad de resolver problemas de este tipo. Entre ellos, el considerado quizá como primer ordenador moderno, Colossus en Bletchley Park, diseñado por un grupo de científicos entre los que se encontraba uno de los padres de la moderna informática: Alan Turing. Colossus fue diseñado ad hoc, para romper el código de las máquinas criptográficas usadas por el Ejército y la Marina Alemanes: Enigma. Este es un trabajo que ejemplariza la definición que antes hice: escasos datos, que se leen al principio del trabajo, que es intensivo en cálculos, en un sistema dedicado.

En el collage anterior, a la izquierda, la razón de tantos dolores de cabeza: la famosa Máquina Enigma, y a la derecha, Colossus en plena operación, y Alan Turing, debajo.

Lástima que Colossus fuera destruido al acabar la guerra… ¿a qué paranoico se le ocurriría tal cosa?, y eso que habían ganado la Guerra…

Durante los años de la Guerra Fría, sobre todo desde 1950 en adelante, los esfuerzos militares para mejorar el armamento o la inteligencia fueron muy intensos, y en muchos casos requirieron la creación de nuevas herramientas informáticas para realizar los complejos cálculos requeridos.

Por ello, estos superordenadores recibieron mucha atención (es decir, fondos) por parte de los Gobiernos, sobre todo del estadounidense.

En la década de los sesenta, la compañía norteamericana Control Data comenzó a construir ordenadores vectoriales, lanzando en 1964 el primer superordenador que es merecedor de tal nombre: el CDC 6600.

El ingeniero que diseñó esa maravilla, que era nada menos que diez veces más rápido que cualquier otro ordenador existente en la época, fue un tal Seymour Cray, que en 1972 abandonó CDC (que tenía serios problemas financieros) y fundó Cray Research, hasta finales del siglo pasado la referencia en supercomputadores vectoriales.

Su primer sistema fue el Cray 1, que tenemos a la derecha, con el propio Seumour Cray posando junto a él.

Cray-1 fue el primer ordenador que realmente explotó el proceso vectorial, obteniendo velocidades de proceso espectaculares para la época.

Su diseño estaba tan cuidado que incluso fue construido en forma cilíndrica, muy poco habitual en ordenadores de entonces y de ahora, con el objetivo de acortar los cables que conectaban las diversas partes del sistema (CPU, memoria, registros, etc). No es que intentaran ahorra costes poniendo menos cables (que, a lo mejor, también, porque llevaba kilómetros y kilómetros de cable…), es que así acortaban el espacio que debía recorrer la electricidad cuando circula (a la velocidad de la electricidad) entre componentes, reduciendo la latencia del sistema (y además, de paso resulta un diseño realmente bonito, para qué negarlo).

Años más tarde, a mediados de los ochenta, lanzó el CRAY 2, que era capaz de alcanzar una asombrosa potencia de cálculo de 1,9 Gflops.

Este sistema fue vendido masivamente a todas las Agencias Estadounidenses (incluidas, por supuesto, las más secretas, que fueron además sus mejores clientes, aunque no podía publicitarlo, pues era información “Classified”), Laboratorios, Universidades, la NASA, etc, y también vendió bastantes máquinas en Europa (en España, que yo sepa, no: ni sabríamos qué hacer con ella, ni creo que pudiéramos pagarla).

Tras el éxito de Cray, otras empresas se dedicaron a fabricar y vender ordenadores vectoriales de computación en paralelo, como Convex o Thinking Machines, en EEUU o NEC, Hitachi y Fujitsu, en Japón. Hubo un gran ruido vectorial en el mundo… pero no había mercado para tanto supercomputador, y sobre todo, la propia evolución de los sistemas normales fue comiendo el terreno a estos monstruos… que cuando hoy los miramos, nos parecen de juguete, pues cualquier ordenador normalito de hoy en día, incluyendo el que tú, querido lector, estás usando ahora, tiene seguramente mayor capacidad de proceso que cualquiera de estos superordenadores.

Eran máquinas especializadas (especializadísimas, diría yo), carísimas, y necesitaban de una cuidadosa programación, generalmente en Fortran, que tenía una extensión para optimizar el uso de las capacidades vectoriales de los sistemas; además, no todos los problemas se prestaban para su resolución en este tipo de Sistemas. Más bien al revés, pocos problemas se prestaban para sacar auténtico partido a estos superordenadores. Y desde luego, entre ellos no se encuentran los Sistemas de Proceso Online de la Información, los Sistemas Transaccionales de Alto Rendimiento.

Que yo sepa, los primeros Sistemas Online de Alto Rendimiento que se pusieron en marcha fueron los de reservas de las Líneas Aéreas, en concreto el sistema Sabre, realizado por IBM para American Airlines, a principios de los 60 del siglo pasado, y que en 1964 era ya plenamente funcional. La cantidad de reservas que era capaz de atender por segundo es ridícula comparada con las que hoy en día consigue cualquier Sistema, pero en la época, y con las máquinas de la época, era un reto de muy difícil solución.

En el diseño de este Sistema se tomaron medidas radicales, como por ejemplo, no mantener colas de transacciones de entrada. Las transacciones provenientes de los operadores de reservas, cuando llegaban al sistema, si podían ser procesadas, se trataban inmediatamente, pero si no, directamente se desechaban. Creo recordar que ni siquiera devolvían ese mensaje tan habitual hoy en día, y que tan felices nos hace cada vez que lo oímos, en tantos Centros de Llamadas de tantas empresas de postín, ése de “Todos nuestros operadores están ocupados, qué pena, penita, pena… haga Vd. el favor de volver a llamar a nuestro simpático 902 dentro de unos minutitos…”.

Volviendo a nuestro gráfico del rinconcito, estos Sistemas especializados en dar servicio a Aplicaciones Transaccionales de Alto Rendimiento requieren colocar la arena de nuestro saco de Potencia Integrada del Sistema lo más pegadita posible al eje del número de usuarios, para que este número sea el mayor posible… a cambio de reducir al máximo tanto el acceso a datos de cada transacción, como su complejidad. Lo que resulta es algo parecido a la imagen que tenemos a continuación.

A mediados de la década de los noventa, con el irresistible auge de internet de aquel tiempo, se comenzó a hablar en serio del “video-on-demand”, donde muchos usuarios, personas normales y corrientes como tú, lector y como yo, podrían conectarse desde sus hogares a un gran servidor de vídeo, sobre todo de películas, y solicitar el visionado de un programa, manejando la emisión como si estuvieras viendo un vídeo VHS como el que entonces teníamos todos: avance rápido, pausa, retroceder, etc. Se suponía que la capacidad de las líneas telefónicas iba a permitir ese ancho de banda en breve, así que empresas de comunicaciones, de televisión, etc, comenzaron a prepararse para este nuevo mercado, y también la tecnología se preparó.

Comenzaron a aparecer diseños de Sistemas Informáticos (hardware más software) que serían capaces de dar este servicio; recuerdo entre ellos a Tandem, que anunció una novedosa tecnología de nombre Servernet, que permitiría espectaculares rendimientos en proceso paralelo, y siempre con la fiabilidad que daba su probada tolerancia a fallos. No tuvo éxito: poco después Tandem fue comprada por Compaq, y nunca llegó a vender muchos sistemas Servernet, si es que vendió alguno, aunque su tecnología es la base del actual Infiniband.

Y otros fabricantes comenzaron también a introducir Sistemas de proceso en paralelo; hubo una cierta batalla entre los que abogaban entre sistemas del tipo SMP (procesamiento simétrico), con su arquitectura “shared all”, los de tipo “cluster” con arquitectura “shared disk”, y los de tipo MPP (Procesamiento Múltiple en Paralelo), con arquitectura “shared nothing”. No voy a entrar a describir las características de cada uno; los interesados podéis seguir los enlaces y leer la muchísima información que hay en la red sobre estos temas.

.

El caso es que los diversos fabricantes (prácticamente todos) comenzaron a mediados de los noventa la guerra por vender más y más sistemas de proceso paralelo, pero como los Gobiernos y Universidades, los principales clientes de los Superordenadores, no eran tantos, el resultado fue que en la segunda mitad de los noventa una tras otra todas las empresas que fabricaban superordenadores quebraron o fueron adquiridas por otras, como es el caso de Cray, que fue comprada por Silicon Graphics, o Thinking Machines, comprada por Sun.

No obstante, a todo el mundo se le ocurrió que algo había que hacer para vender muchas, pero muchas, muchas máquinas de este sofisticado tipo. Y la solución es obvia: que sean las empresas las que adquieran estos nuevos Sistemas. Fácil, ¿no? Pero, claro, las empresas, quitando alguna industrial, no necesitaban grandes ordenadores científicos… ni pequeños, ni ninguno en absoluto.

Pero sí que es cierto que seguía existiendo la necesidad de poder acceder a la información de negocio de la empresa de forma no estructurada, con “queries ad hoc”, y no había “Centro de Información” que valiera que de verdad resolviera el problema…

Así que la necesidad de las empresas e instituciones, nosotros, los clientes, vaya, de acceder libremente a la información de negocio se unió con la necesidad de los fabricantes de vender para subsistir… y en muy poco tiempo fue evidente para todo el mundo que necesitábamos un Data Warehouse… aunque en muchos casos aún no sabíamos que ése era su nombre, que de eso nos enteramos después.

Evidentemente, para obtener un Sistema Informático orientado para la resolución de esas “queries ad hoc”, se necesitaba distribuir la arena en nuestro famoso rinconcito de Macluskey,  de tal modo que  se favorezca el acceso a los datos… a costa de tener muy poca complejidad cada unidad de trabajo, y restringir el número máximo de usuarios a los que es posible dar servicio. El gráfico resultante es, como no podía ser de otro modo, el siguiente:

“Ponga un Data Warehouse en su vida…” se convirtió, alrededor de los años 1996-97, en el slogan de moda: si no tenías ya uno, te tildaban de antiguo, si no estabas pensando en construir uno inmediatamente (contratando a la habitual pléyade de consultores, of course), es que no te enterabas de nada… una historia que a mí me sonaba bastante… y supongo que, si habéis tenido la paciencia de leerme hasta ahora, también a vosotros debería sonaros…

Bueno, como suele ser habitual, la entrada es ya larguísima, así que cortaré por aquí. En la próxima entraremos a describir qué es en realidad un Data Warehouse, cómo se vendían, cómo se comenzaron a construir en España, muchos de ellos terminados en sonoros fracasos (porque, para variar, las cosas no eran tan sencillas como todo el mundo te las vendía)… y procuraré que sea más corta, en aras a conservar vuestra ya escasa salud mental, tras haber leído tanto desvarío de abuelete…

Disfrutad de la vida, mientras podáis.